nhb please share the binary you are loading, seems your hboot simply needs to be hacked to stay in bl/fb mode
"loader.bin" is the exploit code.
"hboot_109.img" is the (hacked) HBOOT-1.09.0099 (shell code).
"chain_109.img" is an Android boot image for the WFS containing the concatenated "loader.bin" + "hboot_109.bin" as kernel and an empty (0 byte) initrd.
Key is the same as previous archive and will arrive via PM.
If you know what to change, please let me know.
Thanks for contributing.
EDIT: bgharz16 has just asked me how to analyze HBOOT images. I'm gonna post this in public in case anyone else wants to know as well.
The HBOOT image is raw machine code from the first to the last byte. No headers or other data structures, nothing. It begins with the bytes "12 00 00 ea", which is the instruction 0xea000012 or "b 0x50" disassembled, an unconditional branch instruction to address 0x50 physical).
In a hex editor I'd search for the string "1.09.0099" (or whatever HBOOT version you're analyzing). You'll find it at offset 0x4. Then just change it, but be careful to overwrite in-place only. Never "insert" or "remove" something as this will mess up all the addresses so that branch instructions will miss their target etc.
To understand the code, you'll want to put the HBOOT image through an ARM disassembler, e. g. "arm-none-eabi-objdump -D -b binary -m armv5 hboot_109.img > hboot_109.s" will disassemble the "hboot.img" into a file called "hboot.s" containing the corresponding assembler source. Mind that this is machine code, so there are no loops and conditions and function calls and other flow-control, there's just conditional branches. There are also no variables, just registers. It won't be easy to read, but that's just how it is. It's boot code so it's very low-level.
For example the first instruction you see in HBOOT-1.09.0099 is the following.
Code:
0: ea000012 b 0x50This is where execution begins. It immediately branches to 0x50. There it does some very obscure "bashing" that performs some low-level configuration for the ARM. Then it performs a "branch with link" to 0x410. A "branch with link" is usually a subroutine call, but in this case the subroutine is not expected to return.
Code:
94: eb0000dd bl 0x410There a lot of stuff is done. The interesting thing is from 0x4d4.
Code:
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, r0It loads the value from 0x4ec into register r0 ("ldr ..." = load register), then does some comparison ("cmp r0, #0" = compare register 0 to the value 0) and some more "bashing" ("mcr ..." .. mmh not sure about that .. move coprocessor register?!) and then it moves the content of register r0 into the program counter pc ("mov pc, r0" = move register 0 into the program counter). So the value from 0x4ec ends up in the program counter and execution will continue there. What value is at 0x4ec?
Code:
4ec: 9d000800 stcls 8, cr0, [r0, #-0]Ah the value is 0x9d000800. This is a virtual address and it corresponds to 0x800 physical. Let's see what's there.
Code:
800: ea000001 b 0x80c
804: 9d0738a4 stcls 8, cr3, [r7, #-656] ; 0xfffffd70
808: 9d07ccc8 stcls 12, cr12, [r7, #-800] ; 0xfffffce0
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 0xbc8This zeroes the area from 0x9d0738a4 (inclusive) to 0x9d07cc8 (exclusive) word by word, 4 bytes at a time. This is the BSS segment. Then it branches to 0xbc8. This is sub "main".
This is how you analyze an HBOOT image. If you want to change something, just change it. Keep in mind that all words start at an address that's a multiple of 4 and are always 4 bytes (32 bits) long. They are also stored as "little endian" values, which means that if you read the bytes "12 34 56 78" in a hex editor, this will decode to 0x78563412 for the processor (bytes in a word are read "right to left", but the bits inside each byte stay in the right place). The disassembly will also show 0x78... in this case.
Last edited:
