[removed]

→ **MyCalcs** profile · by **critor** » 21 Jan 2018, 20:49

Seems to be a mapping problem, yes.

In the nBoot/ControlX context, adding a breakpoint on the Boot1 read_nand() syscall works perfectly :

Code: Select all: Breakpoint at 0x10000034 >k 0000b164 +x >k 0000b164 x 10000034 x >c Breakpoint at 0x0000b164

→ **MyCalcs** profile · by **critor** » 21 Jan 2018, 22:21

Ok, managed to get it.

And yes, read_nand is crashing :

Code: Select all: 0000b168: e24dd014 sub sp,sp,00000014 0000b16c: e1a04002 mov r4,r2 0000b170: e5dd2038 ldrb r2,[sp + 038] 0000b174: e1a07000 mov r7,r0 0000b178: e3a00004 mov r0,00000004 0000b17c: e1a06001 mov r6,r1 0000b180: e1a09003 mov r9,r3 0000b184: e58d2004 str r2,[sp + 004] 0000b188: e59da03c ldr r10,[sp + 03c] 0000b18c: ebfff596 bl 000087ec [...] Warning (000107b8): Data abort: address=0ffffff8 status=05 instruction at 000107b8

→ **MyCalcs** profile · by **critor** » 21 Jan 2018, 23:23

Not sure if it could be possible to reinit the NAND.

Here are some Boot1 3.0.0.99 NAND-related syscalls :

Code: Select all: k 988 +x //setup_clocks_nand k 6660 +x //nand_read_header k 7178 +x //read_nand_header k 87BC +x //nand_partition_size k 87EC +x //nand_partition_start k 8818 +x //nand_add_partition k 8B64 +x //get_nand_drv / get_nand_driver k 8B70 +x //deinit_delete_nand_driver k 8B7C +x //initNAND / create_initialize_nand_driver k 8BAC +x //nand_driver_initialize k 8C9C +x //nand_drv_handler / nand_driver k 9054 +x //ioc_nand_erase / nand_erase_range k 9098 +x //write_nand k 90E0 +x //ioc_nand_read / read_nand k 9138 +x //nand_print_bad_block_list k 91C0 +x //nand_install_debug_print_function k 91E8 +x //nand_is_block_bad k 9214 +x //nand_erase_block_if_good k 924C +x //nand_write_page k 928C +x //nand_get_block_start k 92CC +x //nand_name / nand_get_chip_name k 92F8 +x //nand_get_number_of_blocks k 9324 +x //nand_get_pages_per_block k 9350 +x //nand_get_spare_bytes_per_page k 937C +x //nand_block_size / nand_get_pagesize k 93B0 +x //nand_get_block_size k 93C8 +x //nand_read_page / nand_read_page k 94D0 +x //nand_erase_block k 9DB4 +x //nand_print_badblocks k 9E48 +x //nand_wait_ready k 9E60 +x //nand_set_page k 9F2C +x //nand_read_word k A05C +x //nand_writable_stuff_handler k A76C +x //nand_set_cycles k B11C +x //_nand_erase_range k B164 +x //nand_read / _read_nand k B464 +x //write_nand / _write_nand k B610 +x //nand_page_size k B628 +x //get_nand_spare_bytes k B670 +x //nand_size k D350 +x //nand_writable_stuff k 19748 +x //print_nand_id / print_nand_fash_id k 199F8 +x //nand_read_first_page k 1CB1C +x //nand_partitiontable_ptrs k A4000898 +x //nand_partitiontable_classic k A40008C0 +x //nand_partitiontable_cx k A40008E8 +x //nand_drv k A40008F4 +x //maybe_nand_initialized k A4000934 +x //nand_struct k A4000948 +x //nand_page_log2 k A400094C +x //_nand_spare_bytes k A4000950 +x //_nand_page_count k A4001E28 +x //nand_initialized k A4001FC8 +x //nand_page_log2_0 k A4001FCC +x //nand_spare_bytes k A4001FD0 +x //nand_page_count

The Boot1 seems to call in order :
- create_nand_driver
- get_nand_driver (parameters unknown, if any)
- init_nand_driver

Code: Select all: void (*create_nand_driver)()=(void*) 0x8b7c; void (*get_nand_driver)()=(void*) 0x8c9c; void (*init_nand_driver)()=(void*) 0x8bac;

→ **MyCalcs** profile · by **critor** » 22 Jan 2018, 00:05

More precisely :

Code: Select all: Boot Loader Stage 1 (3.00.99) Build: 2010/9/9, 17:29:13 Copyright (c) 2006-2010 Texas Instruments Incorporated Using production keys Last boot progress: 65 Available system memory: 33196 D350 // nand_writable_stuff D350 // nand_writable_stuff D350 // nand_writable_stuff D350 // nand_writable_stuff Checking for NAND: 8B7C // initNAND / create_initialize_nand_driver 8C9C // nand_drv_handler / nand_driver A76C // nand_set_cycles 8BAC // nand_driver_initialize 9E48 // nand_wait_ready D350 // nand_writable_stuff 8B64 // get_nand_drv / get_nand_driver 8C9C // nand_drv_handler / nand_driver 91C0 // nand_install_debug_print_function 8B64 // get_nand_drv / get_nand_driver 8C9C // nand_drv_handler / nand_driver 19748 // print_nand_id / print_nand_flash_id NAND Flash ID: 92CC // nand_name / nand_get_chip_name 8B64 // get_nand_drv / get_nand_driver 8C9C // nand_drv_handler / nand_driver Generic 1 GBit (0xA1)

→ **MyCalcs** profile · by **parrotgeek1** » 22 Jan 2018, 00:10

Try to find them inside boot1.5 4.4.0.8, then maybe you can call *that* read_nand

(It would be advisable to copy the first 0x1F04 bytes of boot1.5 back, to undo the corruption)

→ **MyCalcs** profile · by **critor** » 22 Jan 2018, 18:55

Could you check how to add a correct size to your 0x8000 HHackers!, so that BtMg is going to flash your image correctly ?

Another possibility is to package your image with a Boot1.5 image instead of a Boot2 image, much smaller. Boot1.5 also has the nand_read/write syscalls.
Like ControlX, your code could then look in the Boot2/Diags/ExtnD partitions for an appropriate Boot2 image to load the OS, and patch it the way it wants.

Are you sure that the installed Boot1.5 read/write_nand syscalls don't work in the context of your exploit ?
(are corrupted, or use variables which have been corrupted)

→ **MyCalcs** profile · by **parrotgeek1** » 22 Jan 2018, 23:01

critor wrote:Could you check how to add a correct size to your 0x8000 HHackers!, so that BtMg is going to flash your image correctly ?

If I do that, the exploit doesn't work

→ **MyCalcs** profile · by **parrotgeek1** » 23 Jan 2018, 03:33

There is a strange problem with the exploit on boot1 4.0.1. It restarts the exploit, and then claims "wrong boot2 version". The same file works on 3.0.0.99. It works, strangely, if you run boot1 4.0.1 but DO NOT pick HW-W in firebird (but with corrupted graphics).

Code: Select all: EXPLOIT: Created by parrotgeek1. Compiled: Jan 22 2018 12:41:51 EXPLOIT: Created by parrotgeek1. Compiled: Jan 22 2018 12:41:51 CAS OS mode Wrong boot2 version

Can anyone help me debug this?

→ **MyCalcs** profile · by **critor** » 23 Jan 2018, 10:16

A more complete bootlog would help.

I don't even know in which context you're getting this (Boot1 since you're mentioning it ? Boot1.5 ?...)

As far as I know Boot1 4.0.1 still boots old 3.x Boot2 images, so I never saw it complaining about a wrong boot2 version.
And unless I made an error, no "...Wrong..." string is visible in Boot1 4.0.1 or in decompressed Boot1.5 4.4.

→ **MyCalcs** profile · by **parrotgeek1** » 23 Jan 2018, 10:45

critor wrote:A more complete bootlog would help.

I don't even know in which context you're getting this (Boot1 since you're mentioning it ? Boot1.5 ?...)

As far as I know Boot1 4.0.1 still boots old 3.x Boot2 images, so I never saw it complaining about a wrong boot2 version.
And unless I made an error, no "...Wrong..." string is visible in Boot1 4.0.1 or in decompressed Boot1.5 4.4.

All of that output is generated by "nanoloader" in my repo, not by boot1/1.5.

On boot1 3.0.0.99 it works fine.

On boot1 4.0.1 it doesn't. After the first line of output, it jumps BACK to 111e0000, starts over, and then thinks that the patched boot2 included in the exploit is not 4.0.3 (it is; this exact image works fine on 3.0.0.99).

The first line of output is only supposed to appear once.