yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
Here the design of Radio and Android communicating via Remote Procedure Calls via shared memory and interrupts is explained. It's pretty much what we expected.

Here the commands that Android can issue to the Radio are documented. Note the commands "emmc_pgdump" (eMMC page dump) and "emmc_pgwrite" (eMMC page write) which are probably for reading from and writing to persistent storage on eMMC devices. I expect that there are similar commands for NAND devices, most likely along with a third "pgerase" call since NAND has to be explicitely erased before being written to, while eMMC does not.

So it seems that Android is actually not permitted to access persistent storage directly (not even reading). Instead, it can only read from and write to a buffer that's shared between Android and Radio and then has to issue an interrupt to the lower level firmware and have it perform the actual operation on the NAND. Quite obvious why we can't erase the Radio area, huh? :D
[HTC Wildfire S] tacromx:
Does that mean it can only be done through hardware?, or can the exploit be re-written to acces the nand via the smem and would the radio allow such a command?.

I'm off to research. ;)
[HTC Wildfire S] no.human.being:
Well it depends. Up to now we always thought that HBOOT was flashing the Radio while installing an RUU or an OTA update and that HBOOT will check the signatures. That would mean that the system can be broken, since HBOOT and Android both run on aARM and in Security Domain 3. We'd have to figure out how HBOOT "authenticates" with the Radio to get permission to write to the Radio area, then implement this mechanism in an Android kernel. So rule of the thumb is "if HBOOT can do it, then Android can do it as well" (at least in principle).

However, note that the Radio has an "ruuwrite" command. This indicates that it's not HBOOT that is writing updates to NAND, but the Radio itself. Remember that we always assumed that signature checks are performed by HBOOT, not the Radio. This would mean that the Radio will flash whatever HBOOT asks it to flash and this in turn would mean we can flash a modified HBOOT by making Android ask the Radio to do so. However, we will have to find a way of getting access to this communication mechanism for talking to the Radio.

Here is an article about how communication between the aARM and mARM works at the lowest level, explaining a bit of the data structures involved.

Also note that the Radio is provided by the SoC manufacturer (so in our case Qualcomm) and is processor-specific. It is not specific for the device manufacturer, so there's no such thing as an "HTC Radio", there's just a "Qualcomm Radio". This proves that the secu_flag is indeed not specific for HTC devices. It's just that HBOOT "exposes" the feature visibly by showing the "S-ON" or "S-OFF" message at boot.

Btw, is it possible to flash custom Radio firmware and custom bootloaders on dev-phones like the Galaxy Nexus or is it just that these devices get their firmware directly from Google instead of the device manufacturer?
[HTC Wildfire S] tacromx:
@NHB...

Galaxy Nexus....

"When you use odin (the tool from samsung.de) you are limited to flashing the 4.0.1 build. If you would have used fastboot, you could have flashed the full 4.0.2 image from Google’s site, and there would be no need for the OTA update…Additionally, odin forces you to flash a bootloader, a radio, and a recovery, as well as the ROM. With fastboot, you don’t have to.

After flashing to yakju build, you can still receive notification of the OTA updates.If you have flashed the radio, system, userdata and boot partitions, and you still have the stock recovery (or have flashed it) from the 4.0.2 image, you will be able to install the updates. However, if you flash a different radio, or different kernel , or a custom recovery, you will need to flash back the stock ones first before being able to install the update."
[HTC Wildfire S] theq86:
We can actually "speak" to the radio directly using a serial connection via USB. It is possible to issue commands but still we don't know how to "authenticate" as a privileged service.
[HTC Wildfire S] tacromx:
@ theq86

Could you please elaborate?
[HTC Wildfire S] no.human.being:
The question is, could you flash a "custom" bootloader (e. g. UBOOT) or a "custom" Radio (say you built a Radio yourself from the Pistachio/Iguana sources) or can you only flash firmware signed by Google? I mean it's clear that you can flash custom ROMs since it's a dev-phone, but the question is if you can alter the lower-level firmware as well or if it's basically just like our "bootloader unlocked" phones.

There is the possibility to somehow connect to the phone and have it appear as a tty device under Linux. This device can then be used like a file handle, so you can "fopen(...)" it (from the computer, not the phone) and "fread(...)"/"fwrite(...)" on it and everything that you write will be interpreted by the Radio firmware until you "fclose(...)". This device will essentially act as some kind of "remote shell" to the phone's low-level firmware.

I'm not sure what you have to do exactly to get to this point, but as far as I know it involves a bit of hardware, so it's not exactly a software-only solution, but the required hardware should be relatively cheap. I think you had to put a TTL level shifter between the computer and the phone's MicroUSB port or something like that. (Please correct me if there is a software-only solution, theq86.)

Another question, theq86. Is this serial interface to the Radio really the same that Android is using for talking to the Radio? I don't think it is. The interface between Android and Radio seems to consist of a few hundreds (or thousands?) of distinct "channels" that both systems are regularly polling and through which large blocks of data can be exchanged which are then interpreted like function calls in an RPC-like protocol. On the other hand, the tty interface is basically a single serial channel that acts like a shell. Not exactly what you would use for pushing large amounts of binary data (e. g. RUUs) to the Radio. I'm not sure whether both interfaces expose the same functionality.

EDIT: Btw, it seems you can issue the command "AT@SIMLOCK?AA" over the tty interface to query for the secu_flag and "AT@SIMLOCK=7,0" to turn the phone S-OFF. Not sure if you have to authenticate for enabling these commands.
[HTC Wildfire S] heavy_metal_man:
Well on the sensation, once you have s-off you can re-inable the security with a fastboot command, so why not s-off. Since I have the xtc clip, I might try flash the revolutionary hboot to gain fastboot commands and then see if I can command the phone back on. If so then maby that's what the xtc clip does, fastboot commands without the fastboot :D
[HTC Wildfire S] tacromx:
i have made a mod to the standard usb cable, 619kohm resistor between pins 4 and 5, modified the qualcomm drivers to load on serial port. downloaded and installed mtty 1.42, i have comunication to my phone but was unaware of the commands "AT@SIMLOCK?AA" and "AT@SIMLOCK=7,0".

The commands i tried were "set 14 0" and "task 29", but all i got in the console was "not allowed"

Ill try with the simlock commands but i doubt very much if i will get any different result.

****UPDATE****

tried the command AT@SIMLOCK?AA

Now i have a "hboot>" with a flashing cursor

tried AT@SIMLOCK=7,0, it accepts the command, but nothing appears to of happened.

Any other commands i can try??

tried ? at promp and get this...

command list

get_identifier_token

keytest

heap

boot

reset

powerdown

rebootRUU

heap_test

lock

rtask

task

enableqxdm

gencheckpt
[HTC Wildfire S] theq86:
There is no need for a piece of hardware. what you have to do beforehand is to disable some kernel modules because higher level drivers overlay lower levels. (i.e. disable mass storage driver)

No, it is not the same.

the tty interface is also for controlling modem functions. it may not be the complete rpc api

Right, you can use these commands to get/set secuflag and simlock. But it needs a kind of authentication. I tried some time ago successfully connecting to the radio tty. But all write commands regarding security were blocked. I can't remember the exact error message but it was something regarding privileges.

---------- Post added 19th May 2012 at 12:04 AM ---------- Previous post was 18th May 2012 at 11:59 PM ----------

your hboot prompt is not the radio prompt.

the hboot commands are actually all those you can also issue via fastboot. just that you have a different connection mode.

the radio prompt will let you send real modem AT commands.
[HTC Wildfire S] no.human.being:
You are talking to HBOOT, not Radio. You have to make the Radio take over the tty. The command for doing this is "rtask C" (on the HBOOT shell). Your connection to HBOOT will disconnect. Afterwards, you should see a device named "Qualcomm" in the "lsusb".

Authentication = engineering SIM? Probably what the xtc-clip's DIAG file does is set off this command. Would be strange if there were multiple ways of doing the same thing, right?

I've heard you can talk to the Radio from within Android via a device called "/dev/smd0", so I tried the following on the phone.

echo -e "AT@SIMLOCK?AA\r" > /dev/smd0; cat /dev/smd0

However, nothing was returned on the device.
[HTC Wildfire S] meanmug:
Can someone verify that the AT commands work in fastboot or just hboot?
[HTC Wildfire S] tacromx:
I can only get it to work in Hboot
[HTC Wildfire S] meanmug:
I think the xtc-clip uses a jumper(inside the clip) to offset security at the time the diag file is flashed, that would be the only reason the sim slot is needed.

Also anything that can be done thru the sim slot could also be recreated thru usb.
[HTC Wildfire S] tacromx:
here are the possible cryptographic signeatures found in .bin file of the stm32f103cbt6 from xtclip

0x00001AC0	SHA2 table

0x0000CA44	SHA2 table

0x0000FFB8	DES RAW Spbox

0x0000CF44	AES sbox1 MUGI/SCREAM

Possible algos little endian: 4

0x0000CB44	AES te

Possible algos big endian: 1
[HTC Wildfire S] no.human.being:
Don't think so. The DIAG file says something like "Unlock SimLock and SECU_FLAG by smartcard OK", so I think it emulates a smart card, which is basically a small cryptoprocessor.

How? You know that CDMA phones can be S-OFFed via DIAG file and it was said that GSM phones cannot because they require some sort of "engineering SIM" to be present in the SIM slot. If we can emulate this SIM via software "through USB" (however one whould do that) we can use the DIAG file to gain full Radio S-OFF.

The STM32F103CBT6 is an ARM Cortex M3 (ARMv7).

Will you actually need the resistor between 4 and 5? Since theq86 said ...

Also, does anyone know an answer to my question two pages back, whether you could flash custom bootloaders and Radios on a Nexus dev phone or is it just that these phones can be bootloader unlocked at will and will get updates directly from Google without the handset manufacturer intervening?

EDIT: Btw, UBOOT has already been built for OMAP, the SoCs in Samsung phones, and seems to bring them up successfully. See here.
[HTC Wildfire S] seaskyways:
S-OFF maybe can be simply achieved !

GUyyssss !!!! The sensation xl guys just got the S-OFF via flashing a modded hboot , just like us ! they were totally S-ON with no developed exploit of anykind !! they have NAND based devices as yours !! Check this thread here !! now please !! maybe we have finished !
[HTC Wildfire S] theq86:
Where you have the info from that Sensation XL also has NAND?

Sensation XL's hboot shows it is an eMMC based device. That means that any exploit for SXL will not work with our devices.
[HTC Wildfire S] *se-nsei.:
Can someone give me an idea of the progress we've made so far? The OP needs updating, and I need to know too. :p
[HTC Wildfire S] seaskyways:
The guy that made the thing said something like ," I don't have a nand lock maybe you have a nand lock and might not work ..." So i thought it is a NAND device ... well , maybe you can call his help after he's finished !
[HTC Wildfire S] heavy_metal_man:
We all have nand devices, the difference is mtd and emmc devices.
[HTC Wildfire S] Antagonist42:
Would I be right in thinking that it would be the MMU for the NAND that would actually write the data to NAND?

If so would I be right in thinking that maybe data to be written to NAND is really written to the MMU which may operate as emmc, the only difference being what the DATA is written to afterwards, with that in mind could MMU writing to the NAND be influenced by a clock frequency so say in normal operation a clock frequency of 37,400 but to write to NAND is maybe jacked up to 38,000 thus a slower clock speed the MMU fails the NAND writing sequence, as clock speeds can be altered and most of the clocks control is either set up or monitored by mARM and that's how a FOTA can update without you having to invoke it as MARM can send phone to shutdown by altering clock to aARM.

I can only surmise this as I'm only finding emmc/mmc writing files and others to set pid's USB ports/channels and frequently settings.

Rooted Xakep E320/C6 EUU Hacked Update
[HTC Wildfire S] cadam11:
S-OFF

mine says inject not found why is this
[HTC Wildfire S] cadam11:
[ LOG ] Step 1: Reading from mtd ...

[ LOG ] Step 2: HBOOT analysis ...

[ LOG ] Incorrect base signature for HBOOT-1.08.0099

[ LOG ] Incorrect base signature for HBOOT-1.09.0099

[ERROR] Failed to detect HBOOT!

/sdcard #
[HTC Wildfire S] heavy_metal_man:
to op, can you update the op stating that the exploit in its current form does NOT work and people shouldnt try it and hope. this thread is getting filled with more and more people asking why it r no work! lol cheers.:D
[HTC Wildfire S] Antagonist42:
Lol if they actually read it and not glanced over it it's perfectly clear it is not in any way in a finished state and not able to effect S-OFF but trials and tests the writing sequence....Stick this at the end of first post...

SO DON'T ATTEMPT TO RUN IF YOU THINK THIS WORKS. :D

Rooted Xakep E320/C6 EUU Hacked Update
[HTC Wildfire S] rezo609:
I'm not sure what this is but I found it in the phone. It has something to do with the mtd partitions except mtd7 .

mtd.zip: http://db.tt/wM3zEtrg

MD5 sum: de5b5be8b798a8d241d57dc9494e9bf7
[HTC Wildfire S] theq86:
those are only the device files found in /dev and some other files. they are not very useful though ;)
[HTC Wildfire S] :
Who remembers rezo's daredevil act?
[HTC Wildfire S] theq86:
I made a simple graphic and table with the wfs partition layout (latest software)

Just to remember and refresh our minds. :D

Visual partition table.

Partition table
[HTC Wildfire S] no.human.being:
Remember that there are actually two different memory layouts for this phone.

In the "old" layout, HBOOT resides at 0x02b00000 inside the Radio. In the "new" layout, HBOOT resides at 0x02400000 inside the Radio.

Offset into the Radio partition will be equivalent to physical address, since the Radio always starts at 0x00000000 physical.

Of course the partition offsets and sizes will also vary.

The post of theq86 describes the "new" layout. I've done a table for the "old" layout.

EDIT: Swap "mtd5" and "mtd6" designators. They're actually the other way round. :D
[HTC Wildfire S] heavy_metal_man:
sorry to ask something that has already been asked but how do you guys work out where each partition started and ended on the nand?? i would like to do this for the wildfire (buzz) but im simply baffled lol:D
[HTC Wildfire S] no.human.being:
We know that the NAND's physical address space is 0x00000000 - 0x1fffffff for a total of 0x20000000 bytes (since the "first" byte is at address "zero", so "number of bytes" is "highest address + 1"). I don't know of any way to find out this value by software, you'll probably have to find which NAND chip is used on the phone and then look up the physical address space in the corresponding datasheet.

The order in which they appear in NAND (from lowest to highest) is: "radio --> recovery --> boot --> system --> cache --> devlog --> userdata --> misc"

I have taken this information about the order from a different Android phone where this has already been figured out and it turned out to work well for the WFS. So the order is probably the same for every Android phone.

Then you just start at "physical size of NAND" (so 0x20000000) and subtract the size of each partition starting from the one with the highest physical address.

So the first we subtract is the size of "misc". You can find the partition sizes by doing "cat /proc/mtd" on the phone while Android is booted. After we have subtracted the size of "misc", we know where "misc" starts. Since we can expect the partition layout to be contiguous (no "gaps" between the partitions), we can then just take this value (so the starting address of "misc") and subtract the size of the partition that physically comes "before" it, which is "userdata". Then we know where "userdata" starts.

You go on like this until you know where "boot" (which is the "first known partition" on NAND) starts. This address will also be the size of the Radio partition, since the Radio always starts at 0x00000000 physical. Well and Radio starts at 0x00000000 physical, so finding the "offset" of the Radio is trivial. Now you have all offsets and all sizes. ;)
[HTC Wildfire S] tacromx:
before and after

Today i started the schem for the xtc clip on proteus, should have a working clip in a couple of weeks, also started scheming a jtag interface.

I'll be doing a dump of before and after via jtag and also logging the data between the clip and the phone when i unlock s58 via data logger.

Anything you need from this,please let me know. Im more hardware than software,so it may be of use maybe.
[HTC Wildfire S] no.human.being:
Oh yeah, finally! A micro-controller guy! :D

Physical NAND dumps will come in very handy! We'll probably find where the actual secu_flag lies. And it'll finally let us verify whether our "NAND dumps" show the actual physical NAND content or if the kernel or a lower-level firmware is fooling us.

Thank you very much in advance. Btw, what tool are you using for JTAG debugging? OpenOCD? If so, could you publish your configurations files for the microcontroller and board?
[HTC Wildfire S] tacromx:
Exellent!!

The Jtag interface will be this one

Have a read,its open jtag and yes i'll post config and progress as i go along.

It's about time that this gets sorted and i'm glad to help, so if there's going to be anything specific you'd like me to try when it's all set up let me know.
[HTC Wildfire S] theq86:
In fact, someone came up with a bootloader log where the right order of the partitions, as well as their start and size were shown.
[HTC Wildfire S] heavy_metal_man:
any idea how?
[HTC Wildfire S] theq86:
http://xdaforums.com/showpost.php?p=23011819&postcount=1075

it was in the information of the boot messages. they can be viewed by typing: fastboot oem boot.

hboot 0.90.0000 showed the partition layout (in the right order with physical start addresses). Newer hboots only show the mappings.
[HTC Wildfire S] no.human.being:
The physical addresses (at least what we believe to be physical - remember that there's a layer beneath us that might do all sorts of things - address translation included, even though we currently have no reason to expect it to actually do such a thing :D ) are passed to the kernel, so one could possibly write a program that acts like a very minimal kernel, reads the parameters and prints them to screen.

I really wonder why they left access to the Radio partition open. I mean this entire "security thing" is about protecting intellectual property, but we can pass a kernel parameter and then read the Radio partition, effectively "stealing" what is meant to be protected.

I mean if actually only mARM has NAND access and aARM can only RPC the Radio for access, why the hell haven't they put an additional check into the Radio that prevents aARM from reading the Radio code? Under "normal operation" aARM should never have a reason to access the Radio partition, right? They could just put in a check determining whether the address of a read operation is below a certain threshold and just return zeros or some sort of "I/O error" if it is. Were the software-engineers really that sloppy or is there a reason why they left this open? I mean it's good for us, but for me as a person having a focus on IT-security it just "catches my eye" straight off. One the one hand this thing is so "nailed down" with QFuses and secure-boot and signatures and everything and then you start digging and it all falls apart. :D
[HTC Wildfire S] theq86:
another thing:

if only mARM had NAND access in the radio area, why then mark it as locked or bad or whatever?

if aARM had no way to read the full radio (which we now know it CAN) there would be no reason to protect the radio from aARM using such mechanisms.
[HTC Wildfire S] no.human.being:
It's not just the Radio area. It seems that only mARM can access the address and data bus. On the other hand, aARM can only RPC the firmware on mARM to do the access for it, then read the results from a shared buffer in RAM. If aARM could access the busses, then we could issue "unlock" commands using suitable kernel-level code. Remember that all pages start out locked and firmware (Radio?) has to issue an "unlock" command for each page that it wants to have unlocked. However, I'm not actually sure whether this mechanism is used at all, since Radio is probably intercepting all of aARMs NAND access anyhow, so they can do access permissions entirely in software and the "hardware lock" would turn out redundant.

Well are we actually certain that what the read returns is indeed what is stored in NAND? :D

I know it's fairly remote, but if the Radio is indeed a "man-in-the-middle" between the NAND and the aARM, it could actually turn out to be some kind of "rootkit". Remember the thousands of unused memory pages in the Radio area being completely erased, holding nothing but 0xff all over again? Have the Qualcomm engineers actually wasted so much space or do they "hide something" in there?

I mean I'm probably far too paranoid, but I'd feel a lot more assured of what we're doing if we had a physical NAND dump acquired via JTAG and verified that what we read from aARM is bit-identical to what is actually in NAND. I really think that it is. Why would they be hiding parts of it and not all? But physical dump would be nice nonetheless. :D
[HTC Wildfire S] tacromx:
progress...

Schem and pcb design ready for production, starting on jtac tomorrow.

Ill build the jtag first so we can get dumps.

Im thinking maybe i should wipe as much as i can in recovery and a factory reset and remove sdcard so that the dump will be as clean as possible...any thoughts?
[HTC Wildfire S] no.human.being:
I hope you know how to operate it. I have a JTAG interface and adapter and the phone here, but I'm not familiar with OpenOCD and with the MSM controller.

Be sure to dump the NAND via JTAG before and after Radio S-OFFing on the phone via DIAG and also pull at least one "software dump" (here is how to map and dump the Radio area via software running on aARM and here are the page tables for both firmware builds) and compare it against what you read via JTAG please, then post the results of these comparisons here. You don't have to upload the full dumps, as they will contain identifying information like your IMEI, serial number, etc., some pages around the areas that are different will be enough. This would be very very helpful!

If you can get me to use JTAG on the phone, I'll try writing one of our patched HBOOT images to NAND and check whether it turns the phone S-OFF.