yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
Against which HBOOT version should I check?

N.H.B. (no.human.being) btw .. NBH is the image format that is used for signed Android images. ;)
[HTC Wildfire S] munjeni:
:) sorry! You can use hboot posted by theq86 ! Paswords for all archives is in your pm... you can analyse everything
[HTC Wildfire S] theq86:
hboot_1.03.0000_cdf32d1_R2 from RUU_Marvel_HTC_Europe_1.66.401.1_Radio_47.10g.35.3032H_7.49.36.01M_release_209754_signed
[HTC Wildfire S] munjeni:
I reached number of thanks per day so thanks again for test!

God thing is that misc shell code is executed by fastboot getvar handler so that mean its not bypassed in wfs hboot version :), but something mising in misc, I still not understand some parts in misc, but I think we are so close to get it!
[HTC Wildfire S] no.human.being:
ROM:0000007C LDR PC, =0x9D0073C8 @ partition_update(bbbbbbbbbb, buf, 0x80000)

Seems strange. It sets program counter to a branch instruction.

73c8:	eb00138e	bl	0xc208

All other offsets at least point to the beginning of a function (saving registers to stack, etc.).

What is this "HBOOT-6.03.0000"? Is it an "HBOOT-1.03.0000" for which you've changed the version number to differentiate it from "stock" HBOOT or what? Or is there actually an HBOOT with a 6.x version number?

Well I know that feeling. My exploit is also close. Just need to know where in HBOOT code that "fallback" (restore from NAND) happens and then ensure that this never gets executed (overwrite either routine itself or branches to it with no-operations) and I believe that it would then get through and achieve S-OFF.

EDIT: Btw, I tried your HBOOT-6.03.0000 image as payload for my exploit and it crashed. So this is either due to the partitioning or there's something else "wrong" with it. Just wanted to mention.
[HTC Wildfire S] munjeni:
You can ask theq86 to give you info about partition tables from his runing rom... I dont think thats problem in hboot! Your exploit allso not working with htcdev hboot!

About version 6.03 I set it to 6 so to become un-overwriteable by an ota update.

About registers, maybe registers is diferent on every diferent hboot? How Revolutionary team found these registers and where/how ... I have no idea.

If you need, I will send you for analyse working aria exploit!
[HTC Wildfire S] no.human.being:
My "inject" exploit is able to patch both HBOOT-1.08.0099 (HTCdev) and HBOOT-1.09.0099 (HTCdev).

My "chainloader" exploit "works" with HBOOT-0.90.0000 (non-HTCdev) and with HBOOT-1.08.0099 (HTCdev) as payload (but both HBOOTs enter some "fallback mode" and restore original HBOOT from NAND - if I'd find the code where that happens I'd almost guarantee that we'd now have S-OFF). I've verified that they both begin booting and show their menu, but then restore "original" HBOOT from NAND.
[HTC Wildfire S] munjeni:
Strange! I have only not working htcdev hboot but on two diferent phones hboot restores

---------- Post added at 11:05 PM ---------- Previous post was at 10:56 PM ----------

Hey, theq86 said about rom marvel, but rom for your phone reguire marvel with s string? On shipedroms site there is 2 version of the roms, one is with s and another without s so maybe its reason for hboot failed to boot! What is diference?

---------- Post added at 11:14 PM ---------- Previous post was at 11:05 PM ----------

Did you removed misc exploit part from hboot 6.0 when you chainloaded it ?
[HTC Wildfire S] no.human.being:
It's first 0xb8 bytes right? No I didn't. But now I did and rebuilt and it still locks up.
[HTC Wildfire S] iuss:
These overlay the old stored R4-R11,PC on the stack when the sprintf overflows the mainver buffer. Read up on stack overflows and/or the (typical) ARM calling convention (ie. old value of R4-R11 must be preserved when returning from a function).

Doesn't seem to have a purpose.
[HTC Wildfire S] munjeni:
So you mean I no need to care about these registers ?

---------- Post added at 09:54 PM ---------- Previous post was at 09:51 PM ----------

Yes, you need to remove first 0xB8 butes!
[HTC Wildfire S] Antagonist42:
This may be of use until we can get hold of right one for our own chip or it may all still be in use (without specific docs to give info for references it's guess work) check Sig - under MSM6025 check out MSM60x5 AMSS Secure Boot Overview and also MSM60x5 AMSS Flash and Memory Layout ;)

Also added AMSS Board Support
[HTC Wildfire S] no.human.being:
Does anyone have an idea how we could approach to where the "fallback" (restore from NAND) happens in HBOOT code? I am quite sure that I can achieve S-OFF if I can prevent this "fallback code" from being executed, either by overwriting all branches to it with no-operations or by overwriting the code itself with no-operations but the HBOOT code base is large and we don't have that many hints where this could happen.
[HTC Wildfire S] munjeni:
Maybe search for "0x80000"... for example: restorehboot(buff, 0x80000...
[HTC Wildfire S] Antagonist42:
From what I can gather it looks as though flashing to the NAND is done under mARM/ARM9 whilst AMSS is running probably under modem/apps (modem applications), it looks like a continual loop for authentication between QCSBL, OEMSBL and AMSS (PBL authenticates QCSBL, in turn Auth's OEMSBL, which Auth's QCSBL) once this loop is in and AMSS already passed and running all AMSS checks is it seems is QCSBL which probably kicks off the whole security check for running commands etc.

Now if all the security checks are done on CRC/magic number(s)/Attestation Signature it may be that we need to know what/where Exploit HBOOT is being checked and maybe edit that if it's removed code where checks are done ---- just an idea
[HTC Wildfire S] no.human.being:
I'll try that. How does NAND access look like on the assembler language level? I guess just like RAM access, right? The two probably make up a common address space and the MMU decides whether a certain address gets resolved to NAND or RAM, what do you think? Any reliable sources (datasheets) on that subject?

EDIT:

Of course when you search disassembled code for "80000" you'll have lots of hits. Most of them look "accidental" as they're something like "0xa80000bc", however, when it comes to the value 0x80000 explicitely, there are only 13 hits total for HBOOT-1.08.0099.

2ee48:	e2033702	and	r3, r3, #524288	; 0x80000
31cf8:	e3a00702	mov	r0, #524288	; 0x80000
3cabc:	e3a03702	mov	r3, #524288	; 0x80000
486e0:	13855702	orrne	r5, r5, #524288	; 0x80000
48ce0:	13811702	orrne	r1, r1, #524288	; 0x80000
490dc:	e3a0c702	mov	ip, #524288	; 0x80000
60c80:	5393d808	orrspl	sp, r3, #8, 16	; 0x80000
664e4:	636e6920	cmnvs	lr, #32, 18	; 0x80000
66520:	636e6920	cmnvs	lr, #32, 18	; 0x80000
6bc04:	73746920	cmnvc	r4, #32, 18	; 0x80000
6d950:	43324920	teqmi	r2, #32, 18	; 0x80000
6d9f8:	43324920	teqmi	r2, #32, 18	; 0x80000
6da2c:	43324920	teqmi	r2, #32, 18	; 0x80000

Sadly, none of them is actually the word 0x00080000 on a specific address. I would have thought that they put it somewhere into the executable image as a word and then load it into a register. Like this.

0: b 0x8
4: 00080000
8: mov r0, #4
8: ldr r0, [r0]
...

As this is how compilers usually handle constants. But sadly no 0x00080000 machine word anywhere. The two hits at 0x31cf8 and 0x3cabc respectively look interesting though, as they explicitely move the value into a register.
[HTC Wildfire S] Antagonist42:
Page 88 from here for Memory Map
[HTC Wildfire S] no.human.being:
Perfect, that's exactly what I was looking for. Gonna look more thoroughly next time. :D
[HTC Wildfire S] artturnip:
Excellent! So are you nearly finished developing your exploit? :D
[HTC Wildfire S] no.human.being:
Exploit works, shell code does not. The exploit is what escalates your privileges and then runs the shell code, which in turn makes use of these privileges to achieve something.

This means we can use the exploit to load hacked HBOOT images (shell code), but hacked HBOOT recognizes that it's been modified and restores unmodified copy from NAND before we have an opportunity to talk to it via Fastboot (at the point where it restores, USB isn't even initialized on the phone).

We could try flashing by supplying a PG76IMG.nbh to hacked HBOOT, but this is risky and can easily result in a brick. Imagine what happens if HBOOT decides to "restore from NAND" when it's half-way through with writing a new HBOOT to NAND. It will restore from an image that hasn't been completely written and is thus very likely corrupted. Bootloader corrupted, thus brick, thus JTAG repair.

What I'd rather do is make the HBOOT run stable (especially prevent it from restoring) and then take the "soft S-OFF and Fastboot" approach. I don't know how to do that though, since I don't know how to find the code that does the restore. It will require A LOT of reverse-engineering.
[HTC Wildfire S] theq86:
Very unlikely it restores itself half-way. this would mean it restore's it's code WHILE flashing.

I'd like to test what happens if a PG76IMG.zip is present while your chainloaded s-off hboot is running. what happens first in every case is, that the zip is going to be uploaded into a temp memory on the phone. It is NOT directly applied from sdcard. I observed this behavior many times hen flashing a zip.

However, since a full rom zip is quite big, we could test if chainloaded hboot proceeds with the file or locks up just before.and if it recovers real hboot before flashing.

again, very unlikely it restores itself WHILE flashing.
[HTC Wildfire S] artturnip:
Ah... sounds like a lot of work... what about munjeni's exploit???
[HTC Wildfire S] theq86:
Basically, the overflow works, but somehow not in the expected way. seems the asm code does not get executed. hoever, the exploit may work but needs assimilation
[HTC Wildfire S] no.human.being:
We currently have no idea what issues the restore or how it happens. If mARM can read aARMs RAM, it could be, say, mARM issuing an interrupt, which could of course happen at ANY time. Or if mARM can even WRITE aARMs RAM it could even be that HBOOT doesn't restore "itself", but that Radio restores HBOOT (that would be bad of course, but I don't think mARM will write aARMs RAM).

We could flash an "uncritical" partition (say "recovery") though and see if it flashes successfully or restores before it starts flashing or restores WHILE flashing (don't think so, but don't want to try with HBOOT partition :) ).
[HTC Wildfire S] theq86:
yes, we should test it with recovery. it will tell us, if sig check is going to be bypassed. If you want me to test I'd be ready.
[HTC Wildfire S] no.human.being:
We'd have to do it with a locked bootloader then, since bootloader unlock removes signature check for recovey (or does it only remove it for the Fastboot command?). Gonna try it tomorrow, need to get up early and go to work. Currently no time for messing around with phone all night (would obviously do a NANDroid before and all that stuff). :D
[HTC Wildfire S] theq86:
Well, even with unlocked bootloader, if you have a PG76IMG it will be sig-checked. Otherwise they had to build in checks if only a system ,boot or recovery image is inside the zip. so they left sig check for rom.zip files independently of the content.
[HTC Wildfire S] munjeni:
N.H.B, on htc hd mini I had some tests with jumpspl, had spl_1.33 installed and after some tests I had spl_1.07 so I realy not understand from where these spl_1.07 come from? Its realy strange! After all I searched in whole jtag dump for string 1.07 but not found it, so realy not understand where is stored these spl and how I get spl_1.07 over 1.33... these is happened after unsucesfully write atempt so its like fail safe restored, but from where...and why version was diferent than version that was in nand + permanently installed? Only my wrong was I could not seen if that spl was ENG! If that was eng spl maybe that eng spl is stored inside an chip permanently? Nand chip have his own firmware? (I think yes because nand chip inside wfs/aria/photon/...etc is 8gb)
[HTC Wildfire S] *se-nsei.:
Any news on progress guys?
[HTC Wildfire S] theq86:
The end of my HTC Wildfire S has come. I sold it and some of my other devices for getting a Samsung Galaxy S3 :victory:

However, I will keep supporting this campaign and community. The only difference is, that I no do not have the device anymore.
[HTC Wildfire S] no.human.being:
Congratulations to your Samsung device and thanks for keeping the good work up.

Seems you missed the HUGE advance we made. We can now execute arbitrary boot code on the device!

The problem is that HBOOT is quite "tamper resistant", detects the changes we made and corrects them. Of course this code is also part of the boot code, so in principle we should be able to disable it. The problem is that we don't know where it happens and HBOOT codebase is quite large (more than 100k LOC).

Not true. S-ON HBOOT shows "signature verification" and then asks me whether I want to install the image. If it did actually check signature and it failed, it certainly would not ask me. I'm quite sure that CWM image is not signed, especially since I modified the image to match my CID and software version. :D

But for testing this did not matter. The "chainloaded" HBOOT doesn't even ask me whether I want to install the image. It reverts to "stock" HBOOT before and "stock" HBOOT then asks me. So passing PG76IMG.zip to "hacked" HBOOT is not an option. We absolutely NEED to prevent it from reverting.
[HTC Wildfire S] artturnip:
And we need JTAG debug access to do so???
[HTC Wildfire S] no.human.being:
Not neccessarily. If we had the manpower, we could cut for example the HBOOT code into a thousand pieces of 200 lines each, let one piece be analyzed by one person, who then publishes any interesting finding. But since we don't have that manpower, we'll either have to get JTAG working or it'll take an extremely long amount of time.

If someone has an idea please post.
[HTC Wildfire S] heavy_metal_man:
what if its not the hboot noticing that its being tampered with but following a script that it has to follow regardless. let me explain.

when hboot loads it checks for sd card files, 2 options present. 1: sd card item found- check image and request user permission to flash ( volume up).

but 2: item not found, add script not to check sd card again (into ram?) and "refresh" or "reboot" the hboot again. but this time it does not check again. maybe if it is issuing some sort of refresh command it is getting confused and restoring nand instead of the chain-loaded hboot?

also, with the j-tag voltage issues. if the device needs to be at a specific voltage could you not rig up the power to the phone battery terminals? logically this should be the correct voltage. i am not 100% on how the connections need to be made, could you possible post some pics of the current set-up and what we feel is missing?
[HTC Wildfire S] munjeni:
I think too! Hboot fail to find "sd" (pripherals off?) and rebooting by self to normal hboot or hang to unused (confused) state! So you need to patch hboot to stop looking for sd card... thats first that you need to do!
[HTC Wildfire S] beaups:
I think you are still missing the opportunity to test flash a zip file containing only nonfatal images. Create a zip file with only a system.img and see what happens?
[HTC Wildfire S] no.human.being:
Has already been tested by me and doesn't work. See here.

It reverts to stock before it even asks to install the image. I performed the test with a "recovery.img", not a "system.img", but that shouldn't matter. This is not "S-OFF related", since even the S-ON stock HBOOT asks me whether I want to flash the image, but the "chainloaded" one does not. It just reverts to stock (and therefore S-ON) and stock then asks whether I want to install the image.

The processor has it's own I/O voltage which is fixed at 0.9 V. This means that the I/O of the processor will always output 0.9 V as logical "high" and/or expect 0.9 V as input as logical "high". The interface has it's own I/O voltage which is fixed at 3.3 V. This means that the I/O of the interface will always output 3.3 V as logical "high" and/or expect 3.3 V as input as logical "high".

These voltages aren't related to the board's supply voltage (which is around 4 V) at all. They're probably generated from the supply voltage by voltage regulators on the board.
[HTC Wildfire S] heavy_metal_man:
So would it possible to attach some resistors to the output of the interface to drop the volts down? Or would it be expecting to receive 3.3v connection back?
[HTC Wildfire S] no.human.being:
The JTAG interface absolutely REQUIRES 3.3 V levels (it will see the 0.9 V that the processor provides as logical zero, thus OpenOCD complains that the "processor returns all zeroes").

But "normal" HBOOT then just runs fine so it seems that HBOOT just initializes the SD as part of its boot process. If "normal" HBOOT does so, "chainloaded" HBOOT should also do so, after all they're basically the same code.
[HTC Wildfire S] heavy_metal_man:
well that makes things much more difficult :( so we would need to up the power out of the processor by 2.4 volts. will the processor have any issues with that voltage or is it just the j-tag interface that has then requirement? all the jtag and riff boxs make it look so simple :/

so are we of the opinion the exploit has damaged something that we have missed in the hboot code? or that something else is interfering in our work? could we chain-load a recovery and see if it boots or would that just be equal to the first exploit where we loaded the cwm via fastboot? also just out of interest what would happen is we chain loaded another devices bootloader? would it just lock up?
[HTC Wildfire S] Antagonist42:
Right seeing as we're not finding some of the info we desire i'm doing a manual hunt(must be mental :silly: unless somebody knows a better way?) going through hboot files, the ones I have are hboot_0.90.0000_720d6ffc74 and hboot_1.09.0099_37fbb7a27f8a, what i'm looking for isn't a section of code but something smaller.... any address looking item that is carried through from early version to latest for eg.

loc_BC14	; CODE XREF: sub_B9E8+20Cj
LDR	R3, =0xEE1251
STR	R3, [R4]

Although both files are different in size and other address' are no match, chunks are carried over and are exactly the same even in code that has been changed so.... if you wanna have a gander at what I found up to now --> HERE (at the bottom of the post) <-- info is just pasted into .txt and mainly only address' but may be worth searching/watching for .... going to continue tomorrow as going :eek: :D
[HTC Wildfire S] no.human.being:
You don't do anything to the processor. You let the processor (with its 0.9 V) provide input to a circuit operating on a higher voltage. 0.9 V is sufficient for switching a transistor, so you could put the output of the processor to the contol gate of a transistor and let the transistor "switch" the higher voltage. You need another transistor before this "output stage" though, since a single transistor always acts as an inverter (turning "low" to "high" and vice versa) as it is "enabled" by the processor providing a "high" signal and "enabling" causes current to flow to ground, therefore making the interface see "logical low" when the transistor is enabled and "logical high" when it is not. So "high" on the input always produces "low" on the output. Therefore you need a second transistor stage for each line to invert the signals once more, effectively reproducing the original digital signal on a higher (or lower) logic level. Of course you need this arrangement for every signal line.

Most likely, yes. Imagine what would happen if you were to flash another device's bootloader. It's the same here, only volatile.

Would another version (I'm on 1.08.0099) be of any help? Oh man, HBOOT must in fact be an INCREDIBLY trivial piece of code in a high-level language like C, considering that the "inject" exploit is already larger when compiled than HBOOT itself. Most likely there's absolutely nothing about HBOOT that's actually complicated, it's just that in assembly language everything becomes extremely unwieldy.
[HTC Wildfire S] Antagonist42:
Not trivial but more simply seperate parts, seems as well there is what looks like 'unused' code in hboot but that code could be what AMSS or QCSBL may read 'after' hboot is loaded as IDA doesn't seem to find pointers to all of it, seems odd it would be left in if it's not used by hboot although I could be wrong it's just an idea as I see it in IDA
[HTC Wildfire S] Mazer.one:
Thanks for all your works on our wfs and like nhb said congratulations to your galaxy s3. ;)
[HTC Wildfire S] VigiDroid:
Is it possible to, say create a circuit between the two, powered by a nine volt battery reduced to 3.3v using resistors. Then use transistors with the base to the 0.9v pins and then connect the emitter pin to the interface and the collector to the circuit so when the 0.9v flows through the base a larger current (3.3v from battery) flows to the interface. Sorry if this makes no sense my knowledge of electronics is limited and I am still learning :)
[HTC Wildfire S] samiam0295:
Problem is a battery would drain. You would be better off finding a power source with the appropriate amp output
[HTC Wildfire S] munjeni:
Please give me link to an wfs jtag dump... going to flash it and test misc exploit!
[HTC Wildfire S] Tera Tike:
Would this work??

Voltage Level-Shifter or the attached.

Still learning to.
[HTC Wildfire S] mstfkaratas:
I don't know if this is what you are looking for. Here is two files i found on internet, it becomes 528 mb when extracted, its format is .bin

link: http://www.general-files.com/files-w/wildfires-full-alive/

edit: it has 0.90.0000 hboot inside file when i open it with hex editor, it is full memory dump from a WFS but i dont know if it is compatible with jtag
[HTC Wildfire S] munjeni:
You can debug whats going with chainloader by using this? -> http://forum.revskills.de/viewtopic.php?f=10&t=123

Edit:

Tried wfs jtag dump in Aria, got it non working:(
[HTC Wildfire S] Antagonist42:
HBOOT 0.90 1.09 eyeballing

another load done... hardest thing is realigning code from the 1.09 changes once you hit the changes lol

updated .txt file --> HERE (at the bottom of the post) <--

Plenty of address' to keep an eye on lol
[HTC Wildfire S] einstein.frat:
Just used a vnc xploit to soffed a pc ren logonui.exe win.com to bak, have fun. Works like a subseven. Except open cds matrix mode etc.

I like this site. :what:

Just bored... Nm

So jtag can only debug, or what does it have a shell or config, tell me about it?
[HTC Wildfire S] theq86:
what the heck ...

don't troll around here.

if you really want to know about jtag then please google the basics and don't waste our time :rolleyes: