[Barnes & Noble Nook Tablet] hkvc:
>>> With UART access NookTab Secure BOOT Chain as been FULLY BROKEN, Custom Kernel and Custom Ramdisk have been succesfully run on NookTab, Look towards 2nd page or so for full info <<<

Hi,

Few days back I had got an idea to try and see if we can BYPASS the boot security chain by replacing the bootloader in memory, because NOOKTAB allows UART ACCESS to UBOOT.

My initial thought was to use a replacement UBOOT without Security checks. However on further thought, as UBOOT has memory access commands, I realised the simpler solution is to edit the UBOOT code directly in memory from UBOOT prompt itself.

In turn I had posted the concept and the commands to try and do the same on the below two threads, for people to try. However as no one seems to have tried it yet, I myself opened up the my NookTab and connected the UART signals and am continuing my experiments and the initial results are promising.

FINDING1: The MShield security logic doesn't mind if one modifies the UBOOT CODE. I was able to NOP the security check result logic check and the code continued to boot.

Next I have to try a modified RAMDisk and see it works fully.

My earlier posts on this can be got from these two threads

http://xdaforums.com/showthread.php?t=1378886

http://xdaforums.com/showthread.php?t=1418172

For someone interested in experimenting with this below are the commands to try on UART of NOOKTAB.

uboot Command summary

---------------------------------------

md.l address_in_Hex ---------- To cross check the memory content before overwriting (should match what I have mentioned as ORIG)

mw.l address_in_Hex 4ByteValueInHex -------------- To modify the given address location with new value

md.l address_in_Hex -------------- To cross check that the new value you have written has come properly.

Command sequence for Ramdisk check bypassing

-----------------------------------------------------------------------------

UBOOTPROMT> md.l 80e84808 ----- This should show 1a00000a

NOTE: I have verified that the 2nd possibility mentioned in my earlier post i.e 0x80e8.0000-0x120 is the load address to use to calculate the offsets.

next run

UBOOTPROMPT> mw.l 80e84808 e1a00000 ------------- This modify with NOP

Next run

UBOOTPROMPT> md.l 80e84808 ------ should show e1a00000

Next if you have updated the recovery.img with new ramdisk into /recovery partition RUN

UBOOTPROMPT> mmcinit 1; booti mmc1 recovery

HOWEVER instead if you have updated the flashing_boot.img file with new ramdisk in microSD then RUN

UBOOTPROMPT> mmcinit 0; fatload mmc 0:1 0x81000000 flashing_boot.img; booti 0x81000000

Now it should boot with out giving a signature error.

NOTE1: I have verified that changing the contents of UBOOT (i.e NOPing) in itself doesn't lock the ARM, next I have to try a updated ramdisk and see what happens. If you ask me It should work, fingers crossed, I will try and update.

NOTE2: In any android img file at offset 0x10 (i.e 16) the ramdisk size is stored as a 4 byte (long) value. Cross verify first that the original img and the ramdisk size at offset 0x10 in it matches the original ramdisk. Then update the 0x10 offset of new img file with new ramdisk's size.

NOTE3: kernel security check bypass address = '0x80e847a0'