[Barnes & Noble Nook Tablet] hkvc:
BYPASS Kernel and Ramdisk check for People with UART ACCESS

Hi,

NOTE: THis is based on a initial look at the source code and then the objdump of u-boot.bin. I haven't cross checked this yet, because for now I haven't opened up the nooktab for uart access yet. Also this assumes by default booti command is used for booting in BN uboot. If some one wants to use bootm, then a different location requires to be patched wrt the image loading security check.

If you are a lucky ;-) person working with opened up NookTab with UART access, then basically replacing the memory contents of these two offsets with NOP will 90% BYPASS the security check successfully and allow you to boot a MODIFIED KERNEL or RAMDISK as required.

All offsets specified Assuming u-boot is loaded at 0 (adjust for the actual address where u-boot.bin is loaded, haven't looked into that yet).

Check for Security check of Kernel image is at

[ORIG] 0x48c0 => bne 0x48d8 (0x1a00.0004)

Make this a NOP by overwriting using uboot memory write command to

[MODI] 0x48c0 => mov r0, r0 (0xe1a0.0000)

Check for Security check of RAMDisk image is at

[ORIG] 0x4928 => bne 0x4958 (1a00.000a)

Make this a NOP by overwriting with

[MODI] 0x4928 => mov r0, r0 (0xe1a0.0000)

Someone (Hi Adamoutler, maybe you) with opened up NookTab can try this and tell me if it worked or not.

NOTE: you have to add up the actual u-boot load address to the offsets specified.

UPDATE1: It appears the load address is either

Possibility 1) 0x80e8.0000 OR

Possibility 2) 0x80e8.0000-0x120 (More likely).

Have to dig thro bit more, but one of these two will potentially work.

So that means to NOP RAMDisk security check the offset is

Possibility 1 ==> 0x80e8.0000+0x4928

Possibility 2 ==> 0x80e8.0000-0x120+0x4928 (More likely)

Best is to cross check if the resultant address contains the BNE instruction bytes specified above.

Same concept applies for the Kernel security check Nopping offset.

NOTE: It appears there is a 0x120 size header before the actual u-boot.bin code starts and in turn, when I did the objdump, it included the 0x120 bytes of header also assumed as code. And inturn the full (including the header) u-boot.bin or for that matter the u-boot from emmc seems to load into 0x80e8.0000-0x120.

UPDATE 2:

Code around the locations to be noped to help identify the same in memory, in case my offset calculations are wrong

48b4: eb0030f1 bl 0x10c80

48b8: e59d3010 ldr r3, [sp, #16]

48bc: e3530000 cmp r3, #0

48c0: 1a000004 bne 0x48d8

48c4: e59f0104 ldr r0, [pc, #260] ; 0x49d0

48c8: e594100c ldr r1, [r4, #12]

48cc: e5942008 ldr r2, [r4, #8]

48d0: eb0015db bl 0xa044

............

491c: eb0030d7 bl 0x10c80

4920: e59d3010 ldr r3, [sp, #16]

4924: e3530000 cmp r3, #0

4928: 1a00000a bne 0x4958

492c: e59f00a4 ldr r0, [pc, #164] ; 0x49d8

4930: e5941014 ldr r1, [r4, #20]

4934: e5942010 ldr r2, [r4, #16]

4938: eb0015c1 bl 0xa044

UPDATE 3: ... for a rainy day in future ;-)

UPDATE 4: For maximum success, first try a changed RAMDisk rather than Changed Kernel. If Changed Ramdisk works then try Changed Kernel (THere is one more thing in Code, which I am not sure if it will impact a modified kernel or not yet, only way is to experiment).