yashsingh1/xdaforums huggingface dataset:
[HTC Pico (Explorer)] no.human.being:
No, sorry but I think you're wrong. An "nbh" is a data structure which consists of a 0x300 byte header (so the executable image starts at 0x300), the first 0x100 (256) bytes of which are a signature followed by raw data. The "PG76DIAG.nbh" ENG HBOOT image is of this format.

RUUs are just utilities that push an archive file called "update.zip" to the phone via the command "fastboot oem rebootRUU" followed by "fastboot flash zip update.zip" (you can also do this manually if you have the corresponding "update.zip" file - I've done this a dozen times and the file can also have a name that's different from "update.zip" - you can also rename it to "PG76IMG.zip" and put it on the SD card to have it installed on the next boot). Inside this zip archive are multiple "img" and "nb0" files and a file called "android-info.txt" containing version information. On the Wildfire S neither an "img" nor an "nb0" is signed, they are both raw images. If you do not believe me, just extract an "update.zip" from a Wildfire S RUU with a zip decompression tool and take a look at the "hboot*.nb0" inside. It starts with the byte sequence "12 00 00 ea" which is an unconditional branch instruction. There is no signature before that and it's also not anywhere else in the "nb0". Also take a look at, say, a "recovery.img" from a Wildfire S RUU. It starts with the string "ANDROID!", the magic string for an Android boot image, again no signature.

So on the Wildfire S "nbh" files are signed, however "img" and "nb0" files are not.
[HTC Pico (Explorer)] #define:
If there is no signature, s-on/s-off becomes a little redundant, doesnt it?? They put this secu_flag to prevent flashing unsigned files to the phone..

If there is no signature, what do they need s-on for??

Sent from my Nexus 7
[HTC Pico (Explorer)] no.human.being:
The archive contains a signature in its header that somehow signs the entire data that's inside. If you change anything inside the archive (e. g. a file name or a modification date or whatever), the entire archive will be rejected. S-ON phones will reject all "nb0" and "img" files unless they are stored in a signed archive. Try to "fastboot flash hboot hboot.nb0" and the phone will tell you "signature fail", even with an HBOOT that came with an original RUU that in its entirety will pass signature verification. An "nbh" file is signed by itself and can thus exist outside of a signed archive.
[HTC Pico (Explorer)] #define:
Is there any way, even by a long shot, that we can duplicate that signature??

Maybe take it from a stock nbh file, and put it in our patch??

Or is that not feasible without the right set of tools??

Sent from my Nexus 7
[HTC Pico (Explorer)] acedexplorerABL:
Some help

I dont know if this has alrady been posted, but i found 2 things... one paid and one free... :P

http://www.xtcclip.com/product.php?id_product=11

surely only sdcard is used in this process... :/

http://xdaforums.com/showthread.php?t=834225

good old xda, but this has an hboot.nb0 not sure if thats what we want.

Keep rocking! :D
[HTC Pico (Explorer)] no.human.being:
This is not a software-only solution. The small black box is not only an SD card writer, but also has a microcontroller inside. This microcontroller has special firmware and HTC engineering keys on it (they probably got leaked - all it takes is a programmer that takes them out of the company). The small flex cable you see produting from the black box has to be connected to the SIM card slot of the phone. They then set off the "AT@SIMLOCK=7,0" (or "8,0" or something - I've seen some variants) command to the Radio. The Radio will then query the SIM slot for the engineering smartcard (also known as a "whitecard" as it's said to be completely blank and not have any imprint on it). This most likely works via some authentication protocol, that enables the card to prove that it knows the engineering key without revealing it ("zero-knowledge protocol").
[HTC Pico (Explorer)] Sachin Thomas:
Guys, I'm trying to find the memory location that's responsible for the revert by trial and error method

If I don't clear anything -> no vibrations, freezes at boot menu

I started by clearing memory like this

0xc0000 - 0x12c08000 -> 7 vibrations, recovery

0xc0000 - 0x9604000 -> 7 vibrations, recovery

0xc0000 - 0x4b02000 -> 7 vibrations, recovery

.....................................................................

.....................................................................

0xc0000 - 0x258100 -> 7 vibrations, recovery

0xc0000 - 0x12c080 -> 7 vibrations, revert ;)

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

0x12c080 - 0x258100 - 10 short vibrations, recovery :confused:

I'll try to narrow it down when I get some more free time
[HTC Pico (Explorer)] no.human.being:
Do you know what this looks like to me? This looks like all "main" data gets loaded to physical zero and the "spare" data is the stuff that gets loaded to the higher address and then accessed by HBOOT. The data is different between the RAM and the NAND dump, but that doesn't mean anything, since they stem from different phones (RAM dump is HBOOT-1.03, NAND dump is HBOOT-1.07).

So the "extra data" that comes after the HBOOT in RAM comes from the "spare" area, the SBL probably reads it from there and loads it to a higher page in RAM (starting at 0xc1800 physical).

Now the question is: Is this "spare" area that the JTAG tool detects actually the same as the "out of band" area that is specified in the datasheets of the NAND chip?

I don't think so, since the "out of band" area is normally used for storing parity data for error-correction. They won't store the HBOOT without proper parity data, right? I mean if they used no redundancy at all, then all it would take were a single defective NAND cell and aARM couldn't boot any longer.

The other question: The HBOOT images ("nb0" files) only come with "main" data, not with "spare" data. Does that mean that the "spare" data is programmed one time at production and then never updated? Is it probably unique for every Qualcomm processor?

Now at least we've "demystified" it so far that we know that the "extra data" is also stored in NAND and that it is included in a JTAG dump. We should try preparing an HBOOT + "extra data" image as we'd expect that the SBL placed it in RAM. Now on the HBOOT-1.07 NAND dump, the "extra data" starts at offset 0xc0000 into the HBOOT partition. On the HBOOT-1.03 RAM dump, it starts at 0xc1800 physical. Is this difference due to the different HBOOT versions (HBOOT-1.03 has it start at 0xc0000, while HBOOT-1.07 has it start at 0xc1800?) or does the SBL differentiate between the actual bootloader code and the "extra data" and starts reading the latter from offset 0xc0000 in the HBOOT partition and loads it to 0xc1800 physical?

Well we cannot really know, but I'd say we should just prepare two images, one containing just the dump as it appears in NAND (simulating the case that SBL loads it directly) and one with 0x1800 bytes of 0xff between the end of the actual HBOOT and the beginning of the "extra data" (simulating the case that SBL reads the extra data from 0xc0000 and loads it to 0xc1800) and try out which of the two works. I'm preparing binary images for both cases, please stand by.
[HTC Pico (Explorer)] #define:
I'm not gonna sleep now...;)

Sent from my Nexus 7
[HTC Pico (Explorer)] no.human.being:
Time for another test.

The HBOOTs are NOT patched S-OFF, they are regular HBOOTs.

Tell me if any of the two works and if not then tell exactly what they do.

If any of these work, I'm gonna patch the working one S-OFF (or you can do it - if you know the byte sequence to patch you can just do it directly in the boot image with a hex editor of course), then we do another test to see if the patched will still work. This might for example fail if the HBOOT compares its own code against its signature. I've seen a reference to the signature within the HBOOT code so it's possible that it checks itself but if it does we can patch that out as well, it's just still more reverse-engineering work.

If we got an S-OFF HBOOT working, we should try zeroing as much of the "extra data" as is possible, as it is possibly identifying (it appears not to be updated since it's not present in the nb0, so it might contain configuration that's unique for a single chip and stored in NAND after manufacturing).

After that, I'm gonna start obfuscating the exploit and payload as much as it gets in order to distract the HTC people. I already have some cool ideas on what one could do to obfuscate all that stuff. There are so many cool things you can do on ARM. I think it's not too difficult to make the code no longer resemble an HBOOT by any means but still work fine. I'm already looking forward to that. Obfuscating code is fun. :D

Now try it out bhargz16. You know the key. ;)
[HTC Pico (Explorer)] Sachin Thomas:
You changed your key? :eek:

Is this one for HBOOT 1.07? Mine is 1.03 :(
[HTC Pico (Explorer)] no.human.being:
No, should still be the same. Don't you get the archive open? Yes it's for HBOOT-1.07 since I've got a JTAG NAND dump from a phone with HBOOT-1.07. You can try it out on your phone though. As long as the NAND layout is the same it'll likely boot. Please try both images, I'm curious as hell. :D
[HTC Pico (Explorer)] Sachin Thomas:
It doesn't open with that key. I think behtash posted the 1.03 dump first

http://xdaforums.com/showpost.php?p=38737800&postcount=488

Edit 1:

Thanks. The key works now :)

Edit 2:

Stuck at the HTC splash screen with both the files. I think my NAND layout is different
[HTC Pico (Explorer)] no.human.being:
I've sent you the key and tested that the file opens with it. I thought it was the key I always used. I've stored it in a file here.

EDIT: Damn! Need bhargz16 for testing. ;)
[HTC Pico (Explorer)] Sachin Thomas:
I'm stuck at the HTC splash screen with both the files. Can you create the chainloader for 1.03 with the dump posted by behtash in his first post?
[HTC Pico (Explorer)] no.human.being:
I'm gonna try it - please stand by.

EDIT: Attached! Please try and let me know.
[HTC Pico (Explorer)] Sachin Thomas:
It's still stuck at the splash screen for 5 minutes :(

Are you specifying the load_addr correctly?

I'm also afraid that our extra data is too small

The real data should be around 1-2 MB in size
[HTC Pico (Explorer)] no.human.being:
Yes, unless there's a problem with the MSM7225A loading a kernel to 0x12c08000 physical, which is the kernel_addr I set in the boot image.

The exploit code is 136 (0x88) bytes long so I load from 0x12c08088 physical to physical zero.

The amount of code I load depends on the exact image.

HBOOT-1.03 RAM dump is 817.344 bytes long so I specify a length of 0xc78c0.

HBOOT-1.07 full NAND dump is 811.008 bytes long so I specify a length of 0xc6000.

HBOOT-1.07 NAND dump with spare area padded so that it starts at 0xc1800 is 817.152 bytes so I specify a length of 0xc7800.

THAT much? That appears weird since it's larger than the HBOOT itself!

Do you have any idea what that data is used for? It looks extremely strange. Like lots of 32-bit values poked from non-contiguous locations. You can find lots of "string fragments" like "urit" (4 byte fragment of the word "security"?) or "otal" (4 byte fragment of the word "total"?) and so on.

And yes it's definitely data, not code. Disassembling it will not yield anything that looks only remotely like it would make any sense.
[HTC Pico (Explorer)] Sachin Thomas:
If behtash can provide a RAM dump via JTAG after halting aARM at it's first instruction we'll have answers to all our questions

Can we help him?
[HTC Pico (Explorer)] no.human.being:
If he has a JTAG interface that's supported by OpenOCD he should definitely try out OpenOCD and gdb on that. I don't know how to get it working, since I've never got a JTAG interface to work with the MSM7227 which I was working on (too low voltage). If we get OpenOCD to work we have won.

Look here at how such a debugging session looks like. It's on an emulator instead of a real ARM processor but if we get OpenOCD working it should look very similar on an actual processor (after all the purpose of an emulator is to act a lot like an actual processor). So once we got the debugger talking to the target I basically know how to debug.

The problem is that you first have to "configure" OpenOCD to work with the processor AND of course the JTAG interface has to be supported by OpenOCD and I think that this was the problem. I think he uses a Riffbox or something like that?! I think that's not supported, at least not officially. If we're lucky we can find some "hacked" or "customized" OpenOCD version that has support for the interface, but chances are probably not that high.

We should first be certain what JTAG interface he uses though.
[HTC Pico (Explorer)] AmalD:
any progress here ??

@op have a look at here

http://xdaforums.com/showthread.php?t=2155135

we can get help from there , lot of soff experts are there :p

"

beaups - m7forsoff@gmail.com - http://xdaforums.com/donatetome.php?u=711482

jcase - jcase@cunninglogic.com - http://xdaforums.com/dona....php?u=2376614

dsb9938 - cubedrom@hotmail.com - http://xdaforums.com/dona....php?u=2963256

dr_drache - biomatrix@gmail.com - https://www.paypal.com/cgi-bin/websc...=6LRSY8MT8P3A6

You can also come by irc for support or just to say thanks: #FacePalm http://chat.andirc.net:8080/?channels=facepalm

"
[HTC Pico (Explorer)] #define:
Sorry guys... Was sleeping...
[HTC Pico (Explorer)] #define:
He uses a Riffbox... Its kind of a "plug-and-play" version, as you probably know...
[HTC Pico (Explorer)] Sachin Thomas:
-----------------------------------------------------------------------------

0x12c080 - 0x258100 - 10 short vibrations, recovery

# (12c080 + 258100) / 2 = 1c20c0

0x12c080 - 0x1c20c0 - No vibrations, stuck at boot menu

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

0x1c20c0 - 0x258100 - 10 short vibrations, recovery

# (0x1c20c0 + 0x258100) / 2 = 20d0e0

0x1c20c0 - 0x20d0e0 - 10 short vibrations, recovery

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

# (1c20c0 + 20d0e0) / 2 = 1e78d0

0x1c20c0 - 0x1e78d0 - No vibrations, stuck at boot menu

0x1e78d0 - 0x20d0e0 - 10 short vibrations, recovery

------------------------------------------------------------------------------
[HTC Pico (Explorer)] #define:
Hey guys...

What's our current play??

Are we still trying to find out the problem with the hoot, or are we going to give a shot to the face palm exploit??

Or both?? :what:

Sent from my Nexus 7
[HTC Pico (Explorer)] Sachin Thomas:
Does anyone know how the face palm exploit actually works?
[HTC Pico (Explorer)] Sachin Thomas:
Some more interesting results. Now it enters recovery without vibrating (but actually waits for some time before booting into recovery, just like it waits for some time before "reverting" ;))

# (1e78d0 + 20d0e0) / 2 = 1fa4d8

0x1e78d0 - 0x1fa4d8 - No vibrations, stuck at boot menu

0x1fa4d8 - 0x20d0e0 - 10 short vibrations, recovery

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

# (1fa4d8 + 20d0e0) / 2 = 203adc

0x1fa4d8 - 0x203adc - 10 short vibrations, recovery

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

# (1fa4d8 + 203adc) / 2 = 1fefda

0x1fa4d8 - 0x1fefda - 10 short vibrations, recovery

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

# (1fa4d8 + 1fefda) / 2 = 1fca59

0x1fa4d8 - 0x1fca59 - 10 short vibrations, recovery

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

# (1fa4d8 + 1fca59) / 2 = 1fb798

0x1fa4d8 - 0x1fb798 - No vibrations, stuck at boot menu

0x1fb798 - 0x1fca59 - 10 short vibrations, recovery

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

# (1fb798 + 1fca59) / 2 = 1fc0f8

0x1fb798 - 0x1fc0f8 - No vibrations, stuck at splash screen

0x1fc0f8 - 0x1fca59 - No vibrations, recovery
[HTC Pico (Explorer)] #define:
Beaups can help with this...

Sent from my Nexus 7
[HTC Pico (Explorer)] #define:
If nhb was right, you may have skipped the download mode...

Sent from my Nexus 7
[HTC Pico (Explorer)] beaups:
I know how it works.
[HTC Pico (Explorer)] RIFFBox:
Just small hint,

Depending on NAND page size in this model, appsbl address is different.

In both cases file must meet DCC loader req-s, so in case that You have file 0x85900 size, You have to add extra bytes to it so it matches DCC loader requirements - in this case it must be at least 0x10 0000 size + additional 0x8000 bytes for spare.

Since this is android phones and spare data are calculated in different way, it's required to write it with ROM2 selected, so DCC loader can recalculate ECC correctly.

Or simply wait for us to add this patched spl to DLL, so You dont need to think at all :)
[HTC Pico (Explorer)] #define:
Exactly man!!

You know everything about it... :D

Sent from my Nexus 7
[HTC Pico (Explorer)] no.human.being:
Is there any chance of getting a COMPLETE RAM dump from an HTC Explorer running HBOOT? And is there a chance of getting a complete NAND dump? Disassembling the SBL for example might be useful for understanding in what state the system is exactly when the APSBL (HBOOT) takes over.

EDIT: Forget about it. ;) Just disassembled QCSBL for the WFS taken from an RUU and it's ~16k LOC in assembly before the "wall of 0xff" starts and OEMSBL is ~116k LOC before the "wall of 0xff" starts.
[HTC Pico (Explorer)] beaups:
Indeed, but It won't help here. Sadly, the architecture and secure flag storage on emmc devices is totally different.
[HTC Pico (Explorer)] siddharth1102:
Guys if the problem is in making jtag i.e. What I've seen all through you can't make it therefore i was searching over net on this and came across their site and they ship riff box in india as well as they have given instructions how to use this which i think u guys know.

I am attaching links below there is phone no. For the person who sells riff box in india try contacting him if its out of budget then consider donations :p

Instructions : http://www.jtagbox.com/jtag-news/riff-jtag-htc-explorer-htc-pico-unbrick-unlock-supercid-imei-repair/

Dealer info : http://www.jtagbox.com/category/jtag-dealers/

See the second one its viru and stock is available n phone no and email id are given try contacting him to purchase it.

Edit : just saw one more for india its mobile clinic see and contact him too. :)

Edit 2 : found one more Ultimate sales and services ;)
[HTC Pico (Explorer)] no.human.being:
This guy has Riffbox on an HTC Explorer, but Riffbox has no OpenOCD support so you cannot use it for serious debugging work, you can mostly use it for programming the Flash memory. We need to have someone that has a JTAG interface on HTC Explorer which has full debugging support. :(

See here for interfaces with full debug support (section "Interface Drivers"). However, mind that not all of them will work with the MSM7225A. Not even all of them are for ARM. And some are very old legacy products that work over RS232 serial connection etc. so they can't be used on modern computers. Finding a proper JTAG interface is not an easy task.
[HTC Pico (Explorer)] cute_prince:
Hmm.. RIFF box CAN be used for on-chip debugging too.. Although it may not support OpenOCD there are other on-chip debugger tools that can be used with it.. I have already posted about it in this thread.. See the following video it shows on chip debugging of Samsung I9100 with RIFF box using IDA ARM Debugger tool..

http://jtagbox.com/RIFF_JTAG_GDB_SERVER_IDA_DEBUG_SAMSUNG_I9100.swf
[HTC Pico (Explorer)] behtash:
yes i try any way with riff but dead after write this patche need OpenOCD support .... riff not support

thanks all
[HTC Pico (Explorer)] no.human.being:
If we had a debug facility we could take a look where the revert happens.
[HTC Pico (Explorer)] behtash:
hi all i test again with Project Manager riff mr legija but after more test not working ur patch and not boot up this patched unsigned not workingg

this my bootrom

plz find other wy for find s-off this phone

thanks
[HTC Pico (Explorer)] Sachin Thomas:
Do you still believe that there is a mechanism that checks whether the boot code is tampered in RAM? The "revert" looks as if I have selected "REBOOT BOOTLOADER" menu item in fastboot and the "reboot into recovery" that I get (with cleared RAM) looks as if I have selected "POWER DOWN" menu item in fastboot

Our device doesn't support offline charging, so it's normal for it to boot into recovery when it's powered down and connected to USB. So I'm quite sure that what I get is a "POWER DOWN"

Edit:

The PBL contains sparse constants for SHA-1

Can't we reverse engineer the SBL to find what's getting loaded after the HBOOT?
[HTC Pico (Explorer)] no.human.being:
Yes.

Ok, the WFS supported offline charging. But even if it's a "POWER DOWN", something has to trigger that. There has to be a conditional branch in HBOOT that invokes tha same code as if "POWER DOWN" was selected. And I want to know what that condition is so that we can avoid it. I mean something has to be different when our exploit loads the APSBL code than when SBL loads the APSBL code and that difference results in different behaviour (reverting, rebooting, powering down, whatever). So it would be cool to know what the RAM looks like before APSBL executes its first instruction just after SBL is through and what RAM looks like before APSBL executes its first instruction after our exploit is through and compare that. And then it would be cool to know the full NAND content of the same phone since the stuff that comes after HBOOT probably comes from the NAND.

Yes it contains an implementation of SHA-1 and also an RSA implementation. Probably both used for verifying SBL for "trusted boot".

In principle, yes, but it's once again a large codebase. If we could halt aARM before the first instruction, then dump its RAM and compare it to the NAND contents, we can probably find out where the blocks come from.
[HTC Pico (Explorer)] Sachin Thomas:
Yeah. That's why I tried to use some "trial and error" method to find the address that's read to decide whether it should revert,power down etc. If we know at least the approximate value, I think we can locate the conditional branch by finding the code that references this memory region.

But I had made a HUGE mistake. I forgot to round the last few addresses to multiples of 4, my loop was written in such a way that it required multiples of 4
[HTC Pico (Explorer)] no.human.being:
Ah I see. Just branch out when it becomes

greater or equal

(or jump back as long as it's

less

). Also mind that it matters whether you branch out of the loop

before

or

after

you have written the zero. If you branch out

before

, your upper limit will be

excluded

, if you branch out

after

, your upper limit will be

included

.

I would do it this way. Let's assume r2 is the lower limit inclusive (address of first word that's zeroed), and r3 is the upper limit exclusive (address of first word that's no longer zeroed).

prepare_zero:
mov r0, #0
mov r1, r2

zero_loop:
cmp r0, r3
bge zero_loop_end
str r0, [r1]
add r1, #4
b zero_loop

zero_loop_end:
nop

If the upper limit is not a multiple of four, it will include the word that begins at the address that's the lower multiple of four. If it is a multiple of four, the upper limit is the address of the first word that is

not

zeroed.
[HTC Pico (Explorer)] galaxyfreak:
Bump.
[HTC Pico (Explorer)] efuzone:
How to gain S-OFF can somebody share?
[HTC Pico (Explorer)] Parth_14:
Kill yourself please :banghead:
[HTC Pico (Explorer)] efuzone:
really?
[HTC Pico (Explorer)] #define:
Take it to PMs please guys...

Sent from my Nexus 7
[HTC Pico (Explorer)] ngoralph:
The SUPPOSEDLY s-offed hboot from the chinese devs

http://www.mediafire.com/?x92eyhhc4y1jdja

can you take a look at it guys
[HTC Pico (Explorer)] #define:
This is probably a Stock S-OFFed hboot v1.01.0000..

So if anybody has that hboot version, you can boot this...

@no.human.being

@Sachin Thomas

@cute_prince

We can work off of this, cant we??

Sent from my Nexus 7