yashsingh1/xdaforums huggingface dataset:
[HTC Pico (Explorer)] mmtrt:
Did great job guys keep working!!

looking forward for S-off my device when it is fully fixed.

I did more comparsion on different hboot files. did take ruu different versions with same radio versions hboot have same checksums mean they are same hboot but for same hboot version of different radios are not same.

here more hboot files taken from 5 different ruu versions might help in the devlopment.
[HTC Pico (Explorer)] galaxyfreak:
[NOOB ALERT] I have 1.07... I'd like to upload it but I dont know how?!
[HTC Pico (Explorer)] #define:
Ok... If I find a cheap enough JTAG hardware, will you help me set it up and troubleshoot?? I have an Explorer and a Wildfire.. And I'm almost pretty sure that I can get my hands on a WFS thats willing to be JTAGed... If yes, I'll start looking for a JTAG and study about JTAGs.. In the meantime, post any material that can help me get up to speed on JTAG.. And any links to get my hands on JTAG equipment..
[HTC Pico (Explorer)] Sachin Thomas:
NHB has already stated that the processor logic level isn't enough for OCD
[HTC Pico (Explorer)] #define:
Whaaaat?? Didnt understnd.. :confused:
[HTC Pico (Explorer)] Sachin Thomas:
Read the first post in WFS S-OFF thread
[HTC Pico (Explorer)] #define:
Ok.. Now I got it.. But now we have a lot of people and support.. We can atleast try.. Something better than nothing..
[HTC Pico (Explorer)] no.human.being:
It's not enough on the MSM7227 (no idea about the MSM7225A but since the processor core is newer it's probably running on an even lower voltage) and it's not enough for the UART in the JTAG interface we used (UART was an FTDI FT2232H). OpenOCD is just the software. If you have a UART that is supported by OpenOCD and can go as low as the processor requires, it's probably going to work.

However, the FT2232H was a 3.3 V logic thing and the MSM7227 was a 0.9 V logic thing so the FT2232H saw the MSM7227's "high" logic level still as "logical low" so OpenOCD claimed "processor returns all zeroes". (It's not OpenOCD's fault though. If the UART doesn't "see" the signal from the processor because it's too low, OpenOCD can't do anything about it.) Data transfer from the JTAG interface to the processor worked (even though the logic level provided by the interface was way too high for the processor), as I saw the processor "responding" at its 0.9 V level when hooked to an oscilloscope. Only the "back channel" from the processor to the interface didn't work because the logic level was too low.

Two inverters per JTAG signal line and two DC sources would probably suffice for doing the conversion, but it's a pain to build with discrete transistors and we didn't find a level shifting IC that fit. JTAG clock is not that high (~100 kHz is fine for the MSM7227) so the transistors don't need to be specifically "fast switching".
[HTC Pico (Explorer)] Sachin Thomas:
Are these values used in mkbootimg_wfs enough for explorer? We haven't tried changing them

hdr.kernel_addr = 0x12C08000;
hdr.ramdisk_addr = 0x13C00000;
hdr.second_addr = 0x13B00000;
hdr.tags_addr = 0x12C00100;
[HTC Pico (Explorer)] cute_prince:
The kernel address is definitely wrong ... It's 0x12C00000 for Pico.

I am not sure about the remaining
[HTC Pico (Explorer)] Sachin Thomas:
If it's the value at offset 0xc in boot.img, then I'm sure that it's 0x12C08000

What about the other values? How do we check them?
[HTC Pico (Explorer)] #define:
Actually the standard "mkbootimg" found in the Android Toolchains didnt work.. So we tried it with the "mkbootimg_wfs".. And that worked.. So we've been using that... And since it worked, we came to the conclusion that the memory layout is somewhat very similar to WFS in Pico..
[HTC Pico (Explorer)] no.human.being:
They're all stored in the boot image.

kernel_addr: Offset 0x0000000c.

ramdisk_addr: Offset 0x00000014.

second_addr: Offset 0x0000001c.

tags_addr: Offset 0x00000020.

All 32 bits (4 bytes) little-endian. The only thing that the exploit (currently) needs is the kernel_addr though. If you adjusted the exploit's "load_addr" to be the same as "ramdisk_addr", you could probably use the exploit (without any additional code) as kernel and the payload as ramdisk when building the boot image. Probably makes building different boot images with different payloads easier. I haven't tested it but I'd expect it to work since the bootloader takes the ramdisk and loads it to "ramdisk_addr" physical and then the exploit comes and moves it over to "execute_addr" (usually zero) physical.

Btw, I've just tested IDA Pro 5.0, modified configuration to load "img" and "bin" files for "arm" processor (otherwise it tries to disassemble for x86), but if I try to open an HBOOT, an error appears.

.

I find the "ordering" thing specifically weird. ARM support only at additional cost?

---------- Post added at 06:16 PM ---------- Previous post was at 05:49 PM ----------

But "mkbootimg_wfs" sets "kernel_addr" to 0x12c08000. I thought you had a different RAM layout than we do, which is why you had to recalculate all addresses that the exploit takes. Now if the devices are THAT similar that they even have the same RAM layout, then I'm very confident that both can be S-OFFed with very similar methods. :fingers-crossed:

And if you get the Explorer S-OFF, the Desire C people can probably also port it to their device since it's also powered by an MSM7225A.
[HTC Pico (Explorer)] cute_prince:
Actually 0x12C00000 is the kernel base address for Pico :)

Following is an excerpt I took from mkbootimg.c file (The source code of mkbootimg utility, which is used for generating boot images)

See the rectangled region ..

The hdr.kernel_addr, hdr.ramdisk_addr, hdr.second_addr and hdr.tags_addr values are all generated from the kernel base address (which is 0x12C00000 for Pico )

So,

hdr.kernel_addr = 0x12C00000 + 0x000080000 = 0x12C08000

hdr.ramdisk_addr = 0x12C00000 + 0x01000000 = 0x13C00000

hdr.second_addr = 0x12C00000 + 0x00F00000 = 0x13B00000

hdr.tags_addr = 0x12C00000 + 0x00000100 = 0x12C00100

Therefore, values used in mkbootimg_wfs is correct for explorer :)

That means WFS and Explorer has exactly the same RAM layout :highfive:
[HTC Pico (Explorer)] no.human.being:
If this is so, then why have I explained to bgharz16 in all detail how to re-calculate all the addresses that are used in the exploit? The only thing that had to be adjusted must be the "length" field, since as far as I know HBOOT-7225A is 768k (probably 0xc0000 right?) in size while HBOOT-7227 is 512k (0x80000) in size. :D

Nevermind, must have been a good lesson. :D
[HTC Pico (Explorer)] immortal_yash:
Slightly NOOB alert :P ( having reading this post for a while... :))

what about the unresponsiveness issue can we do it without jtag??
[HTC Pico (Explorer)] #define:
Man it was a very good lesson.. helped my midterm exams.. :D

And just to come clean, i made absolutely no change in the "loader.s" file.. Not even length.. Its been kept exactly the same as you gave me NHB.. And still it works... I dnt know whether I should be confused or happy.. Well, I guess I'm both..

PS : Where do we stand on the JTAG thing i posted earlier??
[HTC Pico (Explorer)] #define:
Hey, BTW, where's munjeni these days?? Last time I heard he got a Sony phone... And Antagonist42 even??? Havent heard from them in a long time on the WFS thread either..
[HTC Pico (Explorer)] #define:
Ok... For such a setup I'll need some expert help.. I'll talk to my professors.. If they're willing to help and dont rant about pending assignments(which they probably will), I can get it done.. I'll let you guys know in a couple days if thats gonna be possible.. If it is possible(lets hope for the best), then I can get the hardware side done.. But after that, we still have to figure out the OpenOCD side..

Now, on to the worst case scenario.. Is there even a teeny, tiny possibility to do this without JTAG?? If yes, then how do we do that?? Is it something like we did with the S-OFF/S-ON routine??

I remember a dev, Schlund.. In the WFS thread, he made some changes to the WFS hboot... There were some switches.. And he made all the cases to enter just 1 "gate"..

Here's his original post :
[HTC Pico (Explorer)] Sachin Thomas:
I have a doubt. If the bootloader state (LOCKED/UNLOCKED/RE-LOCKED) is stored somewhere in the "misc" partition why does our chainloaded hboot display "LOCKED", when our bootloader is actually unlocked via htcdev?

Aren't they both (the original and chainloaded hboots) reading data from the same "misc" partition?
[HTC Pico (Explorer)] no.human.being:
My chainloaded HBOOT says "UNLOCKED" (or rather "INJECTED", which is what I've patched the "RELCKED" string with ;) ). It depends on where you got the HBOOT from. For the Wildfire S, there are different partition layouts, so the "misc" partition is at different physical addresses for different revisions of the phone. The physical address where it reads the "locked/unlocked/relocked" state (as well as basically all other NAND addresses) is/are hardcoded in the Wildfire S HBOOT so when you run an HBOOT that does not fit your partition layout, it will read/write in the wrong places. On the Wildfire S the bootloader will lock up in this case, but on the Explorer, this might be different.

Btw, is the HTC Explorer NAND- or eMMC-based?
[HTC Pico (Explorer)] #define:
Its eMMC(corrected) based...
[HTC Pico (Explorer)] Sachin Thomas:
I tested it with an HBOOT 1.03.0000 (same version on my phone) extracted from an RUU. And still it shows "LOCKED". The different partition layout could be the reason why Explorer always locks up (even when an SD card is present), without reverting like the WFS HBOOT
[HTC Pico (Explorer)] #define:
We use hboots directly extracted from RUUs... And RUUs are supposed to be applied to stock/ locked bootloaders... when we apply an RUU, we have to lock our bootloader, if its unlocked.. Now since our bootloaders are unlocked, when we lock them, we get relocked.. That string is referenced from the misc partition to display, as nhb said.. now if there were no string check for unlocked/locked/relocked, then after applying a stock RUU, our bootloader would display locked... hypothetically speaking, ofcourse...
[HTC Pico (Explorer)] no.human.being:
When you unlock/relock a bootloader, the bootloader code is not changed. Only a flag in the "misc" partition is changed. I'd expect the bootloader from the RUU to read the "misc" partition, find that it's "unlocked" and display "unlocked". It did as expected on the WFS. The contents of the "hboot.img" in the RUU get written directly (and unaltered) to the "hboot" partition inside the Radio when installing that RUU.
[HTC Pico (Explorer)] #define:
Yes thats what i'm saying... if there were no check for the string in the misc partition, then the hboot in the stock ruu will write locked, in the hboot partition in the radio, and thus display locked... maybe thats whats happening in explorer.. the hboot we load, ie, chainloaded, gets loaded in the ram, but doesnt make any query anywhere for the injected or unlocked string.. so it just loads in the ram, and before being able to do anything other than display itself on the screen, locks up...
[HTC Pico (Explorer)] no.human.being:
Possible. The obvious question is WHERE it locks up. It must be a loop that breaks on some condition and this condition is never met. If we knew which loop it was, we could modify it so that it exits after some cycles or something like that.
[HTC Pico (Explorer)] #define:
Would a misc dump help here??
[HTC Pico (Explorer)] no.human.being:
Don't think so. Single-stepping through the HBOOT code would help. :D

If someone had and was familiar with an ARM emulator we could of course also run and debug the HBOOT inside that thing instead of a real phone.
[HTC Pico (Explorer)] #define:
Cute_prince or sachin could help... this is where my knowledge ends at the moment... :D
[HTC Pico (Explorer)] #define:
http://www.arm.com/products/processors/cortex-a/cortex-a5.php

Helpful for jtag maybe??
[HTC Pico (Explorer)] Sachin Thomas:
This is the closest thing I have seen

http://www.hexblog.com/?p=111

But how will an emulator be able to read and write data from partitions?
[HTC Pico (Explorer)] no.human.being:
I'd imagine you could dump the partitions and put them into a "virtual NAND file" for the emulator, much like you can put data into a "virtual disk file" in a virtualizer like VMware.

The software you've found uses QEMU and QEMU can principally work with virtual disks. QEMU would also have been my suggestion as an emulator. I wasn't sure if one could debug in QEMU though.
[HTC Pico (Explorer)] Sachin Thomas:
QEMU supports debugging. I also found that it can handle up to 4 virtual disks simultaneously. IDA only provides a GUI, and there are other free alternatives :)

Which all partitions should we dump? Also, is it possible to dump the radio without S-OFF or JTAG?

EDIT:

Should we dump all the partitions and concatenate them into a single "virtual NAND file"? In that case how do we know the order of the partitions in NAND?
[HTC Pico (Explorer)] no.human.being:
Part of the NAND is probably "unmapped" (inaccessible for Android). On the Wildfire S, we could take a recovery image (e. g. CWM recovery), then boot it with the following command line (this specifies how the partitions are mapped).

./fastboot -c "mtdparts=msm_nand:0x00100000@0x1ff00000(misc),0x00500000@0x02fc0000(recovery),0x00340000@0x034c0000(boot),0x10400000@0x03800000(system),0x02300000@0x13c00000(cache),0x09600000@0x16900000(userdata),0x00a00000@0x15f00000(devlog),0x02fc0000@0x00000000(radio)" boot recovery.img

The "radio" partition is normally "unmapped". Then mount SD card and dump all of them. The syntax is "size@physical_address", so e. g. "misc" is 0x00100000 (1.048.576 bytes) large and starts at a physical address of 0x1ff00000.

cat /dev/mtd/mtd0 > /sdcard/misc.img
cat /dev/mtd/mtd1 > /sdcard/recovery.img
cat /dev/mtd/mtd2 > /sdcard/boot.img
cat /dev/mtd/mtd3 > /sdcard/system.img
cat /dev/mtd/mtd4 > /sdcard/cache.img
cat /dev/mtd/mtd5 > /sdcard/userdata.img
cat /dev/mtd/mtd6 > /sdcard/devlog.img
cat /dev/mtd/mtd7 > /sdcard/radio.img

Now order by ascending physical address: mtd7, mtd1, mtd2, mtd3, mtd4, mtd6, mtd5, mtd0

Then concatenate into a single image.

cat /sdcard/radio.img /sdcard/recovery.img /sdcard/boot.img /sdcard/system.img /sdcard/cache.img /scard/devlog.img /sdcard/userdata.img /sdcard/misc.img > /sdcard/entire_nand.img

Or create a single large (0x20000000@0x00000000) mtd for the entire NAND and dump. If you actually want to use a CWM recovery image for this, you need to specify all "normal" partitions correctly, as the recovery tries to mount them and will run havoc when they're not correct. If someone manages to build a fully "self contained" operating system (that runs entirely from ramdisk and doesn't mount anything, apart from SD card) that would of course be very helpful, then you could just specify a single mtd for the entire NAND and dump it.

In case you want to upload your dump, make sure that you wipe (factory reset) your phone before you create the memory dump, to get rid of most personal data. On the Wildfire S, factory reset via HBOOT was very thorough and a quick review didn't reveal a lot of useful personal data (apart from the persistent IMEI and other serial numbers in the Radio image) afterwards.

Mind that, at least on the MSM7227, all code runs inside a virtualized environment on top of a "class zero hypervisor" running on another unixoid operating system called Iguana. Especially the "radio" partition does NOT reflect physical NAND content at all, but is entirely "virtual" and "made up" by Iguana. However, for the "running HBOOT inside a virtual machine" issue this should be ok, since HBOOT (being a guest of Iguana) perceives this as the actual NAND content. If you were to look at NAND using JTAG though, you'd see that the content is actually very different from what it appears to be for HBOOT/Android.
[HTC Pico (Explorer)] Sachin Thomas:
This is what I got from cat /proc/mtd

dev: size erasesize name
mtd0: 00100000 00040000 "misc"
mtd1: 00500000 00040000 "recovery"
mtd2: 00400000 00040000 "boot"
mtd3: 0eb40000 00040000 "system"
mtd4: 03b00000 00040000 "cache"
mtd5: 09600000 00040000 "userdata"
mtd6: 00a00000 00040000 "devlog"

I followed NHB's instructions for "backwards chaining"

And ended up with the following

"radio" : 0x00000000 - 0x02fbffff
"recovery" : 0x02fc0000 - 0x034bffff
"boot" : 0x034c0000 - 0x038bffff
"system" : 0x038c0000 - 0x123fffff
"cache" : 0x12400000 - 0x15efffff
"devlog" : 0x15f00000 - 0x168fffff
"userdata" : 0x16900000 - 0x1fefffff
"misc" : 0x1ff00000 - 0x1fffffff

Can somebody please verify these calculations for me? :D
[HTC Pico (Explorer)] #define:
Calculations are fine.. I've successfully mapped the radio partition using these values.. But I cant dump it.. It gives me I/O error.. "cat" command cannot read it..

bhargav@bhargav-MacBookPro:~$ sudo fastboot -c "mtdparts=msm_nand:0x00100000@0x1ff00000(misc),0x00500000@0x02fc0000(recovery),0x00400000@0x034c0000(boot),0x0eb40000@0x038c0000(system),0x03b00000@0x12400000(cache),0x09600000@0x16900000(userdata),0x00a00000@0x15f00000(devlog),0x02fc0000@0x00000000(radio)" boot recovery.img
[sudo] password for bhargav:
downloading 'boot.img'...
OKAY [ 6.474s]
booting...
OKAY [ 0.006s]
finished. total time: 6.480s
bhargav@bhargav-MacBookPro:~$ su
Password:
root@bhargav-MacBookPro:/home/bhargav# adb shell
adb server is out of date. killing...
* daemon started successfully *
~ # cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00040000 "misc"
mtd1: 00500000 00040000 "recovery"
mtd2: 00400000 00040000 "boot"
mtd3: 0eb40000 00040000 "system"mtd4: 03b00000 00040000 "cache"
mtd5: 09600000 00040000 "userdata"
mtd6: 00a00000 00040000 "devlog"
mtd7: 02fc0000 00040000 "radio"
~ # cat /dev/mtd/mtd0 > /sdcard/misc.img
~ # cat /dev/mtd/mtd1 > /sdcard/recovery.img
~ # cat /dev/mtd/mtd2 > /sdcard/boot.img
~ # cat /dev/mtd/mtd3 > /sdcard/system.img
~ # cat /dev/mtd/mtd4 > /sdcard/cache.img
~ # cat /dev/mtd/mtd5 > /sdcard/userdata.img
~ # cat /dev/mtd/mtd6 > /sdcard/devlog.img
~ # cat /dev/mtd/mtd7 > /sdcard/radio.img
cat: read error: I/O error

EDIT : I used yannou90's CWM based recovery, since its stable, ie, doesnt have any sort of mounting bugs what-so-ever... Other recoveries have some mounting issues..

EDIT2 : I just took a look at my sdcard, and I've found a radio.img file of the size {6295552} bytes.. So I'm guessing it can read the radio partition, just not all of it.. Why would that happen?? Corrupt/unreadable data maybe??
[HTC Pico (Explorer)] cute_prince:
@bhargz16

Try to execute above commands one at a time and see which partition is actually causing read error :)
[HTC Pico (Explorer)] Sachin Thomas:
Are you sure that you got the same values that I got with "cat /proc/mtd" before mapping radio?
[HTC Pico (Explorer)] #define:
yes... I checked before and after.. Only difference is that i checked before on phone.. but that doesnt make much of a difference... Also, running 'ls' in the /dev/mtd' dir gives me 14 files...

mtd1, mtd1r0/ro(not sure), 2, 3, so on..
[HTC Pico (Explorer)] #define:
these are executed one at a time only.. and only radio is giving read error and that too after reading and writing 6.3 mb...
[HTC Pico (Explorer)] #define:
And the only dumps we really need are "misc" and "radio" partitions.. And also, the radio dump generated will not be actual NAND data, as posted by NHB a few posts earlier... And since we dont have JTAG access(dead-end from my end), our only hope atm is an ARM emulator, since ts the closest thing to JTAG... btw, where are we on the emulator?? I have qemu, but i'm having a bit of trouble setting it up... If anybody can help, please PM me...
[HTC Pico (Explorer)] Sachin Thomas:
Can you compare the md5 hash of other partitions with that of a nandroid backup? If they match, we can at least be sure that the other partitions are mapped and dumped correctly, and the problem is with radio only.
[HTC Pico (Explorer)] #define:
The others are done properly... only problem with radio.. and that to midway..
[HTC Pico (Explorer)] Sachin Thomas:
Did you really check it? For example,does the dumped boot.img and recovery.img start with the bytes "41 4E 44 52 4F 49 44 21 B8" ?
[HTC Pico (Explorer)] #define:
In place of last B8, in boot.img there's 78 and in recovery.img there's 34... Rest matches.. Should I make a nandroid and check??
[HTC Pico (Explorer)] Sachin Thomas:
It's better to compare with a nandroid backup

EDIT:

It depends on the boot.img and recovery.img installed on your phone. Only the first 8 bytes are universal. So the problem is with radio only.

EDIT 2:

I get the same error. cat dumps only the first 6,295,552 (0x601000) bytes from radio :(
[HTC Pico (Explorer)] #define:
Ok... so now its confirmed that radio is giving problems... could it be that it wouldnt allow access to certain sections of its data?? If thats the case, is there a way to skip the "bad"(so to speak) sectors??
[HTC Pico (Explorer)] Sachin Thomas:
Unfortunately, the cat command doesn't allow us to skip bad regions (unlike dd conv=noerror,sync)

I tried to dump it from somewhere in the middle (0x01000000@0x01fc0000) and I got only 512 KB (0x80000) of garbage (I'm not sure whether it's garbage it was 512 KB of 0xff)

EDIT:

According to NHB

According to munjeni
[HTC Pico (Explorer)] #define:
Tbh, i dnt think a radio dump would help us that much without JTAG... since what we dump isnt actually NAND data... its just something that the unixoid generates... Our best bet right now, would be to work with ARM emulator... and work through the hboot itself...
[HTC Pico (Explorer)] Sachin Thomas:
But the HBOOT inside the emulator will try to read data from radio and misc and will crash if they are not found. That's why we are looking for a virtual NAND
[HTC Pico (Explorer)] #define:
Agreed, and we have the misc dump... But the radio dump we get, even if we do, will not work.. As the hboot probably has access to the physical data, which it'll be looking for, but wont get.. So there's a high probability that it'll crash with our radio dump as well.. Just my logic..

EDIT : I talked to my professors about the JTAG project, and they declined, not so respectfully.. So thats a dead end...
[HTC Pico (Explorer)] Sachin Thomas:
So, what can we do now?
[HTC Pico (Explorer)] #define:
I dont really know.. We could try and strip the hboot.. Something like Becimester's doings.. Maybe we need a new direction to work in.. A whole new idea..
[HTC Pico (Explorer)] Sachin Thomas:
Our HBOOT is a bit bigger than the WFS HBOOT and we don't have sufficient manpower :(

I think it's also more complicated, because it uses Rijndael encryption in addition to RSA and hashing algorithms
[HTC Pico (Explorer)] #define:
Hmmm.. Thats true.. But the encryption and algorithms only deal with the signature.. We boot from the modified hboot.. So we can even create one from scratch, and it'll still allow us to boot from it...
[HTC Pico (Explorer)] BeciMester:
I would sooo like to help you guys, but I have 2 nights left to finish this stupid assignment... :(

You mean there's more code, or just extra data tacked on at the end?

I haven't seen your hboot yet, but I don't think there's going to be much difference. The WFS hboot is 98% the same as the original Desire (Bravo) so, seeing how similar the Explorer is to the WFS, I expect it to be even closer. :) I believe when the reason for our rebooting is found, it'll be applicable (or at least helpful) to you guys as well.

Hang in there, we'll figure this thing out. ;)

(I'm on my phone...)
[HTC Pico (Explorer)] #define:
Thanks man... thanks a lot.... m all out of thanks for the day....

Actually the output of both the hboots is slightly different.... but the solution would be applicable to our phone as well...
[HTC Pico (Explorer)] Sachin Thomas:
Yes. And the main problem is that in our case it doesn't properly read the flag from misc partition and display "UNLOCKED". It displays "LOCKED"

There's more code too. It should include code for implementing Rijndael. But once we identify it, we can skip it.