yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] Antagonist42:
The ACER OTA contains pretty much the same:

. acer_e320_0.0.0.Flex.0.0_1.014.00.Flex.114.00_EMEA_ORGUK.txt

. AMSS.zip and amss.mbn/amsshd.mbn (the zip contains all files except AMSS.zip {not an actual RADIO image!} and .txt file)

. appsboothd and appsboot.mbn

. qcsblhd_cfgdata.mbn qcsbl.mbn

. oemsblhd/oemsbl.mbn

. partition.mbn

. boot.img - recovery.img - flex.img - system.img

. update.zip (contains zero data?!)

The only reason I can see for the differing .bin .img .mbn .nb0 images are the manufacturers and programs they are using, then there is no conflict between flashing phone brand A and B and each model XYZ, basics like system remain the same to a degree, they depend more on the phone actually operating than to flash (if you wanted you could load any file into an appropriate program without a file-type as long as the data is correct inside). The above data is exactly the same as in the EUU except for the AMSS.zip and .txt file, the EUU the files are .bin and are unmarked from description, the containing .hex has the files extracted to bin images (using Hex_romtool to extract they are named ***.hex.part1.bin etc).

As to partitions and why various parts of radio.img are spread out maybe the idea that, as with the android system, containing the radio on one partition would in theory make it more vulnerable (even from say hardware corruption), if it was broken into parts and parts are needed by more than one process so multiple items over small 'partitions' would make it more robust and less likely to fall foul of errors. This has come to my mind as with the write error I have now on NAND, the device still shows the full 512Mb ROM but there is only approx 150.37Mb, RAM on the other hand shows 404Mb (and has never shown the full 512Mb on any system install due to partitioning of DATA/FLEX etc).

Partitions on the ACER when flashing with the EUU run as:

Partition Name..........Partition #
Partition Table - 0x00000015
QCSBLHD_CFG - 0x00000002
QCSBL - 0x00000003
OEMSBLHD
and OEMSBL - 0x00000004
AMSSHD
and AMSS - 0x00000005
APPSBOOT - 0x0000000a
BOOT - 0x00000018
SYSTEM - 0x00000019
RECOVERY - 0x0000001b
FLEX - 0x0000001c
[HTC Wildfire S] no.human.being:
The "Radio" that aARM sees is not the "actual Radio". mARM (where the Radio runs) and aARM (where HBOOT and Android run) are probably "virtual machines" running on common hardware and you'd probably have to "break out of the virtual environment" to access the "actual Radio" from aARM.

I currently have no idea of the exact architecture though. Either Iguana (= Radio) is the "host" (hypervisor) and Android is the "guest" or there a "class zero hypervisor" and both Iguana and Android are "guests".

I currently have no idea how a Radio update is installed either. It probably has to be done by the Radio itself, since aARM "normally" cannot access mARM's memory and HBOOT is running on aARM. While aARM can access some "Radio area" where some Radio-related code lies, we've verified that it's NOT the Iguana build that's in NAND. The contents of the "Radio area" that aARM sees are probably entirely "made up" and "generated on the fly" by Iguana as aARM performs read requests to these memory locations, a bit like "memory mapped I/O" addresses have no "real memory" behind. I currently don't know what purpose this "Radio area" serves though. It might be required for communication between Radio (mARM) and the RIL (Radio Interface Layer) within Android (aARM), but aARM doesn't appear to be very "aware" of this memory region and communication between aARM and mARM appears to happen mainly via IMEM, a 256 KiB large section of RAM that's shared between mARM and aARM. Anyhow, the actual Iguana code does not appear to live in ANY memory region that would be accessible from aARM (not even in "unmapped memory"/"Radio area").
[HTC Wildfire S] Antagonist42:
Coooool..... just found a hint at what the BASEBAND may be running as and the system as well... it's from a lecture I think from 2011 so probably some of the info could be a year or so out but then again these chips and phones have been around basically since 2007.

Found on this site here a .pdf with the lecture slides here ;)
[HTC Wildfire S] no.human.being:
I've already come across these some months ago. However, since in our case we have access to the Iguana sources, reverse engineering the baseband is moot.

Mind that the lecture analyzes a device that is only a modem, while in our case, we have two operating systems interoperating.
[HTC Wildfire S] rezo:
Remember the "radioflag" in the misc partition? http://xdaforums.com/showthread.php?t=1540515

It is for 2K partition layout.

One of my phone has 4K partition layout (like no.human.being's phone) and the radioflag is located at 0x2020.

That phone is on 0.90.0000 hboot and 7.54.39.08M radio (from rom_01.zip) so... I have hboot s-off.

But...

If I set something before the radioflag at 0x2010, the phone is s-on!

The next thing. If I set something at 0x2020 (radioflag) the phone goes to "RAMDUMP" instead of "HBOOT".

As I said it is for 4K partition layout. For 2K it would be probably at 0x1010.

It looks like 0.90.0000 hboot reads something before the radioflag.

Maybe we could find something similar in other hboots...
[HTC Wildfire S] no.human.being:
On some devices, RAMDUMP seems to be a regular Fastboot option, see here. Don't know what it does though. Probably dumps the contents of the device RAM somewhere (to SD card?) much like a coredump on a Unix system. Since the option is in the Fastboot menu, perhaps there's also a Fastboot command that triggers it?

@rezo: How did you get the idea of writing a7 f5 a7 86 ... to offset 0x2010 in "misc"? :confused:
[HTC Wildfire S] rezo:
I wanted to find the radioflag adress on 4K phones so I filled the misc with the random data, looked at "fastboot oem gencheckpt" how it looks and found the adress with given data. After the first try I saw the s-on, but when I set only the radioflag, my phone was back s-off. So I flashed again it with random data and cutting next and next large blocks I found 0x2010 :D
[HTC Wildfire S] Antagonist42:
I was more interested in the parts that mention REX - that being " All tasks share the same address space, ARM supervisor mode " (mentioned under the REX Scheduler) but it also mentions that " REX kernel running as OKL4 guest in newer generations " so would it be right to think that REX kicks up the Iguana? If so that would make all running OS a guest except maybe REX?

Like it says it's for the MSM6280 but I don't see why there would be too much difference between them as it's still on the ARM926
[HTC Wildfire S] no.human.being:
REX

is

(a propriatary version of) Iguana that has been optimized for Qualcomm chipsets.

Source
[HTC Wildfire S] ONeill123:
That is what i wqnt to kbow, and how we can rewrite the secuflag.

------Last dev-question------

So the secuflag is in the radio, if i'm right. But how a user can write into the NVRAM? I have seen today first ever how revolutionary unlock a Sensation XE. The program strat the phone into fastboot mode, right?

Then the phone restarts 3x into the fastboot and after this is it s-off. What revolutionary do at this time, flash with fastboot? But then the hboot will give an signaturerror, or not?

So what they do?
[HTC Wildfire S] Lt.Win:
Using the new temproot exploit, which doesn't go even after a battery pull, can't we boot into fastboot and follow revolutionary's method? Isn't that what they did? We're just using another temproot exploit, that's all.
[HTC Wildfire S] sythe179:
New temproot exploit?

Link?
[HTC Wildfire S] ONeill123:
Search tacoroot.bin with google and you find the new exploit.

But what revulotionary do in fastboot mode, and what they do before?
[HTC Wildfire S] sythe179:
Before, think it was a more extensive temproot.

/edit

Not sure I trust that new method yet, needs more testing and verification.

I say that due to others knowing about it, but not develping a method with it. Got to be a reason why they dident.
[HTC Wildfire S] ONeill123:
Also, if u install the temproot, then u really have temproot after restrt, but its very instable, the statusbar doesn't funct.

But you have root after restart. Maybe we can port the revolutionary method to marvel?
[HTC Wildfire S] sythe179:
Maybe, but going to need more info and some serious stability issues ironed out before this is made the new temproot workaround.
[HTC Wildfire S] Lt.Win:
Atleast we have some new methods to work on and our genius devs island3r and eoghan and ofc no human being. They would be knowing about this new exploit, let's see what they can do.
[HTC Wildfire S] island3r:
Well, not genius :p and no dev :D

On that note, I think the hboot diag files here are from a cdma phone are they not? If they are, they are not going to flash on a gsm phone. At least on other phones if you do that you'll get a brick, so I guess this is the case here as well.

Is there any gsm WFS user out there with an s-offed phone willing to dump his hboot?

Also, happy new year :)
[HTC Wildfire S] ONeill123:
How you want to dump the hboot and why?

An dev from alpharev said, that the secuflag is stored in the radio files. So we must know how to write there and where the secuflag stored exactly to reqrite there.
[HTC Wildfire S] island3r:
Because you can't write on the radio and the best way to bypass the security check is to tell the hboot not to look for it. AFAIK the same with other nand devices.
[HTC Wildfire S] ONeill123:
But how we can write a new hboot?

The same as redio i think. And we need someone who can rewrite the hboot, that they don't look for the secuflag.
[HTC Wildfire S] djpc:
This is what the diag files do, its exploits the hboot to remove the check.
[HTC Wildfire S] ONeill123:
Yea, but they check the sim or not?

And how we can remove this check?
[HTC Wildfire S] djpc:
Im not sure how it works exactly but from my understanding once you have removed the NAND write lock removing the sim lock is a trival process. What we need to find is a similar exploit to what the CDMA users have. It might be HTC have removed this loophole completely or it could be that slight differnces in the hboots mean we need to just use different diag files to the CDMA.

The problem is is finding the hacked hboot and the diag files could be difficult as im not sure how the xtc clip works but it might use a different exploit.
[HTC Wildfire S] ONeill123:
hmm, but the exploit must be on the goldcard, i will ask someone who used the xtc clip. Maybe he has the files ;)
[HTC Wildfire S] Schnello:
Here the files from the XTC Clip Goldcard
[HTC Wildfire S] ONeill123:
Thanks schnello ;) I think you are the same as in AH.de?

Ok, i will test it now and will report

---------- Post added at 06:55 PM ---------- Previous post was at 06:50 PM ----------

Hmm, doesn't funct, but the files are different, the md5 checksums. I think, the sim dummy must be insert when running this diag files.

Hm, maybe the devs can something do with this.
[HTC Wildfire S] *se-nsei.:
Speaking of which, haven't heard from no.human.being in a while..
[HTC Wildfire S] w()$k:
small gotcha )

If you go to recovery, you can flash the signed official zip-image, so i guess, that before or at the moment switch in to recovery mode we get s-off mode.

So we can check dump of hboot with IDA in looking for code to switch in s-off )
[HTC Wildfire S] artturnip:
Anything for a noob to do here guys? I'd love to see s-off and therefore would love to support your work... but I don't know how... :banghead:
[HTC Wildfire S] rezo:
Ok... after some researching:

(0.90.0000 hboot + 7.54.39.08M radio + 4K partition layout phone) look for the 6th bit at 0x201C in the misc partition. If it is '1' then we got s-on. If it is '0' we got hboot s-off.

So.. 2*, 3*, 6*, 7*, A*, B*, E*, F* would be also doing s-on.

It is possible that other hboots + radios have also that "hboot s-off flag"?

Filling all misc with FF or 00 doesn't do that so that mechanism doesn't exist or it's more complicated.
[HTC Wildfire S] no.human.being:
I cannot explain this behaviour, however the "actual" secu_flag is not in "misc". In fact it's not anywhere in the "virtual NAND" that HBOOT and Android see. If you binary-compare the entire address space that aARM sees on a phone before and after achieving "Radio S-OFF" via xtc-clip, the only change you'll see is that the backup CID is erased from "misc". Everything else is bit-identical. The secu_flag resides in Iguana and cannot be accessed by aARM. The ways for achieving S-OFF are either ...

1. ... authenticate with Iguana so that it disables security. This is what xtc-clip does, but the authentication cannot be done in software.

2. ... flash Iguana so that it's S-OFF. Don't know if this is possible in software, since I don't know how updates for Iguana are performed.

3. ... make HBOOT never query Iguana for the status of the flag. This works in principle as is proven here, but the status doesn't "stick". "Something" (Iguana? HBOOT itself?) always "restores" an "original" HBOOT image after a very short period of time if you modify something in the HBOOT code. If we find the code where this happens we can most likely do something about it.

That "misc mechanism" probably only works with that strange "special" Radio. I don't have the phone anymore, but there definitely wasn't a single non-zero byte surrounded by many zero bytes somewhere in my "misc" partition and since you say bit unset (zero) is S-OFF, it would have to be set, since my phone was S-ON.

EDIT: Ah, I forgot. HBOOT

must

restore itself. If you overwrite HBOOT with some code that's really different from an HBOOT (say you overwrite it with no-operations and a jump back to the beginning), there's no HBOOT restored to that memory (and the infinite loop runs forever on aARM). So yes, we can definitely do something about it since we can overwrite the entire HBOOT via this "chainloader" exploit. We "only" have to find where this happens in the HBOOT. And it would be best if we could find it in the 1.09.0099 HBOOT since that's the one we've done the most analysis for.
[HTC Wildfire S] rezo:
I rather thought about that may be two sec flags: h-boot s-flag and radio s-flag (master s-flag). You are right about "that strange "special" Radio" but why it works only with the 0.90.0000 hboot? :eek:

BTW...

Look how the hboot is written in NAND. There is a lot of small differences... You use a raw hboot image but what if you could try with the hboot image extracted from the jtag dump (WildFireS_Full_alive.bin)? Maybe that causes restoring in your exploit?

RAW HBOOT IMAGE VS HBOOT from JTAG DUMP
[HTC Wildfire S] BeciMester:
(emphasis by me)

Yes there are indeed two checks done, and you may have just shed some light on the second one!

The following code shows the whole of the secu_flag check in the 0.90 hboot, edited to show the program flow:

9D008698 STMFD SP!, {R4,LR} ; Save registers
9D00869C BL sub_9D04414C

9D04414C STMFD SP!, {R4,LR} ; save registers
9D044150 BL sub_9D04CE00

9D04CE00 STR R4, [SP,#var_4]!
9D04CE04 LDR R3, =0x9D086A8C
9D04CE08 LDR R4, [R3] ; R4 = 0xBD100000
9D04CE0C ADD R4, R4, #0xFC000 ; R4 = 0xBD1FC000
9D04CE10 ADD R4, R4, #0xA0 ; R4 = 0xBD1FC0A0
9D04CE14 LDR R0, [R4] ; value from 0xBD1FC0A0 into R0
9D04CE18 AND R0, R0, #1 ; clear all but 1st bit
9D04CE1C LDMFD SP!, {R4} ; restore registers
9D04CE20 BX LR ; return

9D044154 LDMFD SP!, {R4,PC} ; return again

9D0086A0 CMP R0, #0 ; if R0 is not 0...
9D0086A4 MOVNE R0, #1 ; ...load 1 into R0 ...
9D0086A8 LDMNEFD SP!, {R4,PC} ; ...and return
9D0086AC BL sub_9D00769C ; if the first check passed...

9D00769C STR R4, [SP,#var_4]! ; save registers
9D0076A0 LDR R3, =dword_9D07A2DC ; = 0x60303000
9D0076A4 LDR R4, [R3] ; R4 = 0x60303000
9D0076A8 LDR R3, =0x101C ; load the offset
9D0076AC LDR R0, [R4,R3] ; value from 0x6030401C into R0
9D0076B0 LDMFD SP!, {R4} ; restore registers...
9D0076B4 BX LR ; ...and return

9D0086B0 MOV R0, R0,LSR#5 ; shift to the right 5 times
; (move the 6th bit into 1st)
9D0086B4 AND R0, R0, #1 ; clear all but 1st bit
9D0086B8 LDMFD SP!, {R4,PC} ; return

What it does is, it checks the least significant bit of 0xBD1FC0A0, and if it's not 0, the test fails (R0 returns 1). I think this is the (representation of the) radio flag.

The interesting part is the second, at 0x9D00769C: loads a base address, adds the offset, and returns the 6th bit (!) of the value at 0x6030401C. It seems to be the "misc check", and if that fails, the end result of the secu_flag check will still show "s-on", it doesn't matter if you have radio s-off or not! The interesting info is that the misc partition (or at least part of it) is mapped in from the virtual address 0x60302000. :laugh:

This makes me think that the "jtag dump" is not accurate. I used the hboot's own built-in memory dump routine to extract the RAM content, and that dump is the exact match of the raw hboot data. Could you have a look at how often the differences occur? They seem to follow a pattern, like after every 0x200 bytes one 4-byte block is missing or something. EDIT: the missing bytes you highlighted are part of the page table and if they were really missing the whole thing wouldn't work. So the dump must be inaccurate.
[HTC Wildfire S] no.human.being:
Well, like I said, unfortunately I can't test anymore since I don't have the phone anymore. However, I think that the HBOOT that aARM "sees" (remember that this is not what's actually in NAND - for example the Radio code that aARM sees looks VERY different compared to the code that's actually stored in NAND) is the same that is in the nb0 and not what is in the JTAG dump (and therefore probably in physical NAND). But like I said I don't have the phone anymore so I actually cannot verify anything at the moment.

We have KNOWN for some time that they perform two checks, but why? Is it for easier testing? Their developers probably test on Radio S-OFF devices. Do they perform this "misc"-check to allow their devs to easily enable security temporarily on their devices by changing a bit in the "misc" partition?
[HTC Wildfire S] BeciMester:
What happened to your phone? :eek:
[HTC Wildfire S] no.human.being:
The micro-switches were worn out. It was still usable, but I decided to send it to HTC to have it fixed before the warrenty period ends. However, they said that the board on which it is based is no longer produced by their supplier, so they can neither replace the board on it nor manufacture new devices of this type, so the device is basically discontinued. Since they don't have any devices left in stock, they could not send me a replacement device either, so they offered me a refund of the entire price I paid for it. Good news for me, as I basically had a phone now for one and a half years basically without paying anything for it, but it also means that I don't have access to the device anymore.

I'm on a Samsung Galaxy Nexus now. As you know that one's based on an OMAP4460 chipset, which has absolutely no security in place, so there's currently nothing I could hack. :D
[HTC Wildfire S] rezo:
Thanks BeciMester for explaining it to me.

I agree. Munjeni also said that. So that jtag dump may be proper.

BTW...

In the 1.09.0099 hboot, the whole value from 0x201C is used in two other places... @BeciMester do you know what for?

@n.h.b That's sad :( Hope you don't leave this thread... If you want I can send you one of my phones :)

----------------------------------

EDIT:

About comparing:

Yes, 90% is the some kind of pattern.

3% part from whole:

Bigger parts of non matched data:

Some insertion and all deletions:
[HTC Wildfire S] no.human.being:
I first thought it may be proper, as I thought that JTAG had the stuff "inserted", so I thought that it might be some sort of redundancy that is created when HBOOT is written to NAND and stripped off again when loaded by the SBL, but now I've seen that the stuff is MISSING from JTAG but is THERE in the nb0, so I no longer think that it's proper. We can be quite sure that what's in the nb0 is what actually gets executed. This is what happens in HBOOT-0.90.0000 (nb0 version) after the MMU was set up.

4d4:	e59f0010	ldr	r0, [pc, #16]	; 0x4ec
4d8:	e3500000	cmp	r0, #0
4dc:	ee011f10	mcr	15, 0, r1, cr1, cr0, {0}
4e0:	e1a0f000	mov	pc, r0
4e4:	e1a00000	nop	; (mov r0, r0)
4e8:	fff00000	; <UNDEFINED> instruction: 0xfff00000	; IMB
4ec:	9d000800	stcls	8, cr0, [r0, #-0]

See that it jumps to 0x9d000800 virtual, which is 0x800 inside the nb0. There's the code that zeroes the BSS, then jumps to 0xbc8 ("main").

800:	ea000001	b	0x80c
804:	9d0798d0	stcls	8, cr9, [r7, #-832]	; 0xfffffcc0
808:	9d08d324	stcls	3, cr13, [r8, #-144]	; 0xffffff70
80c:	e51f0010	ldr	r0, [pc, #-16]	; 0x804
810:	e51f1010	ldr	r1, [pc, #-16]	; 0x808
814:	e3a02000	mov	r2, #0
818:	e5802000	str	r2, [r0]
81c:	e2800004	add	r0, r0, #4
820:	e1500001	cmp	r0, r1
824:	1afffffb	bne	0x818
828:	e59fd37c	ldr	sp, [pc, #892]	; 0xbac
82c:	ea0000e5	b	0xbc8

So let's have a look at what's at 0xbc8.

bc8:	e92d47f0	push	{r4, r5, r6, r7, r8, r9, sl, lr}

Mmh, saves a lot of registers to the stack. Looks much like the beginning of a function (in fact it's function "main"). So far we've had one branch from 0x9d0004e0 to 0x9d000800 and one branch from 0x9d00082c to 0x9d000bc8 and they all ended up where we expected them.

Contrary, in your JTAG dump 4 bytes are missing at 0x202 to 0x205 and 0x40d to 0x410. That means that this thing at 0x9d000800 would actually be 8 bytes "earlier", at 0x9d0007f8. Thus setting the program counter to 0x9d000800 would actually end up two instructions "after" what we see inside the nb0 at 0x800. It would branch to what we see as 0x808. At this offset there is the word 0x9d08d324, which is clearly a virtual address and not an instruction.

Forget the JTAG dump, it's screwed.
[HTC Wildfire S] davidang:
No!! Chances of s-off our wfs will be gone :(
[HTC Wildfire S] theq86:
yes and the world will burn in flames in december 2012 ...

stay on the ground. many people contributed in this thread. many without even owning a wfs. so don't cry :rolleyes:
[HTC Wildfire S] heavy_metal_man:
Indeed, all we need is a working JTAG :rolleyes:
[HTC Wildfire S] artturnip:
Are they expensive? Or will it just not work with jtag? Yes... I know of the voltage problems... I have been following this thread. But can we fix that? :confused:
[HTC Wildfire S] heavy_metal_man:
There is bound to be JTAG for the htc wildfire s specifically. I think the JTAG nhb got was a more generic arm jtag . But if we could get a specific JTAG for the marvel we would at least have a chance. Maybe we could all chip in and get it?

---------- Post added at 03:04 AM ---------- Previous post was at 02:51 AM ----------

http://www.fonefunshop.co.uk/cable_picker/94954_RIFF_Box.html

I have found this, and I saw an Adapter for the marvel as well. What do we think guys? Who here still has the device and the will to get this done?
[HTC Wildfire S] artturnip:
£130!!!??? Don't think anyone's gonna spend that amount... :banghead: