yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] Antagonist42:
It's chainloaded i'm pretty sure

EUU .vdh file I was looking at for my ACER looks as though n.h.b. is right it is chainloaded to install updates, it may also have to be re-installed after each part of the update is 'FLASHED' essentially once data is passed hboot ends it's operations, adb says there's another .img to send it re-loads hboot and continues to flash, maybe until the reboot from EUU through adb is sent.

Halting or interrupting the EUU before it actually sends data could leave us with the NAND open for us to intervene and try that way to get code in, this way as well it means just about everything is signed/keyed so would seem to be a legit operation. It maybe worth looking into exactly what an EUU/RUU does when it initially connects with phone internals ie. taskkill /f /im HTCVBTServer.exe ....does this just turn off BlueTooth or does it shut it down completely leaving it's access ports open for use?

This post has the .vdh file the 'original file' if you know how to extract the data from the hex contained go ahead or let me know as I still can't get the actual thing converted (keep getting errors as to actual data type incorrect I think) would be a big help :o
[HTC Wildfire S] Antagonist42:
CRUCIAL...

After digging around and head scratching I think I got another part to the puzzle :fingers-crossed:

Running my EUU the .exe uses the file BlahBlah.vdh this I have dropped into IDA, HxD, BinText even notepad :p using Hex_romtool.exe that I downloaded from here I was still unable to extract the data that I have already seen in IDA as what looked highly like what is contained in fastboot.

I still have not managed to extract the data but I have worked something out by the HEX data in it reading from here and more so from here at Keil that part of the reason it won't extract is that it's a 'MEMORY' file that is sent from the EUU directly to a memory address (mine being 0x00500000) so i'd hazard a guess that if you were to take an RUU and it has similar file for updating this would give you the address to run the exploit from as at the moment we could be loading it into an arbitrary address that doesn't tally with any security checks as maybe a memory location hash or something .... :confused: don't forget I'm still a noob at this at 40 :laugh:

Interesting :cowboy: they do NOT stick to the seemingly normal ways of obtaining the address either as I guess there are no rules how you use .hex data only that the best start point is Intel Hex, this is what I mean...

Android .hex Data extracted to .bin images.
:0A000003414E44525F494D414745FF
:020000040000FA
:200000009A1B7DAABC487D1F0300000014000000303A4D4942494200000000000000000080

Line 01 - RAW Data - ANDR_MODEM

Line 02 - Hex Data including image type, length etc *040000FA* left blank as is an image

Line 03 - Hex Data

If this was to be written to RAM then Line 02 would read something like :2000000412345678FA but it's not as the only way to tally the address with the Data and Address in IDA it works out as:

ACER BlahBlah.vhd file
:020000040050AA
:1000000007000000030000002800500028005000F6
:100010007020030096170300BE1753000001000074

No Image Name.

Line 01 - Hex Data standard type/layout but address should read 0400000050AA as explained here under 'Start Linear Address Records (MDK-ARM only)' but is not and that could be down to the Thumb Instruction Set reading 2 bytes at a time.

The address carries over you have 40050AA and the next line of data 1000 then the address carries on 0000 end of address then data 07000 etc

... as close as a NooB can work it out :confused:

..... tried altering the address and load into IDA - it fails to load correctly :laugh: :highfive:
[HTC Wildfire S] munjeni:
Nand page (one page) is not 0x200 butes len, nand page is 0x20000 (131072) len! When you erasing/writing to an block you need to "use" whole block or your operations to an block will fail if you not set size 0x20000 (whole block)! Aria and wfs have 4096 blocks (4096 * 131072 = 536870912 == 0x20000000) Block where s-flag lies is block 36! You can see all blocks here -> http://paste.ubuntu.com/1163988/ I used that just for offsets reference when I worked with...

N.B.H I think exploit will work but do you have idea where hboot fail (freze) when we load it by exploit? I think we need to patch something inside hboot to get "hboot continue"... I think hboot have "constant loop" to something (there fail to continue) while we load it by exploit ?
[HTC Wildfire S] beaups:
RUUs just send a rom.zip to the device for flashing. All the security and dirty work is done on the device. No magic happens in the RUU, you're wasting your time reversing it.
[HTC Wildfire S] theq86:
this is what I stated pages and pages ago and again and again. :D
[HTC Wildfire S] Antagonist42:
OK if it is such a waste of time looking at it why do I have a RAM address to load (what looks more than likely) fastboot as DIRECT DATA and not a .nb0 .img etc. - as for security/keys etc if it's through fastboot being loaded maybe it's not 'What' is loaded but 'Where' it's loaded if you think about it fastboot contained on your phone is called from NAND and from Qualcomms docs there is something running that whatever is called passes through AXI Bridge, it's checked, so running it from the phone won't work, using it through adb you're still using at the end point the fastboot from either your PC or the NAND, the security (however it is run/running or makes it's checks) will in all likelyhood have picked this up, if it's run as a normal update the same would apply the thing is maybe it's not 'What' is checked but 'Where' it's checked to pass, all it may take is a hash from a specific memory location at a certain address.

If it all seems so tied up but should be so simple then maybe it is :confused:

Like i've said a long time ago too I tried installing a Malez boot, on it's own failed, ran the EUU, halted it's progress before it began to send data to be flashed, installed Malez boot, if it didn't matter about fastboot (which I tried installing with fastboot from ACER update - didn't work) why does it not flash with any fastboot but does with EUU (EUU installing fastboot to RAM at specific Address not arbitrary)?
[HTC Wildfire S] munjeni:
Allso I think you wasting your time with ruu! Ruu is only for preparing your phone to download mode, for example ruu check installed version, check for model, and if everything match than send command to your phone "fastboot oem rebootRUU" and than send your signed zip to phone... all other thing is done by hboot (signature checks...etc).
[HTC Wildfire S] beaups:
It's not strange. SBL3 sig checks hboot before it passes execution to it,
[HTC Wildfire S] munjeni:
I'm not sure. I tried to chainload unmodified hboot(unmodified stock hboot with unmodified signature) and it fail too! So it mean there is something strange, is not? Where you found that? Any link?
[HTC Wildfire S] no.human.being:
You'd probably have to set up the MMU though. You'd do that after the copy loop and then jump to 0x9d044408 virtual. Most HBOOT code is designed to be run with the MMU configured.

Yes, I know what it feels like. I'm also explaining the same things again and again. :D

It's so bad that we cannot debug. Programming without a debugger is not fun (and also not productive). :(
[HTC Wildfire S] munjeni:
Thats what I truing to do :) ...tried some things (unsucesfull) but will try later for example to simple reboot device by jumping to function_reboot... than if that working I'm surre we are ready to implement revolutionary method (hboot append to "position" than install by calling update_partition() without needs for misc partition exploit)
[HTC Wildfire S] beaups:
Could be a million things. Exploit might not work on your device, you could be building it wrong, etc. etc.

I'm going to try not to take this thread too far OT since it's for WFS. But on eMMC devices the qualcomm eMMC recovery mode is contained in SBL3. When hboot sig fails, the phone drops to that mode. I suppose it's possible that it's not SBL3 doing the check on hboot, but it's the safest assumption right now.
[HTC Wildfire S] munjeni:
I am surre I building exploit corectly because that exploit working on nand based devices (my old phone)! And allso I think exploit working too on emmc bassed device because my device can not rebooting (allso I verified that exploit can run "mov pc, #0" - so that mean exploit working!) but only problem is that hboot is runing unmodified and I have no idea now how to debug whats going in (maybe hboot have some other checks by self before continue to boot?), one function I have bypassed (hboot signature check) but still this not working again
[HTC Wildfire S] beaups:
Can't you find a modified hboot to try loading? (engineering hboot, etc.). What chipset?
[HTC Wildfire S] munjeni:
I haven't found any eng hboot for my device... there is only 2 hboots (one is 1.25.0000 and seccond is 1.28.0000)... my device is: HTC Desire C; armv7a, msm7225A Cortex A5; Adreno200... no dedicated forum :crying: tiny development:crying:...

N.B.H, did you tried to dump shared memory (MSM_HARED) kernel side, maybe there we can see "T2t string"? Maybe there lies secu-flag and if yes maybe we can set "bute" s-flag 0x01 to 0x00? Just idea. :(
[HTC Wildfire S] no.human.being:
I wouldn't know where to store a dump. Remember when you want to access physical memory, you have no operating system underneath, which means no drivers for file system, framebuffer, USB, just nothing. No way to interact with the "outside world". I don't know where to put a dump without a file system driver.
[HTC Wildfire S] munjeni:
You can dump MSM_SHARED ram by kernel or by kernel module by writing to kernel dmesg in hex form! For example you can add simpe code to for example htc_wifi_nvs.c in this form:

...
for (i=0; i<0x20000; i++)
printk("%02X ", readb(MSM_SHARED_BASE + i));
printk("\n");

shared memory is very interested and you can see many DEX cals use that memory to set/get something!
[HTC Wildfire S] Antagonist42:
Noooooo you're missing what i'm getting at....

1. Run EUU

2. EUU triggers adb and fastboot

3. phone reboots to fastboot

4. EUU Extracts .bin files from .hex files (Building images)

5. EUU checks phone status etc

6. EUU converts images

5. EUU sends images

.vdh is a part of either the converting images or the sending images as images are 'sent to be burned' not burned 'on the fly'.

Phone has already rebooted into fastboot, the .vdh file gets loaded either before EUU sends the converted images to flash or as part of the converted image either way it's put into RAM 'AFTER' fastboot has been loaded otherwise there is absolutely no need for a file that already resides in NAND and has already been activated and run and possibly still in memory (not sure if fastboot would still be in memory? ...like I say i'm a learning NooB) it would make more sense just to use it rather than load another.

Also the data in the .vdh 'LooKs Like' fastboot, it could be what is missing from fastboot to flash NAND in supervisor mode, there has to be a relevance to it being written to an address in RAM or it wouldn't have an address as nothing else flashed has an address except I think I recall 1 other file .....*off to find it again....*
[HTC Wildfire S] munjeni:
Antagonist42, you can install "device monitoring studio" and dump all usb packets that is sent/received trought usb, including all commands that is set/received! Than you can analyse it!
[HTC Wildfire S] no.human.being:
Back a few hundred pages I tried to build a kernel that implements the "msm_lock" and "msm_unlock" functions in the hope that this might enable us to write to the Radio area from within Android but I never managed to build a kernel that boots. Well the hope that implementing "msm_lock" and "msm_unlock" would give us anything is now more or less gone since we now know that there's actually a virtualization layer in between the Linux kernel and the actual hardware. I don't think that they use the "cheapish" NAND locks when they have a virtualization layer in place that they can make trap on illegal requests and block them in firmware so implementing functions to unlock the NAND chip is moot. :D

But I didn't want to write about NAND locks, I wanted to state that I never managed to build a kernel that boots. It's black magic for me and now I think I really have a clue about what a crazy guru we can expect alquez to be. I never even managed to BUILD a kernel that boots and he develops kernel code ya know? :D
[HTC Wildfire S] munjeni:
N.B.H, here is reference for DEX -> http://xdaforums.com/showthread.php?t=1177488 ...just for idea!
[HTC Wildfire S] beaups:
Is EUU an HTC thing? We are on HTC phones here and use RUUs. HTC security for flashing is simple. Zip file is sent to the phone by RUU utility. The zip itself is signed. Phone checks signature then extracts (if pass). Then each (or most) image file is sig checked and flashed. It all happens on the phone. Again, there is no magic happening from the RUU.
[HTC Wildfire S] Antagonist42:
No other file has an address in the .hex files from what I can see and I think (but not sure) that there are none even for the .img files to be loaded to in them either from what I can tell .....off to find 'device monitoring studio' ;) thankyou for that Munjeni

---------- Post added at 04:25 PM ---------- Previous post was at 04:15 PM ----------

This ACER E320 is an ODM (not OEM and produced by CCI) and the motherboard is a ChaCha... which is HTC and looks like only differences are face recognition (if ChaCha has dual camera?), keyboard and so screen size
[HTC Wildfire S] beaups:
Well from your dissection of EUU it seems as though the flash process and security could be quite different.
[HTC Wildfire S] no.human.being:
I just tried to chainload HBOOT-0.90.0000, same result as with HBOOT-1.08.0099, so yes it boots, then checks SD card for PG76IMG.nbh / PG76DIAG.nbh, then reverts to stock HBOOT-1.08.0099. Also putting the PG76DIAG.nbh file on the SD card doesn't change anything. The HBOOT-0.90.000 image was "stock" so the "restore" has nothing to do with the HBOOT running being "modified".

However, when I run the exploit with the SD card removed (!!) from the phone, it doesn't revert to stock, but locks up instead. So it stays in the bootloader screen stating "S-OFF", but it doesn't respond to anything. Both HBOOT-0.90.0000 and HBOOT-1.08.0099 show this behaviour.

Then I extracted the ENG HBOOT image from the PG76DIAG.nbh file and tried chainloading it, but when I then run the exploit with it as "payload", the phone crashes (whitescreen - no response - pull battery).

It's interesting that the "revert to stock" has something to do with the SD card. This makes it very likely that it's in fact the chainloaded HBOOT itself issuing the restore though, since the Radio is probably not very interested in the SD card. This is good since the chainloaded code does not have to be signed so if we find out why it reverts we can probably change this behaviour.
[HTC Wildfire S] munjeni:
Did you tried to load the same zip/nbh from same sd card but without exploit? First you must be surre if that working!
[HTC Wildfire S] no.human.being:
Well it will fail signature verification. However, read what I wrote. The PRESENCE of an SD card alone causes the "chainloaded" HBOOT to restore "original" HBOOT from NAND. If you remove the MicroSD from the phone, it will not restore, but lock up instead. I do not understand why this is so. This behaviour might be an indicator WHERE the restore is happening (in code). Obviously it accesses the SD card and then restores from NAND based on a condition that depends on whether an SD card is present. Does this make any sense? What do you think?
[HTC Wildfire S] beaups:
Am I understand correctly:

Sdcard inserted - exploit loads but searches sdcard for restore zip and then locks

Sdcard removed - exploit locks

?
[HTC Wildfire S] no.human.being:
No. First the exploit doesn't access SD card, the "chainloaded" bootloader (payload) does. It restores the "original" bootloader from phone NAND (overwriting the code we "chainloaded" with the code that's in NAND, then execute it). But it only does this restore when an SD card is inserted. When no SD card is present, it just locks up. In detail, this is what I observe.

SD card inserted: Exploit successfully loads and executes "chainloaded" HBOOT. "Chainloaded" HBOOT shows its "menu" (but you can't interact because it's too early stage - it still shows "HBOOT", not even "HBOOT USB PLUG" so even USB is not initialized yet), then searches SD card for the "usual files" (PG76DIAG.nbh and PG76IMG.nbh), then restores "original" HBOOT from phone NAND. Afterwards "normal boot" continues (so when you hold Vol-Down you will see HBOOT that's stock again and S-ON, when you don't hold it, stock bootloader will boot into ROM). So in this case nothing locks, but stock HBOOT is restored from NAND by "chainloaded" HBOOT. Both HBOOT-0.90.0000 and HBOOT-1.08.0099 will perform a restore from NAND when "chainloaded" and I'm quite certain all other HBOOTs will do this as well unless they're modified not to do it.

SD card removed: Exploit successfully loads end executes "chainloaded" HBOOT. "Chainloaded" HBOOT shows its "menu" and locks up ("crashes") immediately (again this behaviour is not version-dependant - both HBOOT-0.90.000 and HBOOT-1.08.0099 will crash and I think the others will crash as well). It shows "HBOOT", not "HBOOT USB PLUG" so the lock up happens before USB is initialized. Need to pull the battery.

This is for all "SHIP" HBOOTs. Chainloading an ENG HBOOT (extracted from the PG76DIAG.nbh file - yes I know that the DIAG file contains more than the HBOOT that's why I said "extracted" ;) ) via the exploit will lock up the phone immediately to a "whitescreen" (which means that it locks up before the ENG HBOOT has even initialized the framebuffer).

Because of this (behaviour of "chainloaded" HBOOT being dependant on whether SD card is present) I also tried disconnecting the phone's USB connection to the computer directly after loading the exploit, thinking that this might also have an effect on the "chainloaded" HBOOT (when a phone is "USB bricked", both the USB controller and the SD controller will cease working, so the two components seem to be related somehow and HBOOT definitely initialized USB for both a shell and Fastboot support). However, it didn't have any effect.

Did I mention that debugging would be nice to have now? :D
[HTC Wildfire S] beaups:
Interesting. What did you do in your chainloaded hboot to make it show "s-off"?
[HTC Wildfire S] no.human.being:
It won't just "show" S-OFF, it will also "act" S-OFF. Once we get this running, you can expect it to be like Revolutionary HBOOT.

I ran this exploit (called "exploit-inject") that I developed some time ago against an HBOOT image that I put onto the SD card of the phone (instead of against an mtd device - running it against an mtd device was first the intended use case, but it turned out that it won't help because security is "too strong" for such a simple hack).

What it will do is, it will make it output "*** INJECTED ***" (so that you know that you're running an exploited HBOOT) and overwrite the function in HBOOT that asks the Radio for S-ON or S-OFF with the following code.

e92d4010 ???
e3a00000 mov r0, #0
e8bd8010 bx lr

I have forgotten what the first instruction is in assembler (would have to disassemble it) but I think it saves some register to the stack. Basically what the function does is always return zero (S-OFF) so it's basically the assembly equivalent of the following.

int check_secu_flag()
{
return 0;
}

The function is called whenever HBOOT needs to query the Radio for the secu_flag so effectively, even though we didn't change the actual flag in the Radio, HBOOT will behave S-OFF because that's what the function that allegedly queries the Radio for the secu_flag returns.

The exploit can be run against HBOOT-1.08.0099 and HBOOT-1.09.0099 images. Other HBOOT images are currently not supported. If you want to patch HBOOT manually, the function is at offset 0x8b68 into the HBOOT-1.08.0099 code and at offset 0x8b58 into the HBOOT-1.09.0099 code. The function is quite long, but overwriting the first three instructions (12 bytes) will be sufficient since the third instruction will return from the function, so that what comes after it will never be executed. We currently don't know how to patch other HBOOT images to S-OFF. It's requires quite a lot of reverse-engineering effort (that Beci-Mester did - thanks pal!) to locate this function in the HBOOT code, which is why we currently only support these two HBOOT versions.
[HTC Wildfire S] beaups:
^Nice work.

In your reversing of hboot, have you identified the routine for "writesecureflag"? If so, do the diag/javacard authentication routines get called by hboot or radio? If the former, could we not just jump to it?
[HTC Wildfire S] no.human.being:
I'm quite sure that authentication is performed by the Radio.

At least when you S-OFF via DIAG all that DIAG does is ask the Radio to set S-OFF (probably like sending "AT@SIMLOCK=7,0" to the REX "shell" after doing "fastboot oem rtask C"). We know that since on CDMA phones you can achieve S-OFF with the DIAG files alone. No need for a smart card (or xtc-clip emulating one). However, on GSM you absolutely need a smart card for this. Obviously, the Radio for CDMA is different than the GSM Radio. The DIAG files are the same. So the authentication is performed by the Radio, not the DIAG utility. I think that "writesecureflag" does exactly the same.
[HTC Wildfire S] beaups:
You're probably right, but are you sure? Seems odd that all of the javacard status gets echoed out by fastboot.
[HTC Wildfire S] munjeni:
No no no, its not true! First way. This working with "standard" sd card "only" if update.zip contain right CID that is the same like CID in your phone(you can check it in CID.txt) ! Allso your zip must be unmodified because if you modify zip signature will fail. So zip must be original (unmodified and signed by htc)l!!! Seccond way. If zip contain CID that not match CID in your phone than that will not working without gold sd card and you will must to generate one! What gold card is? When you have gold card - mean you have super cid and you can install any zip without cid matching you phone cid (of course unmodified zip or nbh...whatever is)!!! So with super cid you can install any zip for your phone model ! Allso to get "sd card method" working your sd card must be not biger than 1gb (not surre if that working with 2gb) but for surre sd cards biger that 2gb not working!!!!!! Ideal is 512mb or 1gb!

About diag file. I think allso it send AT@SIMLOCK command to phone. For example I done s-on by sending command AT@SIMLOCK=7,1 but I tried to set s-off with the same comand (AT@SIMLOCK=7,0) but its not possible, only possible is s-on!
[HTC Wildfire S] BeciMester:
That's what I proposed a couple of pages back. I believe I found the subroutine that constructs the AT@ command and sends it to the radio, can't remember the exact offset but it's in my last post. There are checks done before it, so I assume this part gets executed only if all checks are passed. I'm at work right now but can post specifics once I get back home to the 'puter.

Edit: quote fail.

(I'm on my One X...)