[HTC Wildfire S] no.human.being:
Please read this post.

"Normally" the Radio determines how the phone's NAND is partitioned. The Radio is its own operating-system called Iguana running on a kernel named Pistachio. It is a so-called RTOS (real-time operating system), which is a class of extremely simple and basic "operating systems" for embedded use. It doesn't provide most of the things that a "full" operating system provides (like memory management, hardware abstraction by a driver layer, a file system, let alone user management, networking stack, ...), it just provides scheduling and that's it. Every "process" can directly access the hardware, as if it was running "on the metal" (with no operating system below) but multiple processes may run concurrently.

Since there is no abstraction, every software (including the operating system itself) must "know" where things lie in memory. All the addresses are physical and must be hard-coded at compile time, there is no "program loader" that could do dynamic relocation or even dynamic linking. Nothing, it's just not there.

Now all the phones I've seen so far are either running on RADIO-7.53.39.03M or RADIO-7.54.39.28M. In the first case, they are partitioned like the table at the bottom of the post I linked to indicates, while in the latter case they are partitioned like the table at the top of the post indicates. All of them .. just not yours. Yours is running RADIO-7.53.39.03M (that's at least what the version string in the RADIO firmware says) but the memory layout is more like on a RADIO-7.54.39.28M. I'm not sure whether it's exactly like on RADIO-7.54.39.28M but it's definitely not like on "every other" RADIO-7.53.39.03M.

Now for obtaining S-OFF, we have to know exactly where the code that we want to patch lies in memory. So the exploit checks that certain key-pieces of code are in the right places and expects that some pointers point to some specific addresses and so on. And then it decides that it's either RADIO-7.53.39.03M or RADIO-7.54.39.28M and will then perform the patching at different physical addresses. However, your Radio claims to be RADIO-7.53.39.03M, but it doesn't expose the memory layout of RADIO-7.53.39.03M. Currently we're unable to patch such a thing. Either it's RADIO-7.53.39.03M or it's not. We're currently not supporting things that are "in between".

Your dump is 50.069.504 bytes long (this is how long a RADIO-7.53.39.03M should be) but your actual Radio is smaller. The Radio's code section ends before the dump ends. Your dump goes a bit "beyond" the Radio section as your Radio has an "exotic" memory layout that we cannot recognize yet.

@all the others: Testing went extremely well. I've done the reading from the "true" mtd and the writing to "image files" with the exploit run on the actual phone hardware, reading from the actual NAND (but not writing to it yet, I'm too afraid :D ). We don't need "dd" no more. Remember we already have this "patch" function which opens two file descriptors, reading from the one, writing to the other and then patching the values we want to change on the fly while copying the data blocks over. I've just put a switch into the routine for disabling the patching and then it's more or less the same as "dd". :D

Advantage is that we don't require a working "dd" on the recovery and that we can better react to errors should they occur, e. g. abort the process when an error occurs during the patching of the dumps on the SD card so that we don't write "junk" back to the actual NAND.