yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
My idea was: You boot the phone into HBOOT mode with Vol-Down held and trap the bootloader right at the beginning of its codebase, then change the mentioned instructions, then let execution continue normally. Then your phone will be S-OFF until rebooted, so you boot into Fastboot mode, then use Fastboot utility to flash one of our patched HBOOT images.

We don't want to distribute them since they are HTC's property, so you must create them with our "exploit-inject" utility from an original HBOOT image you have on your phone or its SD card, but the procedure is well-documented and works as long as the image is either HBOOT-1.08-0099 or HBOOT-1.09.0099.

After you flashed the patched image to your phone, S-OFF will be permanent. At least until you install an RUU which flashes the HBOOT. It'll be just like Revolutionary (which unfortunately isn't available for the WFS).

Good luck and document everything as thoroughly as possible, so that in case of success we can try to replicate it and be happy (at least the owners of a JTAG interface can :D ) or in case of failure we can try to figure out what went wrong and improve the process. Thanks!
[HTC Wildfire S] munjeni:
Maybe patching hboot inside nbh and bruteforcing that block signature in nbh? Or "watching" memory by jtag in order to catch log from hboot after signature go compared from hboot function "check signature" ? For example if((char)signature != 423465494) ... we can catch that $signature that is needed and add it to nbh:D Hmmm, or at least, finding printk funcion in hboot, modifying "check signature" function and adding printk to it, than writing modified hboot to flash, than runing nbh ubgrade and watching log on screen :D, or at least asking htc for rsa signing key:eek:

http://xdaforums.com/showpost.php?p=23269580&postcount=1541 this can do nothing to hboot in nand... I allready tried!!! Its same as a simple writeb or writel to an offset (nothing to do to the protected offset... big message write wail)!
[HTC Wildfire S] surma:
Is there a way of doing this method for European WFS? I bought mine from Finland I'm still with HBOOT 0.90.0000. Looks like the file from htcdev for HTC EU model WFS only contains HBOOT upgrade and doesn't have the radio images. Can I use what ever GSM-model file there is at htcdev or does it have to be HTC EU for phones that doesn't really match with any other file in there?

Thanks for all your efforts towards software S-OFF!
[HTC Wildfire S] theq86:
Right, the current htcdev RUUs only contain the new hboot.

they require you to do a software upgrade to the latest version 2.13.401.3.

That software update upgrades your radio files etc.

so the current htcdev files can not be used to s-off.

what you will need is the european htcdev ruu for 2.13.401.2. then extract it (do not upgrade) and rename the extracted rom_01.zip to PG76IMG.zip. put it onto your sd root and boot into bootloader. click update and you should be s-off.

however, you have to get the rom_01.zip from this forum.
[HTC Wildfire S] no.human.being:
The signature works something like that:

- The HBOOT image is fed through a hash function. This is most likely SHA-256, since this is probably the most secure that still uses 32-bit integers, so it can run on the ARMv6 without greater modufications. SHA-512 requires 64-bit integers.

- The hash is signed ("RSA encrypted", signing uses the "RSA encrypt" function, even though the purpose of this "encryption" is not to provide confidentiality, but to guarantee that the image has not been tampered with) by HTC with their private key and appended to the image.

- The image is fed to HBOOT via Fastboot to be flashed.

- HBOOT has HTC's public key and uses it to "RSA decrypt" the signature, obtaining the hash that HTC embedded into the image.

- HBOOT then hashes the image with the same function that was used by HTC.

- HBOOT compares the two hashes, one obtained from the signature and one calculated on its own, and refuses to flash when there is a mismatch.

So what can we do?

Well, we can obtain the original hash from the signature with HTC's public key and we can verify whether the signature matches. But that's basically all. When we modify the image, its hash value will most likely change (unless our modification produces a collision in the hash function, which is a rare condition).

Of course we can compute the hash value of a modified image, but we cannot generate a valid signature, since we don't have HTC's private key, we only have the public. We could try deriving the private from the public key using an integer factoring algorithm, but this will be hard to implement and will take too long. 15 years are guessed for 2048-bit RSA, which seems to be what HTC is using.

Only thing that MIGHT be feasible is further modifying the patched HBOOT images (by appending "junk" that will never get executed) and hashing them until we find a collision, another (different) image that hashes to the same value as an original HBOOT image.

But for now let's just do the JTAG trick, trapping when HBOOT begins executing (or before it first calls the code we're trying to patch by setting a "breakpoint" there), then modifying the code just as we would patch it and let it continue to run. Then using Fastboot to flash an unsigned, patched HBOOT image generated by the "inject" utility. My bet is that this will turn the phone S-OFF permanently. Then we use the knowledge acquired from this JTAG run to further engineer our software-only solution.
[HTC Wildfire S] munjeni:
Ok, I know bruteforce is not possible, but I thinked:

For example, function in hboot looks like:

int check_signature(void) {

if (sig != expected_sig)

return 1;

else

return 0;

}

than, we find printk function in hboot. Than, we hex editing hboot add function printk for example function checksignature after patching looks like:

int check_signature(void) {

if (sig != expected_sig)

printk(expected_sig);

else

return 0;

}

So we find signature for that block from printk :D and add these signature to block of the modified nbh... wat you think? :)
[HTC Wildfire S] munjeni:
I think you misunderstand how signatures work. A signature is basically a hash of the data to be signed (so e. g. of the HBOOT image in your file/RUU/whatever) encrypted with a (private, asymmetric) signature key. The verifier (HBOOT) has the (public, asymmetric) verification key to decrypt the original hash from the signature[/QUOTE]

I agre with you, but you misunderstand me what I thinked. Signature is stored in nbh allready, on every block! So I thinked for example... modifuing your function... fastboot function if exist...

if (val_a == val_b)

{

unlock_all_pages();

write_to_nand(image);

}

else

printf("Signature error!\n");

reboot();

and modifuing to:

if (val_a == val_b)
{
unlock_all_pages();
[COLOR="Red"]printk(val_a)[/COLOR]
}
else
[COLOR="Red"] printf(val_a)[/COLOR];

//reboot();

Val_a is signature generated on the fly from public rsa key and is generated from hboot, but val_b is signature that is stored for example in block 13 inside nbh... so instead of printing "signature is wrong" we get val_a, and that hash we put into end of block 13....
[HTC Wildfire S] no.human.being:
No, it doesn't work that way. The signatures in the NBH are "hashes of the data encrypted with a private key". This private key (also called "signature key") is kept secret, so we don't have it and HBOOT doesn't have it, so we can't "extract" it. However, HBOOT is in posession of the corresponding public key (also called "verification key"). It uses this key to decrypt the signature, reversing the encryption that was performed with the private key, obtaining the original hash, then hashes the block by itself and compares whether the two hashes match.

We can't make HBOOT put valid signatures into the NBH, because it cannot generate them (generating signatures requires you to encrypt the hash with the private key, which only HTC has), it can only verify them (verifying signatures requires you to decrypt the hash with the public key, which HBOOT has). So HBOOT can't generate a valid signature for a specific given payload. It can only tell, when given both a payload and a signature, whether the signature matches the payload or not. Even if we extract the key from HBOOT (which will definitely be possible) we can only decrypt (verify signatures), but never encrypt (generate signatures).

You have to look up how asymmetric cryptography works. It always requires a pair of keys, a public and a private one. The private cannot be derived from the public with "reasonable effort". Then you can either have everyone encrypt a message only you are supposed to decrypt using the public key and decrypt using the private key (this mode provides confidentiality, since everyone can generate a message you can decrypt, but no one but you can decrypt it) OR you can encrypt your message with your own private key and let everyone decrypt it with your public key (this mode provides integrity, since only you can generate a message that can be decrypted with your public key, but everyone can decrypt and thus read it and verify that it originated from you). What HTC uses is the second mode.

What we could do is "NOP out" or "make unconditional" (depending on how it is coded) the branch that decides what to do after checking whether the signatures match. However, this is probably not easier than making the function that checks the secu_flag always return zero (S-OFF), which is what I suggested here, so IF we decided to modify HBOOT we should probably do that part. As far as I know S-OFF disables signature checks, right?
[HTC Wildfire S] seaskyways:
Guys , I just found this tool for comparing Stuff by hex , it shows you the differences between large files (by hex) , you may need this for later use ! Note : while using it the RET key is the return/enter key ...

http://www.cjmweb.net/vbindiff/ here you can find the thing ... ( I have tried it with miscs , very cool and nice )
[HTC Wildfire S] no.human.being:
Sounds a lot like dhex, which is what I'm using.
[HTC Wildfire S] safsaf43:
thnx so much
[HTC Wildfire S] tacromx:
error

Any idea why i get this error??, im on HBOOT-1.08.0099. thanks in advance.

*************************

* Cold opcode injection *

*************************

An S-OFF exploit for HBOOT: 1.08.0099, 1.09.0099

(C) 2012 no.human.being

Project coordination, Fastboot and Radio analysis, exploit development and boot

image integration.

Thanks to the all the contributors from xda-developers, especially ...

... *se-nsei. for initiating the quest and keeping the community informed.

... heavy_metal_man for the '/system' dumps.

... seaskyways, MrTaco505, mstfkaratas and pihug12 for the Radio image.

... theq86 for the mtd tools analysis and Radio image.

... BeciMester for the HBOOT analysis and Radio image.

... pther for the modified kernel mtd driver.

Other contributors and fellows from xda: d33ps1x, Bad-Wolf, benjamingwynn

Thanks to Cyanogen, Alquez and Drowningchild for their work on the kernel.

Thanks to the bands Kampfar (Fredrikstad, Norway) and Trivium (Orlando, Florida)

for their inspiring music!

[ LOG ] Step 1: Reading from mtd ...

[ LOG ] Step 2: HBOOT analysis ...

[ LOG ] Incorrect base signature for HBOOT-1.08.0099

[ LOG ] Incorrect base signature for HBOOT-1.09.0099

[ERROR] Failed to detect HBOOT!
[HTC Wildfire S] seaskyways:
The exploit is NOT WORKING , please stop trying iy won't work anyways , with or without errors it won't work !
[HTC Wildfire S] munjeni:
This part of you I waiting. Let check next thing that you say:

COMPARE ! Lets stop at compare ! Thats thing about I want to say!!! Nbh is not rsa encripted, nbh only HAVE HASHES inside. So I thinked:

- example: modifying hboot inside NBH (this will needed later) than modify hboot to print "expected hash" instead of printing "nbh hash mismatch", than using jtag and putting that modified hboot to flash, than trying to install modified nbh and waiting on screen message from hboot for hash, than using that "expected hash" and puting on right place insede nbh.... until all hashes is === expected hashes... if all hashes match expected hashes we have nbh with modified hboot ready to all devices!
[HTC Wildfire S] :
Calm down! He's fairly new to this forum. He is also a new developer. I believe he is the one who has the JTAG, which will bring us forward.
[HTC Wildfire S] tacromx:
@seaskyways ....Appologies for asking the question, my reasoning was that i was expecting a 'permission denied' rather than 'Incorrect base signature',so i presume that's what everyone who tries the exploit gets.

All the parts for the jtag build came today,work starts tomorrow.

Nearly finished the compiling of Summon-ARM-Toolchain in cygwin, had to make a few mods to the script.

'Summon-ARM-Toolchain' compiled successfully in cygwin, took a while though :D
[HTC Wildfire S] Antagonist42:
@tacromx

don't know if these will be of any use but they're here anyway....

NAND access

Qualcomm NAND JTAG direct jilink

And also a load of docs here if not already seen them ;)

Hope there's something useful for you :)

:eek: :rolleyes:

Here's something that should be worth reading, no mention of the MSM7227 but this document listed in the MSM7227 Schematic. :D
[HTC Wildfire S] munjeni:
I don't know. Every 0x10000 byte from nbh have 0x80 byte signature or whatewer is. It is 0x80 byte len same as a rsa modulus from hboot (publc key). But maybe it is extractable from hacked hboot? What you think? How hboot handle information about if expected_signature==nbh_block_signature or if expected_signature!=nbh_block_signature ?? I think hboot have an loop function and 2 chars: one *char inside to store expected_signature obtained from rsa verification and seccond *char to store signature from nbh block ? So we can print all expected_signature from hacked hboot? It is realy interested !
[HTC Wildfire S] no.human.being:
0x80 bytes = 128 bytes = 1024 bits. This is quite a strange size. On the one hand, it's far too large for anything symmetric (like a symmetric key, a hash, an HMAC, ... 256 bits symmetric are considered sufficient even for "highly confidential data") but on the other hand it's rather weak for something asymmetric. 1024 bits RSA is not what I would consider secure. Remember that asymmetric cryptography doesn't have to be bruteforced, but can be broken with more efficient methods, usually integer factorization, which is still a "hard" problem, but one for which far more efficient algorithms than brute force search exist (see "Pollard's rho algorithm").

We think the modulus is 2048 bits, since the "unlock_token.bin" is this size and we expect "unlock_token.bin" to be the device-identifier token encrypted with HTC's private key, so that only HTC can generate it and HBOOT can decrypt it again with the public key and verify whether it matches. 2048 bits RSA will currently take about 15 years to break. Of course this number will get lower with time as hardware advances, but it's definitely "secure enough" for the purpose it serves.

I don't think that we have found this code already, at least I haven't. We only know which code is queried for the secu_flag (but not actually HOW it determines the status of the secu_flag itself, it must talk to the Radio somehow but we haven't figured this out, since it doesn't actually matter "how" it does it, as long as we are certain enough "that" it does it :D ) and we thought about making this one return zero (zero = S-OFF, everything else = S-ON). This is also what the exploit does. It patches the function to always return zero.

It does lots of other stuff like checking whether a valid HBOOT image was supplied, determining where the S-OFF function actually is located, verifying that it hasn't already been modified by a different exploit (in case Revolutionary comes to our device later on) and "mangle" a certain area of the code in a certain "unusual" (and therefore characteristic) way that will enable us to be quite certain that the HBOOT on a certain device was patched by our exploit, but that's basically all "gimmicks". The actual change are the 3 instructions I mentioned here.
[HTC Wildfire S] munjeni:
No. Public key (rsa modulus) is 1024 for htc hd mini... i think also for aria and this device!! If you open spl from htc hd mini you will find public key F25C15ADB90BCAF3FD38CB0CD65415B44....... inside same as defined in <modulus>

<key name="HTC NBH 2 (HTC HD Mini)">
<Modulus>F25C15ADB90BCAF3FD38CB0CD65415B4432CECF43C0D35B021AC25436059DBDF288592D56E93CCEAC31A9F9EAB81462CBFFB8C687C57D3A5B8141E3ACF801DF879BDAE94B0E33A2460D22C9592C7C86FA0E70FA5FB70F05DB7CC3D495A26AEFE7F285075BFB757F7133FC6F8412076D6A99E996866A2DF67937EABFC124C2A6B</Modulus>
<Exponent>010001</Exponent>
</key>

I have nbh verification tool for verifying nbh validity, I put that key to hex editor and size is 0x80 !

Allso I found now in asembly of the htc hd mini spl:

...
[COLOR="Red"]CMP R3, R2[/COLOR]
BNE loc_8CB2D408
...
loc_8CB2D408:
LDRB R3, [R1,LR]
LDR R2, [R6,R1,LSL#2]
LDR R0, =aSignatureError ; "Signature error(%d) %x != %x\n"

:eek: so I think signature is extractable from r2 or r3 ?
[HTC Wildfire S] seaskyways:
Guys , sorry , but I think the unlock-tokens might be something , because every token is based on a device's thing (forget what it was) , however , every token has the same point , to add the U for unlocked in the misc partition + wipe data , but those 2 are executed through the bootloader , I don't know but they might contain any sort of keys ??
[HTC Wildfire S] tacromx:
I tried the exploit with HBOOT-1.09.0099 code even though im on 1.08.0099

"fastboot -c "mtdparts=msm_nand:0x000a0000@0x1ff60000(misc),0x00500000@0x026c0000(recovery),0x00340000@0x02bc0000(boot),0x10d60000@0x02f00000(system),0x02300000@0x13c60000(cache),0x09600000@0x16960000(userdata),0x00a00000@0x15f60000(devlog),0x00080000@0x02400000(hboot)" boot recovery-clockwork-5.0.2.8-marvel.img"

And it gave me this..

"~ # cat /proc/mtd

cat /proc/mtd

dev: size erasesize name

mtd0: 000a0000 00020000 "misc"

mtd1: 00500000 00020000 "recovery"

mtd2: 00340000 00020000 "boot"

mtd3: 10d60000 00020000 "system"

mtd4: 02300000 00020000 "cache"

mtd5: 09600000 00020000 "userdata"

mtd6: 00a00000 00020000 "devlog"

mtd7: 00080000 00020000 "hboot"

[ LOG ] Step 1: Reading from mtd ...

[ LOG ] Step 2: HBOOT analysis ...

[ LOG ] Incorrect version string for HBOOT-1.09.0099

[ LOG ] HBOOT-1.08.0099 detected.

[ LOG ] Step 3: Patching ...

[ LOG ] Step 4: NAND unlocking ...

[DEBUG] ./mtdutils/flash_unlock /dev/mtd/mtd7

[ LOG ] Step 5: NAND erasure ...

[DEBUG] ./mtdutils/flash_erase -q /dev/mtd/mtd7 0 0

[ LOG ] Step 6: Writeback ...

[ OK ] Done!"

So ill dump an image next and apply it to that.

Also i'm compilling kernel 3.4 rc6 as i'm typing this, going to try the exploit with this kernell, i've aready compiled the latest mtdutils earlier today(they are the ones i used for the exploit above). Idoubt very much wether the result will be any different, but i've got to eliminate it anyhow for research sake.

.....ONWARDS!! :)
[HTC Wildfire S] :
What happened to our JTAG dumps? Me sad. :(
[HTC Wildfire S] no.human.being:
Just be patient. It's not a simple procedure and you can easily destroy (not just brick but actually damage electrically) the processor if you're careless. If he takes two months figuring it all out, then that's how it is.

Considering the Radio section is bit-identical to what we read via mtd we won't even need new dumps but simply the information that they are in fact identical.

I'm really confident though that you can use JTAG to manipulate your device so far that our exploit will work on it. It'll be the first Android device that was successfully exploited by "our" method. This will be a historic moment and munjeni already acquired his place in our "Thanks to ..." section, no matter whether this will be a success or a failure. But of course we all hope for the final breakthrough. May the force be with you! :D
[HTC Wildfire S] tacromx:
@Bad-Wolf .

All the parts have arrived for the jtag build, everything is ready for the build. i have to visit a friend this week who has a reflow oven, after that i'll get to work on dumps. i have oocd and toolchain compiled and ready to go.

I'm doing my best.

Meanwhile........

whilst compiling kernel 3.4, in the kernel config i came across this...

<*> Memory Technology Device (MTD) support --->

here's the submenu content......

--- Memory Technology Device (MTD) support

< > MTD tests support (DANGEROUS)

< > RedBoot partition table parsing

[ ] Command line partition table parsing (NEW)

< > TI AR7 partitioning support

*** User Modules And Translation Layers ***

< > Direct char device access to MTD devices

< > Common interface to block layer for MTD 'translation layers

< > Caching block device access to MTD devices

< > Readonly block device access to MTD devices

< > FTL (Flash Translation Layer) support

< > NFTL (NAND Flash Translation Layer) support

< > INFTL (Inverse NAND Flash Translation Layer) support

< > Resident Flash Disk (Flash Translation Layer) support

< > NAND SSFDC (SmartMedia) read only translation layer

< > SmartMedia/xD new translation layer

< > Log panic/oops to an MTD buffer

< > Swap on MTD device support

RAM/ROM/Flash chip drivers --->

Mapping drivers for chip access --->

Self-contained MTD device drivers --->

< > NAND Device Support --->

< > OneNAND Device Support --->

LPDDR flash memory drivers --->

< > Enable UBI - Unsorted block images --->

does this imply that there was no mtd support previouslly i wonder?

or is it just not implemented in the previous kernel?

I've had compile errors in cygwin, so im onto linbox tomorrow to try.

Ill keep you posted

*update*

the mtd drivers are Not enabled in kernel 2.6.35 by default,ill compile it later with that option enabled,install it,run the exploit and report the result.....later.....time for bed zzzzzzzz.... ; )
[HTC Wildfire S] jfin79:
HI have a question I have a vm wildfire cdma I gained s-off and unlocked bootloader and custom recovery but cannot gain root any idea why system still says read only is there a rom that includes su and superuser included so I can gain root
[HTC Wildfire S] seaskyways:
Please don't ask such questions here , this is a thread for the S-off , check the Android Dev forums to catchup some roms ! you'll find some !
[HTC Wildfire S] munjeni:
Do not waste your time with mtd dumps in order to use that dumps for restoring back to device via jtag! Mtd dump in comparation with jtag dump have big big big diference, mtd dump can not contain all blocks from nand flash, a lot of blocks you will se with 0xff data !!! Allready compared... !!!
[HTC Wildfire S] no.human.being:
So the kernel is indeed running kind of "virtualized" and firmware below us is "tricking" (or at least isolating) us, just like we expected. I wonder why they're not blocking everything but the memory that is used for the "normal" mtds.
[HTC Wildfire S] munjeni:
I think its amss, oemsbl or qcsbl thing - configured to no-grant access for us there, or to hide some regions, or to enable read or write access or to disable read and write access...etc, so I think its reason why we have 0xff data for some nand parts (its becouse non granted access there)...etc. I looking now in amss asembly for possible rpc calls for htc hd mini battery driver, and indeed there is some things about battery and a lot of other other things. I think key is in amss. Yestearday I found link few posts back to a lot of qcom documents... there is realy good documents that explain how security working in htc devices, what is qcsbl, what is oemsbl, what is appsbl, how device starting, L4 micro kernel...etc...etc...