yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] Antagonist42:
Now that was interesting...and unexpected :confused:

I've been playing around with earlier ROM's for my phone (since I found what I think is the first release although for FR not UK) and decided to see what happens if you yank the battery during an OTA update.... :victory: "nutter!"

Basically - FOTA is downloaded to your SDCard by AMSS (or RADIO) as I used X-plore app and spotted it whilst downloading so as the BAR Notification made it's way to 100% stripped case open and at 100% yanked the Battery, SDCard into PC and update file was there.... Brilliant - you'd think :rolleyes: as it's a .zip file it downloaded dropped it into WinRar and 7-Zip ...both reported it was corrupt so back to downloading it again and that was the first notice that the filename of the FOTA is held after a power down as once the Android System brought in the SDCard the file was deleted.

Again watched for the download reaching 100% ...this time waited a couple of seconds before pulling the Battery, same again onto the PC but this time the filename was what looked more like a HEX string still .zip - into WinRar/7-Zip .... still corrupt :confused: this is something I am guessing at but could the downloaded file actually be compressed by the 'inflate' program that's already in and used by the system? - Anyway did it again this time waited until I got Toast Box 'install now | later' so yanked - PC - Zip progs - still corrupt but a complete file so left it this time to the Toast Box, clicked install ..... 'Unzipping' :fingers-crossed: ...once it Unzipped, yank, PC - folder 'acer_ug' and all the .mbn and .img files (which is what i've not had a hold of yet for this phone :p ) ....amongst them is a .zip - AMSS.zip :rolleyes: funnily enough not what you would expect but also not what was inside.... the exact same set of .mbn/.img files (less the .zip/.txt) :eek:

makes me wonder just exactly how much space AMSS truely needs and if that zip is copied/unpacked to the AMSS/RADIO partition and that is what is checked against?

The other oddity was an 'update.zip' - completely devoid of files or data ...here's what I typed up whilst yanking my Battery :cyclops:
[HTC Wildfire S] BeciMester:
If you want an OTA file for the WFS, I have one. I was doing a backup of the sdcard just in case, and it was just sitting there. :) (Well, I've declined the update a few times already.) Named OTA_Marvel_S_HTC_Europe_2.13.401.2-1.33.401.2_R3_release_2258011tahu4csyppc4kbw.zip, it's 41.3 MB, I'll stick it up in Dropbox if you're interested in poking around in it.
[HTC Wildfire S] Antagonist42:
PM me or public link whichever you prefer ;)

Oooooh please :D it would help then I can see just how much difference there is between WFS and E320 as I want to find out if it's possible now to use my OTA files from an older revision and flash them to my phone even to simply gain root access (only two older versions you can gain root access that I have found), if there's a large enough similarity between them I may try using WFS files on my phone just to see if they are runable or not.... anything to see how it does actually operate :cowboy:

One thing I have come across on security and authentication it seems they only use either of each (CRC - Atestation - Security Key {eg T-Mobile/Orange own key} ..damn memory :rolleyes: ) they don't seem to require to use 'BOTH' but maybe only use one depending on say type of operation that is to be done - Writing to NAND may require say Atestation (this code is blatantly displayed in E320 fastboot) - using fastboot/adb to access files =CRC... just a thought.
[HTC Wildfire S] BeciMester:
Well I reckon that, being an OTA, it was intended for public distribution so here it is. :D
[HTC Wildfire S] BeciMester:
The signature is not part of the image, it will be discarded after checking, so the value 0x200 at offset 0x10c probably signals where the hboot image starts within the whole thing.

3. They probably do it this way because it's simpler. The eng hboot already has all the stuff they want to execute, so why write extra code? They save time and money IMO. It doesn't display the menu because they use only a few functions of the hboot. Isn't 0xb066c in the header the entry point of the freshly loaded eng hboot, once it's copied into the right place in memory? Must investigate tonight. :D

4. See above: same hboot, different entry point?

(I'm on my One X...)
[HTC Wildfire S] rezo:
BTW...

As far I was interested in, there are three PG76DIAG.nbh files that pass the signature check on Wildfire S.

140018c1f2a8a99c3f6d5b704ada1252 *PG76DIAG.nbh (723308 bytes)

Based on 0.81.2000 ENG HBOOT. MAL Service HDIAG 1.00.

fb8ee3557dbb92513580ddcfe86b39ae *PG76DIAG.nbh (658416 bytes)

Based on 0.81.2000 ENG HBOOT. MAL Service HDIAG 5.04A.

6397276e980125f2008bb6bcb04b0207 *PG76DIAG.nbh (755092 bytes)

Based on 0.78.2000 ENG HBOOT. Not working with... GSM phones? I don't really know. It freezes at "jumping to diag"...

You can use RevSkills to extract mfg.nb from those files.
[HTC Wildfire S] no.human.being:
So what if we extract 0x300 to end of file from the "PG76DIAG.nbh", then use this as payload for the chainloader starting execution from 0x00000000 (which would be 0x300 in the NBH)? It should run the ENG HBOOT right? It could still "fall back" though, as only the actual DIAG code (different entry point in image?) may be designed to be loaded by HBOOT, not the ENG HBOOT itself (entry point "zero").
[HTC Wildfire S] theq86:
we should try to execute the embedded hboot. but chances are that it behaves like a normal hboot and falls back.

what came to my mind is:hboot is huge and analysing a pain in the *** but can we reverse what only the diag part calls? at some point it calls the hboots "do s-off" function and we just need a pointer to this and can call it directly.
[HTC Wildfire S] Antagonist42:
Something that may apply to WFS as this is what I unfortunately have done with my E320 :crying:

I have found that an OTA update does not use the same verification as an EUU.

Basically (due to spending too long editing and changing files and not double checking!!) flashed a lower machine system.img to mine (the edited one that 'SHOULD' have flshed in another folder :mad: ) which gives me aSYSTEM download fail!! so tried to rectify it with the SD OTA .... verifies 100% then on reboot...

aSYSTEM download fail!!

Running the EUU (whether the same with wrong system.img or other combinations gives varying results but fail reboot) will flash 100% (some only as far as system) so there must be two differing checks for which you are doing, if not then I can't see how the OTA doesn't pick up the error with the NAND files but passes 100% - then on reboot different check and aSYSTEM fails the check.

I could be wrong with that thought but it does seem to be what is happening.
[HTC Wildfire S] no.human.being:
Well "huge". It's 512 KiB of machine code. That's literally "nothing" in C code. The "inject" utility is less than 600 lines in C code and that gets compiled to around 700 KiB. Based on that, you can expect HBOOT to be somewhere around 400 lines in C, which is nothing. And remember that it includes an implementation of RSA, which is a "standard cryptographic algorithm", that you wouldn't have to analyze because it's known how it works and that probably makes up a good amount of the code, since it requires "large number arithmetic" and you have to implement that as well.

So HBOOT is just that large on the machine level. If we had the code available in the high level language, analysis would be trivial. There's really not much about it. Apart from the RSA stuff, which is standard code, all it does is parse some headers and move some data around in memory.

S-OFF via DIAG is "true" (Radio) S-OFF, not just HBOOT S-OFF. DIAG calls the Radio and asks it to disable security, then the Radio does all the interesting stuff (check for the engineering SIM and turn the actual secu_flag off). I believe you can even see it piecing together that "AT@SIMLOCK=7,0" command that makes the Radio disable security. Doing this call is useless since we have to authenticate with the Radio via this "engineering SIM" and unless there is a way to "emulate" that the call alone won't do anything. You don't even have to run HBOOT to do this call. You just do a "fastboot oem rtask c" and then you can directly talk to the Radio and send the command. However, without the engineering SIM, it won't do anything. It won't do anything when DIAG calls it either. The Radio is the component that you need to authenticate with, not DIAG.

What one could attempt is finding the function that flashes partitions and then look what HBOOT does to get the Radio to configure the MMU in such a way that aARM (HBOOT) can flash the Radio or the bootloader and try to reconstruct that. However, we don't know how "strong" the authentication is that is required to make the Radio "open up" the MMU. Preventing the fallback is probably the easiest way since most likely one only has to modify a single subroutine to accomplish that goal (I don't expect this "feature" to be very "involved" with the rest of the firmware, while I'm not so sure about the others) and the rest is basically already "in place".
[HTC Wildfire S] BeciMester:
Turns out I was way off: it's the length of the eng hboot that's 0xb066c bytes.

Also: the diag file contains no extra code to tell the eng hboot what to do, I can't even see anything that could be interpreted as an entry point, so it must be done from within the stock hboot. Investigating... ;)

The page tables in the eng hboot are identical to the ones in the stock. Oh, and the eng hboot runs from 0x40000000 virtual. That's 0x12c00000 physical. Where is the Android kernel loaded to...?
[HTC Wildfire S] no.human.being:
The kernel itself is loaded to 0x12c08000 physical, but it actually uses memory beginning at 0x12c00000 (quite a coincidence). "Exception vectors" (interrupt handlers?) and kernel parameters are stored in the 0x8000 bytes "before" the actual kernel.

/* default load addresses */
hdr.kernel_addr = 0x12C08000;
hdr.ramdisk_addr = 0x13C00000;
hdr.second_addr = 0x13B00000;
hdr.tags_addr = 0x12C00100;

Looks like the ENG HBOOT is DESIGNED for being loaded by another bootloader, huh? :D

0x12c00000 is bad though. Remember "we" (chainloader) are loaded to 0x12c08000. We want to move our "payload" to 0x12c00000. We will overwrite ourselves before we finish moving our payload around. We will need two "chainloader levels" for this.

"Outer" chainloader has "inner" chainloader as payload and moves its payload ("inner" chainloader) to some "uncritical" address (say 0x13c00000 physical), then jumps to it. "Inner" chainloader then moves its payload (ENG HBOOT) to its destination address (0x12c00000 physical), then jumps to it. ENG HBOOT runs. So yes, it's still possible. You need to run the exploit code two times in a row and be careful that you're not overwriting something critical with that much "shuffling code around in memory" though.

EDIT: This is how far I got in tracing to the entry point for DIAG.

You'll find the string "Jumping to DIAG" in the PG76DIAG.nbh at offset 0x97d94.

Subtracting 0x300 for the header and adding 0x12c00000 (physical loading address) yields 0x12c97a94 physical.

Translating that to virtual: 0x40097a94

You'll find this address at offset 0xb588 inside the NBH (0xb288 without the header, 0x12c0b288 physical when loaded) as well as at offset 0x1e0b4 (0x1ddb4 without the header, 0x12c1ddb4 when loaded).

The instructions that reference these offsets are:

b0c8:	e59f04b8	ldr	r0, [pc, #1208]	; 0xb588

1dbf4:	e59f04b8	ldr	r0, [pc, #1208]	; 0x1e0b4

Things get extremely messy after that. Lots and lots of branches - some conditional - who knows which will be taken?
[HTC Wildfire S] Antagonist42:
More numbers to keep an eye out for then ;) Thanks n.h.b. as I is all out of 'thanks' lol

Do we know which part of the whole system uses reverse endian? (only way I can put it really) as I have come across 'retuoR' in the HBOOT images and now (whilst trying to recover my ACER) 'PEAH' in the appsbl at the end of data and next in incremental line is code, so to me that suggests ~maybe~ some address's could be read in reverse depending what is reading it (as I don't know it may be something to bear in mind) or even that whole data block prior to 'PAEH'....may have a go at extracting it and reversing it just to see what it is :confused:

........................................................ I won't accept owning a £140 Brick!! ........................................................
[HTC Wildfire S] no.human.being:
Lol! I would never have realized that "retuor" is "router" backwards. :D

I always thought of the French "retour" (English "return") and that some Iguana dev ("retuor" is a command that the Iguana shell accepts if I remember correctly) was typing too fast and thus accidentally got the letters "o" and "u" swapped. :D

Never thought of the word "router" backwards. :D

ARM is a processor supporting both endiannesses (is that a proper English word? :D ), but little-endian is native. You can work with big-endian on an ARM, but there are certain quirks so you almost never do it. However, if you turn stuff around for endian reasons, you always turn the bytes in the words around so that for example "12345678" (as a character string with single-byte characters) becomes "43218765" when read with the wrong endianness. It will not turn around, say, an entire page, but only on a word by word level. When swapping endianness, words remain in the same order, just the bytes within the words are reversed.

If I remember correctly, this "retuor" command on the Iguana shell acts a bit like the "exit" command on a Unix shell in that if you got the shell into some kind of "special mode", it will either get you out of that mode or terminate your shell session, which is why I always thought of this "retour"/"return" stuff. Never realized that it's "router" backwards. However, the interpretation as "router" doesn't appear to make much sense, does it? But on the other hand, having two letters swapped and being a proper English word when read backwards is a bit too much for being a coincidence, right?
[HTC Wildfire S] Antagonist42:
That and now finding HEAP in reverse in appsbl is waaaaaay to much of a coincedence...... I have read a document which was on about endian byte swapping and which is swapped where and almost sure there is one that reads in reverse.... going checking...
[HTC Wildfire S] no.human.being:
Somewhere in this thread, someone got the beginning of the APSBL (HBOOT) dumped from RAM via the Iguana shell. Remember that it contains the word "SHIP". However, Iguana read "PIHS". Perhaps the L4/Pistachio kernel is big-endian. (It was only word-wise inversion though, so the 4 bytes within every 32-bit word were reversed, but the 32-bit words were in correct order, which is exactly what you would expect by inverting endianness.) Would that change anything for us though? I know from some datasheet that the endianness mode only affects data. Instructions are always fetched as little-endian.

However, remember that "retuor" is actually a shell command, much like, say, "AT$QCPWRDN" or "AT@SIMLOCK?AA" is. Why would a SHELL COMMAND get reversed due to "endianness issues"? I mean it's scanned from the "console device" by Iguana and then interpreted by a command interpreter within Iguana. And the interpreter that interprets "AT$QCPWRDN" ("correct endianness" as it reads "ATTENTION! QUALCOMM POWER DOWN!") is probably the same as the one that interprets "retuor". How could it have "correct endianness" in the one case, but "incorrect endianness" in the other?

Also, "retuor" is 6 bytes long so it consists of at least two words. Considering it is a command and it starts at a word-boundary (address multiple of 4) the first word would be "retu" and the second would be "or\0\0" (considering the string is zero-padded to the next word-boundary). Read with "inverted endianness" would yield "uter\0\0ro" (remember the bytes in the words get reversed but the word order remains), not "router\0\0". If it's padded in the "beginning" (so "\0\0retuor") would yield "er\0\0rout". To yield "router\0\0" it would have to appear in memory as "tuor\0\0re" (which it does not).

Having inverted endianness and reading words by decreasing addresses (which would cause the entire memory to appear "inverted" and thus even longer strings would appear "in reverse") seems extremely "exotic".

And it still doesn't explain why the command is called "router" (like I said it "returns" from special modes of the shell, much like "exit" does in a Unix system, who would call such a command "router"?) and why they "read commands with endianness". I mean the shell is a "serial device". It transmits data byte by byte. Each byte yields a character. The characters form a string and when a newline character comes, this string is interpreted by the command line interpreter. You usually don't have to deal with endianness at all when implementing a shell.

It doesn't appear to make a lot of sense yet.
[HTC Wildfire S] Antagonist42:
Been having a flick through a bunch of Docs and Lecture pdf's and the only other thing I have come across is maybe the output from an LSL Instruction, so what we may be seeing in this spare 'mess of data' between actual code is (I can only guess) maybe what registers have written out while processing so the intermediate code (may still be being processed whilst files are written out and that is what we are seeing?) is still visible?

Like I say I can only guess - it's the only thing I've seen that could possibly make sense if as n.h.b. says reversing endianess there would be padding when reversed.
[HTC Wildfire S] EdikNeznanov:
How xtc clip connects to the phone?
[HTC Wildfire S] no.human.being:
Via SIM card slot. :rolleyes:
[HTC Wildfire S] heavy_metal_man:
lol 2000+ posts to come to this conclusion :P
[HTC Wildfire S] rezo:
BTW...

Someone asked about OTA updates. Here are all OTA's that I know:

OTA_Marvel_HTC_Europe_1.33.401.3-1.33.401.2_R3_release_237839jgesb0shqqyomvcx

http://fotadl.htc.com/OTA_Marvel_HT...3.401.2_R3_release_237839jgesb0shqqyomvcx.zip

OTA_Marvel_S_HTC_Europe_2.13.401.2-1.33.401.2_R3_release_225798zs6j8xkg74sghm2d

OTA_Marvel_S_HTC_Europe_2.13.401.3-1.33.401.3_release_237845pg2016qpaadczbkc

http://fotadl.htc.com/OTA_Marvel_S_...1.33.401.3_release_237845pg2016qpaadczbkc.zip

OTA_Marvel_S_HTC_Europe_2.13.401.3-2.13.401.2_release_237041qqcw21hxt5vkhdz6

http://fotadl.htc.com/OTA_Marvel_S_...2.13.401.2_release_237041qqcw21hxt5vkhdz6.zip

OTA_Marvel_S_HTC_Europe_2.14.401.1-2.13.401.3_release_246828bqvnfs0scxz4qj5d

http://fotadl.htc.com/OTA_Marvel_S_...2.13.401.3_release_246828bqvnfs0scxz4qj5d.zip

OTA_Marvel_S_HTC_Europe_2.24.401.3-2.13.401.3_release_255607irci2bc3pjwg6siv

http://fotadl.htc.com/OTA_Marvel_S_...2.13.401.3_release_255607irci2bc3pjwg6siv.zip

OTA_Marvel_S_HTC_Europe_2.26.401.3-2.13.401.3_release_2617117t5xizmcxam8j8v6

http://fotadl.htc.com/OTA_Marvel_S_...2.13.401.3_release_2617117t5xizmcxam8j8v6.zip

OTA_Marvel_S_HTC_Europe_2.26.401.3-2.14.401.1_release_261810uuzn2yxubjlshdle

http://fotadl.htc.com/OTA_Marvel_S_...2.14.401.1_release_261810uuzn2yxubjlshdle.zip

That update (to Android 2.3.5):

OTA_Marvel_S_HTC_Europe_2.13.401.2-1.33.401.2_R3_release_225798zs6j8xkg74sghm2d

was faulty and HTC removed it from their servers. A lot of people had wifi/usb/etc bricked phones after that update.

Now phones download

OTA_Marvel_HTC_Europe_1.33.401.3-1.33.401.2_R3_release_237839jgesb0shqqyomvcx

and next

OTA_Marvel_S_HTC_Europe_2.13.401.3-1.33.401.3_release_237845pg2016qpaadczbkc

And... one thing...

OTA updates have version numbers 11.*.*.* because at the begining a lot of phones were sold with the software version 9.0.0.0...

Probably HTC wanted to connect the software version with the bootloader but they made "a mistake" and instead of 0.9.0.0 they put 9.0.0.0 :)

And the result of that is the fact that RUU's have versions 2.*.*.* and OTA's 11.*.*.* to avoid "main version check failed" :)
[HTC Wildfire S] no.human.being:
Btw while you've pulled apart a FOTA image for your phone, I've pulled apart an RUU for mine. An RUU "firmware.zip" image for the WFS contains the following.

"android-info.txt": Version information.

"boot.img": Image of the "boot" partition (Android boot image header + kernel + initrd).

"hboot_<version>_<commit>.nb0": HBOOT image ("<version>" is to be replaced by version number, "<commit>" is to be replaced by commit identifier).

"radio.img": Radio image. Should be a "raw" (no file system) Iguana build. This is for some reason NOT what you see when you read the "Radio area" via software.

"ramdisk.img": This is the same ramdisk as in the "boot.img". Why have this in here again?!

"rcdata.img": This seems to be a small configuration file for the Radio. You will find some (but not all) of the stuff that's in here scattered in various places of "radio.img" as well, e. g. 0x00 to 0x13 in 0x1e7030 to 0x1e7043, 0x27 to 0x34 in 0xdc896c to 0xdc897f. Why have this in here again? Where does this get written?

"recovery.img": Image of the "recovery" partition (Android boot image header + kernel + initrd).

"splash1.nb0": The boot splash?

"system.img": Image of the "system" partition. Should contain a YAFFS file system.

"tp_MAL_CYP340G15.img": Touch panel calibration data. Where does this get written?

"tp_MAL_HM8526A0A.img": Touch panel calibration data. Where does this get written?

"userdata.img": This file is very small and probably contains an empty file system for the "userdata" partition so that it appears "formatted" when the image gets written. Very quick and dirty but it probably does the trick. :D

What's the difference between ".img" and ".nb0" files? Both seem to be "raw partition images". The image as a whole is signed (first 256 bytes of file). The inividual files are not signed, so you cannot take them out of the image and flash some of them while not flashing others.
[HTC Wildfire S] heavy_metal_man:
just out of interest, if we have a revolutionary style s-off that is hboot and not radio would we be able to use a kernel that maps the full nand booted into android, and then use this "forged s-off" we have to give us full root to atain radio s-off by writing to the radio?