yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] Tera Tike:
Honestly I really have no idea how to tell.I do know the RUU's would have different img files in the zip file.

Marvel_S_HTC_Europe_2.26.401.3_Radio_47.23e.35.3038H_7.57.39.10M

android-info.txt
boot.img
hboot_1.09.0099_37fbb7a27f8a.nb0
radio.img
ramdisk.img
rcdata.img
recovery.img
splash1.nb0
system.img
tp_MAL_CYP340G15.img
tp_MAL_HM8526A0A.img
userdata.img

Marvel_HTC_Europe_1.33.401.2_Radio_47.10.35.3029H_7.46.35.08_release_185724

android-info.txt
boot.img
hboot_0.90.0000_720d6ffc74.nb0
microp.img
radio.img
ramdisk.img
rcdata.img
recovery.img
splash1.nb0
system.img
userdata.img

Marvel_TMOUS_1.62.531.3_Radio_47.10f.35.3032_7.48.36.17M

android-info.txt
boot.img
hboot_1.03.0001_181386c9.nb0
radio.img
ramdisk.img
rcdata.img
recovery.img
splash1.nb0
system.img
userdata.img

Just some examples.
[HTC Wildfire S] munjeni:
removed
[HTC Wildfire S] Tera Tike:
removed.
[HTC Wildfire S] munjeni:
Sorry my wrong... mine device had installed hacked hboot but title on screen was stock hboot and I thinked I done s-off... no! Sorry!
[HTC Wildfire S] Tera Tike:
What does fastboot getvar all return for you.

I get:

INFOversion: 0.5
INFOversion-bootloader: 0.90.0000
INFOversion-baseband: 7.53.39.11M
INFOversion-cpld: None
INFOversion-microp: 0354
INFOversion-main: 1.33.401.2
INFOserialno: xxxxx
INFOimei: xxxxxxxxxxxxxxxxxxxxxx
INFOproduct: marvel
INFOplatform: HBOOT-7227
INFOmodelid: PG76*****
[b]INFOcidnum: 11111111[/b]
INFObattery-status: good
INFObattery-voltage: 4054mV
INFOpartition-layout: HTC
INFOsecurity: off
INFObuild-mode: SHIP
INFOboot-mode: FASTBOOT
INFOcommitno-bootloader: dirty-720d6ffc
INFOhbootpreupdate: 12
INFOgencheckpt: 0
all: Done!
finished. total time: 0.031s
[HTC Wildfire S] munjeni:
INFOversion: 0.5

INFOversion-bootloader: 1.02.0000

INFOversion-baseband: 7.13.35.13

INFOversion-cpld: None

INFOversion-microp: 031b

INFOversion-main: 2.37.709.4

INFOserialno: xxxxxxxxxxx1

INFOimei: xxxxxxxxxxxxxxxxxx

INFOproduct: liberty

INFOplatform: HBOOT-7227

INFOmodelid: PB92******

INFOcidnum: 11111111

INFObattery-status: good

INFObattery-voltage: 3856mV

INFOpartition-layout: HTC

INFOsecurity: on

INFObuild-mode: SHIP

INFOboot-mode: FASTBOOT

INFOcommitno-bootloader: dirty-45bf9871

INFOhbootpreupdate: 11

INFOgencheckpt: 0

all: Done!
[HTC Wildfire S] Tera Tike:
I see at least you have Super CID. :)
[HTC Wildfire S] munjeni:
Invalid part num!

invalid checksum!

All that is in diag screen when I pres "device info" but when I trying to clear s58 data got device rebooted and nothing happened about s-off, so for now its not possible with diag file (think gold card is not like diag expecting, so maybe its reason why htc clip is connected to sim port?!)

I think htc not maded that htc clip "to be naively" easy dumped diag file and used for every devices without using htc clip... I think diag file is unusable without htc clip !!!
[HTC Wildfire S] munjeni:
Done it many months ago by jtag...

---------- Post added at 08:31 PM ---------- Previous post was at 08:27 PM ----------

I'm not sure... I think htc clip "sim port" emulate security card... so without it I think this is not possible! This is very naive to be true... is not? Every device is unique so I think htc clip "generate" something unique for every device "in prevention" for possible "diag things" .
[HTC Wildfire S] Tera Tike:
Now that makes sense, maybe thats also why HTCDev has tokens.

By the way hav you looked at the HTC Dev unlock for your device.

HTC Aria Unlock Hboot
[HTC Wildfire S] Antagonist42:
Every device is the same except for one component that I can find, that is the NAND chip itself, each chip has it's own unique identifier (check signature docs for Micron NAND tech data page 31) I suspect this is what is needed for Gold/Diag card, something that leads me to believe this is the lack of a Serial # or Ver # for my phones MSM7227 so it would seem they are not 'tied' together as say for eg. Xbox and DVD drive rom
[HTC Wildfire S] pihug12:
I quoted a part of a document posted by Antagonist42, some days ago. I'm not quite sure if that's what you're looking for.

See here : http://xdaforums.com/showpost.php?p=28194702&postcount=2793
[HTC Wildfire S] Antagonist42:
Not sure if you guys will be interested but it's here anyway as it may hold some info in it, I know our EUU/RUU's differ but mine I think is using a virtual drive loaded into EUU then the .img files (contained in .hex files) are loaded then passed onto phone for flashing so I dumped it into IDA and dumped a LST file as I don't know enough to rip it apart (or know where the code may start :eek: ), there is more than one .vdh file although only one seems to be called in config/.ini for the EUU so hoping it may hold something interesting we could utilize :fingers-crossed:

here's the original file if you prefer to check that *.vdh = 564k* *.lst = 5.19Mb can be dumped in a txt editor*.
[HTC Wildfire S] munjeni:
Guys, let me know if you are ready to test revolutionary "method" on your device... if not I will stop work in that thing and will leave this thread! I have done 80% in hboot patch, next 20% I will finish today and will wait for testers! Will not publish it public! Will send only to tester! If here is testers, tester need to send me misc partition dump so I can add shell code to his misc partition and will give him instructions for exploit... Tester need to have installed hboot version 1.03.0001 (hboot_1.03.0001_181386c9.nb0) ! Other hboots is not suported! Warning: exploit is untested on wfs so there maybe will be a brick, I will patch hboot carefully but I not guarante if your device will be sucesfully exploited! Must to say I tested it on htc aria and it working like a charm without needs of using revolutionary tool! So you can do this test on your own risk and I am not rensponsible if something go wrong or if your device go bricked!!!
[HTC Wildfire S] pihug12:
Does your exploit perform HBOOT S-OFF or Radio S-OFF ?

Did you manage to flash unsigned things on the device once S-OFFed ?

Does the exploit give Super CID ?

I don't really see the point to have S-OFF with HBOOT 1.03.0001 if we can't flash unsigned things. We will lost all the features of HBOOT 1.08.0099/1.09.0099 too. :(

Are you sure these two HBOOTs can't be exploited ?
[HTC Wildfire S] csoulr666:
He doesnt own a WFS......which is why he needs testers

I seriously don't know which RUU has HBOOT 1.03.0001 (I've known of 1.03.0000)

Also someone who doesnt have a backup phone(like me) can't test it.......if my phone is bricked,there are no guys who can restore it in my town......Plus my mom would kill me

Perhaps i'll ask someone who has the WFS he doesn't use(I know of one guy)
[HTC Wildfire S] no.human.being:
Chainloading appears to work! Stay tuned!
[HTC Wildfire S] munjeni:
1. everything is like revolutionary hboot

2. Yes I can flash unsigned things!

3. You no need super cid using this patched hboot because you can install everything!

I don't know if any of this hboots is exloitable trought misc partition (you need to try), but I must to say I have ready hboot (patched) just need tester with his misc partition dump! Hboot is patched (have s-off, have hboot version check bypassed, have super cid, have bypassed signature checking, you can flash every wfs hboot, radio...etc, only I not wanted to patch (enable) is "other hboot commans" so only that feature missing, but you can patch that and enable but I think its not important now because we want first to see if this can work or not)

This is temporary now (just to see if this can work), so if this working we can patch another hboot and install trought this hboot :)
[HTC Wildfire S] no.human.being:
GOT IT! PHONE SHOWS S-OFF! Bootloader is unusable though. Shows boot screen (including S-OFF), then checks SD card for PG76IMG.nbh, then boots into ROM. No chance to do anything. But I think that only SMALL modification is required now.
[HTC Wildfire S] munjeni:
Great! How you got it? Trought fastboot boot command?? Maybe I can help? If this can working there will be a lot off s-off devices using your method!If you no want to risk I will test your code on my aria!
[HTC Wildfire S] pihug12:
So, you found a second flag or this one just applied when the Radio is S-OFF ?

Congrats ! :good:
[HTC Wildfire S] no.human.being:
Proof (screenshot) is attached.

Yes I managed to "chainload" a patched ("exploit inject" generated) HBOOT on the device via Fastboot. Have prefixed it with a small (assembly language) exploit code that moves it to over to physical zero and jumps into it, then put it into an Android boot image created with mkbootimg_wfs and booted that via Fastboot. You have to hold Vol-Down when issuing the Fastboot command, since obviously otherwise it won't get into bootloader mode but boot straight into ROM. It shows S-OFF and "*** INJECTED ***" (which is the string that the exploit leaves inside the HBOOT image to prove that it worked - I've "stolen" the idea from Revolutionary that show "*** REVOLUTIONARY ***" or something like that). Cannot test whether it actually "acts S-OFF" (allows stuff like "fastboot flash hboot" etc.) since I have no way to enter Fastboot mode. It will boot straight into the ROM after checking the SD card for the PG76IMG.nbh.

Don't want to publish yet since the image obviously contains an entire HBOOT and while I really want to gain S-OFF on the device, I also respect HTC's copyright on their code. I have to turn this into an exploit that generates the image from an HBOOT dump pulled off the phone itself since then I do not have to ship any HTC code with it, which I'd consider "fair".
[HTC Wildfire S] munjeni:
I doing that things using jtag, so I was set true s-off flag to radio by jtag and confirmed that I had true radio s-off... but hboot was stock hboot (allso tried with htcdev hboot) and still have nothing about s-off - still can not flash unsigned code (for that feature hacked hboot is reguired, or at least we need to find where hboot flag lies)... there is two flags, one is for radio and seccond is for hboot... I found only flag for radio but not found for hboot... understand ?
[HTC Wildfire S] Root-Maniac:
Good job guys!!!
[HTC Wildfire S] mstfkaratas:
Congratulations!!

So you can now flash your patched hboot with PG76IMG to real hboot partition and make it permanent?
[HTC Wildfire S] munjeni:
Just that! Thats one option! There will be a lot of other... he managed to boot it so thats a big progress !:)

---------- Post added at 08:36 PM ---------- Previous post was at 08:30 PM ----------

I want only part of code that not contain hboot image :laugh: just want to se how that working on my device and if working modify it for my new device that is still s-on :(, maybe I can improve something... great great great congrats!!!:victory:
[HTC Wildfire S] no.human.being:
I wouldn't try it unless it runs stable. I don't know why it boots into ROM after checking SD card. Could be because it actually loads the ROM or could be because some check fails and then it loads the "stock HBOOT" from NAND, which in turn loads the ROM. In second case, if it would flash, you'd probably have a bricked device that bootloops (HBOOT fails check and loads HBOOT which fails check and loads HBOOT which fails check and loads ...) until you manage to restore stock bootloader via JTAG. We need to get this stable before you should even THINK about flashing it. Nonetheless, I think that we will get this fixed now that we basically have control over entire boot process of aARM.

Problem is, even if it WOULD work (means if that HBOOT would successfully boot into ROM when flashed and not bootloop), you couldn't even enter recovery with this bootloader since it boots straight into the ROM no questions asked. Not very useful, but it shows that loading modified bootloader code is possible with the new "chainloader" exploit.

Thank you very much. I think that this is the actual breakthrough. Now it needs thorough analysis and probably lots and lots of bugfixing, but it shows that the principle works perfectly. Yes I'm gonna publish the chainloader exploit (in encrypted archive since I don't want to reveal code yet or the vulnerability it exploits might get fixed in next OTA or RUU or whatever before most even had a chance to get their hands on this - not worth it). First want to do a bit more testing/analysis though. I've just seen "S-OFF", grabbed digicam, taken photo, published here. First want to understand a bit more about what's actually happening there. :D
[HTC Wildfire S] theq86:
You should check if chainloading a stock hboot is working correctly and to exclude, that it doesn't misbehave because of the memory shifting or something like that.

maybe then first just hack in the "INJECTED" string and see if it still works.

Wish I could also do experiments on that.
[HTC Wildfire S] munjeni:
You are a definitelly right! But obfuscation have no sense since htc can dump it "unpacked" from memory :)
[HTC Wildfire S] rezo:
Congratulations!

no.human.being, try "erase_image boot". When there is no "boot" partition in the phone, it boots directly to fastboot.
[HTC Wildfire S] munjeni:
This is temporary only hboot (loaded to memory) so on next reboot you have stock hboot as had before :). So when you isue command (fastboot reboot xxxx) you have lose temp hboot!
[HTC Wildfire S] 18th.abn:
Boot partition is later in the line then the hboot, so if its already skipping hboot then doesnt have a boot partition wont that most likely put you into qshusb_dload mode? Just asking
[HTC Wildfire S] beaups:
Great progress guys,

I think the angle here would be to chainload booting to a hacked (either engineering or unsigned) hboot and use the "fastboot oem writesecureflag 0" command from there. Are there hacked hboots available that allow that command to be executed without doing all the diag/javacard routines?

If you simply flash a hacked hboot in this mode I'm pretty certain you'll have a brick on your hands because the hacked hboot will fail sig-checks unless you are soff.
[HTC Wildfire S] Antagonist42:
Great going on the progress :highfive:

There is something I believe in say 'extra space' on the NAND chips that isn't normally available under operating circumstances although could possibly be brought into play 'IF' you know how certain things work although one thing that would throw it out as plausible is the 'working life' duration, if that is a specific amount of read/write combined with operational hours it could have a 'life expectancy' and eventually fail.

The following snippet gives me more of an idea that there may be more 'Blocks' in the NAND than we can access but maybe the NAND can access after a Bad Block failure...

Quote 1.
This NAND Flash device is specified to have a minimum of 4,016 valid blocks (NVB) out of every 4,096 total available blocks. This means the devices may have blocks that are invalid when shipped from the factory. An invalid block is one that contains one or more bad bits. Additional bad blocks may develop with use. However, the total number of available blocks will not fall below NVB during the endurance life of the product.

Quote 2.
2. The 12-bit column address is capable of addressing from 0 to 4,095 bytes on a x8 device; however, only bytes 0 through 2,111 are valid. Bytes 2,112 through 4,095 of each page are “out of bounds,” do not exist in the device, and cannot be addressed.

taken from NAND Flash Memory Quote 1. Pg58. Error Management Quote 2. Pg12 Memory Mapping

If we were able to access the data for Bad Block marking in either a 'Good' Block or 'Bad' Block, copy the data out to a safe location, edit the 'Bad Block' marker thus bringing into play the 'supposed' extra data block, write your information to that block, recover the original 'Bad Block' marker and write back to the original block re-establishing the original block. This does throw up a couple of things for explanation, does the NAND throw out the 'extra block' that was brought in? Would this also throw out memory addressing? If the 'extra block' stays then which block is lost as you can only have 0 - 4095 (4096 total available blocks).

As the chip is Guaranteed to be valid on the first block for 1000 Program/Erase cycles I would suspect that they don't foresee people 'Flashing' their devices that often and with updates and security even less although it must be done 'behind the scenes' to maintain their 'wear-leveling' to keep the chips read/write capability to wear evenly as everybody installs apps etc it has to be stored so written to NAND it has to basically re-write the page/block.

Seeing it now in black and white like this it is looking 'less' likely there are 'extra blocks' although I wouldn't rule it out :laugh:

Now there's a thought :confused: differing memory maps for NAND on WFS ..... could that be to do with ECC? My thinking is if you have a large partition and needs X amount of space and X amount of recoverable Bad Block space, if there were Bad Blocks already from factory production, would or does software/installation check for Bad Block markers and relocate the partitions to suit?
[HTC Wildfire S] csoulr666:
Great job NHB!!!!! If your phone boots to the rom,you can try "adb reboot bootloader"(I reckon you now this :) ).....it boots into fastboot
[HTC Wildfire S] munjeni:
N.B.H. please help me... I not understand how you booting it, but I truing to reboot device to botloader mode by fastboot boot test.img where test image contain:

test.S

.org 0x00008000	@add 0x8000 zero butes
mov	r0,#8	@bootmode bootloader
mov	lr,pc
ldr	pc,set_boot_mode
ldr	pc,reboot

set_boot_mode:
.word 0x9d00dce8

reboot:
.word 0x9d00e130

arm-eabi-as test.S -o test.o

arm-eabi-objcopy test.o -O binary test

initrd is emty file "empy" (still contain 1 bute 0x00)

mkbootimg --kernel test --initrd empty --cmdline 'no_console_suspend=1 console=null' --board golfu --base 0x13000000 -o test.img

Nothing happened but offset to function reboot is right! When I try "mov pc, #0" got like you got (screen off, on, off, reboot to android)

Edit:

uhhh I know why I'm unable to call an hboot function (hboot is "leave"? free(hboot)??? Phone is allready in boot mode after fastboot boot?)
[HTC Wildfire S] no.human.being:
The MMU is disabled when issuing "fastboot boot ..." since the function is designed to load an operating system kernel, which expects a flat address space and will set up the MMU for its own purposes. Therefore your code works with physical addresses. HBOOT is loaded to 0x9d000000 virtual, 0x00000000 physical. So when you want to run HBOOT's "set_boot_mode" function, you probably have to set program counter to 0x0000dce8 and when calling "reboot" you probably have to set program counter to 0x0000e130. I doubt that these functions work with MMU disabled though, since they are probably designed to operate in the 0x9d... virtual address range and will probably have lots of references to addresses there, that won't resolve when MMU is disabled. So either you manage to "appropriately" set up the MMU from your code before jumping into HBOOT code or you reverse-engineer the functions so that they work with physical addresses.

EDIT: Btw this is incorrect.

.org 0x00008000	@add 0x8000 zero butes

Execution will start at 0x0 into the kernel. Definitely! First four bytes of kernel are first opcode executed and they get loaded to the physical address specified in the "kernel_addr" field of the Android boot image (which is usually not equivalent to the "--base" address you specify so you really have to look into the file to see where you're actually gonna be loaded to!) and execution will start exactly there. So no need to "prefix" the kernel with anything. Start straight off with executable code.
[HTC Wildfire S] munjeni:
Still not working, I tried that now :( Please give me your asm code for chainload... for example, encript it in winrar and send me rar in hex form + password by pm, than delete your pm, I will delete mine pm allso, please! I will not share it!!! Want only for my tests in my new phone! If I found something better I will let you know...
[HTC Wildfire S] no.human.being:
Source code is attached. Key comes via PM. It's a 7zip archive. RAR is uncommon in the Unix world and Zip encryption is broken.

7zip uses AES128 encryption and has open source, LGPL-licensed extractor tool for Windows and Unix. :D

Hope you can find where HBOOT "fails and falls back" when stepping through the code via OpenOCD (you have a working JTAG interface, right?).

EDIT: Of course when you load an HBOOT as "payload" you'll have to hold Vol-Down when issuing the "fastboot boot ..." command or else that "chainloaded" HBOOT will boot straight into ROM.
[HTC Wildfire S] munjeni:
Yes but I have no working "debuging"... BIG thanks!!!
[HTC Wildfire S] no.human.being:
Why not? Is your interface not supported by OpenOCD? If you need processor configuration for MSM7227, I've gathered it from various sources. Couldn't test it yet though, since my interface can't cope with the low I/O voltage of the MSM7227.

EDIT: Eerm well, this should be processor configuration for use with ARM1136EJS (which the MSM7227 is - MSM7227 is the Qualcomm part number - the processor design is from ARM Ltd. which is a "fabless" semiconductor company - they only design processors and let others manufacture them - MSM7227 is the type number for the specific part manufactured - ARM1136EJS is the type number for the processor design). It's for use with a JTAG interface from Olimex that's based on an FTDI FT2232 UART chip (which is what I use). To run it with your interface, you'll probably have to read lots of OpenOCD documentation and find whether it can operate with it and if it can how you must configure it, but if it's a "popular" interface it should be supported.

interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG ARM-USB-TINY-H"
ft2232_layout olimex-jtag
ft2232_vid_pid 0x15ba 0x002a

jtag_khz 100
reset_config trst_and_srst srst_pulls_trst

set _CHIPNAME ARM1136EJS
set _ENDIAN little
set _CPUTAPID 0x203c00e1

set CPU_TYPE arm
set CPU_NAME arm11
set CPU_ARCH armv6
set CPU_MAX_ADDRESS 0xFFFFFFFF
set CPU_NBITS 32

jtag newtap $_CHIPNAME cpu -irlen 5 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
target create marvel $CPU_NAME -endian $_ENDIAN -chain-position $_CHIPNAME.cpu

You can download OpenOCD here. They do not release binaries, only source so you have to build this yourself or find a binary release from a third party that you trust. Its mode of operation is a bit weird. You run OpenOCD and it acts as a server and once it's up and running, you use a Telnet client to connect to the OpenOCD server and you issue debug commands from the Telnet client. You can use gdb to "remote control" OpenOCD, but OpenOCD-only should be more than powerful enough for what we plan to do. I generally love GNU tools (especially gcc toolchain) but gdb is horrible so I avoid it like hell.
[HTC Wildfire S] munjeni:
Hey, got your chainloader working, still I have no reboots, its in fastboot mode!!! Need to test if this load hboot from " chain" or its rebooted to hboot :)

About jtag debuging, I tried many times to debug but when phone boot jtag connection was broked! I'm sure that fail because I don't know where is real vref ! On htc hd2 all worked like a charm but not in htc aria because on hd2 I had vref! My vref is "trick" its battery pin v+ so when I need to halt my device I am unable to do it vithout real vref (still "tricky" v+ have all times voltage) :(

Edit:

chainloader not working with modified hboot on emmc bassed devices (I think crc chech from radio)! Disapointed now :(

Edit: not working in booth ways, I changed version string but version is not changed so mean modified hboot is not loaded :( ...will try with aria in next few days