Just a few notes (my C is also a bit rusty, but it's still there

With cal_read_block() both tmp and len are initialized. rd_mode_string is, at that point, still not initialized (i.e. not a valid pointer).

Then you do if((len < 1) && !rd_mode_string) { ... }

so in principle this is invalid. I guess you want if( (len<1) || (tmp == NULL))

because it's tmp and len that get initialized/assigned by cal_read_block().

The && is important. It should be || (OR). Because, assuming rd_mode_string is hopefully initialized to NULL, you're only exiting if len < 1.

So it can happen that you're actually trying to read from tmp (rd_mode_string) when it's still NULL or uninitialized -> SIGSEGV!

I can't compile anything now (can only do useful "work" here when I'm at work, i.e. no compiler; at home I have the compiler, but no time

Try fixing those bugs.(I only looked at the "-q" code path) and post another compiled binary and I'll give it a try!

5 months and much C experience later, I finally return to this. Funny how instantly clear it is why it's segmentation faulting in one of the situations now...To everyone, reinob especially, I apologize for the delay in getting back to this. Life, busy, etc. The usual.

You may notice that right under the problematic (len > 1 && !rd_mod_string) if-then brackets, I had rd_mod_string = (char *)tmp;

My understanding is, originally (in qwerty12's RD Control program, which I derived most of the meat of this program from), that line was in front of that if-then statement, and at some point back when I understood what I was doing even less than I do now, I moved it down not realizing it would mess things up.

After brief though, I've decided to change the if statement to (len > 1 && !tmp). This is, in my opinion, keeping in line with qwerty12's original logic, and at the same time, might possibly save an instruction cycle or two, because I'm not assigning tmp's value to rd_mod_string until after we know tmp is not null. I'm hesitant to switch to an || instead of &&, because if qwerty12 didn't do it, he probably had a decent reason... maybe.

With this fix, it fixes the segmentation fault on 'virgin' N900's - that is, ones that /never/ had their cal areas' R&D mode flags set. But it does /not/ fix the segmentation fault that occurs in my /sbin/preinit ebedded recovery shell.

@Mentalist Traceur,

Just some off-line debugging.. maybe my comments don't solve anything, but as a "past" C programmer there are some things that hurt my eyes.

Before calling cal_init() I would first initialize cal_s to NULL. We don't know what libcal does exactly, so better to be on the safe side.

Then, before doing cal_read_block make sure that cal_s is not NULL. Otherwise cal_read_block will most likely segfault.

Same with cal_finish(). What if cal_finish expects a non-NULL pointer but cal_read_block actually handles a NULL pointer by merely returning a negative value? I bet 10$ that cal_finish does free() at some point, and we all know what happens (or what should happen anyway) when you free a NULL pointer.

Now, AND and OR. Obviously we don't know what libcal is doing, but it is supposedly writing something to tmp *and* returning a length, presumably of the data being written to tmp, meaning tmp may not necessarily be NUL-terminated (i.e. not a standard C-type string), meaning strcpy() might freak out and write more than 128 bytes to rd_mode_current, meaning that .. well, I don't have to explain that do I?

So, to be on the safe side, use strncpy making sure that you write at most 128 bytes (or sizeof(rd_mode_current)/sizeof(char)) and preferably len, i.e. min(len, 128).
Then put a zero at the end just for security. rd_mode_current[min(len, 128)] = '\0'.

And before that (AND/OR), I would still do if(len < 1 || (tmp == NULL)), as you probably would only continue if len > 0 and tmp is not NULL.

Namely, if for any reason (did I say we don't know what libcal does?) len > 0 and tmp is NULL strcpy() will also segfault.

That's it for now. I'd suggest you add a lot of printf()'s to aid in debugging. Or use assert() wherever you assume something.

e.g. before doing strcpy(a, "hello") put assert(a != NULL). This way you will see the truck before it hits you

Slightly off-topic.

I just found this:
Calvaria - Maemo CAL partition variable access tool.
https://dev.openwrt.org/browser/pack...src/calvaria.c

Not exactly R&D mode settings, but can apparently parse the CAL partition.

This is interesting to follow. Infrequently having to do code analysis during my day job (albeit on a level more abstract), i appreciate your efforts.

@don_falcone,

I also find it very interesting.. but at least we can do code analysis with the source in front of that. In a previously life, I used to do that using a hex editor (long live HIEW and MS-DOS in general!), and I actually developed a sort of "talent" for cracking shareware without even bothering to use a debugger.

I'll see if I can get some time to inspect libcal.so. Nowadays people are very sloppy and leave debugging symbols all over the place..

Quick update: When I last posted here, the state of affairs was such:
1. Segfault when using this program from the /sbin/preinit point in the boot process.
2. Unable to set/read R&D mode on an N900 that has NEVER had R&D mode set before in it's lifetime (but at least it no longer segfaulted in such cases, as was the case in the last precompiled binary I posted on this thread).

I have just gotten back to this yesterday, and as of earlier this morning, I was able to turn on R&D mode on the N900 I had which, until that point, never had R&D mode enabled on it. Rebooted to confirm it worked (it did), and then turned R&D mode off and rebooted to confirm that worked. Success. So issue 2 is near as I can tell, fixed, but still need to figure out the cause for issue 1. But I consider this a major achievement, in that it makes this FAR more useable for it's intended usecase of letting people turn on R&D Mode on-device (and if you depend on flasher to do it for the 'first time', that's a large amount of scenarios where this tool would be useless).

I will update the source in the first post once I've cleaned up the logic of the code better (and once I get around to it after that). Right now I just took a gamble that you could write to the cal area even if the other two functions for reading the contents of the libcal area return 'false's, and just commented out the return statements in those if blocks - this seems to work just fine, but as a result, the code needs rearranging, me thinks.

IT *IS* A MAJOR ACHIEVEMENT.

Thanks a lot for continuing to work on this. I have an N900 waiting for you to post the program

(Oh, and I will do my best to test and debug if/why it works/doesn't work during preinit).