[HTC Wildfire S] no.human.being:
Right. The PBL is not HBOOT. It's part of the processor's internal firmware, that cannot be modified. It's stored in a true ROM. It's not NAND, so it can never be rewritten, its contents are fixed at manufacturing time.

We don't have to modify this SBL (Secondary Boot Loader) either, so the fact that it's signed doesn't change a thing. What we modify is HBOOT, also called APSBL (Application Processor Secondary Boot Loader) and this one is not signed. All that's running "before HBOOT" (except Radio firmware) is from ARM Ltd. and the components all cross-validate each other, so we can't tamper with them. But we don't have to tamper with them either, as none of them have something to do with the secu_flag.

Yes. The point is that Radio has exclusive control over the NAND until HBOOT is started. At this point, control is "handed over". When the Radio wants to access NAND after HBOOT has started executing, it has to wait until the operating system kernel (Android kernel) is booted up

and can then make remote-procedure-calls to the Android kernel running on the application processor to access the NAND!!!

This interface is there and it is documented in some places.

So once that HBOOT has started, Radio is "out of control" concerning NAND and Android (or whatever kernel we have booted via Fastboot) is in control, so essentially with a custom kernel we can actually do whatever we want. This is what we exploit for patching the HBOOT to S-OFF in NAND.

No. The Radio won't intervene the direct NAND access of our kernel. See above.

Yeah. ARM is a "fabless" semiconductor company. It doesn't manufacture semiconductors, it just "designs" them and then licenses these designs (called "IP cores", "IP" as in "intellectual property") to licensees (Qualcomm, Samsung, STM, TI, ...) that manufacture them.

The MSM7227 is a "System on Chip" containing an ARM1136EJS (where did you find that it's an 1136JFS?) and an ARM9xx (wasn't sure about that one, but seems like you found it's an ARM926EJF) in a package.

The ARM9 is called "baseband processor" and it runs (after some "initialization code" from ARM Ltd.) the so-called "Radio firmware" that's talking to the transceiver. Google has licensed the "Radio firmware" for use with Android from an Australian research corporation called NICTA. NICTA in turn got them from University Karlsruhe, Germany. So originally this all came from University Karlsruhe, Germany.

The "Radio firmware" consists of three components. A microkernel called "Pistachio" and an operating system called "Iguana", as well as the so-called AMSS (Advanced Mobile Subscriber Software). "Pistachio" and "Iguana" are open-source, AMSS is proprietary I think.

The ARM11 is called "application processor" and it runs (probably again after some "initialization code" from ARM Ltd.) HBOOT (also called APSBL, Application Processor Secondary Boot Loader). The HBOOT further initializes the controller, then loads the Android boot image (basically a concatenation of some metadata + kernel + initrd) into RAM, either from NAND or via USB with Fastboot protocol, then executes it.

That's what I was looking through. You can just google for it and it'll show up on ARM Ltd. web presence. So this one is not "leaked" or "stolen", it's actually public.

It can't be touched with a "stock" Android/Linux kernel, as the contents of the memory are in a different format than Android/Linux expects. Apart from the data you see in the NAND, there's also a so-called "out of band area" that contains some "extra" bytes for each page for internal use by the NAND.

So when you read a page from the NAND using "fread(...)" you're going to see 2 KiB. However, you can also do some special "ioctl(...)" calls to the kernel (not sure how these are done) to see the "out of band" area attached to this page. This area will be much smaller, say 40 bytes (it's a figure I made up, if you really want to know you'll have to search the datasheets of the NAND).

So "physically" each page is 2 KiB + 40 bytes, but if you "fwrite(...)" only the 2 KiB are written and then the kernel moves on to the next page. Similarly if you "fread(...)" only the 2 KiB are read and then the kernel moves on to the next page. So under normal circumstances you never see the "out of band" area (that's why it's called "out of band" :D ).

The "out of band" area is used by the kernel (and I think also by the NAND chip itself) to store "meta information" like parity information and ECCs (error correction codes), statistics about how "worn" the page is, etc. For the Radio partition (that HBOOT is part of), this "out of band" data seems to be "corrupted", so it's either not in a format that a Linux or an Android kernel expects or it's designed to intentionally "distract" the kernel, telling it that the NAND is totally worn in this area. This is why your operating system kernel will refuse to erase the pages and/or write to them (beware that writing to a page that is not erased is an operation with undefined results!). This is why the memory can't be "touched" from within Linux/Android. If you want to touch it, you probably have to somehow "adapt" the kernel to the special memory format that the Radio partition uses. At the moment, we're also stuck at this point. Making the kernel "ignore" the out of band area will be enough to enable write access to it. But perhaps we actually have to implement the "special format". Otherwise the Radio might not "understand" what we have written.

Lol that one was good! :D

Fire up "gedit", then paste in the following.

#include <stdio.h>

int main(int argc, char** argv)
{
printf("Hello World!\n");
return 0;
}

Save as "hello.c", then fire up a terminal, "cd" into the directory where you put your source, compile (toolchain expected to be in your $PATH).

arm-none-linux-gnueabi-gcc --static -o hello hello.c

This will produce a binary. Upload it to phone (adb expected to be in your $PATH).

sudo adb start-server
adb push hello /data/local/hello

Start remote-shell with phone and execute.

adb shell
cd /data/local
./hello

Disconnect again and kill the server on the phone.

exit
sudo adb kill-server

Simple, huh? :D

EDIT: Btw, 2000th post. :D