W
Okay, if I'm right wouldn't this exploit apply to every current HTC Android device? 
Okay, if I'm right wouldn't this exploit apply to every current HTC Android device?
Well yes and no. The principal idea should work everywhere. However, the address of the secu_flag in non-volatile memory will probably vary. And you'll have to build separate kernels for devices with different CPUs.
I couldn't find reliable information about the kernel's base address by grepping for it. If I understand the kernel source correctly, it expects base address of zero for devices without an MMU. Remember we built the kernel for the MSM7201 processor, as MSM7227 is not directly supported. Supported are MSM7201 and MSM7230 and we decided to go with the older chipset as we expected the chip to be backwards-, rather than forwards-compatible. Now I've selected "MMU support" during kernel configuration, but the only "MMU type" that can be selected for the MSM7201 is called "---", which to me sounds much like a "placeholder".
So I've built a kernel with base address zero. When I boot it, the phone will vibrate one time while booting the kernel, then it will vibrate again, indicating it is rebooting. After vibrating for the second time, the stock firmware (so in my case CM7.2) will boot.
Then I've built a kernel with base address 0x12c00000, which all the other kernels (Alquez' kernel, the kernel that comes with CWM recovery, etc.) seem to use. It will lock up with a white screen.
When I don't supply a "--base" parameter, it seems to default to 0x10000000, but as you know this will also lock the device up with a white screen.
The most fundamental problem is that I'm currently not 100 % sure whether the base address is a characteristic that is device dependant or rather a characteristic that is kernel dependant. So is it right to say "it must be the same address as with all the other kernels for the WFS no matter on which Linux version they are based" or is it rather "it must be the same address as with all the Linux 3.2.5 kernels no matter on which device they run"?
I think it's rather the latter. If I understand correctly, the information is stored in the header of the kernel image and HBOOT reads it and then loads the kernel into the RAM address that's supplied. So HBOOT is the part that's "flexible" and adapts to the kernel. And the kernel is the part that is "inflexible" and only supports being run from exactly one RAM address. So HBOOT loads the kernel whereever the kernel requires it. Now the question is, how to find out where Linux 3.2.5 wants to be loaded?
Okay, if I'm right wouldn't this exploit apply to every current HTC Android device?
the exploits principle would be the same on all HTC devices implementing the security flag like the Wildfire S.
For example, the way to go on the Desire S and newer high end-phones is a different, because the memory location where the secu_flag resides is mapped (thus accessible via android and without a special kernel)
On our devices, the secu_flag is unmapped. That means it resides on a memory location we can not access within the android context.
You can imagine it that way:
----------------------------------
so this exploit would only be necessary on our device and devices with a similar layout as wildfire S.
and even then it would differ in memory addresses.
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.
On the Desire (not the Desire S ), the partition layout is (from low to high addresses):
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.
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.
On the Desire (not the Desire S
), the partition layout is (from low to high addresses):
Code:
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.
Last edited:
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
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
Last edited:
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.
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.
Code:
# 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.
Last edited:
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.
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.
Last edited:
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.
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.
Last edited:
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.
If i knew, I would downgrade to hboot 1.08.0000 (standard, not unlockable)
and run cwm via fastboot command.
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.
EDIT2: Be sure to do a NANDROID backup before flashing the HBOOT and keep it around until everything's restored.
Last edited:
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
---------- Post added at 04:19 AM ---------- Previous post was at 03:37 AM ----------
standard hboot, not unlockable
issued command:
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.
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
---------- Post added at 04:19 AM ---------- Previous post was at 03:37 AM ----------
standard hboot, not unlockable
Code:
MARVEL PVT SHIP S-ON RL
HBOOT-1.08.0000
MICROP-0451
RADIO-7.53.39.03M
Oct 31 2011,20:38:16
Code:
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.782sthe 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.
Last edited:
The following is from a dump of the boot messages from my stock WFS, still on 0.90 hboot:
Code:
0x000002fc0000-0x0000034c0000 : "recovery"
0x0000034c0000-0x000003800000 : "boot"
0x000003800000-0x000013c00000 : "system"
0x000013c00000-0x000015f00000 : "cache"
0x000015f00000-0x000016900000 : "devlog"
0x000016900000-0x00001ff00000 : "userdata"
0x00001ff00000-0x000020000000 : "misc"
Code:
<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)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?
Woow ! You made great progress guys !
Probably more than 50% of Wildfire S owners are in this case.
EDIT :
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.
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 !@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
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.
Last edited:
@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.
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.
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
------------------------------------ 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.
Last edited:
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...
Sent from my HTC Vision using XDA App
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...
Sent from my HTC Vision using XDA App
Exactly. It's between 0x00000000 and 0x02fbffff (always have to go minus one at the higher bound, otherwise the memory areas would overlap
).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.
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.
Last edited:
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.
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.
Last edited:
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
59[DEV][THE S-OFF CAMPAIGN] We need electrical engineers & experts in JTAG, OpenOCD!
Progress so far:
DEVELOPERS!
THIS CAMPAIGN IS STILL GOING!
Please try to read the latest posts in this thread if you would like to help!
---
S-OFF is still needed! Don't get happy with your HTC unlocked bootloaders, you have no more warranty! You still can't resizie your system partitions! You still can't flash the hboot, and many other things! You can get your warranty back, if we crack S-OFF!!
Well I basically did a lot of of low-level (mostly hardware) stuff to the phone recently, not so much actual development. I found out how to configure OpenOCD (don't know whether the configuration is any good, since lots of values are more "good guesses" than actual knowledge but at least it's a starting point). I found how to get the board to boot without being attached to the Lithium cell which is not important for getting JTAG access (because this works as long as the board has power supply, being booted is not neccessary for JTAG to work) but will later be needed for tracing through the boot code, since the phone won't boot without what it thinks is a Lithium cell. However, I didn't get the debugger running yet. I suspect that the processor's logic level might be too low for the JTAG equipment. I don't really have an idea how to work around that yet, I might need to build a circuit that boosts the processor's JTAG signal to the appropriate voltage level (a so-called "level-shifter").
Apart from that munjeni and Antagonist42 also seem to make progress, but I must admit that I wasn't really able to keep track of all the things that they were doing recently. So basically we're now down at the actual physical layer and messing around with the electrical stuff that's going on on the phone's board and trying to find a way of actually talking to the processor to get the on-chip debugging working.
The far goal will be getting a patched HBOOT that has signature verification removed loaded into the device's memory via JTAG, then flash a patched HBOOT image via Fastboot. If this works it will be the first S-OFF GSM WFS that's neither shipped S-OFF nor turned S-OFF via xtc-clip, but this might still be a long long way.35Get your Teeth into these
Do not PM requesting Documents unless.....
If you cannot satisfy the above, do not PM. Thank you
My DropBox is defunct :silly: , as i'm not now as active on XDA I will see about re-posting when I can get some time to sort it all out again (like my mind it's a mess ).... I'll leave page as-is until I can sort it out Thankyou for your patience... and thankyou dropbox for the total lack of any idea of what went wrong
QualcommRelease Info July 2010
Booting
Qualcomm Boot VM984
File Systems
Qualcomm Filesystem Overview
ARM sheets
ARM9 Compiled Framework - Translated
ARM926EJ-S pdf
ARM1136JF-S + J-S pdf
ARM Phone/PC/Chip Info doc
Qualcomm REX User Guide Rev C 2001
REX and common software
ARM9EJ-S r1p2 _ RETIRED _ DDI0222
ARM Architecture Reference Manual v6m _ DDI0194C
eMMC Electrical Standards
ARMv7
Architecture App Level Ref Manual v7-M
Architecture App Level Ref Manual v7-M
Architecture Ref Manual v7-M
ECC
Reed Solomon Error Correcting Codes - OhadRodeh
Qualcomm - System Boards / User System
MSM7xxx Q-Fuses and Security
USB Host Driver W2k/XP -80-V4609-1-Rev-E
Android Linux Device Bus Drivers
Qualcomm - AMSS / Radio ... non user
AMSS - D'ya wanna know how to?
AMSS Overview 7x27 EBI1 cfg Original pdf
AMSS Overview 7x27 EBI1 cfg Translated (roughly lol) rtf
AMSS/DMSS C Debug/Troubleshoot
CMX Overview 80-V1484-1 Rev H
AMSS Multimedia Concurrency
AMSS 6055/6065/6075/6085 Build Instructions and Environment
MSM7227 Info
MSM7200A Sales Datasheet
MSM7500 Sales Datasheet
TM7200 [Test Phone] Sales Datasheet
MSM7227/7227 - Turbo - Build your own!!! See Below For Chip Infos
MSM7227 Chip Training-Overview
MSM7227 modem pdf
Micron NAND information
Package Naming
Part Numbering
NAND or OneNAND + RAM pdf
Micron NAND 101
NAND Flash Memory for MT29F4G08AAA, MT29F8G08BAA, MT29F8G08DAA, MT29F16G08FAA
4Gb, 8Gb, and 16Gb x8 NAND Flash Memory Features
TN-29-16: Boot-from-NAND with the TI OMAP2420 Processor
TN-29-18: Booting from Embedded MMC
TN-29-13: Determining NAND Flash Ready/Busy Status
TN-00-25: Enabling a Flash Device into the Linux MTD
Samsung NAND information
512 NAND
K9K2G08(U/R)0A Datasheet
KFG1G16Q2M-DEB6 Datasheet
Lauterbach - NAND
NAND FLASH Programming User’s Guide
Board IC's
PM7540 Power Manager pdf
RTR6285 RF Transceiver IC pdf
RTR6285/6280 Specs pdf
RTR6285 RF SW Driver pdf
MSM7227 Boot doc - Chinese but mostly the actual android/linux we're after.
MSM7227 Boot - Translated (roughly) - doc
Qualcomm 7X27 Platform Training Summary - rtf
Contains Partition Info .Doc file
Program (Linux) Unsure of authenticity please be aware...
QualcommAuto Test - No idea, Linux OS, trying to find documentation.
MSM6025 QSC60x6
Data Sheet
Device Specification
User Guide
Chipset Training
MSM60x5 AMSS Secure Boot Overview
MSM60x5 AMSS Flash and Memory Layout
MSM60x5 AMSS Board Support
MSM6500
Chipset Training
Basband Ref Schematic
MSM7200/A
Software Interface Manual 80-VA736-2 Rev B
MSM7200A Chipset Training - Baseband Topics
MSM 7225
Device Specification 80-VF815-1 Rev E
MSM7625
MSM7625 Device Info pdf
MSM7627
MSM7627 RF Training pdf
MSM7627 SCHEMATIC pdf - try at your own peril
Training Baseband Topics-80vm151-25 - pdf
Training Baseband Topics-80vm151-25 - (plain text file) - pdf
SURF7627 Main Board Ref Schematic pdf
SURF7627 Platform User Guide
AMSS 7x27A Linux Release 2.0.35 (Modem, Multimode) for Android™
Platform-Enabled MSM7627A Devices Release Notes for M76XXUSNEKNLYM2035
MSM8260/8660
MSM8260/8660 Baseband Reference Schematic
APQ8060/MSM8260/8660 Mobile Station Modem
MSM8660 Voice/Audio Topology and Tools Overview
MSM8x60
MSM8X60 Modem Debug Guide
MSM8960
Schematic including PM8921 WCD9310
MSM8969 Boot Architecture
MSM8960 Chipset Training - Intro & Overview
QSC
QSC6240/QSC6270 Single Chip User Guide
MDM Series Chips
62+6600 User Guide
8200 User Guide
JTAG Info
AND72J v1.0 25.04.2011 doc
JTAG ETM Interface for ARM9
Lauterebach - ARM JTAG Interface Specifications
Program for JTAG
From above site - H-JTAG v2.1
H-JTAG User Documents
MSM Devices.
Lauterbach Dev Tools - Debugging Linux GDB Android
Trace32 Training not Qualcomm.
MSM7227 Schematic Chip Infos
B4B-PH-K_LF_SN
JST - PH Connector Info
CCM03-3013-LFT-R102
C&K Components - SIM Holder
CM1213-08MR
CMD California Micro Devices - 1, 2, 4, 6 and 8-Channel Low Capacitance ESD Protection Arrays
DTC124EE
ROHM Semiconductor - 100mA/50V Digital Transistors
DTC144WE
ROHM Semiconductor - NPN 100mA/50V Transistor
EMIF02-MIC02F2
ST Microelectronics - EMI/RFI Filter
HEC3650-018010
HOSIDEN Electronic Components - DC Power Jacks
IP4047CX6-LF
NXP (founded by Philips) - ESD protection EMI filter Level shifter and buffer
LP5900TL-3.3
Texas Instruments - Ultra Low Noise, 150 mA Linear Regulator for RF/Analog Circuits Requires No Bypass Capacitor
LT3465FA
Linear Technology - 1.2MHz/2.4MHz White LED Drivers with Built-in Schottky in ThinSOT
Linear Technology - High Efficiency ThinSOT White LED Driver Features Internal Switch and Schottky Diode – Design Note 325
MT46H32-64M16-32LF
Micron - Mobile Low-Power DDR SDRAM
NC7SP34L6X
Fairchild Semiconductor - TinyLogic ULP Single Buffer
NC7SZ74
Fairchild Semiconductor - TinyLogic UHS D-Type Flip-Flop with Preset and Clear
PACDN1404-D
On Semiconductor - ESD Protection Arrays in Chip Scale Package
ISP1362
USB Schematic Philips - Philips ISP1362 USB On-The-Go Expansion Board For Accelent IDP's
0522P_0524P
Semtech - Ultra Low Capacitance TVS Arrays
SI2333DS-T1-E3
Vishay Siliconix - P-Channel 12-V (D-S) MOSFET
ZXTD2M832
Zetex Semiconductors - MPPS Miniature Package Power Solutions DUAL 20V PNP LOW SATURATION SWITCHING TRANSISTOR
Programs
QXDM - 3.9.19 Still using 80-V1241-21 Rev. A November 21, 2001
With update info for Expected Differences Between QCAT Version 4 and QCAT Version 5 Output - 2006
QXDM Software Users Guide 80-V1241-21 X2 September 13, 2001
Other Stuff I have come across, passed on, may be of use/interest ...
Intel - Hex Addressing/Recording - Hexadecimal Object File Format Specification
LG VS930 Service Manual
LG KS20 Service Manual pdf - just for interest.
How the Dalvik Virtual Machine works
Qualcomm Rex Boot - Needs Translating though!
AMSS Doc Translated - rtf
Qualcomm OS Kernel Code REX Translated - rtf
Generate Release Version Android System Signature Translated - rtf
Translated Boot doc 1
Translated boot doc 2
Multi-Core Communication - Original txt pdf
Multi-Core Communicaton - Translated
Wavecom Open AT Firmware 7.4
Boot/Kernel Analysis Docs -
Simple Analysis Android Kernel rtf
Android Boot Proc 01 rtf
Android Boot Proc 02 rtf
Linux Kernel Porting (mini2440) rtf
Qualcomm Boot Analysis rtf
U-Boot Analysis rtf
A Physically Addressed L4 Kernel paper - pdf
L4 User Manual API Version X2 pdf
A Secure MicroKernel pdf
This document is intent to provide detailed instruction on building the Android Gingerbread BSP on the
SMDKV210 board.15
Proof (screenshot) is attached.
Yes I managed to "chainload" a patched ("exploit inject" generated) HBOOT on the device via Fastboot. Have prefixed it with a small (assembly language) exploit code that moves it to over to physical zero and jumps into it, then put it into an Android boot image created with mkbootimg_wfs and booted that via Fastboot. You have to hold Vol-Down when issuing the Fastboot command, since obviously otherwise it won't get into bootloader mode but boot straight into ROM. It shows S-OFF and "*** INJECTED ***" (which is the string that the exploit leaves inside the HBOOT image to prove that it worked - I've "stolen" the idea from Revolutionary that show "*** REVOLUTIONARY ***" or something like that). Cannot test whether it actually "acts S-OFF" (allows stuff like "fastboot flash hboot" etc.) since I have no way to enter Fastboot mode. It will boot straight into the ROM after checking the SD card for the PG76IMG.nbh.
Don't want to publish yet since the image obviously contains an entire HBOOT and while I really want to gain S-OFF on the device, I also respect HTC's copyright on their code. I have to turn this into an exploit that generates the image from an HBOOT dump pulled off the phone itself since then I do not have to ship any HTC code with it, which I'd consider "fair".9Haha it works!
Code:~ # cat /proc/mtd dev: size erasesize name mtd0: 00100000 00040000 "misc" mtd1: 00500000 00040000 "recovery" mtd2: 00340000 00040000 "boot" mtd3: 10400000 00040000 "system" mtd4: 02300000 00040000 "cache" mtd5: 09600000 00040000 "userdata" mtd6: 00a00000 00040000 "devlog" mtd7: 02fc0000 00040000 "radio" ~ #
I had a fastboot image of unknown origin that probably couldn't do it for whatever reason. I now used the fastboot that ships with the Android SDK and this one does it.
So yes people, we have access to the Radio!
Code:~ # cat /dev/mtd/mtd7 > /sdcard/radio.img
Succeeds so I'm now having the Radio firmware right on my SD card!
So victory I'd say! We just have to find the flag now. Memory protection is gone! The rest is "good programming work" and "finding out how APIs work" for programming the Flash via mtd devices. It's not that trivial as you have to do quite sophisticated "ioctl" calls to explicitely erase pages before programming them again, otherwise the memory won't be writable. But like I said this is just coding skills and API knowledge. We have passed the challenge, Radio protection is dead!9GOT IT! PHONE SHOWS S-OFF! Bootloader is unusable though. Shows boot screen (including S-OFF), then checks SD card for PG76IMG.nbh, then boots into ROM. No chance to do anything. But I think that only SMALL modification is required now.
New posts
-
-
-
Development [ROM][A14][Pixel 7 Series] MATRIXX-v10.4.2 [GAPPS][04.19.2024]- Latest: nikhil007mmus
-
Themes / Apps / Mods (Magisk Mod) Google photos unlimited back up.
- Latest: pawelmiernik
