yashsingh1/xdaforums huggingface dataset:
[HTC Pico (Explorer)] no.human.being:
Now that's weird.

On the WFS there's a word somewhere in "misc" (don't know the offset anymore) that can either be 0xffffffff (locked), 0x55435448 (unlocked) or 0x4c435448 (relocked). The fastboot commands for unlocking and locking will modify this word. When you change it manually, it will lock/unlock/relock your bootloader without any side effects. I manually edited this word quite a few times, both to unlock without erasing "userdata" (on the WFS when you unlock with the token, "userdata" will be erased) and to get back to "locked" state (for which there is no official command, "fastboot oem lock" won't give you "locked" but "relocked" state - this is a bit inconsistent, why didn't they call this command "fastboot oem relock" then?).

Well that's how it works on the WFS. There's no good reason to do it differently on every phone. So where do these inconsistencies come from? Did they develop the procedure for each phone separately, independant of each other? Ever heard of code reuse? Sorry, but the longer I spend reverse engineering this stuff, the more I get the impression that the people at HTC must be the dumbest fools ever. It appears as if they didn't know even the most basic software engineering skills.

Yeah, beaups is now "with us". Thumps up! :good:

@beaups: Can you tell me what you're gonna do or take a look at?
[HTC Pico (Explorer)] #define:
I unlocked it with the unlock_token as well.. And it didnt erase the user data... Now when i unlocked the bootloader for the first time, back in may, at that time it erased my phone.. I had to do the first time account setup and everything...

I'm beginning to think, why would someone work so hard on sealing a budget phone so weirdly tight??

Sent from my Nexus 7
[HTC Pico (Explorer)] Sachin Thomas:
"4C 43 54 48" -> L C T H -> H T C L (reversed) -> HTC Locked

"55 43 54 48" -> U C T H -> H T C U (reversed) -> HTC Unlocked

On the explorer at offset 0x23fc I have a "46 4E 4F 43" -> F N O C -> C O N F (reversed)

Doesn't make any sense!
[HTC Pico (Explorer)] no.human.being:
Just because it IS a budget phone. They have to "cut it down" somehow so that it doesn't compete with the high-end models. The only thing they can really "cut down" on the hardware level is the display resolution and memory available, most of the rest is firmware differences. Now a Wildfire S is more or less a Desire S with a lower-res display (320x480 instead of 800x480), less memory (512 MiB NAND instead of 1 GiB, 512 MiB RAM instead of 768 MiB) and a bit weaker processor (600 MHz MSM7227 instead of 1 GHz MSM8255).

Now the memory difference is minor given that today we have 1 GiB RAM and 8/16/32 GiB NAND phones and that "fixed storage" may be easily expanded using SD cards. The processor difference is minor given that the MSM7227 processor can be overclocked to 800 MHz, sometimes even more. The major difference is the display and firmware. Now if the firmware was to be easily modified an extended, one could implement the features that are missing from the MSM7227 and present on the MSM8255, since in fact, apart from the actual processing core and the NAND controller (MSM7227 uses normal NAND while MSM8255 uses eMMC but that's a technical detail that's relevant for devs and engineers, not so much for end users), they are very similar hardware-wise. So if all the firmware on the Wildfire S could be modified, it would be too easy to turn it into a "Desire S with a bad display", thus they have to lock the budget phones down extremely tight, otherwise devs will start optimizing them so much that they rival the high-end models. And that's also why high-end phones are so easily cracked. The Desire S was S-OFFed very early. They didn't put a lot of effort into locking down this model, since it was already on the edge of what the hardware could support, there's not a lot left that developers could "tune" or "unlock". On the other hand, the hardware that's used in the Wildfire S has a lot of "headroom" that's just not used.

It's similar with other vendors. The Samsung Galaxy S2 (i9100) was broken very soon (Heimdall). The Samsung Galaxy Nexus (i9250), being an official developer device, is not secured at all. Both are high-end phones. It's similar in the computer world. The top-spec CPUs of every processor generation have open multipliers, the lower models do not. They can make the top-spec models open, since there's currently nothing "above" them that they could rival.

No the bytes are "48 54 43 4c" ("HTCL" - not reversed) or "48 54 43 55" ("HTCU" - not reversed). You can read it just fine in a "misc" dump. It's just that the words are 0x4c435448 or 0x55435448 respectively, since the processor is in little endian mode, so when you perform a load operation from the address, depending on whether the phone is unlocked or relocked, the most significant byte is different.

Locked state is just "ff ff ff ff" since that's the state the NAND is in when erased. As far as I know every value that's different from 0x4c435448 or 0x55435448 will put the bootloader into "locked" state though.

Nope, not really.
[HTC Pico (Explorer)] beaups:
Hey NHB, long time. Can you PM me on andirc.net ? I'm idling in #Facepalm and #Droid-DNA as well.
[HTC Pico (Explorer)] Sachin Thomas:
The chainloaded HBOOT also behaves inconsistently. Just have a look at these posts

Now my chainloaded bootloader displays HBOOT even when Vol-Down is not pressed, just like the original bootloader displays the HBOOT screen as soon as my bootloader is relocked. I'm sure that this wasn't happening earlier! It used to boot into the ROM if I didn't press any keys

We should ask cute_prince whether he can boot into any custom ROM with relocked bootloader

---------- Post added at 10:34 PM ---------- Previous post was at 10:15 PM ----------

We have the string "FNOC" in our hboot.img (just once). I just found it on WFS HBOOT 1.09 too (twice) ;)

Our hboot.img doesn't contain "HTCU" or "HTCL"
[HTC Pico (Explorer)] #define:
Well, so we can expect the Explorer to be even more tightly locked down than the WFS...

Sent from my Nexus 7
[HTC Pico (Explorer)] Sachin Thomas:
Hey guys, when I modified the exploit code to clear the physical RAM from 0xc0000 to 0x12c08000, it shows the HTC splash screen, vibrates 7 times, blanks out for a few seconds and reboots into recovery without showing the splash screen again. Any idea what's going on?

The original HBOOT normally checks for 7 files on the SD card. They are:

PJ03DIAG.zip

PJ03DIAG.nbh

PJ03IMG.zip

PJ03IMG.nbh

PJ03IMG.tar

PJ03IMG.aes

PJ03IMG.enc
[HTC Pico (Explorer)] no.human.being:
So the chainloader runs from 0x12c08000, then you move the bootloader to 0x00000000 (inclusive) - 0x000c0000 (exclusive), then clear the RAM from 0x000c0000 (inclusive) to 0x12c08000 (exclusive, initializing it all to zero I assume), then jump to zero, then the phone vibrates seven times, then boots straight into recovery, right?

Vibrate seven times sounds like the processor gets temporarily put into Download mode for some reason.

Remember that if you add instructions to the exploit code, it will assemble into longer machine code and the payload (HBOOT) will start at a higher offset, so you'll have to correct the "load_addr" to compensate for that.
[HTC Pico (Explorer)] Sachin Thomas:
Yeah, I always change it to (0x12c08000 + size of loader.bin)

I was clearing it from 0xc0004 (inclusive) to 0x12c08000 (exclusive), initializing it all to zero. When I cleared from 0xc0000 it was stuck at the HTC splash screen, without any vibrations and didn't boot into recovery

BeciMester has a "theory":

EDIT:

The vibration and reboot into recovery occur even when I clear from 0xc0000. I had modified the wrong code :)
[HTC Pico (Explorer)] no.human.being:
Should be the SBL, the bootloader that's responsible for booting Iguana.

The chain is something like this.

PBL (runs on mARM directly from on-chip ROM) loads DBL from NAND into RAM and executes it.

DBL (runs on mARM from RAM) loads SBL from NAND into RAM and executes it. SBL is basically the bootloader of Iguana.

SBL (runs on mARM from RAM) loads both the L4/Pistachio kernel and the APSBL (HBOOT) from NAND into RAM, then configures the SoC so that the memory area that the APSBL has been loaded into is seen by aARM as physical zero. (This assumes that both processors in the SoC share common RAM and "partition" it via some MMU mechanism, which makes sense since there's only a single "fast bus" EBI1 interface on the SoC.) It makes sense that SBL loads the data that comes after the APSBL (from where?), since it's the first "complex" bootloader in the chain. It then executes the L4/Pistachio kernel, which in turn loads the rest of the Iguana operating system that then runs on mARM. When Iguana has finished booting and becomes "ready", it will release aARM from halt, which will then start executing the APSBL from RAM at physical zero.

APSBL (runs on aARM from RAM) loads the Android kernel into RAM and executes it. On HTC phones, the APSBL is called HBOOT and (apart from all the cryptographic stuff) it's very similar to a reference bootloader that was once released by Google for Android as open-source (but unfortunately has since been "withdrawn" from the repositories).

Should be. APSBL (HBOOT) is the first (and only) bootloader in the boot chain that has the functionality to load an Android boot image and the recovery partition is an Android boot image. All other bootloaders are SoC-specific (Iguana is still SoC-specific firmware since it's present on all devices that ship with Qualcomm chips), APSBL is OS-specific (and thus "vendor specific" - it's aware of the specifics of the Android operating system - it can load Android boot images - it can pass parameters to a Linux kernel - the SoC itself is not restricted to running Android/Linux).

There is a Fastboot OEM command that's supposed to save aARM RAM content to SD card.

savemem2sd <memory offset> <length> <file name>

Don't know if it works on all phones though (not all Fastboot OEM commands are available on all phones). Might also be that the data is already modified when Fastboot mode is on but it's worth a try. If it's already modified, I see three more possibilities.

Trap before aARM begins executing its first instruction and then dump RAM via JTAG

Grab and reverse-engineer the SBL code (might be infeasable since it runs on mARM - no idea if NAND where it resides is accessible from aARM)

Reverse engineer HBOOT further to find all parts where this data is read and understand their influence on what HBOOT does, then set it up so that HBOOT does what we expect it to do
[HTC Pico (Explorer)] behtash:
hi

my pico phone now connect to riff box and i can change cid+mid+imei:o... but i cant find any metod for s-off and radio s-off AT@SIMLOCK=7,0 but i cant find any command :(!!! i have full dump and also read full dump with qualcomm flash image processing tool and can read any partion and extract

mibib ,qcsbl ,oemsbl1 , oemsbl2,htc,amss,efs2,,fota,reserved,appsbl,misc_mfg,wlan,splash1,splash2,apps,ext rom

from phone with this plagin in riff jtag box

i try write patch.img in this thread but not cant any way for write this img in rom and chipset and replace with appsbl right adress and length because need bin file with right adress and length !! i try rename to patche.bin but show this error ERROR: Image file size wrong. Main and Spare not correlate in size. when try flash in rom!! i also edit and add with hex editor and replace with appsbl.bin and write with riff but after write dead and only vibre after power!!!!!!!!!! again write orginal appsb.bin and phone back alive...

i try read this hboot.bin from rom with ardess 0x0000 0240 0000 and data lenght 0x0000 0020 0000 if any more can patched and modified for write with jtag intarfce i can show s-off in bootloader!!!!!!!:laugh::good:

also i have orginal diag file PJ03DIAG.nbh but need jvacard and show singnature incorrect! in hboot and not loade??? if u have any metod for exploit in rom and i can will s-off with orginal diag ??!!!

i waiting for ur and if need any dump say me my phone now connected to jtag box with solder
[HTC Pico (Explorer)] Sachin Thomas:
Finally, we have someone with JTAG facility!

Try writing this patch.img and check whether you have HBOOT S-OFF

View attachment patch.img
[HTC Pico (Explorer)] #define:
He tried it... It gives him signature error..

I have asked him to help take a log of booting from this patch.img file...

Sent from my Nexus 7
[HTC Pico (Explorer)] Sachin Thomas:
Why should a RIFF box check for signature? Here the error is wrong image file size

ERROR: Image file size wrong. Main and Spare not correlate in size.

@behtash

Can you open the original HBOOT-appspl.bin file in a hex editor and search for the bytes

"10 40 2D E9 02 35 01 EB 00 00 50 E3"

And overwrite it with

"10 40 2D E9 00 00 A0 E3 10 80 BD E8"

Make sure that the file size remains the same (817,344 bytes?) and flash the modified image
[HTC Pico (Explorer)] BeciMester:
This command is not even available when s-off, at least it wasn't on the WFS when I was s-off already. I suspect some other authentication form like engineering SIM or javacard or something. There's a check that has to be hacked before these commands are usable, which means flashing a hacked hboot --> need s-off again. Hence my rhetorical question "how to get that dump". :) I can do it on my WFS though, so I'll give it a shot in the next couple of days, and/or I can do the same mod to the Pico hboot, now that we have someone who's able to flash it. :D Thing is, I'm in the middle of moving house, so 1) my comp gear is in 6 different boxes, 2) internet is not working at the new place yet, Wednesday the earliest I was told. :(

[/QUOTE]

(I'm on my phone...)
[HTC Pico (Explorer)] no.human.being:
Don't know exactly what the utility does, but the "length" seems a bit small for an HBOOT. It is 524.288 bytes for the Wildfire S and afair it's even larger on the Explorer. 0x20000 is only 131.072 bytes.
[HTC Pico (Explorer)] behtash:
hi

this patch for hboot s-off not working after write with jtag box only vibre and phone dead only?!!!

other wayyyy
[HTC Pico (Explorer)] Sachin Thomas:
"radio" : 0x00000000 - 0x02fbffff
"recovery" : 0x02fc0000 - 0x034bffff
"boot" : 0x034c0000 - 0x038bffff
"system" : 0x038c0000 - 0x123fffff
"cache" : 0x12400000 - 0x15efffff
"devlog" : 0x15f00000 - 0x168fffff
"userdata" : 0x16900000 - 0x1fefffff
"misc" : 0x1ff00000 - 0x1fffffff

On my phone the radio starts at 0x00000000 (inclusive) and ends at 0x02fbffff (inclusive)

The size of the radio is 0x2fc0000

The HBOOT begins at "size of radio"- 0x4c0000 = 0x2fc0000 - 0x4c0000 = 0x2b00000

The size of the HBOOT is 0xc0000

So the actual values should be

Address: 000002b00000

Length: 0000000c0000

I've no idea why your utility is using different values, especially for length

The difference in address may be due to OOB (Out-of-band) data but what about length? :confused:
[HTC Pico (Explorer)] no.human.being:
I'm quite certain it did not get written correctly. Addressing may be different with JTAG, since it probably drives the address bus directly, while there's at least an MMU (but probably even more) between aARM and the address bus.

On the MSM7227 (Wildfire S) when you read NAND either via software running on aARM or "directly" via JTAG a lot of stuff was either missing (physical NAND pages without an aARM "virtual address") or shuffled around (physical NAND pages with an aARM "virtual address" that does not match the physical address) or had different content (which suggests that there's probably more in between than just an MMU as an MMU normally only translates addresses before they hit the bus, but doesn't do anything to the actual data on the bus - we don't know what that "more" is and what logic it follows though).

EDIT: Can't you use the JTAG box in conjunction with gdb to trap the bootloader at the first instruction (executed from 0x00000000 physical) and then dump physical RAM via JTAG? That would reveal what SBL loads after the HBOOT and would probably enable us to run it correctly. We already did this on an ARM emulator and it worked quite nicely. See the log/explanation here. With JTAG you should be able to do this on the physical processor.
[HTC Pico (Explorer)] Sachin Thomas:
I'm wondering why the original appsbl.bin is getting written correctly but the modified one isn't :confused:
[HTC Pico (Explorer)] #define:
Same question...

Its not supposed to check for signatures, is it??

Sent from my Nexus 7
[HTC Pico (Explorer)] Sachin Thomas:
It doesn't do that on the WFS but according to beaups the SBL verifies the APSBL's signature on "modern" HTC phones
[HTC Pico (Explorer)] #define:
Damn modernization,!!!

Sent from my Nexus 7
[HTC Pico (Explorer)] no.human.being:
Wait a moment. In the "HBOOT-appsbl.bin" that behtash posted you'll find lots of "empty NAND" (0xff) and then at offset 0xbfeec (quite a "weird" address, not padded to any page size or something) you find 0x108 bytes of data. The last 0x8 bytes read like "Hbo@tSig" (HBOOT signature?) and 0x100 bytes is 256 bytes or 2048 bits, which is a common RSA key size.

Is this the signature the HBOOT checks itself against and then "reverts"? Or is the HBOOT checked against this signature by some component of Iguana (perhaps the SBL)?

EDIT: Damn, someone was faster. ;)

EDIT2: Also what is the stuff that comes AFTER the signature? There's a lot of "empty NAND" and then at 0xc1800 there are "non-0xff-values". I extracted them and tried to disassemble them but they don't disassemble into meaningful stuff, so they're most likely data, not code. I mean it starts at offset 0xc1800, the actual HBOOT is only 0xc0000 in size right? Could you try chainloading the full JTAG dump? Perhaps that is what's missing and causes the revert?
[HTC Pico (Explorer)] Sachin Thomas:
We can try chainloading it but there are additional bytes in the JTAG dump that should be avoided

View attachment Report.zip
[HTC Pico (Explorer)] no.human.being:
The left file is an ".img", what's that? On the WFS the HBOOT images come shipped as "hboot*.nb0" and that is a raw dump (you can load it into RAM and execute it). You see that the "hboot*.img" contains data that is not present in the JTAG dump.

On the other hand, the JTAG dump contains data that's not present in the image file. This is probably OOB (NAND wear-levelling and parity) data. If the image was a "raw dump" (".nb0") you'd probably see that the OOB comes at regular intervals. Then one could build a utility that strips it off.

So what's the data format of the ".img" file?
[HTC Pico (Explorer)] Sachin Thomas:
Lol. Someone extracted the img file from an RUU and posted on this thread, following bhargz's instructions

http://xdaforums.com/showpost.php?p=33503294&postcount=20

http://xdaforums.com/showpost.php?p=33601642&postcount=44

I've never downloaded an RUU myself so I don't know whether there's any nb0 file with it
[HTC Pico (Explorer)] no.human.being:
Probably not. HTC probably replaced the nb0 file format (which was just a raw file) with another format that contains extra information (for error correction or for more security checks or whatever).

I have a hypothesis though. Let me spell it out.

By looking at the comparison it seems as if the "*.img" file had 4 bytes of error-correction data inserted every 514 bytes of "payload" so that each 514 bytes of code becomes a 518 byte block in the "*.img" file.

On the other hand, the JTAG dump appears to have 8 bytes of error-correction data inserted every 2040 bytes of "payload" so that each 2040 bytes of code becomes a 2048 byte block in NAND.

If this hypothesis is true, either chopping the "*.img" file into chunks of 518 bytes, then always discarding the last 4 in each block or chopping the JTAG dump into chunks of 2048 bytes, then always discarding the last 8 in each block should reveal the actual boot code. I could try building a C utility that can "strip img to raw" or "strip jtag to raw". Should not be too complicated and then we can check whether our hypothesis holds true and then try chainloading the "stripped code" (as that's probably what's actually loaded into RAM and executed - having the error correction information in there doesn't make a lot of sense and probably disrupts the code).

EDIT: No, forget about it. If you look closer it's not as regular as it appears to be at the first glance, e. g. in the NAND the "extra data" is sometimes 8 bytes, sometimes 12 bytes and the spacing is also not always the same. Damn!
[HTC Pico (Explorer)] Sachin Thomas:
That should also mess up the string addresses, because they are always supposed to start at multiples of 4
[HTC Pico (Explorer)] behtash:
Well check out this photo from the Nand see Dumb authoring tools (QualcommPartitionToolRIFF BOX) may be able to help us

---------- Post added at 03:45 PM ---------- Previous post was at 03:28 PM ----------

I read ful dump from my phone and before read dump i write ruu 1.41.161 with final hboot_1.07.0000_0d55407a_0607_signedbyaa

i read and save 3 partion in appspl :

save appsbl partion main data into file

save appsbl partion spare data into file

save appsbl partion full main and pare data into file

chack and try decode and edite mybe help me for s-off??!!
[HTC Pico (Explorer)] Sachin Thomas:
Main data gives the actual boot code (0xc0000 bytes) without any OOB data in between :good:

ROM:9D04794C loc_9D04794C ; CODE XREF: sub_9D04784C+58j
ROM:9D04794C ; sub_9D04784C+78j ...
ROM:9D04794C LDR R4, =0xE92D4010
ROM:9D047950 MOV R0, R4
ROM:9D047954 BL sub_9D0310B8
ROM:9D047958 ADD R0, R4, R0
ROM:9D04795C MOV R1, aShip_0 ; " SHIP"
ROM:9D047964 MOV R2, #6
ROM:9D047968 BL sub_9D0312AC
ROM:9D04796C BL loc_9D00B3EC
ROM:9D047970 ; ---------------------------------------------------------------------------
ROM:9D047970 CMP R0, #0
ROM:9D047974 BEQ loc_9D047998
ROM:9D047978 MOV R0, R4
ROM:9D04797C BL sub_9D0310B8
ROM:9D047980 ADD R0, R4, R0
ROM:9D047984 MOV R1, aSOn ; " S-ON"
ROM:9D04798C MOV R2, #6
ROM:9D047990 BL sub_9D0312AC
ROM:9D047994 B locret_9D047A54
ROM:9D047998 ; ---------------------------------------------------------------------------
ROM:9D047998
ROM:9D047998 loc_9D047998 ; CODE XREF: sub_9D04784C+128j
ROM:9D047998 LDR R4, =0xE92D4010
ROM:9D04799C MOV R0, R4
ROM:9D0479A0 BL sub_9D0310B8
ROM:9D0479A4 ADD R0, R4, R0
ROM:9D0479A8 MOV R1, aSOSPcbidIsD ; " S-O%s: PCBID is %d\n"
ROM:9D0479B0 MOV R2, #7
ROM:9D0479B4 BL sub_9D0312AC
ROM:9D0479B8 B locret_9D047A54

This is the code that prints S-ON / S-OFF on screen (where does that "OFF" come from?). But I can't disassemble the subroutine that reads the secu_flag
[HTC Pico (Explorer)] BeciMester:
Lads, AFAIK the difference between .img and .nb0 is the signature. I realize the WFS is a bit different but WFS RUUs have both, like spcustom.img and hboot.nb0. The .nb0 is raw data with 256 bytes of signature appended to the beginning, so the actual image starts from 0x100. Also, when I started disassembling the Pico hboot, I got it from a RUU the usual way and stripped the signature from the front. I can't remember what extension it had, but I can have a look once I get home (comp is up and running now, net will get hooked up tomorrow :D) or you guys can look at it by extracting it from a RUU.

(I'm on my phone...)