yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
C'mon people, it's getting old, we already know!

This only works on devices with VERY OLD production date (it only works on HBOOT-0.90.0000 - that's "pre-1.0-firmware", so basically it's "alpha" :D ) that NEVER performed an OTA firmware update or installed newer firmware via RUU, which obviously aren't that many (probably in the single digits percentage of the devices on the market and NONE of the WFS that HTC ships these days) so it's nice in theory but it's practically irrelevant unless you find a way to "downgrade" to "pre-1.0-firmware", which up to now hasn't been found. Also as soon as you update firmware you're gonna lose S-OFF with no known way of going back.

While there are indications that downgrading MIGHT be possible, the indications that OUR exploit is possible are FAR stronger and thus I'd like to have it pursued and not so much distraction brought into this. Basically we've actually "seen" our exploit S-OFF the phone as is proven here, it's just that HBOOT has code to "heal itself" after being exploited. If we know where that happens, we'll be able to suppress it and then we're done.
[HTC Wildfire S] davidang:
cool,i have learnt something new
[HTC Wildfire S] BeciMester:
F**k I shouldn't have resurrected that thread... :(

(I'm on my One X...)
[HTC Wildfire S] schlund:
If you dump nand with "dd" you will also dump OOB (Out Of Band) which is 0x40 extra storage that is associated with each NAND page (dont know about marvel but think each page is 0x800, too), normally its in front of every page in your dump.

you can easily add and cut that by using revskills tool free version.
[HTC Wildfire S] no.human.being:
I always do it with "cat". You cannot use "dd" on the mtds since mtds are character devices and for some reason Android's "dd" is broken and only operates on block devices. (Linux "dd" operates on character devices as well.)

~ # cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00040000 "misc"
mtd1: 00500000 00040000 "recovery"
mtd2: 00340000 00040000 "boot"
mtd3: 10400000 00040000 "system"
mtd4: 02300000 00040000 "cache"
mtd5: 09600000 00040000 "userdata"
mtd6: 00a00000 00040000 "devlog"
mtd7: 02fc0000 00040000 "radio"
~ # dd if=/dev/mtd/mtd7 of=/sdcard/radio.img
dd: /dev/mtd/mtd7: Invalid argument
~ # cat /dev/mtd/mtd7 > /sdcard/radio.img
~ #

When I do a "cat" of, say "/dev/mtd/mtd1", I get a "clean" recovery image that's bit-identical to the recovery image I supplied to "fastboot flash recovery ..." when installing the recovery, so I assume that the dump contains no OOB data. The OOB is for error correction and stuff and the operating system, precisely the mtd driver, is supposed to strip it off, so you should get a "clean" dump with no OOB.
[HTC Wildfire S] munjeni:
Device is secured/configured to "hide" these offsets, its there but you will see it as a oxff bute :) but you can see right data only by jtag! I confirm that because I tested/compared that! Allso Schlund can let you know about the same story about diference jtag_dump/software_dump in photon device? Dump by jtag (real dump) and dump by software (fake dump -> you can dump the same data but some data is "hidden" and you can see these hiden/unacesible data as a 0xff)

I not agre and its not true! Command "cat" not working good in combination with writing to nand (it working but always corupt data) because you can not set block size for cat! But dd with option bs=131072 working perfect!!! I always use dd and dd always working with CHAR device (mtd)! I can confirm and this story is allready explained by me in my old posts here! To get dd working with char device you must to set block size (bs) to 131072! If you not set bs=131072 than dd not working :)

After some my tests dd/cat dd always write right data to nand (after dumping these writen data and compare them its allways right), but after using cat and comparing these data with jtag dump these data is always corupted! So its reason why your dump few posts back have some data diferent than... try to dump by dd :) and you will see diference!

dd if=/dev/mtd/mtd0 of=/mnt/sdcard/mtd0 bs=131072

Maybe dd not working because you have stock rom and not cm rom?

Nand. Nand erasing procedure: is erasing whole block (block size is (dec)131072 or (hex)0x20000 so you are unable to erase it partitialy, you must to erase whole block!!! Its the same thing in writing!!! So if you set option "block size" for dd command it will work! If not it will not work!
[HTC Wildfire S] no.human.being:
No you do not understand what I mean. It's not that some pages are simply "missing" (and filled with 0xff in dump). What the operating system reads and what's in the image (and probably also in NAND) are two ENTIRELY DIFFERENT SETS OF DATA. The size is different, the content is different and the "differences" aren't simply "some pages are missing when viewed from the OS", they're much more "involved". Some content that the OS "reads" is NOWHERE in the image (and therefore probably nowhere in NAND). Content that matches is in other places. What the operating system sees is COMPLETELY DIFFERENT than what is in the image (and probably the NAND). That's why I always said that the OSes are running inside a "virtual machine" and that aARM and mARM are probably not actually "two physical processors on a common die" but more likely "virtual machines running on a single processor". I think that there's a single ARM11 (or whatever) and then there's a "hypervisor" on top of that that "emulates" ARM9 for REX and ARM11 for Android. It makes so much sense, just think about it. REX most likely doesn't put a lot of load on the hardware (compared to Android) so why have DEDICATED HARDWARE just for it when you can offer it 10 % of the processor's power (and the remaining 90 % to Android) and it will suffice?

Even the data that is "accessible" to both is different. When I take a page that contains "valid content" (so not 0xff) in both "OS dump" and "firmware image" (and "firmware image" is probably identical to "actual NAND content" that you'd see via JTAG) there may be content in both, but THEY DONT MATCH. The contents are entirely different. Wherever the data that you read when accessing the "Radio area" stems from, it doesn't come from NAND. It's probably "generated on the fly" by some software. Radio partition that you see from the OS is more than DOUBLE the size of Radio image (and therefore probably Radio area in NAND). If you get different contents when reading via JTAG and reading via software, then one of them cannot be stored, as you only have one "address space" of NAND available. E. g. you have 512 MiB of NAND on the WFS but if you read the Radio area from within the OS you get different 40 MiB of data than you get via JTAG - but where should that "second state" be stored? You understand the problem?
[HTC Wildfire S] munjeni:
Try with dd! "Cat" is not good! I understand what you mean but you must to know firmware image is an pack! For example radio.img. Radio.img is not only radio, radio.img contain few things inside (spl,pbl,amss...etc) so I allso think these radio image is not stored on nand with the same offsets that is in radio.img, I think these things from radio.img is unpacked to diferent locations around on the fly! It something like hboot in radio installation move/generate these radio.img parts data around nand flash to his right location...! So for example when device is bricked you can not "copy paste" radio.img to nand to get that working, you must to have jtag dump because *.img and dump is a big diferent
[HTC Wildfire S] BeciMester:
I plan to use the "saveprt2sd" and "savemem2sd" features built into the hboot, once I'm finished patching it and it's determined that it's safe to flash a patched unsigned hboot. :D It'll be interesting to see what those will come up with.

(I'm on my One X...)
[HTC Wildfire S] munjeni:
Its good but what is your plan, how you think to write it to nand?
[HTC Wildfire S] no.human.being:
The easiest way is probably getting our "patched HBOOT" not to fall back.

More complicated: Figure out how HBOOT "authenticates" with Radio to get NAND unlocked, then let our exploit code "authenticate". Figure out how to write to NAND using assembly and do it. :D
[HTC Wildfire S] munjeni:
I think hboot+extra data is now potentialy candidate :) Why I think? I think these extra data is generated from for example amss or from pbl...etc and these data need to be after hboot offset and these extra data is for sure hboot part because links from there going to hboot functions! Why exploit not working? I think not working because exploit+hboot writen to ram not contain these extra data because these data is not generated by just for example pbl...etc... because ram expected kernel+ramimage these extra data is unmaped but hboot writen to ram by exploit not contain these extra data and there I think we have fault and freze... understand me what I mean?
[HTC Wildfire S] no.human.being:
But how to fetch extra data without JTAG? I mean you have provided some, but it's from a different phone, right?
[HTC Wildfire S] munjeni:
I will play with this, if I get exploit working I will try to analyse these extra data and port for your hboot. Allso you can analyse now these data if you add these data to htc aria hboot 1.02.0000 and disasemble booth... you will see what functions use these extra data offsets than you can patch/adapt to your hboot version

I forgot to say... I am able to write to ram by jtag + to execute, its solution "one click", but never played with that... will try first time when i connect device to jtag. If you have an ideas you can create an exploit that will be for writing to nand and I will test it on my device!
[HTC Wildfire S] munjeni:
Tried exploit with hboot+extra and bad news can not boot, it rebooted momentaly :(
[HTC Wildfire S] no.human.being:
Just HBOOT without extra data booted but fell back?

Remember that you must adjust the "payload size" in the exploit when you attach more data to it.
[HTC Wildfire S] munjeni:
Yes I added more data to payload but have no sense it still rebooting momentaly. Without "extra" it boots but freze if no sd card or reboot after checking for zip (same thing like in your tests)... do you have idea how we can debug where it fail? Maybe we can add for example "mov r0, 0" to function before sd card init/than after sd card init to see if we fail there (just for debug)? I tested some things now and found something... when LIBEIMG.zip is on sd card device rebooting momentaly, but if no zip inside sd card I can see on screen "looking for zip" than device reboot, so maybe hboot realy fail on sd init? In booth ways hboot looking for sd card whatewer it is in slot or not in slot?

---------- Post added at 06:45 PM ---------- Previous post was at 06:21 PM ----------

you mean this?

length:
.word 0x100000

If yes, yes I set it to 0x202000
[HTC Wildfire S] no.human.being:
Do we know where the SD card "init" (is it really an initialization or just checking for files?) happens? I wouldn't add "mov r0, #0" though (which purpose would that have setting an arbitrary register to zero?), but "mov pc, #0" instead (set the program counter to zero .. this will issue a reboot). If it bootloops we know that the instruction is hit. If it reverts to S-ON we know that fallback happens before the instruction is hit.

It can obviously see whether there are FILES on the SD so it obviously successfully traverses the file system. So I'd say SD card is properly initialized, otherwise it would fail earlier.

Exactly. I already have a newer variant that does more (disabling caches, MMU, etc.) before loading the payload, but it fails at the same point so up to that point it doesn't appear to make any difference. Who knows if it ever will, but at least it should do no harm to disable MMU and caches.
[HTC Wildfire S] munjeni:
Hmm, you are right! See this exploit -> http://paste.ubuntu.com/1197131/ I can see there mmu must be on! Maybe reason for our fail is mmu off? These exploit use the same methosd like your exploit (fastboot boot)!
[HTC Wildfire S] no.human.being:
Interesting.

Yes, it seems to operate on virtual addresses (0x8...). What's interesting is that the comments state that it writes into mARM's RAM after the MMU has been disabled. Is this what we're doing? We're writing to physical zero with the MMU disabled and therefore damage the Radio? That means HBOOT does not run off physical zero? But don't the page tables state that 0x9d000000 virtual is zero physical?

When HBOOT starts the MMU is off. That's why the beginning of HBOOT deals with physical addresses and sets up the MMU, then at some point the virtual addresses appear. When our exploit is executed, the MMU is also off. To be extra-certain, we can let our exploit disable it again and perform other "de-initialization", which shouldn't change anything, and in fact I've tried it and it doesn't change anything.

See section 10 of this document.

EVERY bootloader loading a Linux kernel is expected to adhere to this "protocol" when booting a kernel. The kernels rely on this and if the bootloader doesn't adhere, the kernel will likely "misbehave". This basically gives us some sort of "guarantee" in which state the processor will be when our code starts executing.

How do you know?
[HTC Wildfire S] munjeni:
Its hack for htc hero used to patch hboot runing in ram in order for switching phone to gobi interface and its used than for gaining s-off by command AT@SIMLOCK=7,0 ... look ih htc hero forum you will see there all info!

Addres 0x8xxxxx in hackspl.S is for hero like 0x9dxxxx for wfs... so if you look into hackspl you will see how hboot is patched by self (just for idea)!
[HTC Wildfire S] einstein.frat:
This is getting so far, you can overwrite hboot by jtag no?

Off topic, did you know when your this far on drugs, you'll see humans as weirdos, walking undead, scary sh*t, you can't even enter farther than 10m in mall to see those fugly faces, even the smell smells weird. Pizza smells like toast from hell. :o
[HTC Wildfire S] Lt.Win:
Stop trolling here and go away.

Swiftkey'd from my Sexy Wildfire S powered by Cyanogenmod 9
[HTC Wildfire S] no.human.being:
I'm curious whether this guy has actually found a way to flash the HBOOT on an S-ON phone, which is what he claims in his original post.

IF he has, then we can achieve S-OFF now, but I'm still doubtful.
[HTC Wildfire S] Lt.Win:
I'll given that tool a shot in say 6 hours. I have school, last paper of my current exam. If anyone else can try, go ahead. I'm trying anyways.

Edit : Sorry I didn't get time today, tomorrow perhaps.

Swiftkey'd from my Sexy Wildfire S powered by Cyanogenmod 9
[HTC Wildfire S] davidang:
Maybe let ask him for the exploit or ask him to work with u guys
[HTC Wildfire S] no.human.being:
There's probably no exploit in it (apart from one that can achieve temporary root, like zergRush). He can obviously write to partition 18 (Now that's a lot of partitions! Remember our phone has 7 "visible" partitions with IDs of 0 to 6 and then the "unmapped area".) on his phone using "dd" if he has root privileges within Android and partition 18 is the HBOOT. Seems like the phone he tested this on has no security at all. HBOOT seems to live on a visible partition and if you have root privileges in Android you can just write there. LOL!
[HTC Wildfire S] ctt812:
My wildfire s is on hboot 0.90.0000 and I have s-off with the rom1.zip from the htcdev.com. the only change is that it update the radiov2. Recently I screwed up with my phone and I reinstall the whole stock 2.3.3 rom with hboot 0.90.0000, but flashing the ROM.zip extracted from the RUU. The first step it did is updating the radiov2 and then it reboot into the bootloader, once it reboot, the status is s-on again. Then the phone flash everything including the stock recovery. I can s-off it with the ROM1.zip even it is stock version 2.3.3.

I know the hboot 0.90.0000 can be s-off in this way but not other hboot versions that you guy are working into. But since this s-on and s-off can be done by updating the radiov2, I wonder if this information can help you guy to work out a way to achieve s-off with other hboot version.
[HTC Wildfire S] theq86:
it won't work with other hboots because they are not affected by the exploit. rom1.zip was never intended to really set s-off. you can see it when you flash a new hboot you are s-on again. the flag does not lie in the radiov2 image. radiov2 is our baseband software. for simplicity we call all of the inaccessible area "radio" even though there are more firmwareparts beside modem and baseband software. i.e. all the boot logic is also in there, as well as all the low level security.
[HTC Wildfire S] no.human.being:
Well basically it all belongs to the Radio (more or less), since it's all part of or accessed by Iguana and Iguana = Radio in the Qualcomm case. It's just not the same that gets installed when you "flash a Radio". I'm totally confused now as to what happens when you "flash a Radio", since what's in the image that you flash and what appears in "NAND" (or at least what aARM thinks is NAND) is "related", but totally different. It's either ...

- Not written as a consecutive image. That might indicate that Iguana has a "file system", which would sound logical since it is a Unix system. However, the area is flagged as "raw" (not "yaffs2" or "ext4" or something like that), indicating that it does not have a file system. This doesn't explain the "single bytes different in large matching runs" effect though.

- The values you read from the "Radio area" aren't read from NAND, but the Radio "traps" read access to these areas (much like it "traps" write access) and "dynamically generates the content on the fly" if you understand what I mean. If this is so, then for what purpose are they generated? I mean aARM isn't supposed to access this area under normal circumstances, right? How can HBOOT flash the Radio when "there's no real NAND behind these pages"? Can it somehow "call the Radio" which then makes this "virtual Radio image" disappear so HBOOT can access the raw Flash in this area?

- Something completely different happens. :D

Any idea? Anyone willing to get his hands real dirty and dig into the source code of Iguana and find out how it actually works? (Yes, it's open source and it shares a great amount of code with Linux 2.6, as a look into the "wombat" folder will tell you! Of course it will miss all the proprietary Qualcomm-specific porting and optimizations, but it's better than nothing, right?)
[HTC Wildfire S] munjeni:
Its nothing than an AIO pack (good idea for creating an universal tool) but this is not for us because it will not gain s-off and will not unlock bootloader - tested allready
[HTC Wildfire S] no.human.being:
Well, he claimed that his tool could flash an HBOOT on an S-ON phone, which is why I had hope. Remember if we can write the modified HBOOT image to NAND we MAY have got it. We only thing we still have to prevent is the fallback and we don't know what triggers it. Say that HBOOT compares itself (as in RAM) to the contents in NAND and restores from NAND on mismatch. Then writing the HBOOT to NAND would fix the fallback issue, since RAM and NAND content would be identical if we could write the "hacked" HBOOT to NAND.
[HTC Wildfire S] csoulr666:
Why don't you try chain loading a stock HBOOT to see whether it's the mismatch that causes the reversion to the NAND HBOOT?
[HTC Wildfire S] no.human.being:
I already did and it "falls back" to the one that's in NAND.
[HTC Wildfire S] Antagonist42:
Hypothetically speaking...

OK so from what I'm reading here and gathering from the documents we do at this moment not have 50% of what we need to know...

this being the MSM7227 .... at what precise point is aARM released from it's wait state whilst mARM finishes it's MMU set up, system setup, it's own operation... does aARM actually get released "if" Fastboot/Hboot etc is actually in what would be 'Download Mode' or is Fastboot/Hboot actually running via mARM?

The Weakest Link... by what is in the documents for the 'Security Loop' is it only AMSS/RADIO that kicks it off? or is it via command issuing through Fastboot/Hboot? if it was via command issuing that's going to be getting swamped in code, bouncing address and data, which we at this point don't hold enough cards to stab at a lot of guesses, if it's mARM running Fastboot/Hboot it could be in a continuous 'Security Loop' which (as the phones need to update and the security has to at least have a ... doorway... maybe it is AMSS/RADIO that controls that) may only be under mARM so possibly controlled by AMSS/RADIO so by that there should at least be something simple that interrupts this 'Loop' and maybe something either innocuous or seemingly stupid to suspect it.

Personally I reckon n.h.b. is on the right track with Iguana etc on the Radio side of things as I don't think aARM can control the Operating Frequency or the timing of the phone (playing 'Mirace City' twice now i've had mARM Fatal Errors so mARM is it would seem is in charge of timers even for games I suspect).

Back to reality and stopping thinking of 'What If's'....

Soon as I can I'll be back onto the file/code compairing on Hboot.. (running around for family, bad health and losing my 1TB NAS drive really don't help much :crying: )
[HTC Wildfire S] no.human.being:
You're right in that we don't know a lot about the Radio side, but HBOOT is definitely running on aARM. HBOOT is also called the APSBL, Application Processor Secondary Boot Loader so its purpose is to bootstrap the application processor aARM. It runs from physical RAM page zero and is the first code running on aARM.

What I don't quite understand is how it gets "moved" to aARM. You know the mARM has this on-chip boot ROM from which it executes first initialization code and that brings the rest up. On the other hand aARM actually starts off execution from RAM page zero. That means that "something" (and this must be running on mARM since aARM will start execution from physical zero when released from halt) must have "poked into aARMs RAM" when aARM was still halted. This indicates that mARM can directly access aARMs RAM.

I think that "reverse engineering" the Radio from the binary side will not yield anything useful. It's a (very stripped down and bare but still somehow "complete" and probably POSIX-compliant?) Unix operating system. It will be far too complex to analyze on the assembly level. I think it would help us understand it all a lot more if we were porting the open source Iguana to the MSM7227 ("generic ARM support" is there, but I don't know how much "chipset-specific" modifications it will take) and then see how it behaves (probably very similar if we get it runnning). The question is, consider we grab the sources and somehow get it built. How can we install it to the phone for testing when we're not allowed to flash the Radio?
[HTC Wildfire S] Antagonist42:
Both aARM and mARM probably have their own ROM they boot from, I would suspect that both are running from power up BUT the system doesn't initialize until mARM sets up PBL/memory etc. Initial power-up PMIC could be set to 'HOLD' aARM until mARM finishes setup so that AMSS/RADIO is operational it can release aARM (this I suspect as flashing an older ROM even whilst android was beginning it's initial turn on a 'SYSTEM UPDATE OTA' was already waiting to kick in).

Even if there is only one on-chip ROM and that is for mARM both systems (mARM and aARM) are 'tied' together internally via the BUS systems but aARM without mARM setting up the memory etc wouldn't run, the only memory it would have is the IMEM/IRAM which is 256kb (64kb is the boot rom loaded from mARM as part of the PBL) so the question is does aARM execute from page0 in IRAM/IMEM or from external SDRAM? From initial power up if aARM is connected to IMEM/IRAM that would be it's initial page0, once read (mARM having setup the system) it would then take up the addressing (possibly where all the 'virtual address'' come in) and memory map of the rest of the system, once done, page0 on the memory map would be EBI1 but NOT accessible until buses and memory are setup to access SDRAM (mARM's job maybe only to basically setup memory/buses - more could be in the AMSS/RADIO and that's why phones 'BRICK' if it's overwritten).