How to Listen to Beats 1 on Android Right Now

If you felt a bit left out by Apple launching their own online radio station Beats 1 … more

NVidia SHIELD TV – XDA TV Device Review

The SHIELD TV is a not an Android smartphone device. However, that doesn’t mean it … more

PSA: Having cellular connectivity or texting issues tonight?

You’re not alone…Tonight, many users are experiencing a myriad … more

Beats Music No Longer Accepting New Accounts

Whenever Apple launches a new product or service, it definitely manages to grab the … more

[DONE] NOP based Boot security chain FULL BYPASS with UART access

83 posts
Thanks Meter: 252
By hkvc, Member on 3rd January 2012, 06:49 AM
Post Reply Subscribe to Thread Email Thread
>>> 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 <<<


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

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'
Last edited by hkvc; 4th January 2012 at 10:52 AM. Reason: android img ramdisk_size offset, kernel check addr
The Following 15 Users Say Thank You to hkvc For This Useful Post: [ View ]
3rd January 2012, 07:06 AM |#2  
OP Member
Thanks Meter: 252
Wink [REPOSTING OLD, CONCEPT] BYPASS Kernel and Ramdisk check for People with UART ACCESS
>>> This was my original post to the other two threads on this concept, I have put this here for completeness. The load address confusion which I had is already resolved <<<


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.


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).

UPDATE 5: I have cross verified on the target with UART access and the 2nd possibility mentioned above wrt load address is what is correct.
Last edited by hkvc; 3rd January 2012 at 07:10 AM.
The Following User Says Thank You to hkvc For This Useful Post: [ View ]
3rd January 2012, 07:12 AM |#3  
OP Member
Thanks Meter: 252
Post android img header structure for reference
from tools/mkbootimg/bootimg.h

#define BOOT_NAME_SIZE 16
#define BOOT_ARGS_SIZE 512

struct boot_img_hdr
unsigned char magic[BOOT_MAGIC_SIZE];

unsigned kernel_size; /* size in bytes */
unsigned kernel_addr; /* physical load addr */

unsigned ramdisk_size; /* size in bytes */
unsigned ramdisk_addr; /* physical load addr */

unsigned second_size; /* size in bytes */
unsigned second_addr; /* physical load addr */

unsigned tags_addr; /* physical addr for kernel tags */
unsigned page_size; /* flash page size we assume */
unsigned unused[2]; /* future expansion: should be 0 */

unsigned char name[BOOT_NAME_SIZE]; /* asciiz product name */

unsigned char cmdline[BOOT_ARGS_SIZE];

unsigned id[8]; /* timestamp / checksum / sha1 / etc */
The Following 2 Users Say Thank You to hkvc For This Useful Post: [ View ]
3rd January 2012, 10:26 AM |#4  
OP Member
Thanks Meter: 252

By BYPASSING both the Kernel and Ramdisk checks using NOPs, I am able to run the kernel (not modified, but repackaged, so bypassed Kernel sec check) and modified ramdisk.

However either

a) I seem to have done something wrong OR

b) Secure boot chain is doing something internally before passing control to uboot during kernel sec check, which is different between a successful call and a bad call.

Because the kernel crashes after control passes to it, almost immidiately.

NOTE: Have to try with only ramdisk change ...

The UART Dump of my run is given below.

OMAP44XX SDP # booti 0x81000000
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
kernel @ 80088000 (2689312)
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
ramdisk @ 81080000 (513429)
Initrd start : 81080000 , Initrd end : 810fd475Acclaim Board.

Starting kernel ...

undefined instruction
pc : [<800886e4>] lr : [<80e930c0>]
sp : 80e3fac4 ip : 00028f05 fp : 80eabe44
r10: 810fd475 r9 : 80eb1fb8 r8 : 80e3ffdc
r7 : 80088000 r6 : 00000000 r5 : 80e3ffb4 r4 : 80eb1fb8
r3 : 00000000 r2 : 80000100 r1 : 00000e18 r0 : 00000000
Flags: nZCv IRQs off FIQs on Mode SVC_32
Resetting CPU ...

NOTE: This requires UART access to NookTab.

UPDATE 1: I found one mistake in that the unpack tool was always using a fixed size 2048 for page size rather than 4096 in the BN recovery.img, I fixed it and repackaged the new set of files and now even thou success eludes me, I find that this time it didn't give a SEC ERROR for my modified ramdisk !?!?!? But it was slower with the checks this time.

OMAP44XX SDP # booti 0x81000000
kernel @ 80088000 (2687264)
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
ramdisk @ 81080000 (513416)
Initrd start : 81080000 , Initrd end : 810fd468Acclaim Board.

Starting kernel ...
Last edited by hkvc; 3rd January 2012 at 10:52 AM. Reason: unpack correction and a new run
The Following 7 Users Say Thank You to hkvc For This Useful Post: [ View ]
3rd January 2012, 03:05 PM |#5  
OP Member
Thanks Meter: 252
Cool SUCCESS SUCCESS SUCCESS with Modified Ramdisk
Hi All,

SHORT form for impatient people
OMAP44XX SDP # mmcinit 0; fatload mmc 0:1 0x81000000 new.recovery.img;

OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; md.l 80e84808 1; md.l 80e847a0 1

OMAP44XX SDP # booti 0x81000000

LONG form for people who want bit more details

I have been able to boot into a modified recovery image using my NOP based BYPASS logic for secure boot chain.

What I learnt in the process are

a) Secure boot chain logic doesn't bother if we change the UBoot / XYZ code space :) :) :) Key to any logic using/manipulating the memory of the NookTab from uboot.

b) The Android img images for BN NookTab contain

b.1) The standard 2K Android header (nothing special from BN in this).

However NOTE that pagesize is 4096 and a good base address (picked from recovery.img of is 0x80080000

b.2) The Kernel and the Ramdisk images with in the android img file in turn contain 0x120 Byte headers individually

b.3) The Secure Boot chain seems to be particular about these 0x120 byte headers

Even for my modified ramdisk, I had to use the original ramdisks' BN Header. Otherwise the security check seemed to take a hell lot of time most of the time and the end results were touchy (Have to debug this further ..., ALSO THERE IS THE OPTION OF AVOIDING THE SEC_ENTRY call in the FIRST PLACE ITSELF TO TRY AND BYPASS THIS, IF REQUIRED, I have to experiment this later).

So if one is using a tool which searchs for the GZIP MAGIC to decide where to split the img file into strictly two parts consisting of

dump_1) Android_Image_Header+Kernel_BNHeader+Kernel+Ramdis k_BNHeader and
dump_2) Ramdisk file

are fine.

However if one is using a program which uses the Android image header structure to dump the contents need to be careful to extract the BN header from the corresponding ramdisk file and then after manipulating/modifying the ramdisk file, RE PREPEND the BN header back to the ramdisk. Before clubing/joining all the files together.

Or tools which assume wrong pagesize (some I found used 2K page size instead of picking from android header) or which split the constituents into individual parts intelligently (which by the way will discard the BN Header potentially) will have to be MODIFIED before using.

I ended up writing my own c code to dump using Android header and inturn use shell script to extract the BN Header for safe keeping before merging everything back later. I will post the code and simple shell scripts in a day or two.


OMAP44XX SDP # mmcinit 0; fatload mmc 0:1 0x81000000 new.hdr.img;

3207168 bytes read
OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; md.l 80e84808 1; md.l 80e847a0 1
80e84808: 1a00000a ....
80e847a0: 1a000004 ....
80e84808: e1a00000 ....
80e847a0: 1a000004 ....
OMAP44XX SDP # booti 0x81000000
kernel @ 80088000 (2682952)
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
ramdisk @ 81080000 (513707)
Initrd start : 81080000 , Initrd end : 810fd58bAcclaim Board.

Starting kernel ...

Linux version (build@dhabuildimage17) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 SMP PREEMPT Fri Nov 11 12:35:42 PST 1
CPU: ARMv7 Processor [411fc093] revision 3 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP4430 ACCLAIM
Memory policy: ECC disabled, Data cache writealloc
The Following 11 Users Say Thank You to hkvc For This Useful Post: [ View ]
3rd January 2012, 03:18 PM |#6  
CelticWebSolutions's Avatar
Senior Member
Thanks Meter: 2,022
Donate to Me
That all looks very good and sounds extremely promising

So in the realms of being able to boot modified roms where does this put us?
3rd January 2012, 03:37 PM |#7  
OP Member
Thanks Meter: 252
Wink Uses of this method and its merits/demerits or needs/no needs
Hi Celtic/All,

*** The only places I see a meaningful use for this is mentioned towards the end, otherwise, I am working on this mainly for the fun of exploration. In most other cases where one thinks one needs this, I can tell you It can be achieved with out this, except for some exotic things which don't affect majority of users ***

My thoughts on ROMs with different complexities
If a modified ROM is not using (doesn't need) custom Kernel or custom Ramdisk, then my 2ndihkvc or any other working 2nd-init method is the simple and straight forward way of doing a custom rom.

If it however requires a custom Ramdisk, then this NOP based BYPASS method will allow one to achieve the same. However I don't see any need for anyone to use a custom ramdisk. If someone is using a custom ramdisk, It can be 98% modified to use the generic 2nd-init method and in case of NookTab my simple 2ndihkvc method (As documented in my other thread, the default 2nd-init logic fails on NookTab as it uses ONE too many PTRACE calls).

If it requires a custom Kernel then with bit more work on this I don't see why a Custom kernel cann't be booted.

However if you ask me, we don't gain much with a custom kernel or ramdisk, which cann't be achieved using root access and or module loading support in default kernel, and inturn REMEMBER that both of these can be done on NookTab today (i.e 1. Root access and 2. Module loading).

Also NOTE that this requires UART access.

*** ONE PLACE WHERE THIS CAN HELP *** is, with BN 1.4.1 firmware, which has blocked the current rooting method If I am not wrong (Unless someone has found a way to break it recently, which I have missed). For 1.4.1, with this, we can boot into a specific custom recovery image and modify the /system partition, such that we put su and SuperUser back into it under /system/bin (with proper chmod settings) and /system/app, so that we can gain Root access again, on rebooting into the NookTAB normally after this change.

*** Another place *** is when the device is very old and the new kernel can bring in some feature missing badly in a very old device. Again in many of these cases, if one puts sufficient effort the feature may be back portable and or injectable into a older kernel using the module route.


Last edited by hkvc; 3rd January 2012 at 03:46 PM. Reason: Power of kernel modules and Root
The Following 5 Users Say Thank You to hkvc For This Useful Post: [ View ]
3rd January 2012, 03:55 PM |#8  
Senior Member
Flag San Antonio
Thanks Meter: 10
I love reading these threads even though I don't fully understand everything going on in the code parts.

I'm interested in custom kernels because as far as I know there's no way to get ICS running on the Tab without one.

Nexus S 4G 4.0.3
3rd January 2012, 04:02 PM |#9  
rbellis's Avatar
Senior Member
Flag Chapel Hill
Thanks Meter: 17
I honestly dont know much about creating custom ROM's but I have been wondering why every thinks that we have to have the bootloader unlocked before we can get any type of custom ROM. I have a Moto X2. The bootloader is not and never will be unlocked but I am running a really sweet custom ROM on it. I know from other android phones that a ROM is possible with a locked bootloader.

My point is...I am glad to see someone working around this and taking the next step. I was wondering if DEV's have almost given up on the NT. Thank you for your work!
3rd January 2012, 06:43 PM |#10  
DeanGibson's Avatar
Senior Member
Flag Seattle, WA
Thanks Meter: 253
Donate to Me
Lightbulb Rooting 1.4.1
Originally Posted by hkvc

... BN 1.4.1 firmware, which has blocked the current rooting method If I am not wrong (Unless someone has found a way to break it recently, which I have missed).

See my method at (since Dec 27)

Note that my method starts with either a rooted or (preferably) unrooted copy of 1.4.0, roots it if necessary, modifies it slightly, updates to 1.4.1, and then regains root. Requires ADB/USB access.
Last edited by DeanGibson; 3rd January 2012 at 06:55 PM.
Post Reply Subscribe to Thread

bootloader bypass, nop, nop sec check
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes