yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
Don't think so. They say that you can access logs (probably kernel logs - our exploit runs before an actual kernel is even loaded) and talk to SBL (when our exploit runs, SBL is no longer running).

Just in case you are actually interested. JTAG is a "protocol" that a "debugger" (computer with suitable interface and software) uses for talking to a "target" (processor). Most microcontrollers have built-in JTAG support to enable debugging.

JTAG itself doesn't "have" anything like "a shell or config". It's basically just a feature that the processor supports. You need to run a suitable debugging software (OpenOCD) on the host and this one has "commands" (like upload code to the target, set breakpoint, reset target, etc.) but it's not like you hook it up and are ready to use it. You have to get extremely "involved" with this before you can use it for anything. Basically, before you can do anything with OpenOCD, you have to precisely describe the processor and board to it. Things like which clock speed does the processor use, which clock speeds do the peripherals use, to which address in memory does which I/O map, which memory device is connected to which bus on the processor and so on. This is all physical layer (hardware) stuff.

The thing is once you got all this, you essentially have full control over the entire system. You apply power to the target and the debugger will keep the processors in a halted state. Then you can execute each instruction individually on all processors (aARM, mARM, DSPs, ...), modify contents of registers, RAM, NAND, etc. in between. The problem is that it's extremely hard to get that far. So far I haven't even established JTAG signalling on the physical (electrical) layer (processor is running on too low voltage).
[HTC Wildfire S] Antagonist42:
Interesting chunk found in the hboots, first section that seems to be 'complete' address-to-address from one version to another, i'll keep dropping a post after I update the file (if I could only spend a few days on this to get it done and not the few hours here and there :mad: )

After trying to realign code after 200 or so pages couldn't match so start from the end and work backwards now :laugh: :crying:

so here's BinText of hboot 0.90 and hboot 1.09 ....and 0.90 there's no mention of *** UNLOCKED *** *** RELOCKED *** in hboot 0.90 although I would not discount this not being on a phone with an updated RADIO/AMSS depending on date of production.
[HTC Wildfire S] BeciMester:
0.90 is from a time when HTCdev unlock was not available for the WFS yet, so the hboot wasn't expected to display such things. :) Also in 1.09 you'll find the new code that handles the unlocktoken, the fastboot command interpreter was also changed to include the new commands related to htcdev unlock etc.
[HTC Wildfire S] no.human.being:
Here the exploit code again for BeciMester testing (attached to post, key comes via private message).

Make sure you build it correctly (you'll need an "arm-none-eabi" GCC toolchain for this). Build instructions for a Linux machine are in source code as comments. The "payload.bin" I describe in the comments is the shellcode, the "hacked HBOOT" you want to execute via the "chainloader" exploit. You can generate a hacked (S-OFF) HBOOT for your phone using exploit-inject and use this as payload. I could provide it all bundled and ready for my phone, but since there are different revisions of the WFS with different firmware it's best if you specifically "let exploit-inject generate a payload from your firmware" and use this as the shellcode for the "chainloader" exploit, since firmware from other WFS devices may not run on your phone.

When you execute the combined "exploit + shellcode" via Fastboot, make sure you hold Vol-Down when issuing the Fastboot command and continue holding it until you (hopefully) see an HBOOT screen stating S-OFF. If you do so, the phone should show HBOOT screen with S-OFF and then either lock up or revert to S-ON though. On my device it locks up when you have no SD card inserted when performing the exploit and it reverts to S-ON when the SD card is present. If you do not hold Vol-Down while performing the exploit, the shellcode (being itself a bootloader) will boot the phone straight into the ROM. If you hold Vol-Down and no SD card is present, it will show HBOOT screen stating S-OFF and then lock up (HBOOT will show "S-OFF" and mode "HBOOT", not "HBOOT USB" since it locks up before USB is initialized and it won't respond to any key presses). If you hold Vol-Down when an SD card is present, it will show HBOOT screen stating S-OFF and then either boot into your ROM after a short period of time (when you released Vol-Down when the screen stating S-OFF appeared) or will restore "stock" HBOOT from NAND, therefore reverting to S-ON (when you continue holding Vol-Down when the screen stating S-OFF appeared).
[HTC Wildfire S] :
Anyone ever try the exploit above combined with the pg76diag on gold card that CDMA used to soff I read it was searching sdcard
[HTC Wildfire S] no.human.being:
No. Btw, even "stock" (S-ON) HBOOT will jump to DIAG. Wasn't expecting that.

EDIT: Oh no, DIAG didn't just wipe my phone, did it? Aaargh!!! Of course I don't have a recent backup. Don't run DIAG on your phone, it will wipe your data partitions without notice. :(
[HTC Wildfire S] rezo:
Yes, diag works with the s-on and s-off phones.

For the GSM phones:

- It is used to calibrate the touchscreen after replacing a digitizer.

- It wipes userdata and talktime.

- It fixes the USB brick because it clears some parts of the misc partition (it sets board_marvel.usb_h2w_sw=0).

- It operates in a different way with a SIM card in...

- ... and/or (strange) setting diag.enabled=1 in the misc partition (0x0000C40). (Clearing S58 data doesn't reboot the phone, etc...)
[HTC Wildfire S] csoulr666:
You didnt know?????? I knew it from the time when we just started using the diag files(WAY before our bootloaders were unlockable)......never used them since
[HTC Wildfire S] rezo:
BTW... Do we know where s-flag is in the Wildfire S? I have a fullflash from the phone with 4096 pagesize. Like munjeni wrote, I found that string at 0x00841020. What about 2048 pagesize phones? Is it in the same place?
[HTC Wildfire S] no.human.being:
No, I thought DIAG was a DIAGnostic utility used by the OEM to DIAGnose firmware and/or hardware problems. Why should one expect a DIAGnostic utility to FORMAT THE DATA PARTITION WITHOUT ANY WARNING? :confused:

Oh man! I didn't think it would write anywhere without explicitely asking it to do such a thing. But it seems that just RUNNING the utility (without even selecting ANYTHING from the menu) already causes a reformat of the data partition. As such I didn't backup ANYTHING before I run it, which means that I don't have a recent backup of ANYTHING. I didn't select anything from the menu, since I thought "oh 'Clear S58' sounds dangerous, let's better do a NANDroid backup", but it was already too late. Now I have a NANDroid backup of a freshly formatted data partition. Soooo incredibly useful! :D

So now again for all people that didn't know :D : RUNNING THE DIAG UTILITY WILL IMMEDIATELY WIPE YOUR DATA PARTITION! Don't be stupid like me and do it without a recent backup. :D

What the hell?!

Just good that I don't have anything on the phone that's actually important. There's gonna be a lot of "me asking people again for their numbers" in the next weeks though since I didn't have the "backup my data in the cloud" stuff enabled. :(

BTW @BeciMester: Any news? Don't hurry, I know it takes time and the codebase is large. Just would like to know if you got the exploit built and running in principle.
[HTC Wildfire S] heavy_metal_man:
did you clear the s58 data? if you do it will in theory give you super cid and sim unlock, also that will tell us if the diag attempts the s-off before or after the clear s58 data command ;) if you did it already try the command fastboot getvar cid. if that has worked, which it will usually not if a device is s-on, then the utility would be recognising that the device is definately s-off. maybe we could patch the diag file?

also just incase there are others who are not aware the xtc clip guys do NOT recommend using this tool on custom firmware, but why i dont know.

Just to clarafi with the sensation once we have s-off we can run the diag file for our phones to give super cid and sim unlock so I know it will work if the phone registers as s-off :cool:

PS. N.h.b if I was you I would check your Google account anyway to see if your contacts are there, if you have ticked back up ( or not ticked dont back up) at any time your stuff should still be on there. Its scary how much info their back ups hold....
[HTC Wildfire S] no.human.being:
I first didn't do it since I was afraid I'd lose some data. Then I did a backup (but data partition was already wiped so DIAG WILL WIPE JUST BY EXECUTING - YOU MUST NOT SELECT ANYTHING, JUST RUNNING DIAG WILL WIPE DATA) and rebooted phone. Recognizing that data partition was already wiped I thought "well now you cannot lose a lot" and chose "Clean S58", but it didn't succeed.

Btw, "chainloaded" S-OFF HBOOT will not run the DIAG file. It will fallback and I was very quick to remove the SD card then and it booted into ROM. :D
[HTC Wildfire S] rezo:
no.human.being, could I look at your exploit?

BTW...

There is a line in hboot "MARVEL PVT SHIP S-ON RL". Do you know that in WFS after unplugging that smallest ribbon from mainboard you get "MARVEL PVT SHIP S-ON RH".

What the hell RL/RH indicates? Anybody knows?
[HTC Wildfire S] no.human.being:
You do not accept private messages, therefore I couldn't even send you a key.

The L/H probably for "low" and "high" (logic levels) respectively? Radio low, radio high? Resistance low, resistance high? Don't know! :D
[HTC Wildfire S] rezo:
I changed that option in my profile. You should be able to send PM now. I'm sorry for that.

There is one more possibility: RIL. So we have RH,RL,RIL.

PS. "radio incredibly low -3,3V" :):) Just kidding.
[HTC Wildfire S] heavy_metal_man:
Ah, So you were running it on stock s-on hboot? Hmm. Any luck with a custom JTAG set up?
[HTC Wildfire S] no.human.being:
I just know that RIL = Radio Interface Layer (the interface between the Linux kernel in Android and the Radio firmware), but that's probably not the same RIL. :D
[HTC Wildfire S] theq86:
Might also be a service information to see if the customer already opened the case nd played around with the cables inside
[HTC Wildfire S] no.human.being:
I've tried doing similar coprocessor bashing (invalidating caches, disabling MMU, etc.) before executing HBOOT again, but the result is still the same. (HBOOT loads and then "falls back".) I think that HBOOT already does it on its own when booting a kernel, as it is a prerequisite for running Linux (or probably not, since it's in the kernel code?).
[HTC Wildfire S] rezo:
BTW...

In the some undefined states, the WFS can't load some things... the graphic driver, the bootloader version...

The way to enter that state:

1. Run DIAG.

2. Click "clean s58 data -> OK" and remove the battery after 5-7sec.

3. Put the baterry in and prepare your hands :)

4. Press Vol- button (all the time).

5. Pressing Vol- button, plug the usb cable in.

6. Still pressing Vol- wait about 1 second for the orange LED.

7. Still pressing Vol-, press the power button 0,5 second after the orange light appear. (for few seconds)

8. After 10 seconds the phone vibrates once.

9. You can release your hands and wait :)

Is any way to boot directly to hboot, or enter hboot from fastboot with usb commands (buttons don't work)? Maybe, if the bootloader version is inaccessible we could flash the RUU with 0.90 bootloader? :)
[HTC Wildfire S] munjeni:
Kernel have allso! And allso some coprocessor things is on begining of the hboot so hboot allso doing something there! Did you tried to modify/compile/boot legacy bootloader from android source three using your exploit?... just for idea.

This "red" is first instruction in hboot:

[COLOR="Red"]B loc_9D000050[/COLOR]
loc_9D000050:
MRS R0, CPSR
ORR R1, R0, #0x80
MSR CPSR_cf, R1
/* aux control */
MRC p15, 0, R0,c1,c0, 1
ORR R0, R0, #0x80000000
MCR p15, 0, R0,c1,c0, 1
////////////////////////////////////
MOV R0, #0
MCR p15, 0, R0,c7,c10, 4
/* control - enable FIQ */
MRC p15, 0, R0,c1,c0, 0
ORR R0, R0, #0x200000
MCR p15, 0, R0,c1,c0, 0
/////////////////////////////////////
MOV R0, #0
MCR p15, 0, R0,c7,c10, 4
/* remap 2GB@0x80000000 peripheral port */
MOV R0, 0x80000016
MCR p15, 0, R0,c15,c2, 4
////////////////////////////////////////////////////
ADR R0, loc_9D000098
BL loc_9D000410

loc_9D000098:
ANDMI R0, R0, R0
SBCNE R0, R0, #0
LDREQD R0, [R0],-R4
STCMIL p0, c0, [R0]
ANDCS R0, R0, R0
ANDEQ R0, R0, R0,LSL#1
STRPLB R0, [R0]
...

so maybe hboot fail from there because its allready "in set" because device was not rebooted? Maybe you can try to "nop" some instructions...

Wauuuu great dude... its a way for sure for installing hboot 0.90!!!!!!!!!!! Allso before everything misc partition need to be modified too (version string)!!! On aria I have problem to clean s58 data (still not working without xtc clip because these diag file working only if special sim is present... I am unable to do something using only diag file)
[HTC Wildfire S] heavy_metal_man:
If you patch your device s-off with your jtag the diag file will run Without the xtc clip pal.
[HTC Wildfire S] munjeni:
Ok, but what is sense with diag file after I have patched everything with jtag? :)...right?
[HTC Wildfire S] heavy_metal_man:
Well it also resets the device by wiping the user data and on some devices like the wildfire s it recalibrates the screen as well. Like a proper diagnosis file should

:D
[HTC Wildfire S] rezo:
So... I interupted radio flashing to get to the RUU recovery mode (direct boot to ruu mode). I did the above trick and any information about hboot disappeared. If we can flash RUU without the main version number, why don't try with the 0.90 bootloader. Unfortunately, there is also the platform check during updating hboot... And that was empty... :D

Any ideas?
[HTC Wildfire S] no.human.being:
Btw "fastboot flash zip". Any idea why this does not work?

# ./fastboot flash zip PG76IMG.zip
sending 'zip' (157838 KB)...
OKAY [ 19.935s]
writing 'zip'...
(bootloader) adopting the signature contained in this image...
(bootloader) signature checking...
FAILED (remote: not allowed)
finished. total time: 58.131s
#

The file is extracted from an RUU so it should be signed. Bootloader is relocked via "fastboot oem lock" (afaik RUUs require this). Putting the file on SD card (even if it's a gold card) doesn't work either. It "loads" and "verifies" the file, but doesn't install it. I tried installing an RUU with a 7.57 Radio since I'm still on 7.53 and experiencing extremely poor reception since the last few days. Most likely the mobile network base station where I live has some problems and thus it has to go one station further away and the signal is weak, but I thought I might try if it improves with a newer Radio, but it won't install.

I cannot install it via RUU since the RUU doesn't recognize the device, so I thought flashing the zip via bootloader might work, but as it seems it does not. Any idea?
[HTC Wildfire S] rezo:
It works only in the RUU mode. Type: fastboot oem rebootRUU.
[HTC Wildfire S] BeciMester:
All the information missing from your list is directly copied from the first 0x50 bytes of hboot:

9D000000 12 00 00 EA 31 2E 30 38 2E 30 30 39 39 00 00 00 ...Û1.08.0099...
9D000010 37 32 32 37 20 53 50 4C 00 00 00 00 00 00 A0 E1 7227 SPL......áß
9D000020 53 48 49 50 00 00 00 00 00 00 A0 E1 00 00 A0 E1 SHIP......áß..áß
9D000030 48 42 4F 4F 54 2D 37 32 32 37 00 00 00 00 A0 E1 HBOOT-7227....áß
9D000040 36 65 32 30 62 36 66 61 00 00 00 00 00 00 A0 E1 6e20b6fa......áß

version-bootloader is at 0x9D000004

platform is at 0x9D000030

commitno-bootloader is at 0x9D000040

How can they be missing/zeroed and your hboot still work?! It looks like the old hboot was wiped in the radio area but the new one hasn't been written yet, and it works from RAM now... :eek: I hope you haven't bricked your phone. Did you reboot? If not, don't! EDIT: nvm that didn't make sense :confused:
[HTC Wildfire S] rezo:
Hboot operates so it is still in its place... But somehow, the phone cannot read any information about it.

And one thing... Everything is very slow in that state. Look at the times from the log.
[HTC Wildfire S] no.human.being:
Thanks. I'm on RADIO-7.57 and HBOOT-1.09.0099 now. Weird thing is, I'm still on my "old" partition layout. Didn't we say that Radio and HBOOT contain the partition tables?
[HTC Wildfire S] munjeni:
N.H.B I think you have wrong gold sdcard or you doing something wrong... your phone must be updated trought gold card for sure but why that is not happened I realy don't understand...

You must to know: Hboot in zip with lower version than installed hboot version will fail installation completely! If gold card is wrong (that mean your sd card is threated as a standard sd card and not gold sd card) you will be abble to install zip ONLY if zip contain cid that match cid in your phone! But with right gold card (that mean your sd card is threated as a gold sd card and your phone now have super cid 11111111) you can install every zip but again ONLY "if":

- If zip contain hboot lower version than installed hboot version instalation will fail!

- If version string in misc partition is biger than version string in zip installation will fail

Radio version in never checked...etc...etc, so to get success in instalation you need:

- change version string in misc partition to 1.11.111...

- double check your gold card

- fastboot oem lock

- zip must be unmodified!

- double check if hboot version in zip is ">=" installed hboot version

- if { you are not sure if you have "right" gold sd card, than you need to check if your zip contain cid that match your phone cid

- } else { if you are sure that you have right gold sd card than you no need to check cid }:)

If you get sucess than you can try method by rezo to bypass hboot version in order to install lower version hboot like 0.90. Allso you can try to install zip "diferent partition layout". What is use of hboot 0.90, is it enginering hboot?

---------- Post added at 08:40 AM ---------- Previous post was at 08:34 AM ----------

Good thing is hboot version not exist so I think hboot version will be treated as a "-1" or "0" or at least "char" readed as an interval... If hboot is stuck in ruu mode than you can try:

fastboot oem gotofastboot

fastboot oem gotohboot

and I think installation will continue from sdcard if zip is there!
[HTC Wildfire S] no.human.being:
I managed to flash the image via Fastboot RUU mode (instead of putting it on SD card) so problem is solved. Do "fastboot oem rebootRUU", then "fastboot flash zip PG76IMG.zip" and it will flash successfully. You will have to flash it TWICE and MUST NOT reboot phone between the two consecutive flashes. At least that's what Fastboot will tell you. The second flashing will take MUCH longer and Fastboot will print A LOT MORE to the screen.

No, but HBOOT-0.90.0000 is the oldest non-ENG-HBOOT that's available for the phone. At some Radio version, the RPC call that queries for the secu_flag has been changed and if you have HBOOT-0.90.0000 (which is HBOOT BEFORE that change) and a new Radio (AFTER that change) HBOOT will do an incorrect RPC call and the Radio will return 0, thus HBOOT thinks the phone is S-OFF.

Because of this "bug", you usually cannot downgrade to anything below HBOOT-1.03.0000 (which already uses the "new" RPC) but if you manage to install a "new" Radio and HBOOT-0.90.0000 together on the phone, you will be S-OFF. You will lose S-OFF by updating HBOOT though (since that will correct the RPC call) and once you go to HBOOT-1.03.0000 or newer you cannot go back (or at least the way of going back is not known).
[HTC Wildfire S] munjeni:
with trick by Rezo I think you can flash hboot 0.90 trought gold card because hboot version string not exist after that trick and hboot will think that you have older version of the hboot installed than 0.90 !
[HTC Wildfire S] no.human.being:
Remember that you need both an old HBOOT and a new Radio (so you need an HBOOT and a Radio that "don't match"). The images always contain both, don't they? Or will Radio not downgrade when you have newer?
[HTC Wildfire S] munjeni:
Yes they contain both... radio have no version check... but I not understand now how you think to install only hboot_0.90, its not posible without htc rsa key (key for signing zip)... so you need to forget hboot_0.90 and focus only on hboot hacking, if you found a way for overwriting hboot on nand (or temp runing hboot from exploit) than you have all done!

I want to ask now... did you tried to call an hboot function for example function "reboot to recovery" using your exploit? Or you wasting your time without real tests? Did you analysed misc exploit and tried to fix? For example why you dont buy an "comfirmed working" box and make real test to your device so if you brick it you can easilly unbrick...?
[HTC Wildfire S] no.human.being:
It's possible. People who were still on HBOOT-0.90.0000 (there are not many devices still on that version) found some "special RUU" with a "rom01.zip" and a "rom02.zip" or something like that and if you only install the second without installing the first you have new Radio and old bootloader and are S-OFF or something like that. It's mentioned somewhere in the xda forums but like I said most people couldn't do it since no one has HBOOT-0.90.0000 (you'd need a phone with very old production date that has never done an OTA to have that HBOOT version since an option to downgrade HBOOT was not known) and obviously updating to anything newer than HBOOT-0.90.0000 will make you lose S-OFF.

If we know where the "fallback" happens I think we just have to overwrite the branches to that function with no-ops and then we're done, but I have no good idea how to find this systematically. I tried issuing commands for disabling MMU, caches, etc. so that the processor is actually in a state like when it's booting for the first time (apart from contents of some registers, but HBOOT probably won't check these since it uses most registers straight away for its own purposes) but it still falls back. If we know the difference in processor state between "exploit run, then bootloader run" and "bootloader run straight" we can probably make the exploit put the processor in the correct state before running chainloaded HBOOT, what do you think?

Oh man, I need JTAG access. If I got that, I could trap the aARM when HBOOT begins running, investigate processor state, then run exploit, trap aARM when HBOOT runs after exploit, investigate processor state, compare both states and then we'd probably see some difference and could probably derive what we have to do in order to get HBOOT running after exploit without "falling back".

Overwriting HBOOT (at least with anything other than an "unmodified, original" HBOOT) in NAND is dangerous since there are indications that Radio signature-checks HBOOT (remember the bootloader is part of the Radio area in NAND) and will probably refuse to load a "modified" HBOOT resulting in a brick (would require JTAG to fix since bootloader won't be loaded anymore so you cannot flash anything anymore). Obviously, if we can run ("chainload") HBOOT from RAM we avoid that issue. Could we write the "orignal secu_flag" in the Radio from our exploit if we disable the MMU?
[HTC Wildfire S] no.human.being:
Too large investment for the crappy phone. JTAG equipment is not cheap and I already invested a lot. :D

Now that I know that I can get back to "factory state" via RUU mode I might rather consider selling the phone and get my hands on a piece of proper (non-HTC) hardware.
[HTC Wildfire S] munjeni:
I not agre because right box you can use with new phones/old phones too, so investition to an good and compatible/future_useable/always_compatible (for example Segger Jlink Edu that costs 40eur) I think have sense! You will not waste your money and your time for sure!