Originally Posted by 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?

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.

Originally Posted by 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" ?

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".

Originally Posted by theq86

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.

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.

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.

Originally Posted by 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. 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

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 ), 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.

Originally Posted by theq86

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.

Where did you get the fastboot source code from?

Originally Posted by theq86

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.

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.

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

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.

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 Android = High Tech robot phone.

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 ...

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.

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.

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.

Originally Posted by 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.

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.

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.

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

---------- 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 !

I'm already trying for some time now, building an operating system around a "vanilla" Linux 3.2.5 kernel for the MSM7227 (well actually for the MSM7201, as "vanilla" Linux doesn't have support for the MSM7227 itself). However, it always locks up the device.

So the other idea was extracting the kernel from the CWM recovery image and then build an OS around that. It's not as "nice and clean", as we're actually taking a "black box" as kernel here, but it may be faster than trying to resolve the problems with the Linux 3.2.5 kernel.

acually the recovery is a very good skeleton os. I think there is not that much to change. a minimal gnu system is also included.