[HTC Wildfire S] no.human.being:
It's the CPU. Qualcomm is the manufacturer, Snapdragon is the processor line, MSM7227 is the part number. ARM1136EJS is the part number of the "processor design" from ARM Ltd. on which the chip is based. Basically ARM Ltd. creates "reference designs" and other companies manufacture chips that are based on ARM's chip design. ARM Ltd. itself is "fabless", which means that they do not have the facilities required to manufacture semiconductors themselves, they only develop them and let other companies manufacture them.

Qualcomm manufactures ARM processors, calling them Snapdragon, but almost every semiconductor company manufactures them. Texas Instruments calls them OMAP, nVidia Tegra, Intel XScale, Samsung Hummingbird and Samsung Exynos, just to name a few.

Qualcomm took the processor design from AMD which "sold" theirs to Qualcomm, so originally these were AMD chips now manufactured by Qualcomm. However, they have nothing to do with the notebook, desktop and server processors manufactured by AMD.

Yes, C is the choice for system level programming and exploits (which is what we're doing here) and the entire "system level code" (like Android kernel and Radio firmware) running on our devices is written in C. Java is good for developing apps though if you want to take a look at this. Our S-OFF thing certainly won't involve any Java code though. Some knowledge about ARM's assembly language will be useful if you want to reverse-engineer stuff. The assembly language is basically a human-readable form of what the processor does so each instruction for the processor will be encoded by one statement in assembly language.

The Radio firmware is actually a complete operating system called Iguana, that's based on a kernel called Pistachio. Both, operating system and kernel, were developed by an Australian research corporation and licensed by Google for inclusion into Android as the firmware for baseband communication duties. Iguana and Pistachio are open-source by the way, but the code that's running on top of this operating system is proprietary. It's called AMSS (Advanced Mobile Subscriber Software). The bundle of Pistachio + Iguana is called REX (Realtime Executive). The bundle of REX + AMSS is what we call the Radio.

When the phone is booted, the processor's firmware loads Radio and HBOOT into memory. Radio is booted first and has exclusive control over the NAND at this stage, while HBOOT is completely halted. As soon as Radio has finished initializing, it gives up control over the NAND and signals the processor's firmware, which then "unlocks" HBOOT. From this point on, both Radio and HBOOT will run "in parallel" on the device. HBOOT will then claim exclusive control over the NAND to load a kernel (Android boot or recovery image or our kernel :-D ) into RAM and jump into it. From this point on, Radio and Android will run in parallel on the processor. Communication between Radio and HBOOT/Android is possible since they both run on the same processor and within the same address space and can therefore communicate via shared memory regions in RAM.

It's also important to note that system level code will run in a "privileged" (or "supervisor") mode on the processor while non-system level (application level) code will run in an "unprivileged" mode. The processor supports "trapping" certain instructions (like memory access), passing execution to "privileged" (kernel) code whenever they are executed from an unprivileged (application) context. This is why it's so important that the system level code is trustworthy. An untrusted kernel can actually trap almost every instruction our application wants to perform and do something else instead without us noticing. So we can say "read at address 0x25323594", that instruction traps, the kernel reads at addresss "0x3bc34fff" and returns what's there and we'll never know. This is actually done by the operating system all the time (even by Linux :-) ) but normally it's not used for "malicious" purposes but simply to "isolate" the processes from each other and giving each process the impression that it is totally alone on the system and can use the entire RAM for its own purpose, while in reality the RAM is of course shared between multiple processes. So when two processes want data to be written to say 0x00008000, the operating system will intervene and store both at different addresses in RAM and store metadata to know which process has which data mapped where in the RAM, so that it knows where it has to retrieve the data from when the process wants to read from that address again (of course for this purpose the memory read must also be trapped). It's called "virtual memory" and the first two letters of the Linux kernel's default filename "vmlinuz" (the "z" at the end is not a typing mistake!) are an indicator that the kernel makes use of this facility. Like I said this is normal behaviour for an operating system, but you can see that the operating system might also use this facility in order to "hide" memory from application-level processes. This is one of the reasons why it's so important that the operating system is trustworthy.