yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
Yes exactly. However, we're not sure about whether the "unmapped" areas are contiguous and "at the beginning" of the address space. I don't think they "scattered" the firmware into several "gaps" between the mtd partitions, so the "contiguous area" model makes sense, but we don't actually "know".

We do know however that some kind of "reassembly" of firmware is performed while the processor initializes. So the firmware is "pulled together" from different parts of the NAND and copied to adjacent pages in RAM before it is executed. However, we don't know which logic this "pulling together" follows. It's low level firmware that's already shipped on the processor that's doing this and currently I'd expect few people have seen this firmware (of course engineers working at the semiconductor companies which manufacture ARM processors have).

Of course our exploit would in principle also work on phones where the secu_flag does not reside in "unmapped memory". It's not that we can only access "unmapped memory". It's just that it will enable us to access the entire NAND by physical address, which includes "unmapped memory". So in principle one could port it to devices like the Desire S that do not "unmap" the memory, it's just that it's "overkill" as there are easier methods for these devices. :D

On the Desire (not the Desire S :D ), the partition layout is (from low to high addresses):

0x00000000 - 0x00e1ffff: RADIO (raw partition, UMTS transceiver firmware)
0x03e20000 - 0x03edffff: HBOOT (raw partition, bootloader)
0x03ee0000 - 0x03fbffff: SP2 (raw partition, service partition 2 ?!?!)
0x03fc0000 - 0x407fffff: MFG (raw partition, ?!?!)
0x04080000 - 0x419fffff: SP1 (raw partition, service partition 1 ?!?!)
0x041a0000 - 0x0423ffff: WIFI (raw partition, WIFI transceiver firmware ?!?!)
0x04240000 - 0x046bffff: RECOVERY (raw partition, recovery kernel + initrd)
0x046c0000 - 0x049bffff: BOOT (raw partition, main kernel + initrd)
0x049c0000 - 0x0dfbffff: SYSTEM (yaffs2 file system, "/system")
0x0dfc0000 - 0x0e4bffff: CACHE (yaffs2 file system, "/cache")
0x0e4c0000 - 0x1ff5ffff: USERDATA (yaffs2 file system, "/data")
0x1ff60000 - 0x1fffffff: MISC (raw partition, ?!?!)

0x1fffffff is the highest physical memory address of the memory that's supplied on the Desire (at least from the CPU's point of view, some higher spec NANDs are "overprovisioned" and have more physical storage than is available through the interface to improve performance and reliability, but this doesn't memory from the software point of view) so you see it's all somehow "used". This also tells us that the controller-specific firmware resides in a separate physical memory, probably in a real ROM (read-only memory) that's on the processor die.
[HTC Wildfire S] theq86:
Question: Do we know if

a) the mtd partitions are mapped and the radio firmware is just left out or

b) the access is somehow really restricted.

If just a) is the case we can maybe change the init.rc files somehow to map other memory addresses (and just guess the start and end addresses) I don't know if there are suitable commands to achieve this
[HTC Wildfire S] no.human.being:
We need to boot a system that is self-contained. We can't use CM for this or any other firmware designed for being "installed" on a device. Try mounting "/dev/block/mtdblock3" as read-only (so nothing that would in any way violate device security!!) under CM.

# mount /dev/block/mtdblock3 /data/local/tmp -o ro
mount: mounting /dev/block/mtdblock3 on /data/local/tmp failed: Device or resource busy
#

It will fail because the "ressource" (NAND) is in use (well obviously it is, since the operating system is running from it). So when we want to have control over the NAND on the device level, we need to make sure that the system is not accessing it. This is problem number one.

Problem number two is that someone tested running CWM recovery (which is based on an Android kernel) on an S-ON device and the recovery refused e. g. to wipe caches, etc. I'm not sure how this "wiping" is performed, but in my opinion it is a strong indicator that the kernel is aware of the secu_flag and restricts access to certain memory areas on the block device level.

Since we don't know how this lock is implemented (e. g. if it just says "mtd3 is to be protected, so don't write to mtd3", we could map our memory as say "mtd5", if this were unprotected, and be done with it, however if it says "address ranges xyz are protected" we'd probably be screwed), we better go with a "vanilla" kernel that isn't even aware of such constraints and then build an operating system around that runs fully self-contained from RAM. This should basically resolve all the problems that might come in our way.

BTW, even the Android developer documentation says ...

So getting Linux running on a device is a basic test before manufacturers even begin porting an Android kernel to it (at least that's the strategy Google suggests). So it should definitely be possible to boot "vanilla" Linux on our devices. We're just doing something wrong. Probably nothing major, but enough to cause it to lock up.
[HTC Wildfire S] theq86:
Okay, sit down, keep calm ...

following happened:

I managed to lock the bootloader. (via fastboot)

Then I took the latest CWM Recovery (5.0.2.8) (of course flashed while unlocked ;) )

And I could backup, I could restore, I could install update-zips and everything.

I don't know what happened or changed but it definately worked!

Then I went back to Android OS. Root was still there, but the device would not let me write on /system. This is evidence for that the bootloader was definately locked.

However, it is definatly true that...

CWM Recovery 5.0.2.8 can write to protected partitions (/system, /boot, /recovery, /cache etc) on a locked S-ON device

That means, the kernel that is in that recovery image does also definately NOT care about the write protection.

So something other than the kernel (probably something loaded later than the kernel) does block the access on android.

Pittily, you can not downgrade to a non HCTDEV hboot without losing CWM. Because stock recovery.img is inside all RUUs and changing or deleting it would screw HTC signature, leading it to be non-flashable.

Conclusions and questions:

a) Would a standard hboot along with cwm still ignore these restrictions?

It may be possible, but also possible is, that a HTCDEV hboot enables some kind of access permission, regardingless of the locked/unlocked state. We can not test it, because we will not get a standard hboot along with cwm on an S-ON phone.

b) CWM 5.0.2.8 does not care about those restrictions, as I have tested above. That means, we have a functional kernel that has no artificial restrictions and we have even a minimal OS to build upon, namely CWM.

So, I'd say we try to use the cwm to access the unmapped area. if it is as you said, nhb, the nand will not be blocked by the OS. If we fail, we can still try a vanilla kernel.

edit: I tried to install an update-zip using the stock recovery on unlocked device. It refused to write to /system e.g.

so that means the stock recovery kernel does block this, the cwm kernel (probably not built from htc sources) does not care. It seems the latest CWM kernel is the solution to get device access.

edit2:

Since HTC is the only manucaturer I know employing S-ON it would be stupid to assume the restrictions were standard in a aosp android kernel. It's probably hidden in the HTC kernel sources. This is just logic. So I guess every non-htc kernel would do, being it derived from vanilla or android sources. CWM gives me right.
[HTC Wildfire S] no.human.being:
This means that the CWM image contains a kernel that ignores the secu_flag. If this is true, then you just found out some real awesome stuff pal! We could extract the kernel from the image, make it map the entire NAND by passing parameters to it (either by altering the default parameters in the kernel image or by passing parameters via fastboot) and then stick another initrd to it. However, not being able to write to "/system" is no evidence that the bootloader is locked. I'm running CM7.2 and have the bootloader unlocked. I can't write to "/system" since it's mounted read-only, and I cannot mount it read-write since the file system is in use while the system is booted and you can only remount when the file system is not in use. It seems to be a "security measure" to prevent accidental changes to system files (which makes sense after all).

No, security is almost always implemented in the kernel, since the kernel runs in "supervisor mode" on the processor and all the rest runs in "user mode". The recovery system uses an entirely separate kernel. It's not the kernel that's running when "normal" Android is booted. Basically the recovery is a completely separate operating system.

As far as I know you can run CWM on the device without flashing it. You can use fastboot to bootstrap it into the device's RAM. If you do so, it should execute from RAM only.

Yes you will. Via fastboot.

Yes, it should be possible to extract the kernel though and build another OS around it should this be neccessary.

Yes, I'd suggest we try to build a minimal GNU system around the kernel that comes with CWM.

Stock recovery could always write to "/system", that's how OTA updates are performed and it's also one of the reasons we know that the kernel can definitely write to "protected" memory, it's just that most Android kernels are built not to do so. It's just that you cannot flash custom ROMs with stock recovery since there's some kind of signature verification in place. Stock recovery will happily flash signed OTA ROMs on an S-ON and locked device. That's how we got the Android 2.3.5 OTA update from HTC some months ago.

Yes they do, it's just that the string that's displayed is not "S-ON" or "S-OFF" since HBOOT is a bootloader that's been customized by HTC. Even the "developer phones" like Galaxy Nexus have the lock. It's just that it can be disabled with a simple fastboot command called "fastboot oem unlock" to disable it. Before you do that, you'll have no luck flashing anything and system partitions will be locked from within Android, just as on an "S-ON" HTC device.

I'll try getting some hours of sleep now and will look into this in the afternoon. Thank you very much. What you've just found out might turn out to be an important part of the key to success.
[HTC Wildfire S] theq86:
unfortunately I do not know how to use fastboot to bootstrap the device.

If i knew, I would downgrade to hboot 1.08.0000 (standard, not unlockable)

and run cwm via fastboot command.
[HTC Wildfire S] no.human.being:
Eeerm ... just download Clockworkmod. It's an *.img file, which is a kernel + initrd. Put the file into the directory where your fastboot utility resides and then do "fastboot boot recovery-clockwork-5.0.2.8-marvel.img" (obviously the file name is going to change as newer versions of CWM are released). The boot image will be transferred to the device via USB and executed.

EDIT: Obviously you got to have your device booted into the bootloader and then select "FASTBOOT" for this to work. :D

EDIT2: Be sure to do a NANDROID backup before flashing the HBOOT and keep it around until everything's restored. :D
[HTC Wildfire S] theq86:
Okay, that this is my schedule for tomorrow. gonna get some sleep now, too.

I'll report then here. If a completely locked device can be written to by cwm like an unlocked it would be a great success.

that will also tell us, if we have to be bootloader unlocked to use the exploit, or if it is sufficient to boot into cwm on a locked device (thus never having the need of going through the htcdev process at all)

regarding edits 1 and 2:

I have known both and always a current nandroid backup ;)

edit: you forgot edit 3: plug the cable :D

---------- Post added at 04:19 AM ---------- Previous post was at 03:37 AM ----------

standard hboot, not unlockable

MARVEL PVT SHIP S-ON RL
HBOOT-1.08.0000
MICROP-0451
RADIO-7.53.39.03M
Oct 31 2011,20:38:16

issued command:

C:\Users\XXX\MarvelDev\fastboot> fastboot boot ..\recovery\ClockWorkMod\recovery.img
downloading 'boot.img'...
OKAY [ 1.778s]
booting...
FAILED (remote: not allowed)
finished. total time: 1.782s

That's the proof. To use the boot command you need the unlocked bootloader.

the htcdev hboot itself is not sufficient, you have to go through the unlock process, otherwise hboot refuses manual boot, too.

This is obviously wanted. Otherwise the locked bootloader would have no serious security, if it could be bypassed so easily.

As I said, no way to have standard hboot along with cwm. but never mind, this just strengthens my opinion, that even on a standard hboot cwm would ignore the security flag. why would they prohibit booting a custom kernel, if even the custom kernel could not act against security.
[HTC Wildfire S] BeciMester:
The following is from a dump of the boot messages from my stock WFS, still on 0.90 hboot:

0x000002fc0000-0x0000034c0000 : "recovery"
0x0000034c0000-0x000003800000 : "boot"
0x000003800000-0x000013c00000 : "system"
0x000013c00000-0x000015f00000 : "cache"
0x000015f00000-0x000016900000 : "devlog"
0x000016900000-0x00001ff00000 : "userdata"
0x00001ff00000-0x000020000000 : "misc"

Also memory layout, I dunno how useful it might be:

<6>[ 0.000000] Memory: 428MB = 428MB total
<5>[ 0.000000] Memory: 428008k/428008k available, 10264k reserved, 0K highmem
<5>[ 0.000000] Virtual kernel memory layout:
<5>[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
<5>[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
<5>[ 0.000000] DMA : 0xffa00000 - 0xffe00000 ( 4 MB)
<5>[ 0.000000] vmalloc : 0xdb000000 - 0xf8000000 ( 464 MB)
<5>[ 0.000000] lowmem : 0xc0000000 - 0xdac00000 ( 428 MB)
<5>[ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
<5>[ 0.000000] .init : 0xc0008000 - 0xc0037000 ( 188 kB)
<5>[ 0.000000] .text : 0xc0037000 - 0xc04c6000 (4668 kB)
<5>[ 0.000000] .data : 0xc04c6000 - 0xc0514900 ( 315 kB)

I can PM yous the whole bootmessages.txt if you guys require it. I'd rather not upload it here, I don't know what sensitive info might be there, I didn't read it all...
[HTC Wildfire S] theq86:
Looks quite contagious. I expect the secu_flag among the radio firmware to be somwhere between 0x00 and 0x000002fc0000.

Could also be after 0x000020000000 but isn't it rather improbable?
[HTC Wildfire S] pihug12:
Woow ! You made great progress guys !

Maybe I don't get the whole procedure, but does it mean that the users who applied the OTA 2.13.401.3 update after unlocking their bootloaders (which relocks it and doesn't allow to go back) or the users who are not European (who can't apply the HTCDev procedure) are screwed ?

Probably more than 50% of Wildfire S owners are in this case. :(

EDIT :

I wasn't aware of this update. Thanks !

I just hope that anyone can unlock their bootloader.

Sorry for disturbing you.

EDIT 2 :

So, if I'm right, we cannot gain a software S-OFF without losing warranty. That's kinda sad. :(
[HTC Wildfire S] theq86:
@pihug:

You may have not read it yet, but about 2 weeks ago HTC released an update for 2.13.401.3 to be unlocked.

So if you are one of the people who got locked again after applying 2.13.401.3, just head back to htcdev.com and download the new update :)

If you need further assistance regarding 2.13.401.3 please go to http://xdaforums.com/showthread.php?t=1502979 because this thread is dedicated to the S-OFF exploit only.
[HTC Wildfire S] theq86:
I had a first look into an unpacked recovery.img (cwm 5.0.2.8) and could see that it already is a minimal GNU system. Gonna get and compile mkbootimg now and modify the recovery for testing purpose. maybe I can also get a radio dump. but I'm not that experienced :D

------------------------------------ edit -----------------------------------

I compiled mkbootimg and used the perl scripts here to play around with the recovery image. But I was not able to reintegrate it correctly.

recovery.img 5,2 megabytes --> unpacked --> packed --> recovery2.img 4,8 MB

where do the other 400k go?

Of course I could not boot the recovery2.img.
[HTC Wildfire S] a.s.j:
Maybe just a stupid question... Does this image have to be somehow "hw aware"? Or is it just about "I am runnable on ARM" ?

Some time ago we had tinboot created for Kaisers, which are originally VM6 phones and used that to force Android there and it worked really nice...

Would this image solve your need for minimal image runnable on this device?

I am not using it, so I am not 100% sure of the hw setup, it is my gf's phone, but I am running with you from now on if you wish...
[HTC Wildfire S] no.human.being:
Exactly. It's between 0x00000000 and 0x02fbffff (always have to go minus one at the higher bound, otherwise the memory areas would overlap :D ).

It can't be from 0x20000000 onwards since 0x1fffffff is the highest physical address on the NAND.

I think it must be able to run on MSM7227. You can select the chip manufacturer and model number in the menuconfig of the kernels and I think it's for more than just optimizations. I expect the processors to exhibit slightly different behaviour (especially the memory controller stuff is probably quite model specific), even when they're all "ARM".

Yes. I'd say we focus on "escalating Unlocked S-ON to true S-OFF" first, regarding bootloader unlock as a prerequisite. When we got that, we can focus on breaking the bootloader lock. There are two ways we could do this.

The first and most obvious is reverse-engineering the process that generates the Unlock_code.bin and then provide a utility that generates it without HTC's involvement.

The second is provoking a buffer overflow in HBOOT via the Fastboot protocol and using this to disable the bootloader lock. This is still quite hypothetical though, it'll require lots and lots of research and it'll involve building a custom Fastboot utility. (Is the specification for the Fastboot protocol available to the public?) It's really not the thing I want to focus on at the moment. :D

However, let's just ignore this until we got the way from "Unlocked S-ON to true S-OFF". The bootloader lock will not be that difficult to overcome. Remember S-ON is there to protect the Radio and protecting the Radio firmware is extremely important to the manufacturers, since they'll get into lots of trouble when people run "illegal" Radio firmware that tampers with the mobile networks. So if the security, which protects this "holy grail", namely the Radio firmware, can be broken, then the f***ing bootloader lock, that doesn't protect anything that's nearly that precious, won't pose too much of a problem.
[HTC Wildfire S] theq86:
Then I hope the Unlock_code.bin is really generated. If device token and unlock code were an asymmetric key pair your first method would also be hypothetical.

edit: after looking at fastboot sourcecode and comparing Unlock_code.bin and Identifier_token.bin I have a strong feeling they both are a 2048 Bit RSA key pair.

I expect the device identifier token to be the public key (it's on the phone, everyone can see) and the unlock code ta private key

So even reverse engineering will not work, unless we could change the identifier token of the device to a key that we have a private key for.
[HTC Wildfire S] no.human.being:
It might not even be a key pair (that would actually be weird as HTC would have to keep every private key for every device stored, as you cannot derive a private key from a public one ... obviously ... after all that's the entire point in asymmetric cryptography :D ), but the unlock code could actually be the device token "encrypted" with HTC's private key (then they'd only have to store one key). Of course the HBOOT already has HTC's public key, so it could use that one to "decrypt" it again and therefore verify that the unlock code does really originate from HTC.

I put "encrypted" and "decrypted" in quotes, as it's not really a measure that's supposed to provide confidentiality of the message (after all the decryption key is public in this case, so obviously it's not used with confidentiality in mind) but rather as a proof of identity.

Where did you get the fastboot source code from? :eek:

Well ... we could remove the verification from HBOOT. We're having physical access to the device. We can do anything with it. We could unsolder the NAND chip from the PCB and put it into an EEPROM programmer if we wanted to, replacing the entire HBOOT and Radio and stuff with open-source equivalents. UBOOT would be a good replacement for HBOOT and the Radio can be built from the Iguana/Pistachio sources. :D

Just kidding. Well, kinda. It would definitely be possible. It's just that it's not worth it. :D

However, I want to make a point that you cannot "secure" a system against an "adversary" having physical access. It's one of the most fundamental principles in computer security. It has never worked and it doesn't make sense. :D
[HTC Wildfire S] theq86:
yes, you are right. the phone has the public key and could check against a signed device identifier token.

strange is, both unlock code and identifier are 2048 bits long.

the fastboot source was in a git repository along with mkbootimg sources (i actually only wanted this and got a full bunch of source codes including those from fastboot and adb etc.)

I'll edit the repository's url when I found it in my chronicles

EDIT: here the sources of all the android platform core tools

git clone http://android.googlesource.com/platform/system/core

obviously, this source does not include the oem commands, since these are added by the manufacturers
[HTC Wildfire S] m1ndh4x8r:
HTC Android = High Tech robot phone. :confused:
[HTC Wildfire S] seaskyways:
Secu_flag

Guys , i am telling i am not a dev i am just a tester but i have found Secu_flag in a radio.img for the wildfire S , i don't know if you need it but i just found it using the HxD.exe , i just typed in search for Secu_ , and Secu_flag pops up between the lines , in the hex thing it is between lines 00225800 and 00225810 .... maybe that will help somehow ! Also there is another secu_flag at between lines 00AE72A0 and 00AE72B0 ...
[HTC Wildfire S] no.human.being:
Thanks for your effort, but what you've found is just a string.

The "true" secu_flag is just a binary flag (aka bit) and there's nothing that really "designates" it as such, other than probably some pointer to it that we found the HBOOT to follow. Besides that, it looks exactly like the roughly 4 billion (512 MiB * 8 bit per byte) other bits in the NAND. :D

Well, not exactly. We know that it's in "unmapped memory" and this area is exactly 50.069.504 bytes (47.75 MiB) large so this cuts it down to a bit more than 400 million bits. :D

Now the method that's most likely to bring success in finding the secu_flag is dumping the physical memory (including unmapped memory) via a custom OS image, then xtc-clipping a phone, then dumping it again. We should then look for changes in the first 47.75 MiB. Probably there won't be so many, as the Radio firmware is quite a "sensitive" part of the phone. When you damage it, chances are you're in for a JTAG repair, so xtc-clip certainly won't go crazy patching around in it like hell, but will probably flip exactly the flag and do not much else.
[HTC Wildfire S] seaskyways:
Haha , LOL , when i found that string i thought i made an improvement , well you guys are "Loudly Brilliant";) my effort is nothing as yours , but actually i needed help which i couldn't have earlier with my WFS , i just needed to restore every single partition in my phone as original including misc cuz it is maybe messed up , the thing in my phone is that I can't mount my Sd as Disk Drive while USB debugging is on and other USB connection problems which i only had after messing up with my phone , pm me for any ideas ? btw if this is taking time from the s-off thing, please don't help:rolleyes:

---------- Post added at 08:53 PM ---------- Previous post was at 08:49 PM ----------

By the way , brilliant idea ! it won't require a dev to catch it , only a brilliant thinking ! I recommend to try what no.human.being just said cuz it makes lots of sense !