yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] beaups:
Who filled up the other 346 pages of this thread? Do you even know what you are doing? Looking at your recent posts, it sure doesn't look like it.
[HTC Wildfire S] no.human.being:
This thread is about the HTC Wildfire S. He means that there is no team (yet) for the HTC Explorer, it's just him.
[HTC Wildfire S] beaups:
Ah, my bad. I retract my comment, at least the first part of it.
[HTC Wildfire S] #define:
Actually you're right.. I have very little/almost no idea of what I am doing... I am trying to learn what to do along the way, and how to do it..

I just understand the principle of the chainloader exploit, and a little bit of how it works, and even "littler" of how to apply it to my device..

This is just an effort, by a rather "under-knowledged" person.. I bought the explorer as my first droid.. But i didnt know what I was getting into.. But now that I have it, I might as well try.. The thing is, the people over at the Explorer forum are, how you say, "noobs".. We dont have the knowledge, that urself, NHB, beci_mester, theq86, munjeni, antagonist42, and other the contributors at this forum have.. But if we can get a little help from you guys, then with that help, and the 346 pages of this thread, I'm sure we can do it.. :)
[HTC Wildfire S] :
I'm probably going to get a riffbox some time soon, but what would I do/need from that point?

Sent from my Baconator Over-9000
[HTC Wildfire S] heavy_metal_man:
Allowing you have the device you would need the adapter for the wildfire s, to work out a way to rig the battery to the motherboard when the phone is stripped and the chain loader exploit I think. If you manage to get everything set up correctly then it would be a matter for performing the chain loading exploit and "capturing" the results to see what is returning the stock bootloader. Assuming the riffbox has the support it says, I believe that you can step by step the processes to the processor which will allow us to see exactly what is causing the issue and patch the issue. Thus gaining s-off :cool:
[HTC Wildfire S] schlund:
nhb please share the binary you are loading, seems your hboot simply needs to be hacked to stay in bl/fb mode ;)
[HTC Wildfire S] :
What do you mean by adapter for the wildfire s? If it is separate where do I get it?

Sent from my Baconator Over-9000
[HTC Wildfire S] no.human.being:
JTAG interfaces (Riffbox, etc.) have a 20-pin JTAG connector, which you won't find on the board of the phone for obvious reasons (it's too large). JTAG on the phones is just available as signal traces on the PCB. The "JTAG adapter" is a (phone-specific) circuit board, which has a 20-pin JTAG pin header to connect to a JTAG interface and small needles that pierce through the insulation on the phone's board to "tap into" the JTAG traces.

The JTAG adapter for the Wildfire S is available through this Polish distributor. On the picture you see the 20-pin JTAG header. On the other side of the PCB you have the needles. To perform JTAG debugging on the phone, you need to open it up and remove the board, disconnecting all peripherals such as LCD display, etc. Then you press the JTAG adapter against the board using considerable force so that the needles can "cut through" the insulation and tap the JTAG traces. I used a pair of strong clothespegs to keep pressure on the needles while debugging.

The second problem is that, after you have disconnected everything from the board to remove it from the phone, you won't have a battery housing anymore. The phone will only boot if there's a battery connected (or at least it think there is a battery connected). If you want to avoid connecting the actual battery, you'll need to "emulate" it. "Emulation" must be fairly sophisticated using a regulated DC supply adjusted to 4 V (a Lithium cell has a "nominal voltage" of 3.7 V but it may go to about 4 V when fully charged) and several resistors. I have described the setup here.

Note that you only need a Lithium cell to boot the phone (which you need to do if you want to debug the boot code for obvious reasons). JTAG works without Lithium cell as long as power is provided via USB. This way you can use JTAG to program the phone (write stuff to NAND etc.) but for booting you will need to provide (or emulate) a Lithium cell.
[HTC Wildfire S] schlund:
thank you. attached a dirty hacked hboot for testing, i removed several "enter"-options only left fastboot mode .. just to see if it works

(password as known)
[HTC Wildfire S] no.human.being:
I cannot test the code as I don't have a Wildfire S, but what exactly did you change? Seems that some pointers are now pointing somewhere else. Aaah, you made that thing always jump to Fastboot mode right?
[HTC Wildfire S] schlund:
uff, so i need some instructions how to use the loader.

what i have done is quite simple, i have changed this kind of "switch case" function.i made the locations of every case stored in 32-bit words to the "fastboot" location, so it has no other possibility than entering this one.

EDIT (as addition to your edit): yes ;)
[HTC Wildfire S] no.human.being:
Yeah yeah, I've seen it now. Forget the thing I said about page tables, they look similar but are stored at a lower address.

Using the chainloader exploit is not THAT difficult.

The word at 0x4 is the physical address where the shell code (HBOOT code) will lie when the exploit is running. If you use the "mkbootimg_wfs" utility, it's usually 0x12c08000 (address where the kernel will be loaded by the bootloader on the phone, you'll find this as a little-endian value in the boot image at offset 0xc) plus the size of the exploit code (which is 0x88 bytes if not modified) for a final value of 0x12c08088.

The word at 0x8 is the address where the chainloader exploit will move the shell code to before executing it. This is where the boot code will physically end up in memory and should be left at zero.

The word at 0xc is the size of the shell code in bytes. This is 0x80000 (524.288 bytes) for a normal HBOOT image, since this is the size of the "hboot" partition in NAND.

Remember that all words are little-endian so you'll have to write "88 80 c0 12" in your hex editor for address 0x12c08088 and "88 00 00 00" for 0x00000088 shell code size. What the exploit does is move <word at 0xc> bytes in memory from physical address <word at 0x4> to physical address <word at 0x8>, then disable MMU, caches, etc. to make it appear as if the processor is coming out of a reset and then set the program counter to the address where the code has been moved to (<word at 0x8>).

To combine the exploit with the payload, just concatenate them.

cat loader.bin hboot_109.img > chain_109.bin

Next create an empty ramdisk.

echo "" > initrd

Make a bootable Android image.

./mkbootimg_wfs --kernel chain_109.bin --ramdisk initrd -o chain_109.img

Put the phone into Fastboot mode, then boot the image.

./fastboot boot chain_109.img

Start holding "Vol-Down" when issuing the Fasboot command to make sure that the "chainloaded" bootloader does not proceed booting into the ROM. In our tests, it would show its boot screen (our "hacked" HBOOT will show "S-OFF" and an "*** INJECTED ***" banner at the top) for about a second or so, then it would revert to "normal" S-ON HBOOT which will show its boot screen in case you're still holding Vol-Down or just boot into the ROM if you released the Vol-Down button in the meantime.
[HTC Wildfire S] schlund:
great, ty, sounds simple, one final question, could you attach the "mkbootimg_wfs" utility ? :D
[HTC Wildfire S] no.human.being:
Of course. Credit goes to xda-member "pther", who created this wonderful utility. :D
[HTC Wildfire S] #define:
Please dont mind this little OT..

But thanks a million NHB..!!

You are teaching me more than my college professors... :D
[HTC Wildfire S] artturnip:
Right... nhb... can you say with a good amount of belief that this won't brick the phone? :D

If so, I'll be happy to test this if given a tutorial for a noob who doesn't even use Linux as his OS :p
[HTC Wildfire S] no.human.being:
As long as the boot code has no reason to flash anything (no "fastboot flash ..." instruction and no "PG76IMG.nbh" on the SD card) it should not brick the phone.

I think "schlund" can test this himself. At least his signature says "Devices: HTC HD MINI (CM 7.2) | HTC WILDFIRE S (CM 7.2)" so it seems he has a WFS.
[HTC Wildfire S] schlund:
well, my phone was just "s-off" but to use fastboot boot command i had to unlock it, too, of course in a way without losing warranty ;)

so this took me some time.

finally i was able to test, but unfortunately it wasn't sucessful, yet.

have to do some further research

EDIT: Found out that i have to edit "default" case (seems that this is the case we jump into, cause that pointer to 0x9d0742b0 is empty (well, not "empty" but filled with 0xFF)

it stays in hboot now (no sd checks anymore) and shows "FASTBOOT", as expected. unfortunately usb is not working and we cannot use the keys.

but honestly, thats what i have expected, too :D (known from my other device). we have to hack it now to autoconnect usb in fastboot mode.
[HTC Wildfire S] no.human.being:
Wow that sounds GREAT! I'll give you thanks as soon as I have some available. :D

USB connection does not work because it's initialized by the code that gets "skipped" when going straight to Fastboot mode?
[HTC Wildfire S] artturnip:
Seriously... I'll test if you want me to... l:D
[HTC Wildfire S] no.human.being:
@schlund: Are you sure that the problem is actually "USB and keys not working"? I mean how can you distinguish between an HBOOT that is neither responding to USB nor responding to keypresses and an HBOOT that has crashed (e. g. entered an infinite loop)? Both won't show any "signs of life", will they?

If you have followed the thread for a long enough time, you'll know that even without your modification, when there is no SD card in the phone, HBOOT will show its menu and then "crash" (enter an infinite loop). When there's an SD card in the phone, it will check it for the "PG76IMG.nbh" and "PG76DIAG.nbh" files and then "revert" (restore stock HBOOT from NAND). I suspect that the behaviour with the "Fastboot hack" in place is the same as on a stock HBOOT booting to the HBOOT menu with no SD card in place.
[HTC Wildfire S] BeciMester:
The "switch case" that schlund edited handles the keypresses and the SD card init, that's why they're not working now. Not sure about USB but most probably it's done there somewhere too. It's not frozen, but without keys or USB there's no way to interact with it so it looks like it's frozen.

(I'm on my One X...)
[HTC Wildfire S] no.human.being:
Good to know. So USB and keys are not working because the switch-case is edited to always (re-)enter Fastboot mode on any event, right?

So basically the HBOOT enters its "main loop", then polls for events.

- If any key was pressed --> enter Fastboot mode.

- If USB was connected --> enter Fastboot mode.

- If SD card was inserted --> enter Fastboot mode.

- If nothing happened --> enter Fastboot mode.

That's about what it does now, right? :D
[HTC Wildfire S] dbunic:
First my apology for OT. I have just have one question:

Is it possible to unbrick Samsung Galaxy Mini S5570 (it has msm7227 Qualcomm chip and OneNAND storage) with Clone wiggler and OpenOCD software?

I have built Clone wiggler and I think communication with hard bricked S5570 is established (just search for my first post to see details and images). I'm stuck at this point and any hint, direction or guidance is more than welcome.

Thanks in advance!
[HTC Wildfire S] :
Do know for a fact that the riffbox software supports debugging?

Sent from my Baconator Over-9000
[HTC Wildfire S] dbunic:
Unfortunately I don't have Riff Box but it's seems it's inevitable. :(

I came here (live thread with experts) to ask for information before S5570 send to the service. Here is my OpenOCD output:

Open On-Chip Debugger 0.6.1 (2012-11-04-19:22)
Licensed under GNU GPL v2
Warn : Adapter driver 'parport' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
adapter speed: 300 kHz
trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
arm9
Info : clock speed 250 kHz
Info : JTAG tap: arm9.cpu tap/device found: 0x203c10e1 (mfg: 0x070, part: 0x03c1, ver: 0x2)
Info : Embedded ICE version 6
Info : arm9: hardware has 2 breakpoint/watchpoint units

And here is config:

interface parport
parport_cable wiggler

adapter_khz 300
reset_config trst_and_srst srst_pulls_trst
#debug_level 3

# CPU settings
set _CPUTAPID 0x203c10e1
set _TARGETNAME arm9.cpu
set _ENDIAN little

# create jtag
jtag newtap arm9 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID

# create target
target create arm9 arm926ejs -endian $_ENDIAN -chain-position $_TARGETNAME

I'm new with OpenOCD but have some experience with Linux and PIC micro-controller. With help of the mentor, maybe I will be able save bricked phone.

Thanks!
[HTC Wildfire S] *se-nsei.:
Loll, be my guest.
[HTC Wildfire S] dbunic:
Thanks.

Here are some facts (please correct me if something is written wrong):

- S5570 is based on MSM7227 Qualcomm chip

- phone has 4Gb OneNand KAT007012C - BRTT storage (512MB)

- Qualcomm chip has several cores that work independent: arm11 (application), arm9 (modem) and two others

- OpenOCD doesn't have feature to flash OneNAND storage

After reading a lot of posts and wild googling I still can't find exact intructions for unbricking S5570 with OpenOCD. The closest info I can find is based on phones with the same chip (like Wildfire S). So, if flashing of OneNAND is not possible from OpenOCD, maybe you know some other approach that I would like to try.

OK, this may sound also funny but is it possible to find right HBOOT or U-BOOT bootloader, load it to the phone's memory and start from OpenOCD? Then try to flash it from bootloader itself. All this in the aim to boot phone to the "download mode" and proceed with Odin to flash complete ROM. Or to load HBOOT image to the phone's memory and with some utility (like tom3q did with his Spica) flash it to the OneNAND.

Here is how tom3q restored fully bricked Samsung Spica with his OneNAND flasher (unfortunately it's not applicable for Qualcomm):

forum.samdroid.net/f63/totally-bricked-when-downgrading-there-jtag-pinout-service-manual-buy-new-5439/

And his reply to my question:

twitter.com/tom3q/statuses/254362901039689728

(sorry I'm a new on XDA forum and can't post full links)

Phone is hardbricked (due to wrong ROM flash) and clone Wiggler recognizes modem processor arm926ejs (Info : JTAG tap: arm9.cpu tap/device found: 0x203c10e1 mfg: 0x070, part: 0x03c1, ver: 0x2). Search for this device ID, will list a lot of "Detected dead body / Resurrection sequence" Riff Box pages and successfully recovered boot loaders - Riff Box can do it because of existing flash drivers for OneNAND.

So is there a way to fix S5570 boot loader with OpenOCD?
[HTC Wildfire S] Antagonist42:
Check my profile for signature and a link for documents in this thread, mainly phone docs for Qualcomm ;)
[HTC Wildfire S] munjeni:
Hi! Idea for these who have working jtag and want to make something for Wildfire S users.

...you know how "signature" is stored inside an nbh image and how these signature working. Hboot have an interesting function for signature comparation! Look into hboot function that doing signature comparation between stored signatures inside an hbh and "needed" signatures! I tried to hack these function by (idea) implementing hboot function "print on screen" into these function, but without luck, still I tried only one time... I am sure its posible to dump "expected signature" by printing them on screen and using these signature (adding these signature to specific block position in an generated hboot.nbh that failing signature match)... just for idea please analyse an hboot, you will see what I mean! Idea is modifying signature inside an "generic" hboot.nbh that will match signature if we dump and add new signature that will match"! Best way will be making generic nbh that will not fail installation caused by wrong signature... if you find a way for dumping signature that was compared trought these function than we will be able to make nbh that will be installable on all Wildfire devices like an ota update :) Function is really funny, something like (dirty example):

So I thinked to hack function printf and instead of printf add function "print on screen" for example in this way:

...

But it allso can be done for example in this way:

So instead of error message we can see signature for these block, so we can insert signature by signature for every block untill all signatures match! :laugh:

Understand me what I mean? :) Hboot update (aka ota hboot upgrade) packed into an hboot.nbh have ~10 signature blocks so it will be easy adding "good" signature without needs for imposible (100 years) brute forcing an RSA...
[HTC Wildfire S] no.human.being:
@munjenji: If HTC engineers did correctly implement RSA signatures, then this won't work. Signing with RSA is normally done like this.

int signature = rsa_encrypt(hash(message), private_key);

Then "signature" is stored alongside "message" and verification is done like this (C-like pseudo-code - of course it can't be done that way since the hashes and signatures are much larger than a machine word, so they cannot be stored in a single variable, passed as a single argument or returned from a single function call - but it gives you a basic idea).

int hash_a = hash(message);
int hash_b = rsa_decrypt(signature, public_key);

if (hash_a == hash_b)
; /* signature match */
else
; /* signature_fail */

Knowing both "hash(message)" (of modified HBOOT) and "rsa_decrypt(signature, public_key)" (of original HBOOT) won't help you since you don't have the "private_key" to generate signature as "rsa_encrypt(hash(message), private_key)".
[HTC Wildfire S] munjeni:
Hi, no! Look into hboot function... you will see!
[HTC Wildfire S] no.human.being:
I wouldn't even know where to look. I believe what you say, but it's a flawed design then. A "proper" RSA implementation wouldn't do it this way. :D

Is there good documentation for the NBH format? I found this utility and this utility. It's Perl code and appears to be quite complicated.
[HTC Wildfire S] munjeni:
http://code.google.com/p/htc-flasher/w/list its open source for nbh generating...

Sorry I forgot where I found function inside hboot, I have no Htc device to produce error mesage about wrong signature so just for idea you can see these function by using string from error message...
[HTC Wildfire S] heavy_metal_man:
Any advancements on the alternative dev team?
[HTC Wildfire S] heavy_metal_man:
ok guys i got my hands on a wildfire s with radio version 7.57.39.15m and hboot version 1.09.0099 and i performed radio dumps of before and after the use of the xtc clip :) bad news is i dont think it heralded any useful information. the radio partition only has a change to the mid. and the misc partition has a change where the backup cid was formatted to 00ff . i have the dumps if any of you guys would like to see them and cross compare :) ask and i shall pm
[HTC Wildfire S] #define:
Help needed....

Guys, I need help.. I'm trying to locate where the S-OFF check in the hboot lies(HTC Explorer).. Could someone help me check it?? I'm uploading an hboot analysis(with strings)(done with IDA)..

The 1st 8 digits(along with 'ROM:') is the address of the string.. The next 8 digits is the length of the string.. The "C" is the code, ie, its C lang(i think).. Whatever comes after C is the string value.. Can someone help me look for the S-OFF check??

Thanks..

EDIT : NVM guys.. Its just strings..

-----------------------------------------------------------------------------

The exploit NHB gave me, in that, when I use the command "cat loader.bin hboot.img > payload.bin" and do the rest of the procedure, the phone is always stuck at the HTC white screen.. The kernel I created with the payload.bin and an empty ramdisk was created using the "mkbootimg" utility standard in the android toolchains..

Also, when I use the "arm-none-eabi-objdump .." command to convert hboot.img to hboot.s, it works, but after doing this, the command "arm-none-eabi-as .." throws a few thousand lines of errors before quitting.. Errors of "junk, unrecognized, and bad instructions"

Can someone help??
[HTC Wildfire S] :
Hey everyone! How's the project been? From the OP I've seen that you have made serious progress. As you all know, my p phone was stolen, so the WFS section became useless. I can remember the first exploit. It was really fun.

Sent from somewhere too far away from my computer.
[HTC Wildfire S] heavy_metal_man:
Long story short many of the people who had this device that were trying for s-off have either had it lost/damaged Or upgraded and development has slowed to a snails crawl as no-one has any more ideas that can be tested without the device or JTAG. Another user for another device has asked for permission to carry on the work for his device, but he seems to be running into issues setting everything up. Without a jtag or nhb's input I fear this project is dead in the water. :(

---------- Post added at 09:25 PM ---------- Previous post was at 09:18 PM ----------

Furthermore the wfs section did not become useless. If anything it became useless to you not useless in general. Lots of people work hard on these forums and they don't become irrelevant just because people leave. You should choose better words next time bad wolf. :/
[HTC Wildfire S] :
I'm guessing he meant to himself.

Sent from my Baconmuffinator Over-9000
[HTC Wildfire S] heavy_metal_man:
I suppose, But I wish people would be clearer :-/ no offense was intended I imagine.
[HTC Wildfire S] matchstick-dev:
If it helps at all, I have a Wildfire S (marvel) kicking about here just gathering dust.

Haven't got any access to anything fancy like JTAG, but i can test exploits on it for you guys, get memory dumps etc :)
[HTC Wildfire S] artturnip:
I think they need a dev who's got JTAG equipment with the voltage shifter AND the device foe any hope of succeeding :banghead:
[HTC Wildfire S] davidang:
Seem like this project is dead
[HTC Wildfire S] artturnip:
It seems so...
[HTC Wildfire S] BeciMester:
I still haven't given up, working to learn what makes the hboot tick, because I do believe n.h.b's idea is viable. At the same time it's assignment/exam season in college and I'm mad busy, so unfortunately I can't devote as much time to research as I'd like to. :(

(I'm on my phone...)
[HTC Wildfire S] no.human.being:
Oh man, look at the news. Once again U-Boot was the key to having a device's bootloader protection broken.

Too bad that "unpopular" chips (like Qualcomm Snapdragon) don't have a U-Boot port yet (and we don't have enough manpower to port it). :(

Obviously, once you have a working port of U-Boot, you don't have to fiddle around a lot since of course it won't "self-check" and "fall back". After all, it's designed to be modified and built from source. In addition, you can modify the NAND MMU page tables at will.
[HTC Wildfire S] :
Who remembers me? I hope I'm not forgotten lol! And how is everybody? And the project?

Sent from somewhere too far away from my computer.