yashsingh1/xdaforums huggingface dataset:
[HTC Wildfire S] munjeni:
WFS hboot loading offset is 0x9d000000 (same as a htc aria) . Just for idea... look here -> ftp://xda:xda@ftp.xda-developers.com/Hero/Tools/hackspl.zip ... I downloaded these hboot for these device, decompiled them, ...in order to analyse them in comparation with hackspl.S, ... loading offset for these hboot is 0x8f000000 ...but few things I not understand there, where guys found next parts:

newcommandset:
.word 0x8f07c0b0
dest:
.word 0x8f010090

security_hack:
.word 0x18047280

cid_hack:
.word 0x1804717c

mpu1:
.word 0x93640000
mpu2:
.word 0x93640800
mpu3:
.word 0x93650000
mpu4:
.word 0x93650800

After decompiling hboot I tried to see for example what is inside these hboot (offset 0x8f07c0b0) but I can see nothing there (my knownledge in asm is tiny)... where guys found "newcomandset" there? How it working (how/what he set new comand set)?

I want to say now after few things I done in hboot for aria... I played with hboot and patched one function inside, disabled hboot erase protection, got completely hboot partition erasable with command fastboot erase hboot!!!... lets back... thing that I want to say is: all protections is inside hboot? I don't know how it working, but I think hboot working in background like daemon and that is only thing that blocking us for doing something in protected areas?

Next thing I will try later in hboot patching: going to edit "boot" partition, boot partition layout will be with next offsets: start->0x0, end->0x2820000 . Because boot partition is not protected for erasing/writing I will try to make that partition layout for boot partition in order to try if I can write to radio/hboot using these partition layout... in my first opinion after playing with disabling "hboot partition erase protection" I think that will be maybe possible :)... my idea is to use fastboot flash/erase command (without needs for using jtag) for installing diferent jtag dumps directly to 0x0 nand offset... so idea is making big boot partition that will start from 0x0 to 0x2820000 that will be maped for fastboot protocol as a normal boot partition so I can start writing/erasing to it... will let you know!
[HTC Wildfire S] no.human.being:
HBOOT will boot into the ROM when loaded to 0x9d000000. Perhaps it will load "stock" HBOOT to another address first, then execute it and this will in turn load the ROM. I have no way to determine what's actually going on. The only thing is that when you load HBOOT to 0x9d000000, hold Vol-Down, then start execution from 0x9d000000, it will load the ROM at some point. It won't enter HBOOT mode and there's no way to communicate to it via Fastboot this way. So something must be different than what is when HBOOT is loaded from NAND and executed.

If the offsets are correct, then it must be that some registers have different values than they do have when HBOOT just got loaded from NAND and that HBOOT checks for this.

Sounds a bit unlikely though, doesn't it? Remember HBOOT is the first firmware component running on aARM. When it gets booted, the state of the processor is likely undetermined and HBOOT is the component performing initialization. Wouldn't it be weird to do a decision straight from an "undetermined" state?

How could it run like a deamon? I think it loads a kernel into RAM and then branches into it. Running like a daemon would require some sort of "scheduler" allocating processing time to HBOOT and the kernel and doing context switches. Like if HBOOT contained another kernel on which Android is running like a process? I don't think that Linux (and therefore Android) can be run this way. Linux expects to be run in "supervisor mode", which is the highest mode of privilege on the ARM. Don't see how this would work. I'd say as soon as a kernel is loaded, HBOOT is "dead". Therefore my hypothesis is that the actual "memory protection mechanism" is actually implemented in the Radio (or inside what's beneath the Radio, see below), but is based on HBOOT's "discretion". Like HBOOT says "allow me to write here" or "disallow me to write here" and Radio intercepts write access to NAND by aARM.

This may work or it may not. The Radio will likely have its own "partition table". It depends on which level protection is enforced (per page or per partition) but I'm sure it's worth a try.

Remember that aARM does not see physical NAND. I have reason to believe that all firmware like REX and HBOOT run inside a virtual environment. When you map the Radio area of the NAND via Fastboot and dump it from within a recovery image, you will get different results than you get when dumping it via JTAG. What HBOOT/REX/Android see as "NAND" is not what's actually there. My hypothesis is that all read/write requests will get trapped by a lower-level firmware (some sort of "micro program") which then decides where to fetch/store data.
[HTC Wildfire S] Antagonist42:
This kinda thing may come in handy probably ;) it's ARMv5 Architecture ref manual, that's what I think N.H.B. is finding below the HBOOT etc.

As for addressing - depending what the address is for either data or commands, doesn't that dictate how the address is read? what with it being used with the ARM Thumb instruction set don't you end up with 16bit words as opposed to 32bit, you also have the the swapped high/low byte so would the address possibly be 0x00009d00?

Must admit .... dealing with highschool was easier than getting my head round this :eek: :laugh:
[HTC Wildfire S] munjeni:
I'm not sure about partition table inside radio firmware, but I'm 100% sure partition table is in hboot... see my latest project inside htc aria forum (tool for generating hboots with custom partition layouts)
[HTC Wildfire S] no.human.being:
This is a description of the ARM architecture. No idea where you read ARMv5. Anyhow, our MSM7227 is actually an ARM1136EJS, which is in ARMv6 architecture. I haven't found any datasheet for the ARM1136EJS though. However, there are datasheets for the ARM1136JS which should come close enough. Just search for "ddi0211k_arm1136_r1p5_trm", it's provided directly by ARM Ltd. (I hate how Google no longer provides true links to the sites, but links to Google itself that will in turn redirect to sites. You no longer have useful links to copy around.)

Well what I "manipulate" to get code loaded to different points in memory is a 32-bit word (it's not an instruction, it's really just a data word) and it's in little endian, so it reads "00 00 00 9d" (lowest to highest addresses) for 0x9d000000 (value in usual order, most significant digits to on the left hand side).
[HTC Wildfire S] munjeni:
progress:

Done! Instead of boot partition I played with recovery partition(which was now with new partition layout -> 0x0 to 0x2800000). One thing that I not had time for patching was bypassing ANDROID header that fastboot expect inside recovery.img. While writing to nand using fastboot write recovery jtag_dump.img got error "FAILimage error! (BootMagic check fail)" so its because jtag_dump.img not contain these header. But good thing is (with command fastboot erase recovery) I hard bricked my phone so it mean I sucesfully erased offset from 0 to 0x2800000 (radio, hboot...etc) :)... tomorrow I will connect device to jtag to verify if nand is realy erased and will try again... good thing is this way is possible !!!

Next idea is bypassing recovery header check:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 41 4E 44 52 4F 49 44 21 7C 81 1D 00 00 80 C0 12 ANDROID!|....€Ŕ.

to new header (thats first 8 butes from radio (offset 0x0 to 0x8)):

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

00000000 D1 DC 4B 84 34 10 D7 73 5A 43 0B 7D FF FF FF ŃÜK„4.×sZC.}˙˙˙

and I think jtag_dump.img will be aceptable in flashing procedure :):)
[HTC Wildfire S] :
You have to brick your phone to test things. Well this desires huge respect. I wouldn't do it. Unbricking shouldn't be too hard I guess. Good luck anyways.

sent from my WFS running MIUI V4
[HTC Wildfire S] Antagonist42:
Reason I was thinking ARMv5 is that modem is booting the phone up before HBOOT etc kicks in so would it be feasible that it can be an influence on writing to NAND?

What I have read is that ARM11 is forward compatible with ARMv7 instructions (not all) so i'm on the hunt for info on that if I can find it for free ;)

I'll check what I got for ARM11 but the docs for boot etc for Qualcomm are def secured and not out on the net that we could really do with :(

WILL THIS DO? ARM9EJ-S Tech Ref ----Hit him on the head for getting ahead of himself!!!

Added a couple docs for ARM and a JEDEC doc here

I'm beginning to wonder if the ARM1136EJ-S is just a crossover chip seeing as ARM still have up in the news room!! both the ARM926EJ-S and ARM1136EJ-S are named there, as there seems to be little or no data on the ARM1136EJ-S i'm suspecting it may well have the v5TEJ Architecture. trying to find the ARM Naming System for chips is a bit hit and miss and I suspect as they are so 'flexible' seeing as the 1136JF-S/J-S cores are superseded and use v7 now not v6 as was previous. The Prefix 'E' from what I can gather is for the DSP, 'J' is the Jazelle, 'F' is for Floating Point Co-processor but still not found anything relating to the -S other than the 'SecureCore' which seems to have come in with ARM7 or the start for the ARM11 series of SIMD (Single Instruction Multiple Data) so a data sheet for 'that specific chip' may depend on how much Sun Microsystems have a hand in it's design maybe :rolleyes:
[HTC Wildfire S] theq86:
Hope you have backups and are able to recover it via jtag to unbrick :)

if you really managed to erase radio area, we're probably almost done. we just had to limit the erasure to the blocks we want to rewrite and afterwards write it.
[HTC Wildfire S] :
Afaik shouldn't we be able to bypass the header and just flash a whole partition that's patched. I thought fast boots job was to flash mtd easily for us
[HTC Wildfire S] munjeni:
My idea... not working! :( it still erase (not completelly) offset 0 to 0x2840000 but after writing data is BIG corupted!
[HTC Wildfire S] no.human.being:
Does Fastboot take the out-of-band data from images (might explain why it gets corrupted - out-of-band is not dumped with a normal read operation on the mtd and we're currently not able to patch an HBOOT image that includes out-of-band data) or does it expect images with "payload" only and generates the out-of-band on the fly?
[HTC Wildfire S] no.human.being:
How do you establish the connection to the Radio?

$ sudo ./fastboot oem heap
...
(bootloader) Total free heap size: 486488908 Bytes (0x1CFF3B4C)
(bootloader) Max. free heap segment size: 486481920 Bytes (0x1CFF2000)
(bootloader) Max. free NPC heap segment size: 486481920 Bytes (0x1CFF2000
(bootloader) )
OKAY [ 0.017s]
finished. total time: 0.017s
$

So phone is responding.

$ lsusb
...
Bus 001 Device 009: ID 0bb4:0ff0 High Tech Computer Corp.
...
$

So we got device and vendor id.

$ sudo modprobe usbserial vendor=0x0bb4 product=0x0ff0
$ ls /dev/tty*
/dev/tty /dev/tty19 /dev/tty3 /dev/tty40 /dev/tty51 /dev/tty62
/dev/tty0 /dev/tty2 /dev/tty30 /dev/tty41 /dev/tty52 /dev/tty63
/dev/tty1 /dev/tty20 /dev/tty31 /dev/tty42 /dev/tty53 /dev/tty7
/dev/tty10 /dev/tty21 /dev/tty32 /dev/tty43 /dev/tty54 /dev/tty8
/dev/tty11 /dev/tty22 /dev/tty33 /dev/tty44 /dev/tty55 /dev/tty9
/dev/tty12 /dev/tty23 /dev/tty34 /dev/tty45 /dev/tty56 /dev/ttyS0
/dev/tty13 /dev/tty24 /dev/tty35 /dev/tty46 /dev/tty57 /dev/ttyS1
/dev/tty14 /dev/tty25 /dev/tty36 /dev/tty47 /dev/tty58 /dev/ttyS2
/dev/tty15 /dev/tty26 /dev/tty37 /dev/tty48 /dev/tty59 /dev/ttyS3
/dev/tty16 /dev/tty27 /dev/tty38 /dev/tty49 /dev/tty6
/dev/tty17 /dev/tty28 /dev/tty39 /dev/tty5 /dev/tty60
/dev/tty18 /dev/tty29 /dev/tty4 /dev/tty50 /dev/tty61
$

No "/dev/ttyUSB*" device though.
[HTC Wildfire S] munjeni:
You need to blacklist qcserial, or just simply unload these module every time before you modprobe usbserial:

sudo modprobe -r qcserial

than:

sudo modprobe -r usbserial

sudo modprobe usbserial vendor=0x0bb4 product=product_in_hboot_mode

but you must to know when phone is in fastboot mode you can not see ttyUSB0 !!! You need to enter phone in hboot mode to get it working!

For gobi interface(ttyUSB2) you need to send rtask c to ttyUSB0 (when phone is in hboot mode):

echo "rtask c" >/dev/ttyUSB0

than your usbserial will automaticaly disconect from ttyUSB0 and you will see new devices (ttyUSB1 and ttyUSB2), than with lsusb you will see what you need to modprobe again in order to connect to gobi (ttyUSB2)...

Allways after modprobe see if generic usb serial is connected because qcserial not working... by command: dmesg | grep ttyUSB... you will see something like: generic usb serial is now connected to yttyUSB*...
[HTC Wildfire S] no.human.being:
Device in HBOOT (not Fastboot) mode.

$ lsusb
...
Bus 001 Device 009: ID 0bb4:0c94 High Tech Computer Corp. Vision
...
$ sudo modprobe -r qcserial
$ sudo modprobe -r usbserial
FATAL: Module usbserial is builtin.
$ sudo modprobe usbserial vendor=0x0bb4 product=0x0c94
$

No ttyUSB device though. "dmesg | grep ttyUSB" does not return anything.
[HTC Wildfire S] munjeni:
Try:

rmmod qcserial

rmmod usbserial
[HTC Wildfire S] no.human.being:
No chance.

$ sudo rmmod qcserial
Error: Module qcserial is not currently loaded
$ sudo rmmod usbserial
Error: Module usbserial is in use
$ sudo rmmod -f usbserial
Error: could not remove module usbserial: No such file or directory
$ sudo modprobe usbserial vendor=0x0bb4 product=0x0c94
$

No "/dev/ttyUSB*".

I suspect that my kernel doesn't have "usbserial" support, since modinfo doesn't work on it.

$ modinfo usbserial
ERROR: Module usbserial not found.
$

Or is that just because "usbserial" is builtin and not a module?
[HTC Wildfire S] munjeni:
Hmmm, I had the same problem like you (tried 5-6 linux distros without succes to get ttyUSM0) but now I think I fixed (no such file ttyUSB0) by blacklisting qcserial and adding to udev rules:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bb4", ATTRS{idProduct}=="0c01", MODE="0666", OWNER="root"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bb4", ATTRS{idProduct}=="0fff", MODE="0666", OWNER="root"

EDIT:

I think you are right (module is needed instead of builtin module)... see whats in my machine with modinfo usbserial:

root@server:~# modinfo usbserial
filename: /lib/modules/3.2.0-23-generic/kernel/drivers/usb/serial/usbserial.ko
license: GPL
description: USB Serial Driver core
author: Greg Kroah-Hartman, greg@kroah.com, http://www.kroah.com/linux/
srcversion: 02286F34E2B54697D9F8680
depends:
intree: Y
vermagic: 3.2.0-23-generic SMP mod_unload modversions
parm: vendor:User specified USB idVendor (ushort)
parm: product:User specified USB idProduct (ushort)
parm: debug:Debug enabled or not (bool)
root@server:~#

I'm runing ubuntu 64:

root@server:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.04 LTS
Release: 12.04
Codename: precise
root@server:~# uname -v
#36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012
root@server:~# uname -r
3.2.0-23-generic
[HTC Wildfire S] The.Org.Ian:
Any progress?:)
[HTC Wildfire S] The.Org.Ian:
Isn't it a way to find out how the xtc clip does it an make so kind of software, that does the same? ;)
[HTC Wildfire S] csoulr666:
This idea has been thought a long time ago.......it just didn't work
[HTC Wildfire S] no.human.being:
Well obviously the xtc-clip works. However, the idea has been dismissed since it's not our goal.

The xtc-clip makes use of an internal diagnostic utility that requires a special "whitecard" (or "engineering smartcard") for authentication and will then allow certain modifications to the phone (e. g. SIM unlock, S-OFF, CID change and so on). The xtc-clip emulates this smartcard via a microcontroller embedded in the clip's housing running suitable firmware. For a CDMA phone, I think all you need is a copy of the diagnostic utility put on a MicroSD and you can turn the phone S-OFF. However, GSM phones are a bit more secured (don't ask me why this is so - it's a bit illogical since you can do more "harm" by modifying the firmware of a CDMA phone than modifying the firmware of a GSM phone since on a CDMA phone your identity is bound to the phone firmware, while on a GSM phone it is bound to the SIM card - yet the GSM phones have stronger security in place) and there is no way to do it without the smartcard.

We're striving for a software-only solution here, so emulating the smartcard is not an option. If you want S-OFF via smartcard, then please pay for an xtc-clip. The circuit and firmware of the xtc-clip has been reverse-engineered, but you still need the microcontroller (and some auxiliary circuitry) to run it and microcontrollers and printed circuit boards are only cheap in large quantities, so any "do-it-yourself-xtc-clip-replica" will probably be more expensive than the regular price for an xtc-clip. It's just not worth it. You either wait until we can do it in software (replicating software is free) or you pay for an xtc-clip or you get it done at a phone shop that has an xtc-clip and unlocks phones for a fee.

It's such a pity that the processor's JTAG levels are so low. With JTAG access we could verify what happens when HBOOT loads a kernel via Fastboot. I do not understand why "chainloading" a patched HBOOT image via Fastboot does not work. I thought that HBOOT loaded the kernel to a certain address in RAM and then jumped to that address, executing the first instruction. If this was how it is done, it should be possible to load a modified HBOOT to 0x9d000000 (which is the address in RAM where HBOOT expects to be loaded) and then execute it but if you try it, it will "abort" at some point, restore the regular HBOOT from NAND again and load and execute that. Or perhaps there's something bad hapenning because we overwrite HBOOT itself, which is the code that's currently executing in this state. I find the latter scenario unlikely though, since we overwrite most of it with the same values which are already in memory, so the write operations shouldn't change much. The only thing we change are the routines that we believe are enforcing the protection and these should not be executing while loading a boot image via Fastboot. I really don't understand why this fails. I somehow doubt that the boot code is protected against overwriting it in RAM via a Fastboot instruction. I doubt that most developers would even think of this possibility, let alone care to protect against it.
[HTC Wildfire S] pihug12:
Could there be a checksum check of the "patched 512KB HBOOT" that failed (CRC32, MD5...) ? It seems impossible that this kind of check exists, because Revolutionnary patches only this same routine.

If we extract the HBOOT and we modify a single bit, let's say the version number ("1.09.0099" => "1.09.0098" for example), and then we flash it via Fastboot. Which version will show up in the end ?
[HTC Wildfire S] :
I'm afraid that I can no longer be part of this campaign. Yes, it's not like I helped (other than supplying my radio image leading to the discovery of my weird memory layout). But I liked being here anyway. My WFS was stolen, so now this S-OFF thing is pointless to me. Sorry.
[HTC Wildfire S] no.human.being:
You canot flash a modified HBOOT while the "original" HBOOT is booted on the phone because the "original" HBOOT will check the signature of the image and this will obviously fail.

$ sudo ./fastboot flash hboot hboot.img
sending 'hboot' (512 KB)...
OKAY [ 0.145s]
writing 'hboot'...
(bootloader) signature checking...
FAILED (remote: signature verify fail)
finished. total time: 8.401s
$

If you carefully pay attention to what the phone is doing while trying to "chainload" a modified HBOOT via Fastboot, you will notice that the phone will show the progress bar in the bootloader indicating that code is transferred into memory via Fastboot. Then it will vibrate and show the "HTC" logo on the display. Then it will turn the display off, vibrate again, turn the display on again, show the "HTC" logo and boot into your ROM. So it will do the "vibrate -> show HTC logo" thing exactly two times before booting into the ROM and turn the display off and on again between the two vibrations. This might be an indicator that the modified HBOOT actually gets executed, tests the vibration unit and shows the HTC logo, then somehow notices that "something is wrong", resets the processor (which might be why the display is turning off and on again) and then boot is done normally from NAND by stock HBOOT, which tests the vibration unit and shows the HTC logo a second time.

We'd have to know which checks HBOOT performs when booting the phone. It might be that certain registers are guaranteed to be in a certain state when the processor is powered up, the first HBOOT that boots from the phone NAND modifies these values and the second one then notices these changes and knows that code has already been executed on the processor before it was loaded, causing it to enter some "failover state" which issues a reboot from NAND. I think we can remove these checks by overwriting them with no-op statements, but of course we'd have to find out where they are performed. I'm gonna "objdump" my HBOOT now.

Another opportunity would be finding how HBOOT authenticates with the Radio to get the NAND unlocked and then implement the "msm_lock()" and "msm_unlock()" functions in the "msm_nand" driver inside the kernel to fake this authentication and request the Radio to do the unlocking. This should enable us to write to the Radio area (including HBOOT) from within Android. This was the way security was broken on the Evo. However, the problem is that we don't have enough kernel devs to get this done. I think we need some kind of "a second Alquez". The "original" is obviously too busy with CM (which is good - I think good ROMs are more important than true S-OFF now that HTC has unlocked its bootloader).
[HTC Wildfire S] iuss:
Try 0x00000000 instead. 0x9d000000 is probably a virtual address. Yes, hboot executes from it, but only after it has configured the mmu.

If that doesn't work, find the page table layout in hboot and check what 0x9d000000 is actually mapped to.
[HTC Wildfire S] no.human.being:
Wait! HBOOTs task is to load an operating system kernel (and optionally an initrd) from NAND to RAM and pass execution to it. Why would it set up the MMU? Won't Android's Linux kernel expect a flat, physical address space when loaded and set up the MMU on its own at some point?

But yes, you're right. 0x9d000000 sounds quite "virtual" given that we have 512 MiB of RAM, which should be 0x00000000 to 0x1fffffff physical.
[HTC Wildfire S] kalaker:
I think we're far past trying to figure out what things should or shouldn't expect. I think if it hasn't been tested, try it! It can't hurt!
[HTC Wildfire S] no.human.being:
I'm quite sure that I've already tested it and if I remember correctly it locked up the phone so that you couldn't even shut it down, you needed to pull the battery out.

Mind that we pass the address in the header of a boot image supplied to the "original" HBOOT via Fastboot. It sounds a bit strange that a physical address is expected here. Won't the MMU already be set up at this point? Or will HBOOT make the address space "flat" again when booting an image given that a "flat" address space is probably what Android's Linux kernel expects?

EDIT: You are right that the physical address is required in the boot image. It's defined in the "bootimg.h" as ...

unsigned kernel_addr; /* physical load addr */

However, loading HBOOT to 0x00000000 doesn't change anything. Two times the "HTC" screen, then booting into ROM, even though Vol-Down is held.
[HTC Wildfire S] :
Anyone know how to sign a IMG file. I have some leaked HTC keys you can try
[HTC Wildfire S] theq86:
the keys that simonsimons has are unfortunately not useful. they are public keys.

these are probably keys found on some device. I had a look at them som time ago.

the needed private keys are unlikely to be on a phone