yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
Well, one of the main differences is that this device has its Radio partition completely hidden from the operating system via some sort of paging mechanism. It took us quite some time to figure out that there is more physical memory available than is normally addressable and how we could modify the page tables to make it all accessible. We had to do it via Fastboot while the device was booting and it was quite hard to figure this all out.

It seems that for other devices there is an exploit that can map the protected area in while the device is already booted with Android fully running. Revolutionary tried their exploit on our phone, found that it would not work, then gave up. Probably user base is too small for them to be willing to put some actual development effort into this.
[HTC Wildfire S] paul.robo:
i think they made a bad choice in giving up. this device is very neglected. i think s-off should be the MAIN priority for EVERY HTC and android device. i hope i can be of more help. like i said in my PM as soon as i get hold on a nand dump. i will be able to tell you EXACTLY what talks to the nand and even in what order. asoon as u get hold ov the nand dump that will solve ALL your problems.
[HTC Wildfire S] no.human.being:
Be careful! The NAND contains sensitive information. The Radio area will contain your IMEI and serial number, among others. The "visible" partitions will contain SMS messages, account data for your Google account and other accounts and whatnot. I'm not sure how much CWM recovery's "wipe" will actually wipe. It will probably just the clear file system data with "mkfs". Obviously, CWM wipe will never touch the Radio area.
[HTC Wildfire S] paul.robo:
doing a nand dump is very safe i could do it with my j tag riff box but i have NO wildfire s to do it with :( if i did i could tell u exactly what talks to the nand
[HTC Wildfire S] seaskyways:
nand-dumps ? maybe if you made it a bit breifer , more like excluding the system and data etc ... there is that post for nhb where it shows how to mount our radios , but it includes the mount for the whole NAND , but isn't it easier to tell us the command to mount the whole Nand at once more like the before but this time setting the permiters from 0x000000 (whatever) to the end which i don't know :p
[HTC Wildfire S] paul.robo:
nothing to make briefer all i need is a nand dump. that will tel me exactly whats talking to the nand and in what order. then i can tell you exactly how to proceed with getting s-off :)
[HTC Wildfire S] dudeman1996:
How does one go about getting a nand dump then? Nothing harmful I assume? ;)

EDIT: Never mind, I Googled it...
[HTC Wildfire S] heavy_metal_man:
Would we be correct in thinking that you already have a xtc clip? If so when you get your device/ or someone up to get clipped, please perform a nand dump of before and after xtc clipping so we can see if the xtc clip changes a value on the nand, the sim unlock location and the cid location :D:cool:
[HTC Wildfire S] paul.robo:
yes i have a clip, if someone is willing to travel to me i can guarantee i can get ALL info from nand before and after. and just encase they think there device will get broken i will let u hold 200pound just encase it does break. this then gives u a option. because even if i do brick it you have the cash to get a new 1 straight away that day. no1 else will offer this. i live in Swindon England :) if anyone's up for that then that's cool. we can get started in a few days . or you will have to wait until i can get hold of 1. makes thing difficult as i cant walk very well. ( im going in for major back surgery soon im having a lumbar discectomy ( look it up on youtube its a massive operation ) :) but i want this to get done :) its my goal to have your device s-off :) PM me if your up for what i said
[HTC Wildfire S] no.human.being:
We have never compared entire physical address range (0x00000000 to 0x1fffffff) on the same phone before and after S-OFFing. However, we have done the following:

- Binary compared visible address range (0x02b00000 to 0x1fffffff physical or 0x02400000 to 0x1fffffff physical, depending on firmware version) on the same phone before and after S-OFFing with xtc-clip and found no changes, except that the first few bytes in the "misc" partition were changed to 0xff (which is certainly not the thing that does the S-OFF).

- Binary compared the Radio area (0x00000000 to 0x02afffff physical or 0x00000000 to 0x023fffff physical, depending on firmware version) on different phones, some which were S-ON and some which were S-OFF, but none of the differences could be attributed to S-OFF, because they were either different even on phones with same secu_flag status or the same on phones with different secu_flag status.

So either the secu_flag is extremely well-hidden, say not a single bitflag, but a combination of bitflags that e. g. state "S-ON" when they have even parity and "S-OFF" when they have odd parity. This is possible, but I think this is quite unlikely. In this case dumping the same device directly before and after S-OFFing might shed some light on what's going on.

Or, and this I find much more likely, the status of the secu_flag is not stored inside the NAND at all, but inside some "special device", probably connected to a GPIO-pin of the controller. I expect the device to work like a Q-Fuse. It is intact (S-ON) normally and DIAG can "blow" it to S-OFF. This would also explain why even DIAG can't revert a clipped (or shipped S-OFF) phone back to S-ON, as the transition from S-ON to S-OFF is stored in some "one time programmable" area that is "still unprogrammed" when S-ON and the transition to S-OFF is thus irreversible.

So the second option seems plausible, but we actually don't know for sure. However, for our exploit this does not really matter much. For the phone to become S-OFF, it is enough when the application processor firmware thinks that it's S-OFF. The baseband processor (Radio) firmware will still know that the device is S-ON, but the phone still behaves like S-OFF. So we patched the function inside the application processor firmware that asks the Radio about the secu_flag status. This is exactly what Revolutionary is doing and it should be working fine.

After we got the phone S-OFF, we will try porting UBOOT to the MSM7227. UBOOT is a bootloader for Embedded Linux, so we'll have to customize it so that it is able to boot Android. However, it is much more advanced than HBOOT or any other Android bootloader. It will offer you a remote-console with the ability to flash the phone with firmware images provided via WiFi with FTP and whatnot. This will just be pure awesomeness and it will get us rid of HBOOT and thus let us prevent the possible IP infringement against HTC/Google.
[HTC Wildfire S] paul.robo:
if i can get hold of wildfire s ill do a dump b4 and after i use my clip and ill have a gander at it. but need a volunteer for a free use of my clip ???? any1 want to use my clip to get s-off ???
[HTC Wildfire S] dudeman1996:
You're 2 hours away from me.. Unfortunately I'm 16 and don't drive.. Otherwise I'd definitely come to you!
[HTC Wildfire S] no.human.being:
How are you going to dump the NAND? Via software or via JTAG? I already know how to do it via software, but I have a JTAG interface and adapter for the MSM7227 here for use with OpenOCD and could use some introduction to get me started on this. First I wanted to reverse-engineer the firmware via JTAG (this was my first idea of doing it, even before I found how to map the Radio partition via Fastboot), but I didn't have the skills and the people who had never had time. :D

JTAG access will make sure that you get the actual NAND content with no firmware component intervening. I mean the chance is quite low, but you never know. Google's engineers seem to be quite evil when it comes to preventing their product from reverse-engineering. I found some quirks inside the operating system that have almost clearly been designed just to increase complexity and make reverse-engineering harder. I'd love to take both a "software dump" and a "JTAG dump" of the phone's memory and do a binary diff in order to verify that they're actually identical.
[HTC Wildfire S] paul.robo:
where do u live mate ?
[HTC Wildfire S] dudeman1996:
North London
[HTC Wildfire S] paul.robo:
arghhh shame this nand dump will be very useful aswell. never mind i have opend a thread to ask if anyone near my area can let me s-off there wildfire s so i can get a nand dump b4 and after i hope i get it done soon
[HTC Wildfire S] jimhed:
Windows newbie - need more basic info

I'm used to the fruity platform for development work, but on windows it seems I need a bit of help. The instructions given are very helpful, but I think there are a number of underlying assumptions about the ability for someone to do this without setting up the background requirements - I guess mostly with the Android SDK, AVD manager and their variables. It would be helpful if all the assumptions were laid out in regard of the development tools, terminal settings etc.

Essentially, I could not get the lengthy code string to do anything in the Terminal window which makes me think it's not getting parsed by the right tool or not getting parsed at all. I need help!

[BTW - great if it can be automated - though assumptions will still apply - SDK loaded in a particular location maybe, plus a few other assumed bits.]

:confused:
[HTC Wildfire S] paul.robo:
please explain in more detail what you say is hard to fully understand
[HTC Wildfire S] heavy_metal_man:
You need to install the adb android programs for this to work, or have the ad and fastboot files I think.
[HTC Wildfire S] gordo79:
This of any use for people having trouble getting adb working properly on windows http://xdaforums.com/showthread.php?t=1272595
[HTC Wildfire S] ghekua:
I'd followed the instruction, but unfortunately still S-ON haha...

Thank you guys for the hard work! Keep it up guys!
[HTC Wildfire S] seaskyways:
What now ??
[HTC Wildfire S] :
Looks cool. Btw, most productive first post ever!
[HTC Wildfire S] :
Didn't you sell your WFS?
[HTC Wildfire S] seaskyways:
Yes , I did , but i like helping if I could , and you , make the NAND dump already , i could have been the first person to do so if i had my phone !
[HTC Wildfire S] :
Cool. What do you have now? And if we got S-OFF tomorrow would you regret selling it?
[HTC Wildfire S] theq86:
Please use the code tag when you want to share code.

However, we are already aware of those functions, but they do not work correctly due to some still unknown restrictions.
[HTC Wildfire S] no.human.being:
Basically, to get this done, we will have to figure out what happens from the moment that userspace (mtdutils) calls "mtd_unlock(...)" until some I/O pins are driven at the memory bus.

Basically, what happens is that somehow the kernel level function "int mtd_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)" is called in "drivers/mtd/mtdcore.c". This in turn seems to call the function pointer "int (*_unlock) (struct mtd_info *mtd, loff_t ofs, uint64_t len)" in "struct mtd_info" in "include/linux/mtd/mtd.h". This is where my journey ends, since I don't know the value of that pointer at run time, so I can't "follow" it.

Like I said there are two possibilities. Either the kernel talks directly to the NAND or it RPCs the Radio and the Radio talks to the NAND. It's most likely the latter case for security reasons, but I haven't seen the code yet that talks to the Radio.

If NAND access is direct, erasure will be prevented on the kernel level by the OOB and we will have to modify the kernel to ignore the OOB.

If NAND access is indirect via Radio, we probably have to "authenticate" with the Radio to make it believe that we are HBOOT. Remember that HBOOT may flash the Radio partition when installing an RUU and it's HBOOT that checks the authenticity of the update, not the Radio itself. Now, both HBOOT and our kernel run on the application processor (aARM), so there's probably no reliable way for the Radio to tell HBOOT and our kernel apart, so we have to figure out (by reverse-engineering) how HBOOT authenticates with the Radio for getting premission to flash the Radio area while installing an RUU. Then we try to replicate that behaviour from within our own kernel.

Another idea: Would it be possible to "chainload" a modified HBOOT via Fastboot and the "original" HBOOT on the handset by sticking an Android kernel header to an HBOOT image? Remember our exploit can patch an HBOOT image, it just can't patch it in NAND, so dump your HBOOT into a file on your phone's SD card, then run the exploit on that file and you have an HBOOT that will be S-OFF. Move the file to your computer, stick an Android header to it (say by hex-editing), then bootstrap that HBOOT via Fastboot. The HBOOT will be S-OFF, so it won't check signatures. Then we use this state for flashing the modified HBOOT to NAND, again via Fastboot, but this time talking to our modified HBOOT. I know this sounds crazy, but we might consider trying. Remember that on a PC, you can have GRUB chainloading an NTLDR for example, so why not try it on a phone? :D
[HTC Wildfire S] no.human.being:
A low-level look via JTAG will probably be really helpful here, but at least on the Desire S it is. GFree writes to this location on partition 7 on the Desire S when turning the device S-OFF. Wildfire S doesn't have a partition 7 though, but possibly only the numbering scheme is different but the address is the same.

No, has nothing to do with the address. Android cannot open the device at all. You can't even do a "cat" on it.

The devices are already mounted as "rw". As soon as zergRush is through, all these devices are mounted as "rw". But that doesn't matter on the device level anyways, since "rw" only means that you can write to the device on the file system level and the file system is not involved here at all, as I am accessing the raw device.

On a "normal" Linux system, you can use the device files for low-level reading/writing. You can access them, even when the file system on the device isn't mounted at all. I often use this facility for creating forensic images of media.
[HTC Wildfire S] ONeill123:
Hmm ****, i can't follow. That is to many stuff i dont know, sry, but now i will inly read this topic and if i know anything i will write.

Hope that you find a way to set s-off with software, plz!
[HTC Wildfire S] no.human.being:
Nooooo... :(

You were one of the few contributors here. :(

:D
[HTC Wildfire S] ONeill123:
Lol, you mean? If u are sure i will think loud in next time, and then u can see wilhich idea you can use and if it is possible ;)
[HTC Wildfire S] *se-nsei.:
Don't worry, the progress you are making is great. :)

We just need some more help..
[HTC Wildfire S] meanmug:
Is it possible that block of memory is located on the processor, may explain why it is unaccessable? I saw somewhere in a thread here that someone mentioned on/off die.
[HTC Wildfire S] no.human.being:
I think I mentioned it. :D

But seriously, it won't make any difference at this level. It could make a difference during JTAG sessions, I'm not sure about that yet.

However, the operating system can obviously read from it, otherwise it wouldn't be able to boot from it and have the file systems on these devices mounted. I just asked this question for curiosity reasons, as I've expected the memory to be on-die, but have actually never seen any datasheet that would confirm this (however, I haven't seen one to state the opposite either). Even if the memory was on-die, it wouldn't explain why the block devices are not accessible.
[HTC Wildfire S] meanmug:
I didnt bother to look it up, but the proccess xtc-clip uses to s-off, is the device on or in bootloader mode?

---------- Post added at 07:17 PM ---------- Previous post was at 07:07 PM ----------

@no.human.being, you seem to be quite intellegent did you by chance have or could take a look at this post http://xdaforums.com/showpost.php?p=20590416&postcount=8 by insink71. Do you think theres any possiblity this method would work?
[HTC Wildfire S] no.human.being:
It is in bootloader mode.

I expect you can't install a custom RUU on an S-ON device.
[HTC Wildfire S] meanmug:
Those 2 flashers allow you to flash custom ruu's or the .nbh files on HTC devices.
[HTC Wildfire S] no.human.being:
Even when the device is S-ON? This would enable us to install custom roms via a "hacked" recovery, without even getting S-OFF, right?
[HTC Wildfire S] meanmug:
Yes sir, thats there purpose they replace the windows installer.
[HTC Wildfire S] no.human.being:
Well, nice.
[HTC Wildfire S] meanmug:
This one here inparticular http://xdaforums.com/showthread.php?t=399762.

I have very little experience with linux machine, but it looks like we can just flash the .nbh file. If so we should be able to use the PG76DIAG.nbh file that gave the cdma users s-off.

PG76DIAG.nbh attached
[HTC Wildfire S] Lt.Win:
Okay, so I've heard from various sites that using the identifier token of the Desire [not Desire S or HD] on HTCDev, you can unlock the WFS bootloader.

So, anyone with an identifier token? I want to test it out.

UPDATE: The Identifier token of the Explorer or any phone that has been unlocked via HTCDev will do, just let me see what I can do.
[HTC Wildfire S] meanmug:
Look at step 10 and why not just ask for the unlock code binary file?
[HTC Wildfire S] sythe179:
Why not get a fact version of a WFS image, and a s-off image, and run a byte compare to find what changes?....well, just an idea...
[HTC Wildfire S] ONeill123:
I think too. You can built an ruu, but the ruu sents the rom.zip and the phones hboot or something else checks the signature when s-on. And u can't sign a rom.zip with an htc certificate, bc u haven't got any cert.
[HTC Wildfire S] sythe179:
Wouldent the s-off image allready be certed since its a modded s-on?

And couldent you just extract the cert out of another?
[HTC Wildfire S] y0da89:
I just got my phone S-OFF Marvel GSM in a shop for 15€ with a XTC Clip

Android 2.3.5 ans HBoot 1.08

Those files were on my sd card after the trick

Hope it helps
[HTC Wildfire S] tacromx:
Am i right in saying that the first 2k of data is the header?
[HTC Wildfire S] no.human.being:
Yes, but you probably can't just take the header from an arbitrary "boot.img" and stick it to an HBOOT image. The header basically tells the bootloader on the phone how many payloads there are (kernel, initrd, ...), how large they are, to which physical memory addresses the kernel expects them to be loaded, etc. We need to figure out at least the physical address to which HBOOT expects to be loaded and then put them into the header, set the "kernel size" to 512 KiB (this is how large HBOOT is) and set the other payloads to zero.

However, I'm not absolutely certain whether this will actually work, since you know it's HBOOT that loads our "payload" into RAM and we would basically tell him to overwrite his own address range, so we'd overwrite the code that is executing. We're not changing the code section that's responsible for loading boot images into RAM, so it may actually work without crashing, it's just that at the first glance the procedure seems a bit awkward. :D
[HTC Wildfire S] heavy_metal_man:
So in layman's terms you want to try patch the hboot to s-off onto the sdcard and then try run the boot from the ram?
[HTC Wildfire S] no.human.being:
One could try it, but there's a chance that it won't work. First I'd like to know the entire "software stack" that's involved when Android accesses NAND.
[HTC Wildfire S] jimhed:
Hmmm - not there yet

Did this on a Mac and followed to the letter. Unfortunately rebooted into S-ON <scream>.

Thought I'd try it again, but it fails when trying to boot into the clock recovery image (in my case... boot recovery-clockwork-5.0.2.8-marvel.img) with...

downloading 'boot.img'...

FAILED (status malformed (1 bytes))

I tried reloading with new files to no avail. It looks like there has been a change somewhere, but not S-OFF unfortunately.

Any thoughts?
[HTC Wildfire S] no.human.being:
The "FAILED (status malformed (1 bytes))" usually appears when trying to boot an image via Fastboot when the phone is in bootloader, but not in Fastboot mode.

Be sure that after booting the phone into the bootloader with Vol-Down held, you press the Power button on the phone after the bootloader has started and checked the SD card for the PG76IMG.nbh to enter Fastboot mode on the phone.

The text "FASTBOOT USB" should appear on the phone's screen, then run the "fastboot boot ..." command on the computer with the phone connected. Please also verify that your bootloader is unlocked. Locked bootloaders will refuse the Fastboot protocol. If your bootloader is unlocked and in Fastboot mode, but still refuses to boot via Fastboot please return with more details (especially Radio and HBOOT version).
[HTC Wildfire S] Gloris:
so, is this method working for anyone yet? I just tried to method on the front page, and it all goes through like it should, but I'm still s-on. i do get some slightly different figures though, for example all my erasesize are 00020000, instead of 00040000.

Haven't noticed any adverse affects, phone still boots and runs as normal.
[HTC Wildfire S] no.human.being:
It probably won't work for anyone due to the software architecture of the phone's firmware. Our I/O is not hitting the NAND, since there are lower level firmware layers, one of which is blocking it. This is either the kernel of CWM recovery or the Radio itself. We suspect that all NAND access that Android performs might actually happen indirectly via the Radio.

Imagine the Android kernel being cut off the NAND's address and data busses doing NAND access indirectly by putting the read/write request into some buffer in that is shared between Android and the Radio, have the Radio perform the actual access and then read the result back from the buffer. This way the Radio could protect his partition against access from Android. Even worse, it might actually "fool" Android by pretending that there's data in the NAND that isn't really there - in this sense the Radio could actually act a bit like a rootkit. :D

All this is just guesswork though, since we haven't traced our way far enough through the Android kernel yet to find the piece of code that either drives the NAND's busses themselves or communicates with the Radio for requesting NAND access from it, so we currently have proof for neither scenario.

Be aware though, that this mechanism is always in place (even on an S-OFF phone) and has nothing to do with the secu_flag itself. The goal is rather the protection of intellectual property. The Radio is not under a Free Software license, so you don't have the right to modify it and this lack of right is enforced through software. In addition, it serves to protect the low-level firmware from being damaged by accidental NAND writes by the operating-system kernel thus preventing bricks by software bugs in the stock and custom ROMs.
[HTC Wildfire S] akestrel1987:
Hboot 1.10.0001

My Bother-in-law and Sister both have the MetroPCS version of the phone and it has HBOOT 1.10.0001 on it..... has any one found a way to S-OFF this version yet?

If so please reply back or direct message me on here please!!!!

They have the worst memory problems with their phones due to the bloatware from MetroPCS!!!

At one point I remember my sisters phone having less then 5mb of space on it.... I know most of the issue lies with the Dalvik Cache but this is ridiculous.....

Thanks!
[HTC Wildfire S] meanmug:
Yea its a few post back, you might want to start reading at the 1st post.