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 us. In a previous 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).

Hello all, so the code in the first post is STILL not updated, even though I posted over a year ago saying "I'll update it when I've cleaned up the code". Someday, I swear....

Anyway, I've made headway on the segfault issue, albeit not actually solved it.

This is all thanks to freemangordon having created opensource libcal (which, BTW, works beautifully for me so far - my development N900 is running with that libcal installed over the stock one with no issues for days now [Edit: well... it worked once I fixed a single missing #include in the cal.h file]. One thing to note - the gcc version built for ARM in the sdk repo, when installed on the N900 (as opposed to scratchbox) is NOT capable of building the library, thanks to some bug in that ARM version of GCC with compiling dynamic things; so it needs to be compiled in scratchbox - I have not tested with the gcc-4.6 that's in the extras-devel repo to see if that does any better).

Long story short, libcal uses semaphores, as provided by semaphore.h. The function sem_open(), specifically, is what is causing the segfault. That's in the semaphore.h library, which means the problem is way deeper than my code, or even libcal code. I guess so early in the boot as my preinit shell, the kernel/OS simply isn't set up enough to even allow semaphores to be used properly.

Two potential workarounds come to mind. 1) figure out how to proceed the boot the minimal amount needed to get working semaphores, and package that with the code - catch segserv (or whatever the segfault error signal is), and run that code in response, or just leave it to the user to run the required stuff (either shell script or built into the rdmod binary invoked by commandline flag). OR 2) rewrite the relevant aspects to NOT use semaphores, build that version of libcal statically into rdmod, and then have it invoke the statically included versions of the functions when it detects semaphores aren't available, under the assumption that so early in the boot nothing else that could access rdmod will be running at the same time.

Further investigation path before I do anything else tho: Figure out why the stock cal-tool, that lets you get r&d mode flags, isn't segfaulting still (if it does with the new libcal, that means the new reverse-engineered libcal isn't 1-to-1 with the old libcal; if it doesn't, then it's worth looking into why cal-tool doesn't fail, or if it's even using libcal at all (or if it just doesn't use it at all)).

Don't expect further progress by me for the next week or two (or more, who knows with my busy schedule and unpredictable direction for my bursts of motivation), because collegiate work and actual work (not that anyone cares, but I got a job as a parttime job as a programmer about two weeks ago: which means I have much less time to donate to community but more more money to donate to members thereof, yay).

But yeah, this is promising. And I felt like updating you guys.

@Mentalist Traceur - check if you have /dev/shm mounted by the time the segfault occurs