yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
Mmh, damn!

Are you sure you got all the values right? Just to check again, here's what you have to do in order to "configure" the exploit for your bootloader and payload.

"load_addr" must be set where you load your code from. It's set to <physical kernel load address> + <length of exploit code>. Unless you modified the code, the latter will be 0x48 so you have to add 0x48 to your physical kernel load address and write that to "load_addr". This is not your "mkbootimg base address"! You actually MUST check the image that "mkbootimg" generates since only there is the "actual" kernel load address!

"execute_addr" must be set where your payload code expects to be loaded to. Should be 0x0 physical zero for HBOOTs.

"length" is length of the payload. Should be 0x80000 for HBOOTs (unless sizes vary).

Then you must build it using "arm-none-eabi-asm" and "arm-none-eabi-objdump", do a binary concatenation of exploit code (first) and "payload" (HBOOT) code (second). Then you must wrap both up into a "mkbootimg" boot image, together with a (preferably empty) "initrd". Then you must boot it via Fastboot and while you issue the Fastboot command you must hold "Vol-Down" on the phone so that it enters into the (chainloaded) bootloader.

Yes Vref is very weird indeed, also on the MSM7227 in the WFS and on my JTAG interface. Vref is very high-impedance (principally "open" but more likely a high-impedance input) on the MSM7227 but ARM specification says that "Vref is to be provided from the processor to the interface" and my interface is compliant and thus it's an input on the interface side as well (albeit not THAT high impedance as on the MSM7227).

Input on the interface tries to "pull down" to 0 V, so its impedance appears as impedance to ground and so it pulls the Vref line on the MSM7227 low and since it's very high impedance on the MSM7227 (basically "open" - can't even measure which level it refers to since it's so high impedance on the processor side) of course it goes straight to 0 V when I connect the interface.

I've tried pulling it up to 3.3 V with a voltage source over a 10k resistor (to limit current in case something goes wrong) and of course it's pulled high easily, but it doesn't change anything. JTAG interface always puts out 3.3 V no matter how much Vref you supply (swept it from 0 up to 3.3 V - didn't want to exceed JTAG interface's native level) and processor always puts out 0.9 V no matter how much Vref you supply. So I think Vref really doesn't matter. The problem is somewhere else. The levels just don't fit. Vref ("reference voltage") sounds like it's there to make the JTAG interface adjust to the processor's I/O voltage or vice versa, but it seems that both have their "native" level. Don't see the purpose of Vref. When you supply voltage to it, nothing changes regarding the JTAG signals on the other wires.
[HTC Wildfire S] munjeni:
VREF I think mean "check target voltage" instead of "put voltage to target" ? So thats reason why I have not full working jtag because VREF can not see my board voltage (I can get only write/read access with battery trick (1 second battery in, than out but not releasing vref from segger <-> v+ battery pin from phone, pin from segger is all time connected to v+))?

Yes I have set all offsets right (kernel adress=0x8000, load address 0x13008048, base adress=0x13000000, jmp addr=0, lenght 0x100000...)
[HTC Wildfire S] no.human.being:
ARM datasheet says about VREF (they call it VTREF but it's definitely just a different name :D ):

ARM has some strange terminology. The "DSTREAM" is the JTAG interface. Of course the "target" is the processor. The text sounds like the processor should (if adhering to specification) provide its own "high" I/O logic voltage via this pin to enable the JTAG interface to adapt its own voltage levels to match that of the processor.

Howver, it seems that both parts do not adhere to the specification. The pin is high-impedance (so it's definitely an input) on the MSM7227 so the MSM7227 is violating ARM's specification since normally the processor should provide voltage there, not "expect" one. Of course changing the voltage to VREF doesn't change the processor's I/O logic levels (but the specification doesn't expact that either since it expects the JTAG interface to adapt to the processor's I/O level, not the other way round). It just sticks at 0.9 V.

And on the JTAG interface side, no matter what voltage you put on the VREF pin, the interface also sticks to its own 3.3 V logic level. So the interface is also violating the specification in that it doesn't "adjust down" to the voltage one supplies to the VREF pin.

No wonder that nothing works when no one adheres do the specifications. :D

---------- Post added at 09:44 PM ---------- Previous post was at 09:26 PM ----------

Eerm?! Kernel address? Base address? Oh man! In the Android kernel header there's a "kernel address" (it's a little endian 4 byte word starting at offset 0xc). Verify that this is 00 80 00 13 (0x13008000 in little endian). I don't get why they don't just let us specify the address where we want to have the kernel loaded. Why specify "base" and "offset"? It doesn't make sense. They build a single address of it in the end. Why not let us specify this address directly?

Length 0x100000 is 1 MiB (1.048.576 bytes). Quite a lot for a bootloader. Verify that your "kernel" (exploit code + HBOOT concatenated) is exactly 1.048.648 bytes long before you put it into the boot image with "mkbootimg".

If you verified that this is all as expected, well, then there's probably indeed something that prevents you from doing what we do on our devices.
[HTC Wildfire S] munjeni:
... I posted that just for reference only about my device! I not set kernel base, just only say about standard offset 0x8000:)

I no need to set base addr when making boot.img? I think that will not work without basse addr while making test.img using mkbootimg. Just for reference only about my device: mine device: base for "boot.img" addr=0x13000000; hboot=1mb size, not like on aria with size 0x80000, hboot loading (virt) offset =0x9d000000 ...etc. I think I set all corectly?
[HTC Wildfire S] no.human.being:
I don't understand the purpose of this "base address" and "kernel offset" stuff. In the resulting boot image, there's a "kernel address" at offset 0x4 and that's the physical address where the kernel is loaded (so first byte of the file you supply as "--kernel" gets loaded to physical address that's specified in resulting boot image at offset 0xc). I don't understand why "mkbootimg" doesn't let us specify that address directly since basically that's the interesting one since that's where the kernel is actually loaded.

For Wildfire S there's a special "mkbootimg_wfs" utility that doesn't even accept a base address. The CyanogenMod 7 kernel from xda member alquez has 0x12c08000 as "kernel_addr". This is the physical address where the kernel is loaded. You cannot directly specify that in "mkbootimg", but the actual value is a little-endian 32-bit word at offset 0x4 in the resulting boot image file that "mkbootimg" puts out and you take that address and add 0x48 and that's what you specify as "load_addr" in the "loader.s" source. Since you specified 0x13008048 as "load_addr" in "loader.s" (right?), please verify that the bytes starting at 0x4 into the boot image that "mkbootimg" generates for you are 00 80 00 13 hexadecimal (0x13008000 in little endian). If they aren't, then either overwrite them with these bytes so that HBOOT actually loads the exploit code to 0x13008000 physical or adjust the "load_addr" in "loader.s" to the address you have in your boot image (plus 0x48). Hope that this works for your device. If you have more questions, feel free to ask.

EDIT: Ah, this "base address + 0x8000" stuff is a convention of the Linux kernel.

Also, like I said, MMU must be disabled and CPU must be in supervisor mode.

See here.
[HTC Wildfire S] Antagonist42:
VREF etc check the Lauterback docs I posted, if I read them correctly you may only be looking for a 0.3v difference from say the 1.9, this I'm not sure but would would you have to program your pick-up probes to look for that and not drive the unit up to 3.3v as I wouldn't have thought you'd test code by putting hardware at Max so to speak

Had a look at Lauterback doc and schematic, it looks like you have a VTREF and VSUPPLY

VSUPPLY could possibly pick up a 5V_REG line from PM7540 (possibly ensure it is not the 'Flash' 5V line) and VTREF from possibly LP5900TL-3.3/NOPB U42 on schematic although both possibly USB Inputs.... essentially if you supply 5v for power and a seperate 3.3v from the system you have drainable supply for unit and unit will give you your Vref, I think with only one power line supplied the unit will act as though the JTAG is applying a drain and PM7540 will protect the system by dropping the voltage as 'self preservation' as it is part of it's job thus the low voltages and inability to get a decent reading. I am 'NOT' sure if you can use simply a USB connector for a 5v supply rather than trying the board, then you can leave 3.3v to be picked up from the JTAG as normal.
[HTC Wildfire S] munjeni:
I'm building this using arm-none-linux-gnueabi Code Sourcery cross compilers... maybe I need arm-none-eabi- ??

Edit:

tried with arm-none-eabi but chainloader not working... I think, to get it working (in order to move hboot to offset 0) , we need to disable memory protection to allow us to coppy bootloader to the right offset ? In my tests hboot is not overwriten in memory because version string that I changed is not changed on screen, but you exploit still working without reboot!

ldr r0,modem_mpu_addr @disable modem MPU
mov r1, #0
str r1, [r0]

ldr r0,smi_mpu_addr @disable MPU to allow us to copy the bootloader
mov r1, #0
str r1, [r0]

modem_mpu_addr:
.word 0xa8240800
smi_mpu_addr:
.word 0xa8250800
[HTC Wildfire S] munjeni:
Hey, found why I am unable to boot hboot on desire c ... hboot image (dumped or not dumped "stock") is signed!!! So modifying any bute inside hboot cause signature mismatch!!! :( I don't understand if this is the new htc method for hboot bootloader but for sure it contain hashes at and of the file... If this is true than hboot modifications will not be possible :( Now I don't know if I can remove hashes from hboot?
[HTC Wildfire S] beaups:
I've been telling you all along that hboots are signed!

You still should be able to use this exploit to one-time boot to an unsigned hboot though....do you have an engineering hboot to test?
[HTC Wildfire S] munjeni:
I haven't enginering hboot! Is that "new thing" for hboot on all new devices??? If yes than for sure I will not by an htc phone next time :mad: this htc devices going to be true secured instead of true unlocked... I think his company for sure will lose 30% of the profit by making devices like this "more secured" and "non-development based"... I realy not understand why his devices is from-time-to-next-time more secured than before... why it is secured I realy not understand)... for sure will buy non-htc device next time and for sure will double check for "is development-posible" before by an phone :mad:. I have Desire C and I must to say its **i* phone, phone mising compass, phone mising button lights, phone mising auto focus for camera, phone missing... its very funny that he selling phones that have no lights for keypad buttons... is that phone? I don't think + its hard secured...pfhhh cccc, will not be fooled next time, for sure. If someone have plan for buying desire c than DO NOT BUY IT !!! Double check forums before you go to buy an phone!!! Any xda link to an post with "new" devices that have done s-off???
[HTC Wildfire S] beaups:
I think hboots have been signed and sig-enforced for a long time, if the device is s-on. But I don't know for certain.

Also, I believe you need an unlocked bootloader to boot to a non-signed image of any kind through fastboot. Is your bootloader unlocked?

ENG hboots leak....or are released by guys like revolutionary, etc. But they are unsigned, so you need s-off to use them.
[HTC Wildfire S] munjeni:
ENG hboot for? Device? Hboot lies in emmc partition allso signed.... its like radio checking hboot signature before hboot loaded, so I think hboot modification is not posible!
[HTC Wildfire S] theq86:
Probably it is. the fastboot boot command is completely forbidden for locked bootloaders.
[HTC Wildfire S] munjeni:
Yes, my botloader is htcdev unlocked and I can boot unsigned images... still I want to know if hboots like this is modifyable and to know if some one managed to s-off an device like this
[HTC Wildfire S] beaups:
Well you probably can get those answers in a thread for your phone?

Anyhow, you can not flash (without bricking) an unsigned or engineering hboot without being s-off FIRST.

The concept with nhb's exploit, and your plan of attack, SHOULD be to simply chainload an engineering or hacked hboot and WHILE still in that mode, apply commands to set s-off.
[HTC Wildfire S] munjeni:
Stil I not know now if radio checking hboot signature? Or if is possible booting an modified hboot because contain hashes :( Question is: why hashes is in hboot and who check it?

I not seen any post about that some one managed to modify an hboot like this and sucesfully flash it... do you have any link? I allso not seen any root exploit for newer htc devices :( still very secured now

---------- Post added at 05:44 PM ---------- Previous post was at 05:31 PM ----------

How you sure?

Curently I have no working usb connection to hboot loaded from chain exploit (still exploit working on htc aria) :( but chain exploit not working on desire c on this 1mb hboots :( so in "two" ways I am unable to get it working on booth devices... think I need to establish jtag connection to my new phone and set s-off+custom hboot:(
[HTC Wildfire S] beaups:
SBL3 checks hboot's signature. But the whole concept of this exploit is to chainload a hacked hboot and push it to the right memory location. SBL3 checks hboot before it loads but with this "fastboot boot" exploit SBL isn't checking our "kernel" for signature since unlocked devices don't require signed kernels/system images. Newer htc phones have been rooted, I know this first hand ;)
[HTC Wildfire S] munjeni:
I saying about root exploits only, not about htcdev unlocked bootloader :)

Exploit is like working on my new phone but hboot is unmodified after boot, for example I changed version string but after boot (theres no reboots!) hboot title is the same, still like restored :)
[HTC Wildfire S] beaups:
There are root exploits. I rooted the one x just a month ago. Newer version is locked pretty good, but where there's a will there's a way ;)

Anyhow, I suspect you just aren't using NHB's exploit properly. And since I don't have it, I can't really help.
[HTC Wildfire S] munjeni:
He said allso about non-working usb, so without usb its unusable now, maybe we can jmp to function "flash(hboot)" trought hboot by self by chain exploit but now hboot is unusable "frozen" after I load it by exploit. We don't know whats going in. I don't know whats n.b.h opinions after his tests... in my tests its unusable now, only good thing is its bootable. On htc aria I can load hboot but I can not see "loading zip", still device reboot when I put sd card into micro usb slot! N.b.h say he have seen "zip loading" on his screen, but I am unable to see that!
[HTC Wildfire S] beaups:
You aren't listening ;)

You don't want to jump to function "flash hboot" because if you flash an unsigned hboot you will have a brick.

Jump to function "fastboot oem writesecureflag 0" in an engineering hboot.

THAT has potential.
[HTC Wildfire S] munjeni:
C:\Documents and Settings\Desktop\adb>fastboot oem writesecureflag 0
... INFO →ŻtjHTCE
INFODone!
INFOHWIO_SDC1_MD_REG_ADDR=0xA86000A0
INFOHWIO_SDC1_NS_REG_ADDR=0xA86000A4
INFOHWIO_SDC3_MD_REG_ADDR=0xA86000B0
INFOHWIO_SDC3_NS_REG_ADDR=0xA86000B4
INFOphys_to_virt(HWIO_SDC1_MD_REG_ADDR)=0xB32000A0
INFOphys_to_virt(HWIO_SDC1_NS_REG_ADDR)=0xB32000A4
INFOphys_to_virt(HWIO_SDC3_MD_REG_ADDR)=0xB32000B0
INFOphys_to_virt(HWIO_SDC3_NS_REG_ADDR)=0xB32000B4
INFOsdc_ns_reg value=0xFF9E0B58
INFOHWIO_SDC1_MD_REG_ADDR=0xA86000A0
INFOHWIO_SDC1_NS_REG_ADDR=0xA86000A4
INFOHWIO_SDC3_MD_REG_ADDR=0xA86000B0
INFOHWIO_SDC3_NS_REG_ADDR=0xA86000B4
INFOphys_to_virt(HWIO_SDC1_MD_REG_ADDR)=0xB32000A0
INFOphys_to_virt(HWIO_SDC1_NS_REG_ADDR)=0xB32000A4
INFOphys_to_virt(HWIO_SDC3_MD_REG_ADDR)=0xB32000B0
INFOphys_to_virt(HWIO_SDC3_NS_REG_ADDR)=0xB32000B4
INFOsdc_ns_reg value=0xFF9E0B58
INFOsdcc_init_memory_device done
INFOHWIO_SDC1_MD_REG_ADDR=0xA86000A0
INFOHWIO_SDC1_NS_REG_ADDR=0xA86000A4
INFOHWIO_SDC3_MD_REG_ADDR=0xA86000B0
INFOHWIO_SDC3_NS_REG_ADDR=0xA86000B4
INFOphys_to_virt(HWIO_SDC1_MD_REG_ADDR)=0xB32000A0
INFOphys_to_virt(HWIO_SDC1_NS_REG_ADDR)=0xB32000A4
INFOphys_to_virt(HWIO_SDC3_MD_REG_ADDR)=0xB32000B0
INFOphys_to_virt(HWIO_SDC3_NS_REG_ADDR)=0xB32000B4
INFOsdc_ns_reg value=0xFE2B0B5A
INFOWait for AMSS ready
INFOAMSS is ready
INFO[FAT_ERROR] fat_open_file: can not find SMART_IO.CRD
INFO[JAVACARD_ERR] SMART_IO.CRD cann't find
INFOwritesecureflag: permission denied, value 1
OKAY

It will not work without smart_io.crd ;)
[HTC Wildfire S] beaups:
Is that a hacked hboot? I think not.
[HTC Wildfire S] theq86:
I have to agree with him. the writesecureflag will definitely radio-s-off the device. all known htc devices where the flag was restored with writesecureflag 3 (i don't know, maybe device specific) to s-on ceased working if a custom hboot was still installed.

not only that, but hboot also showed a security breach message and refused ALL operations.

I don't know if wildfire s already has so sophisticated hboot, but it's fact that there are several additional security measures in place.

However, writesecureflag needs eng hboot. dunno if htcdev hboot also supports it.

PS: we have the diag tools. hex editing it shows that there's at least a portion of eng hboot in it. plus diag can with special sim do the writesecureflag.
[HTC Wildfire S] beaups:
^Dang you asked a lot of questions.

1.) Radio - can we write secureflag to it? Almost urban legend outside of the inner circles where exactly that flag lives. EFS? NV? On newer devices it's on partition 3, but may live elsewhere as well ;)

2.) Signed vs unsigned hboot. Again, this may be a newer/older device argument. I can tell you with certainty that on newer devices the signature persists inside the hboot. It is checked by SBL3 at EVERY boot up.

3.) Qualcomm vs OEM enforcing. Remember they aren't checking anything but signature hashes. Qualcomm could care less if Hboot, for example, is secure...as long as it passes signature checks. And that chain of trust starts with the OEM keys and PBL.

4.) Here's a real noob question. People use the term "radio" loosely. On HOX, I can trash the radio partition, make the phone run funny, etc....but it' won't brick it or fail any sort of security. When folks speak of radio, are they speaking of SBL? Or some sort of hypervisor? Or AMSS? Or what? It's hard to get a clear answer here.
[HTC Wildfire S] munjeni:
No! I have revolutionary installed and I can write radio.img and I can write hboot too ! True S-ON is in radio too ! Only I can not do is flashing an radio for example from htc hd mini to aria...still for it I think I need s-off ?

I say about hboot loaded by exploit in my phone! Hboot loaded by exploit == no usb; no menu moving by volume up/down; no HBOOT checks for XXXXXX.nbh... still freze on hboot screen!

How you got that HBOOT checks for PG76IMG.nbh using hboot loaded by exploit???
[HTC Wildfire S] no.human.being:
I just concatenated the exploit code with a patched HBOOT image (didn't test with stock image but I think that stock would work as well - probably even better, perhaps it wouldn't "fall back" - don't know whether the "fallback" comes from the exploit or whether it comes from the fact that the HBOOT code is modified - probably the latter so loading a stock HBOOT will probably work *), then built a boot image as is described in the exploit code's documentation and it worked. Well "worked". It checks for the PG76IMG.nbh and then restores stock HBOOT from NAND and jumps into it so it's currently not very useful. But if we find a way to prevent it from entering that "fallback condition" I think we got it.

* = Does anyone have a stock HBOOT-0.90.0000 image? That one is exploitable right? You cannot "downgrade" to it by flashing but we may be able to chainload it via the exploit and then perform the S-OFF exploit on it. Would chainloading an ENG HBOOT work? You'd probably have to flash the entire firmware after loading another HBOOT though since the HBOOT contains the partition table and there are different partitioning schemes.

Mind that I used an HBOOT like you would dump it from the phone's NAND via "dd". That means it must NOT contain signatures (so no NBH!) and it must NOT contain out-of-band data (like ECC, page access permission flags, etc.). If you dump HBOOT via JTAG you might get out-of-band data with it so you have to see how you can strip that out.

By the way the Iguana source code is available here in case anyone is interested how the Radio works internally. This is true open-source software, so no reverse-engineered code. Of course the processor-specific stuff is not included since it is intellectual property of the processor manufacturers. However, it seems that "generic ARM support" is there for some older stuff like ARM9 (at least there are some references to that in the source). I don't think that there's a lot of interesting stuff in the code though. Bootloader looks more promising.
[HTC Wildfire S] munjeni:
Tried allready with stock hboot... got freze on hboot screen too! Hboot is raw 0x80000 butes and not contain any signature, ecc...etc!
[HTC Wildfire S] beaups:
I was just teasing there

0x00480828 physical RAM address? Well certainly it must live somewhere persistent, right? Like I said, on modern devices it's in partition 3.

Totally agree. That's why I'm suggesting chainloading an engineering or hacked hboot. Something that would allow us to execute 'fun" fastboot commands - such as fastboot oem writesecureflag 0

Hmm, I think qualcomm is just enforcing security per the oem request. You can order unlocked, fully modifiable development boards, no? What IP could they be protecting? We can DD away and reverse all the bootloaders except PBL, right?

Yeah I've read and studied all this stuff. But it doesn't really answer the question. Let me put it this way. On the HOX, the "radio" partition is left wide open, writeable, and unsignature checked. If I screw with it, the device boots fine (although won't connect to network etc).

So when we say "radio", which specific area are we discussing? If it's the REX (where is it?) then why does writesecureflag call up AMSS?

I don't claim to understand this radio stuff, I've read the same stuff you have, I just can't see how exactly it maps to our devices.
[HTC Wildfire S] BeciMester:
Guys, I'm following the discussion and am pretty excited with the progress you've made. :good:

Here's an idea. Poking around in hboot v1.08.0099 (this is the version you're loading, right?), I think I've identified the part that sends the radio the command to turn off the secu_flag, after all the security checks were done. Entry point is at offset 0x00044408, and if it returns an error, the part that called it displays "Set security flag 0 fail!!!" :p So... seeing that now y'all can chainload the hboot image and jump to its first instruction... if you feel adventurous, jump to the address above instead, might have instant s-off... :laugh:

Edit: of course the stock hboot will do, just in case the modifications break something.

Btw my WFS died on me a few weeks ago, suddenly stopped taking charge and now the battery is completely flat, can't even turn it on. :crying:
[HTC Wildfire S] mstfkaratas:
here hboot_0.90.0000_720d6ffc74.nb0

I can install it to my wfs and dump it with "dd" if you want.