yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] no.human.being:
It's REX. REX is always running and therefore able to intercept our communication. OEMSBL/QCSBL only load stuff into memory and then terminate.

Remember that the firmware is not developed by Qualcomm, but only licensed by them (they are a semiconductor company, not a software development company). Distributed by the Australian NICTA, the Radio firmware is REX, which is a build of this operating system (OzPBL license, never heard, but at least it's open source) and this microkernel (BSD license). The opeating system is called Iguana, which is short for "Independant Group of Unix-Alike Network Activists" and the microkernel is called Pistachio, stems from the L4 family and was developed by University Karlsruhe, Germany. The kernel also exposes a well-documented interface.

So if we have to take a look into the Radio, there's no need to reverse engineer. It's all open. I can't really see what Qualcomm seeks to protect/hide from "us" (or rather their competitors). Their low-level firmware seems to be entirely based on Iguana, which is open. This is getting so ridiculous. :D
[HTC Wildfire S] munjeni:
Are you sure its not modified for better security and for every device optimised ? I think yes.

If I remembered after read from documents, inside OEMSBL/QCSBL is allso configuration... If I am not wrong or if I remembered, theres configuration for memory banks, configuration for security/non-security...etc, if security enabled than authenticate sbl for security, if not than transfer control to security fail handler in PBL...
[HTC Wildfire S] no.human.being:
It is not original, but I think it's rather "optimized for the Qualcomm chipset" than for better "security". The "security" is "security through obscurity" and just serves to protect their IP. And as we all expected and you now experienced first-hand it can be bypassed via the JTAG interface. So the adversary against which it protects is actually non-existant.

Adversary type 1 is the average end user rooting its phone. Security will protect against this type of attacker, but if he succeeds this won't do any harm to Qualcomm. Their business is selling the chips to phone manufacturers and others. If the end user can modify firmware worst thing that may happen is that the end user will enable features that have intentionally been "cut down" on that particular chip. However, this won't cut into their sales numbers, as the user still has to buy a smartphone and that manufacturer still has to purchase the chips, so no harm for Qualcomm, so no reason to lock the firmware down.

Adversary type 2 is the competitor trying to figure out how the chips work and stealing intellectual property or crippling the firmware and then selling the chips to harm Qualcomm's reputation. Security won't protect against this type of attacker, since he will work at the hardware level, while security is at the firmware level, so no benefit for Qualcomm by locking the firmware down.

It's all rather pointless. The "level" against which it protects does no harm whatsoever and the "level" that might actually do harm won't be repelled.
[HTC Wildfire S] munjeni:
Found document... see page 5 http://dl.dropbox.com/u/69550833/80-V9038-15_MSM7XXX-QFUSES-AND-SECURITY.pdf ..its like all security going from seccond bootloader aka sbl or spl or hboot... which property right is hboot, is it htc ?

A lot of usefull documents http://xdaforums.com/showpost.php?p=24100141&postcount=1968

I tried: replace spl with hspl from other devices but still can not boot, so my opinions is every device have his own amss version paired with own seccond boot loader, so I think all security going from amss
[HTC Wildfire S] Antagonist42:
That is what I've been thinking about the mtd blocks, the results we #cat may only be buffer address pointers not the actual NAND being read, if that is so then the actual NAND address could be entirely different, if you check out my posts from klog and mtd the address sizes don't match as one is 8 digit and another is 12 and as I say on the post I'm not 100% I have that right ( Hit the Noob award button :D ) and also just to confuse things more is which FAT is AMSS using? 12,16 or 32? (I'll not mention 4 and 8 as I can't find where I read it as yet :( )

My guess is maybe 12 as if the system is using vfat would that mean vfat is 32 for SDCard then system maybe 16 so AMSS maybe 12 then any addressing to read it would make it even harder wouldn't it?

... 8 Thanks Limit !!! I'll have to post a Big Thanks in my drop box and post them that way ;)
[HTC Wildfire S] munjeni:
You think this:

01-01 00:00:01.020* <5>0x0000045e0000-0x000004960000 : "fota"
01-01 00:00:01.020* <5>0x000004aa0000-0x000005000000 : "boot"
01-01 00:00:01.030* <5>0x000005000000-0x00000e680000 : "system"
01-01 00:00:01.100* <5>0x00000e680000-0x000012340000 : "flex"
01-01 00:00:01.130* <5>0x000012340000-0x000012b40000 : "recovery"
01-01 00:00:01.130* <5>0x000012b40000-0x00001c2c0000 : "userdata"
01-01 00:00:01.200* <5>0x00001c2c0000-0x00001fea0000 : "cache"
01-01 00:00:01.230* <5>0x00001fea0000-0x00001ffe0000 : "misc"

in comparation with this:

dev: size erasesize name
mtd0: 00380000 00020000 "fota"
mtd1: 00560000 00020000 "boot"
mtd2: 09680000 00020000 "system"
mtd3: 03cc0000 00020000 "flex"
mtd4: 00800000 00020000 "recovery"
mtd5: 09780000 00020000 "userdata"
mtd6: 03be0000 00020000 "cache"
mtd7: 00140000 00020000 "misc"

??? If yes than you are wrong :) First part is dmesg log and seccond part is from cat /proc/mtd. First part explain offset from/to and seccond part explain size/erasesize :) but you thinked its diferent offset?? NO ! And mtd is realy in that offset (I read it with jtag and its stil there)!!! Nand MPU prevent us to write to protected offset, or whatewer other... and we need to learn learn learn learn, its not simple like writeb(0x22222222, 0x33333333)... or using an linux non msm kernel 3.4 and trying to write to nand using an mtd driver... there is stil protection that we need to understand first.
[HTC Wildfire S] no.human.being:
It's not AMSS, it's REX. AMSS is just an "application process", REX is the "operating system".

The partition type is "raw", which means it doesn't have a file system. It's far too primitive. No file system, no drivers, no hardware abstraction. Processes have to access data by address and can directly access I/O (which is of course nice for driving the transceivers without a "user mode" --> "supervisor mode" switch).

Basically, REX is not much more than a scheduler. Android has yaffs2 file system. FAT is not good for Flash memory, because it neither provides the wear-levelling nor the error correction that are required for Flash storage.

This is not from the WFS right? Because our "misc" goes right up to 0x1fffffff, which is the highest physical address. The phone you got this from has 0x1fe00000 as highest physical NAND address? Because why would they leave space unused?

Are you sure that aARM can access "directly" (access goes "only" through MPU, but not via RPC through Radio, which carries out the access)? We always thought that Radio will do all the NAND access and Android will just RPC to Radio to have it read from Flash to RAM or write from RAM to Flash.
[HTC Wildfire S] munjeni:
I think you are wrong ! Open amss and you will see in header .ELF, so...

---------- Post added at 07:55 PM ---------- Previous post was at 07:52 PM ----------

Here is screen capture from my local folder that contain jtag dump of the things inside your phone/aria/gratia/htc_hd_mini...etc http://img17.imageshack.us/img17/3385/20120530194454.jpg (ignore amss.asm)

And here hex part from AMSS (is not primitive, its very very complex!!!):

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000 7F 45 4C 46 01 01 01 61 00 00 00 00 00 00 00 00 .ELF...a........
00000010 02 00 28 00 01 00 00 00 00 00 E0 0C 34 00 00 00 ..(.......ŕ.4...
00000020 00 00 00 00 02 02 00 00 34 00 20 00 08 00 00 00 ........4. .....
00000030 00 00 00 00 01 00 00 00 00 10 00 00 00 50 E2 0E .............Pâ.
00000040 00 50 E2 0E B4 00 00 00 00 10 00 00 00 00 20 .Pâ.´.........
[HTC Wildfire S] no.human.being:
With "primitive" I was referring to the operating system, not the AMSS. It's a real-time operating system (RTOS). RTOSes are never that complex like say an Embedded Linux is since they have to meet hard timing constraints on a verifyable basis and this proof is only possible for "simple" code. (See "halting problem". Even proving whether execution of a particular piece of code will termiate sooner or later or whether the code will enter an infinite loop at some point is impossible for anything but "trivial" code.)
[HTC Wildfire S] munjeni:
Htc aria, htc gratia, htc hd mini, htc wildfire* ...a lot of htc devices have nand space from 0x0 to 0x20000000 !

This is nand layout from htc hd mini needed for android, I created it for that phone kernel, confirmed after play with jtag...:

HTCPHOTON_RESERVED_SECTORS=0x0
HTCPHOTON_FLASH_SIZE=0x20000000
HTCPHOTON_FLASH_OFFSET=0x0
HTCPHOTON_FLASH_SPL_START=0x2400000
HTCPHOTON_FLASH_SPL_SIZE=0x80000
HTCPHOTON_FLASH_LK_START=0x2820000
HTCPHOTON_FLASH_LK_SIZE=0x20000
HTCPHOTON_FLASH_BOOT_START=0x2840000
HTCPHOTON_FLASH_BOOT_SIZE=0x600000
HTCPHOTON_FLASH_RECOVERY_START=0x2e40000
HTCPHOTON_FLASH_RECOVERY_START=0x400000
HTCPHOTON_FLASH_MISC_START=0x3240000
HTCPHOTON_FLASH_MISC_SIZE=0xa0000
HTCPHOTON_FLASH_SYS_START=0x32e0000
HTCPHOTON_FLASH_SYS_SIZE=0xd200000
HTCPHOTON_FLASH_DATA_START=0x104e0000
HTCPHOTON_FLASH_DATA_SIZE=0xf0e0000
HTCPHOTON_FLASH_CACHE_START=0x1f5c0000
HTCPHOTON_FLASH_CACHE_SIZE=0x900000
0x140000 needed but free space=0x140000

boot size=6mb
recovery size=4mb
misc size=0.625mb
system size=210mb
userdata size=240.875mb
cache size=9mb

all data before 0x2400000 is oemsbl, qcsbl ...etc and starting from 0x0 ! Ox140000 I done free because all boards contain bad blocks, so to prevent wrong things to layout I done free 0x140000 (10 blocks free for bad blocks)
[HTC Wildfire S] no.human.being:
Misc definitely goes up to 0x1fffffff on the WFS. We have already verified this. This is our partition layout.

Yes, HBOOT is HTC proprietary software, but it's "heavily based" on some sort of "reference bootloader" that Google distributes to system engineers under a non-disclosure agreement. This is not worth much, however, since the bootloader is not disclosed anyhow, so knowing that it's "based on something else we don't know" is not much of an advantage to us. It just means that you're gonna find similar code on other (non-HTC) handsets as well, as they all share a common base that comes from Google.

You know the bootloaders speak this Fastboot protocol and all and these utilities are from Android SDK, so they have to be identical for each handset, else the SDK tools won't work. Also, Google knows "how its operating system wants to be loaded", so it creates this reference loader for showing handset manufacturers what they have to do.
[HTC Wildfire S] munjeni:
Ok, but who care becouse kernel use partition by name:) whatewer misc is on 0x1fffffff or 0x1234ffff, misc is misc for us and nothing more:D, you can create 30 partitions if is needed. This is only for htc hd mini because its wince device hacked to use lk bootloader and android on nand
[HTC Wildfire S] no.human.being:
You can pass custom mtd layouts to the kernel as parameters, therefore accessing space that is normally "unmapped" (like anything from 0x00000000 to 0x026bffff or 0x02fbffff depending on firmware on your handset) and you find security-relevant code there, e. g. the function that enables aARM to query mARM for the secu_flag. This is the function we try to patch in order to break security.

aARM thinking that secu_flag is zero is sufficient for breaking security. mARM only doesn't seem to be able to enforce security, it needs aARM's cooperation. We know that this is the case, since this is the way Revolutionary breaks security. They only break aARM code, not mARM code and then everything's open, even though mARM still knows that security's supposed to be on. This proves that mARM cannot really "enforce" anything against aARM's will.

This is why we need to know the addresses where the partitions are. You could even map 0x00000000 to 0x1fffffff as one big contiguous mtd and then access "everything" (at least everything that's visible to aARM).

Fastboot command line is ...

./fastboot -c "mtdparts=<page_tables>" boot <image_file>

Where <page_tables> is the string starting with "msm_nand:" followed by "physical_size@physical_offset(partition_name)" for each partition. Multiple partitions separated by comma (",") from mtd0 to mtdn.

SBL != HBOOT

SBL = Secondary Boot Loader (for modem processor)

HBOOT = APSBL (Application Processor Secondary Boot Loader)

SBL = Qualcomm, APSBL = HTC

See here.

So SBL boots the ARM9 (mARM).

So aARM has exclusive memory access and mARM must RPC, not the other way round. So mARM cannot trick "us", but "we" can trick mARM if we put "malicious" code into the rmt_storage driver. So in this sense "we" are in command and can act like a rootkit for mARM if we want to, since mARM can't do a lot on its own and always has to ask us to do it on his behalf.

Must check the Android repositories whether the bootloader code is still there. I always thought it was provided by Google under NDA only.

And so on and so on.
[HTC Wildfire S] Antagonist42:
Don't forget though that while each ARM has at some point control over running the system both still have access and maybe control over other components in the system, EBI1 and EBI2 and the AXI Bridge gives each ARM access to the other or there would be no inter-processor communication as EBI1 and 2 are different speeds along with the NAND and the inbuilt NAND RAM, both are different speeds and reside one on each EBI bus but both ARM have or need access, to a certain degree there is no 'one or the other'.

Yes the mtd and klog is from my ACER C6 not the WFS but was locked down with a FOTA so I'm now AMSS up-to-date (1.013.00) but Kernel Hacked (1.008.00) with su etc but one install previous so at the moment any update is blocked lol
[HTC Wildfire S] heavy_metal_man:
If we were to jtag an wfs while running an xtc clip would it reveal to us its full process?
[HTC Wildfire S] theq86:
Yes and No. Via JTAG we can debug all the processes on the phone, but we can not debug the xtc clip. And I somehow doubt that the clip comes with an own JTAG interface.

We can only reconstruct what the clip does to the phone. So all processes the clip itself makes (like e.g. SIM emulation) will not be readable for us.

It might however be possible to intercept the data that comes over the flex cable somehow. But even if it would provide us with full information about how to emulate a eng sim (which is very unlikely, see next paragraph), it would not enable us to create a software solution.

Remember, the S-OFF is done by the htcdiag tool and the clip only mimics a special sim with probably contains encryption keys or algorithms. Since a SIM actually is a full microprocessor, it might not even send encryption keys to the phone, but do the encryption itself. This is why we will not get the emulation algortihm.

So all the processes will never be revealed to us.

But who cares. It's not the clip we are running after. What we like to know is, how the diag tool does the S-OFF. Where does it write to, wich calls does it to wich process a.s.o.

Stepping through the diag tool while s-offing with a clip would definitively help us.

The first step of all now is to get a jtag running with a wfs and find out how all the low level components work together. Maybe we find a way to write to the radio area and inject our patched hboot.

When we completed that we could also debug the diagtool to get the real xtc-clip-like S-OFF.
[HTC Wildfire S] heavy_metal_man:
That's what I meant, could we not follow how the phone reacts to the htcdiag tool and then just patch there instead. Allowing of course that it reveals to us what it does and we get write access. Also, what are the odds that if we could get the keys from the clip that they would also work for issuing some sort of override to the phone.
[HTC Wildfire S] no.human.being:
The xtc clip runs on an STM32F103CB controller, which is an ARM Cortex M3 (ARMv7). Of course it features JTAG, otherwise you couldn't put a bootloader on to flash the rest of the firmware. Here is the schematic of the clip's circuit board. As you can see, the JTAG interface is even "led out" via J4, J6, J7 and J8 test points.

The firmware of the chip has already been dumped via JTAG by some "hackers". It consists of two files, one for the on-die Flash and a second for an M25P16 Flash memory chip wired to the controller via SPI.

On-chip flash image

SPI flash image

This would require the use of a data logger.

Yes it would. Somewhere in this thread, someone has claimed that all that a SIM can do to the phone could somehow be "emulated via USB".

The question is whether the Radio or the DIAG checks the SIM. If only DIAG checks the SIM, we should figure out what DIAG does after the SIM has been verified and do this. Remember that DIAG is just an ENG HBOOT and HBOOT is running on aARM, so all that DIAG can do we can do as well. However, if DIAG were just asking the Radio to turn security off and the Radio was verifying the SIM, we'd still require an "xtc-clip"-equivalent so no software-only solution.

But the xtc-clip's firmware is accessible and this would reveal the process to us.

Right, I'm quite sure it can be done without the clip and that's what we're striving for.

Or rather JTAG-dump before and after xtc-clipping to check what

actually

changes in NAND.

EDIT: Btw, there are no OpenOCD scripts for the MSM7227, but I've heard that those for the Freescale i.MX31 (also an ARM1136 but manufactured by a different semiconductor fab) are supposed to work.

EDIT2: My "toolchain" is complete. I got tools for getting the device open, I've got a JTAG interface for ARM and I've got the JTAG adapter for the board. Expect more to come as soon as I have time to spare.
[HTC Wildfire S] heavy_metal_man:
Its on! :cool:
[HTC Wildfire S] no.human.being:
If we're to flash HBOOT via Fastboot after obtaining temp S-OFF, what format does this HBOOT image have to be in?

Is it NBH format or is it a "raw" image? If it's NBH format, does someone have a good and correct (!!) description of this file format, so I can try building a utility that creates a valid NBH from our patched HBOOT so that we can flash it via Fastboot after we have disabled signature checks?
[HTC Wildfire S] munjeni:
Its raw hboot with size 0x80000, so you can flash hboot with this command, for example:

fastboot flash hboot hboot_liberty_7227_1.02.0000_101104.nb0

nb0 is allways raw.
[HTC Wildfire S] no.human.being:
Ok, thanks. I'd hit the "Thanks"-button, but my thanks are already used-up. Too many contributors in recent time. :D Great folks! Keep it going. :D

If it's "raw", then how do they verify that it's an "original" HBOOT. "Raw" images can't include signatures, since they only contain what is written to NAND or am I missing something? If they don't include signatures, why can't we "fastboot flash hboot our_patched_hboot.img" straight away on an S-ON device? After all, what "secu_flag" does is enforce signature verification by the bootloader.

EDIT: Another thing. The "nb0" doesn't include the out-of-band-data for the NAND, as this is generated on-the-fly right? If OOB must be included, I must make the exploit generate appropriate OOB data for the HBOOT.
[HTC Wildfire S] theq86:
I think it is working like this:

UseCase 1: fastboot flash hboot imagename.nb0 [S-ON]

--> Always reject, needs no signature.

UseCase 2: fastboot flash hboot imagename.nb0 [S-OFF]

--> Always allow (if the hboot supports flash command), needs also no signature

UseCase 3: Using PG76IMG.zip

--> verify the ZIP's signature. If matching, allow everything to be flashed in the zip

UseCase 4: Writing hboot to radio directly

--> no signature needed. is rejected normally. this is the way we tried.

You see, there is just 1 use case containing the need of a signature. I know for sure, that PG76IMG's do have an embedded signature. (This is the yellow progress bar when upgrading images via fastboot)

This signature will verify the whole zip's integrity. What is quite obvious to prevent the zip from changing itself.

This is what makes me believe there is no hboot signature. no radio image signature. etc.

There is only the PG76IMG signature.
[HTC Wildfire S] no.human.being:
Ok, I understand.

Is it actually ...

- the ZIP (?!) that's signed (ZIP file format has support for asymmetric cryptography? :eek: ) or is it rather that

- there is an NBH inside the ZIP that's signed (you can also supply a PG76IMG.nbh instead of a PG76IMG.zip to the bootloader so is the ZIP just an archive containing the NBH?) or

- an IMG inside the ZIP accompanied by a separate "signature" somehow (like ROMs are distributed as ZIPs and have certificates in a separate subdirectory)?
[HTC Wildfire S] theq86:
Yes, it is the ZIP, that is signed. I already verified that by just altering a single byte in the zip that was not in the data area.

ZIP does include specifications for encryption and passwords, but not for cryptographic signatures. However, PG76IMGes are not standard-conform and contain the signature in a way that let's you still read the files in it. But try to add a file to the zip, it will fail because the zip is not standard.

no file inside the zip is a signature. it only contains the images and an android-info textfile that indicates, if hboot upgrade should be bypassed.
[HTC Wildfire S] no.human.being:
Ok, so I'll get my HBOOT dumped and patched, then get JTAG to work with the phone and use it to figure out where it lies in NAND physically (might not be where we've found it, since what we read was not physical NAND, as there's still an MMU in between).

Then I should be able to write the patched HBOOT back to NAND via JTAG, but that's not what I'm gonna do, since we don't wanna write via JTAG, but find out how it all works. Instead, I'm gonna "trap" the "regular" HBOOT when it starts executing, patch it to S-OFF in volatile memory, then let it continue running and verify that it shows S-OFF. When in this state, I should be able to flash the patched HBOOT via Fastboot, making the S-OFF permanent.

When we got it so far, we can begin figuring out whether we can achieve this "temporary S-OFF" by software means. The Fastboot protocol is quite complex and there might be an option for a buffer overflow exploit in the code handling this protocol on the handset side with a "custom" Fastboot utility running on the computer sending "malformed" Fastboot packets over the wire to the phone. Not sure whether this will get us anywhere, it's all too early to tell, but it seems we got a foot in the door somehow.
[HTC Wildfire S] Antagonist42:
I must ask, what exactly do you expect the signature to be?

A specific set of strings maybe and if so could they be hidden in say file header information?

I only ask as I was thinking about an obvious way to secure a system without using larger programs to secure them, sort of like trying to find point A when you can obtain or hold data X,Y and Z, I was wondering if all the time stamps verified against a known time stamped file and the systems own initial booted time stamp and time since running could this be enough to impose a block on writing to the system if the file you try to write has no time stamp or is say out of date compared to if one has already been run and logged on the device?

BTW great going guys ;)

Rooted Xakep E320/C6 EUU Hacked Update