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

Search This thread

hkvc

Senior Member
Jul 6, 2011
83
240
>>> 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'
 
Last edited:

hkvc

Senior Member
Jul 6, 2011
83
240
[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 <<<
****************************

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

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:
  • Like
Reactions: blazednova

hkvc

Senior Member
Jul 6, 2011
83
240
android img header structure for reference

from tools/mkbootimg/bootimg.h

#define BOOT_MAGIC "ANDROID!"
#define BOOT_MAGIC_SIZE 8
#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 */
};
 

hkvc

Senior Member
Jul 6, 2011
83
240
PARTIAL SUCCESS BYPASSING SEC CHECK using NOP

Hi

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:

hkvc

Senior Member
Jul 6, 2011
83
240
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 factory.zip) 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+Ramdisk_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.

BELOW is the OUTPUT OF MY SUCESSFUL RUN with MODIFIED RAMDISK
--------------------------------------------------------------------------------------------------------------------

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 2.6.35.7 (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
...........
 

CelticWebSolutions

Senior Member
May 25, 2011
855
2,012
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?
 

hkvc

Senior Member
Jul 6, 2011
83
240
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.

REMEMBER IN LINUX - KERNEL MODULE IS SAME AS KERNEL as far as PRIVILAGES are concerned, as it stands TODAY, all LIMITS IF ANY are ARTIFICIAL.

HOPE THAT HELPS :)
 
Last edited:

LiuAnshan

Senior Member
Dec 1, 2010
123
10
San Antonio
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
 

rbellis

Senior Member
Jan 10, 2011
458
16
Chapel Hill
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!
 

DeanGibson

Senior Member
Apr 30, 2011
530
364
Seattle, WA
Rooting 1.4.1

... 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 http://xdaforums.com/showthread.php?t=1413734 (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:

hkvc

Senior Member
Jul 6, 2011
83
240
POTENTIAL SUCCESS with CUSTOM KERNEL (INDIRECT METHOD)

Hi All,

In SHORT for impatient
---------------------------------
OMAP44XX SDP # mmcinit 0; fatload mmc 0:1 0x81000000 new.hdr.img;

OMAP44XX SDP # md.l 80e84794 1; md.l 80e847fc 1; mw.l 80e84794 e1a00000; mw.l 80e847fc e1a00000; md.l 80e84794 1; md.l 80e847fc 1

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

OMAP44XX SDP # booti 0x81000000

(c) HKVC, GPL ;-)

The sufficient minimal Details
-------------------------------------
I have verified that NOT CALLING SEC_ENTRY calls, with in uboot, related to kernel and ramdisk check keeps things smooth. That should mean the FLOOD GATES are POTENTIALLY OPEN for CUSTOM KERNELs with UART ACCESS.

This requires few additional NOPs compared to what I had originally specified (My original set of NOPs had some issue with Kernel booting, which I have to debug later, however this work around seems to resolve it - I don't want to delve more into this than what I have already specified here, unless Secure Bootloader people get any ideas ;-).


UART Boot Dump/log
-------------------------

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

3207168 bytes read
OMAP44XX SDP # md.l 80e84794 1; md.l 80e847fc 1; mw.l 80e84794 e1a00000; mw.l 80e847fc e1a00000; md.l 80e84794 1; md.l 80e847fc 1
80e84794: eb0030f1 .0..
80e847fc: eb0030d7 .0..
80e84794: e1a00000 ....
80e847fc: e1a00000 ....
OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; mw.l 80e847a0 e1a00000; md.l 80e84808 1; md.l 80e847a0 1
80e84808: 1a00000a ....
80e847a0: 1a000004 ....
80e84808: e1a00000 ....
80e847a0: e1a00000 ....
OMAP44XX SDP # booti 0x81000000
kernel @ 80088000 (2682952)
ramdisk @ 81080000 (513707)
Initrd start : 81080000 , Initrd end : 810fd58bAcclaim Board.

Starting kernel ...

Linux version 2.6.35.7 (build@dhabuildimage17) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 SMP PREEMPT Fri Nov 11 12:35:42 PST 2011
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
On node 0 totalpages: 245760
 
Last edited:

LexS007

Member
Oct 27, 2009
9
9
And if the merge bootloader of the nook color and from nook tablet, compare it and try to create one substitution?
 

hkvc

Senior Member
Jul 6, 2011
83
240
See my method at http://xdaforums.com/showthread.php?t=1413734 (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.
Hi DeanGibson,

Thanks for your efforts on that. It should help people who get bumped into 1.41 by BN.

HOWEVER Do note that if the uSD based MLO and u-boot.bin gets loaded first before the ones in eMMC by the internal boot rom of the Omap (Should be the case based on what Pokey had mentioned sometime back, I haven't cross checked myself yet, as I have been busy with these stuff which I am looking into). Then what ever (except for one cavet - which I wont mention here) BN may do in a future update, with the UART based u-boot method which I have mentioned in this thread, one will always be able to get root access to the device.
 

tonyp22

Senior Member
Nov 20, 2011
249
20
OMG hkvc, between you, DG, and AO how can the NT win? :)

You guys are monsters! (in a good way)
 

camapghe

Senior Member
Nov 11, 2009
292
26
Ok, little explaining before questioning is I'm not a tech guy. But from the all post of hkvc in this thread, the understanding that we can access more space in 16GB internal storage and custom ROM/kernel is on the way is correct?
 

cfoesch

Senior Member
Dec 27, 2011
267
98
Albuquerque, NM
Ok, little explaining before questioning is I'm not a tech guy. But from the all post of hkvc in this thread, the understanding that we can access more space in 16GB internal storage and custom ROM/kernel is on the way is correct?

This requires repartitioning the drive, which we are not at this time confident, that it will not brick your nook by doing so. (This double negative actually is making a positive: Repartitioning might brick your nook.)

This hardware modification has nothing to do with accessing more of the space as that is entirely a software remedy. We're just not confident about how hard the Nook looks at the primary partition table.
 
  • Like
Reactions: deralaand

hkvc

Senior Member
Jul 6, 2011
83
240
SUCCESS SUCCESS SUCCESS with CUSTOM Kernel+ CUSTOM Ramdisk, UART NOP BYPASS

Hi All,

As I had mentioned yesterday/today early morning, By bypassing the SEC_ENTRY check I was able to run stock kernel with out any problem. And as I had mentioned then even thou it is a indirect way of verifying possibility of custom kernels, it should still open the flood gate for custom kernels (with UART access for NoW ;-).

Now I have actually verified by RUNNING a CUSTOM Kernel which I compiled along with a CUSTOM Ramdisk (with adb enabled - look at last few lines), which you can know from

a) the kernel version line while booting, which contains the machine used for compiling (Obviously I have redacted part of my name ;-),

b) as well as the size of the kernel and ramdisk images which is different from the stock img files, because this contains both a custom kernel as well as custom ramdisk from me.

SO IT IS SUCCESS with CUSTOM KERNELS+ CUSTOM RAMDISKS, using the uboot commands which I had mentioned in my older post.

UART DUMP including UBoot commands
--------------------------------------------------


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

4157440 bytes read
OMAP44XX SDP # md.l 80e84794 1; md.l 80e847fc 1; mw.l 80e84794 e1a00000; mw.l 80e847fc e1a00000; md.l 80e84794 1; md.l 80e847fc 1
80e84794: eb0030f1 .0..
80e847fc: eb0030d7 .0..
80e84794: e1a00000 ....
80e847fc: e1a00000 ....
OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; mw.l 80e847a0 e1a00000; md.l 80e84808 1; md.l 80e847a0 1
80e84808: 1a00000a ....
80e847a0: 1a000004 ....
80e84808: e1a00000 ....
80e847a0: e1a00000 ....
OMAP44XX SDP # booti 0x81000000
kernel @ 80088000 (2693828)
ramdisk @ 81080000 (1455055)
Initrd start : 81080000 , Initrd end : 811e32afAcclaim Board.

Starting kernel ...

Linux version 2.6.35.7 (hREDACkvc@HCU1) (gcc version 4.5.4 (Ubuntu/Linaro 4.5.3-9ubuntu1) ) #1 SMP PREEMPT Wed Jan 4 02:43:18 IST 2012
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
On node 0 totalpages: 245760

..... Chopped ...............

omapfb omapfb: Unknown ioctl 0x40044620
init: Unable to open persistent property directory /data/property errno: 2
enabling adb
adb_open
android_usb gadget: high speed config #1: android

SO ALL OF YOU out there ITHCING to experiment with Custom Kernels and What not, Go ahead and enjoy the freedom to do so on NOOK TABLET (with UART access for NoW ;-)
 
Last edited:

hkvc

Senior Member
Jul 6, 2011
83
240
My Android Img file manipulation scripts including few older ones by others.

Hi,

I am attaching the simple C program and the scripts which I use for extracting BN Android Imgs consisting of

a) Dumping the individual sections of Android img

b) Allow seperating the header from the actual Kernel or Ramdisk

c) Allow concatenating (This is kind of dummy, but required to take care of u-boot logic of loading) the old header with new Kernel or Ramdisk

d) Pass proper arguments to recreate the Android IMG file.

Also I have attached some of the other open source tools which I started with originally, but due to few things here and there and also to get maximum flexibility I moved to my own set of scripts and program.
 

Attachments

  • AndroidImgToolsHKVCPlus.zip
    17.1 KB · Views: 60
  • NOPBypass-uboot-cmds.txt
    832 bytes · Views: 49
Last edited:

hkvc

Senior Member
Jul 6, 2011
83
240
recovery img with simple ramdisk with ADB and Root shell on Adb and console

Hi,

Attached is a recovery.img file with the standard Kernel from NookTab and a modified Ramdisk which has support for

a) ADB shell
b) Root shell access (Both ADB and Console)
c) Console is enabled in UART.

Note that the sh on the ramdisk is renamed busybox with a symbolic link called busybox pointing to this sh.

go into /system/bin and run
busybox --install /system/bin

So that you have the standard commands available on the recovery shell.

Also remember to run

export PATH=/system/bin:$PATH
 

Attachments

  • new.hdr.img.zip
    3.9 MB · Views: 49
  • NOPBypass-uboot-cmds.txt
    832 bytes · Views: 50

Top Liked Posts

  • There are no posts matching your filters.
  • 15
    >>> 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'
    11
    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 factory.zip) 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+Ramdisk_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.

    BELOW is the OUTPUT OF MY SUCESSFUL RUN with MODIFIED RAMDISK
    --------------------------------------------------------------------------------------------------------------------

    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 2.6.35.7 (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
    ...........
    7
    Great news! this device is now booting from a kernel I modified
    Code:
    Texas Instruments X-Loader 1.41 (Oct 21 2011 - 14:00:05)
    Start not on PWRON, skipping power button check.
    mmc read: Invalid size
    Starting OS Bootloader from MMC/SD1 ...
    
    
    U-Boot 1.1.4-acclaim1.4_1.4.0.1029^{} (Nov 11 2011 - 12:34:20)
    
    Load address: 0x80e80000
    DRAM:  1024 MB
    Using default environment
    
    In:    serial
    Out:   serial
    Err:   serial
    hw_status 0x23 vbus_status 0x80
    MAX17042+UBOOT: battery type=LG
    MAX17042+UBOOT: gas gauge detected (0x0002)
    MAX17042_STATUS (00h) is 0x0002
    MAX17042+UBOOT:  BATTERY      Detected!
    MAX17042+UBOOT:POR detected!
     No valid max17042 init data found, assume no battery history 
    MAX17042_Version (21h) is 0x0092
    MAX17042_DesignCap (18h) is 0x07d0
    MAX17042_OCV (fbh) is 0xbe3d
    MAX17042_FSTAT (fdh) is 0x3950
    MAX17042_SOCvf (ffh) is 0x281b
    uboot verify: 1d CONFIG is 2210 ; should be 2210 & 0xFDFB
    uboot verify: 2a RELAXCFG is 083b ; should be 083b
    uboot verify: 29 FILTERCFG is 87a4 ; should be 87a4
    uboot verify: 28 LEARNCFG is 2406 ; should be 2406 & 0xFF0F
    uboot verify: 18 DesignCap is 07d0 ; should be 205c
    max17042_write_custom_para: use hardcoded values
    ICHGTerm = 0x0140
     use hardcoded Capacity 0x205c
    VFSOC = 0x314a
    fullcap0=0x2067 VFSOC=0x314a remcap=0x0ff8
    MAX17042_STATUS (00h) is 0x0002
    STATUS = 0x0002 -- clearing POR
    MAX17042_STATUS (00h) is 0x0000
    Max17042 init is done
    SOC 49%, booting.
    Board revision PVT
    Booting from sd
    Autobooting in 0 seconds, press <SPACE> to stop...
    
    ** Unable to read "flashing_boot.img" from mmc 0:1 **
    booti: bad boot image magic
    OMAP44XX SDP # mmcinit 0; fatload mmc 0:1 0x81000000 new.flashing_boot.img;
    mmc read: Invalid size
    
    2849988 bytes read
    OMAP44XX SDP # md.l 80e84794 1; md.l 80e847fc 1; mw.l 80e84794 e1a00000; mw.l 80e847fc e1a00000; md.l 80e84794 1; md.l 80e847fc 1;
    80e84794: eb0030f1    .0..
    80e847fc: eb0030d7    .0..
    80e84794: e1a00000    ....
    80e847fc: e1a00000    ....
    OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; mw.l 80e847a0 e1a00000; md.l 80e84808 1; md.l 80e847a0 1;
    80e84808: 1a00000a    ....
    80e847a0: 1a000004    ....
    80e84808: e1a00000    ....
    80e847a0: e1a00000    ....
    OMAP44XX SDP # booti 0x81000000
    kernel   @ 80088000 (2682952)
    ramdisk  @ 81080000 (157153)
     Initrd start : 81080000 , Initrd end : 810a64c1Acclaim Board.
    
    Starting kernel ...
    
    Linux version 2.6.35.7 (build@dhabuildimage17) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 SMP PREEMPT Fri Nov 11 12:35:42 PST 2011
    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
    On node 0 totalpages: 245760
    free_area_init_node: node 0, pgdat c0587e00, node_mem_map c062a000
      Normal zone: 1536 pages used for memmap
      Normal zone: 0 pages reserved
      Normal zone: 178688 pages, LIFO batch:31
      HighMem zone: 512 pages used for memmap
      HighMem zone: 65024 pages, LIFO batch:15
    ***********************
    OMAP4430 ES2.3 type(HS)
    id-code  (6b95c02f)
    Die-id   (66E60006-00000001-091126B3-0600B01B)
    Prod-id  (800DB95C-000600CC)
    ***********************
    SRAM: Mapped pa 0x40300000 to va 0xfe400000 size: 0x100000
    FIXME: omap44xx_sram_init not implemented
    Reserving 33554432 bytes SDRAM for VRAM
    SMC: Allocated workspace of 3M at (0x9c900000)
    PERCPU: Embedded 7 pages/cpu @c0e37000 s5632 r8192 d14848 u65536
    pcpu-alloc: s5632 r8192 d14848 u65536 alloc=16*4096
    pcpu-alloc: [0] 0 [0] 1 
    Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 243712
    Kernel command line: androidboot.console=ttyO0 console=ttyO0,115200n8 mem=448M@0x80000000 mem=512M@0xA0000000 init=/init rootwait vram=32M,82000000 omapfb.vram=0:5M@82000000 row
    PID hash table entries: 4096 (order: 2, 16384 bytes)
    Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
    Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
    Memory: 448MB 256MB 256MB = 960MB total
    Memory: 935252k/935252k available, 47788k reserved, 262144K highmem
    Virtual kernel memory layout:
        vector  : 0xffff0000 - 0xffff1000   (   4 kB)
        fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
        DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
        vmalloc : 0xf0800000 - 0xf8000000   ( 120 MB)
        lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
        pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
        modules : 0xbf000000 - 0xbfe00000   (  14 MB)
          .init : 0xc0008000 - 0xc003d000   ( 212 kB)
          .text : 0xc003d000 - 0xc053f000   (5128 kB)
          .data : 0xc0540000 - 0xc05888c0   ( 291 kB)
    SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
    Hierarchical RCU implementation.
            RCU-based detection of stalled CPUs is disabled.
            Verbose stalled-CPUs detection is disabled.
    NR_IRQS:388
    omap_hwmod: sys_32k_ck: missing clockdomain for sys_32k_ck.
    omap_hwmod: l3_div_ck: missing clockdomain for l3_div_ck.
    omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for dpll_mpu_m2_ck.
    omap_hwmod: dmic: resetting
    omap_hwmod: dss_dsi1: cannot be enabled (3)
    omap_hwmod: dss_dsi2: cannot be enabled (3)
    omap_hwmod: dss_hdmi: cannot be enabled (3)
    omap_hwmod: dss_rfbi: cannot be enabled (3)
    omap_hwmod: dss_venc: cannot be enabled (3)
    omap_hwmod: iva: failed to reset in 10000 usec
    omap_hwmod: mailbox: resetting
    omap_hwmod: omap-mcpdm-dai: cannot be enabled (3)
    omap_hwmod: mcspi1: resetting
    omap_hwmod: mcspi2: resetting
    omap_hwmod: mcspi3: resetting
    omap_hwmod: mcspi4: resetting
    omap_hwmod: mmc1: resetting
    omap_hwmod: mmc2: resetting
    omap_hwmod: mmc3: resetting
    omap_hwmod: mmc4: resetting
    omap_hwmod: mmc5: resetting
    omap_hwmod: timer3: resetting
    omap_hwmod: timer4: resetting
    omap_hwmod: timer5: resetting
    omap_hwmod: timer6: resetting
    omap_hwmod: timer7: resetting
    omap_hwmod: timer8: resetting
    omap_hwmod: timer9: resetting
    omap_hwmod: timer11: resetting
    GPMC revision 6.0
    SmartReflex CLASS3 initialized
    OMAP clockevent source: GPTIMER1 at 32768 Hz
    Console: colour dummy device 80x30
    Calibrating delay loop... 2013.49 BogoMIPS (lpj=7864320)
    pid_max: default: 32768 minimum: 301
    Mount-cache hash table entries: 512
    CPU: Testing write buffer coherency: ok
    Calibrating local timer... 
    50.00MHz.
    L310 cache controller enabled
    l2x0: 16 ways, CACHE_ID 0x410000c4, AUX_CTRL 0x1e470000
    CPU1: Booted secondary processor
    Brought up 2 CPUs
    SMP: Total of 2 processors activated (4010.18 BogoMIPS).
    devtmpfs: initialized
    regulator: core version 0.5
    NET: Registered protocol family 16
    EMIF0 is enabled with IRQ142
    EMIF1 is enabled with IRQ143
    OMAP GPIO hardware version 0.1
    ram_console: got buffer at a0000000, size 4000
    ram_console: uncorrectable error in header
    ram_console: no valid data in buffer (sig = 0x35983b52)
    console [ram-1] enabled
    omap_mux_init: Add partition: #1: core, flags: 2
    omap_mux_init: Add partition: #2: wkup, flags: 2
    Board revision PVT
    _omap_mux_init_signal: Could not set signal sys_pwron_reset_out
    _omap_mux_init_signal: Could not set signal fref_clk3_req
    Elpida DDR Memory 
    Reprogramming LPDDR2 timingsto 400000000 Hz
    _omap_mux_init_signal: Could not set signal fref_clk0_out.gpio_wk6
    _omap_mux_init_gpio: Could not set gpio4
    board-4430sdp.c: kxtf9_dev_init ...
    board-4430sdp.c: kxtf9_dev_init > Init kxtf9 irq pin 66 !
    board-4430sdp.c: max17042_dev_init ...
    board-4430sdp.c: max17042_dev_init > Init max17042 irq pin 65 !
    max17042 GPIO pin read 1
    init_display_led: evt2 hardware
    res->start = 49022000
    res->start = 49024000
    res->start = 49026000
    res->start = 48096000
    OMAP DMA hardware revision 0.0
    dma dma.0: System DMA registered
    bio: create slab <bio-0> at 0
    regulator: vdd_lcdtp: 3300 mV normal 
    i2c_omap i2c_omap.1: bus 1 rev4.0 at 400 kHz
    Skipping twl internal clock init and using bootloader value (unknown osc rate)
    twl6030: PIH (irq 39) chaining IRQs 368..387
    regulator: VUSB: 3300 mV normal standby
    twl6030_usb twl6030_usb: Initialized TWL6030 USB module
    regulator: VMMC: 1200 <--> 3000 mV at 3000 mV normal standby
    regulator: VPP: 1800 <--> 2500 mV at 1700 mV normal standby
    regulator: VANA: 2100 mV normal standby
    regulator: VCXIO: 1800 mV normal standby
    regulator: VAUX1_6030: 1000 <--> 3000 mV at 2800 mV normal standby
    regulator: VAUX3_6030: 1800 mV normal standby
    regulator: CLK32KG: normal 
    i2c_omap i2c_omap.2: bus 2 rev4.0 at 400 kHz
    i2c_omap i2c_omap.3: bus 3 rev4.0 at 400 kHz
    i2c_omap i2c_omap.4: bus 4 rev4.0 at 400 kHz
    Advanced Linux Sound Architecture Driver Version 1.0.23.
    Sangoma WANPIPE Router v1.1 (c) 1995-2000 Sangoma Technologies Inc.
    Switching to clocksource timer-32k
    musb_hdrc: version 6.0, musb-dma, peripheral, debug=0
    HS USB OTG: Cable detected at boot = 0
    musb_hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
    musb_hdrc: MHDRC RTL version 2.0 
    musb_hdrc: setup fifo_mode 4
    musb_hdrc: 28/31 max ep, 16384/16384 memory
    musb_hdrc musb_hdrc: USB Peripheral mode controller at fc0ab000 using DMA, IRQ 124
    NET: Registered protocol family 2
    IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
    TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
    TCP bind hash table entries: 65536 (order: 7, 786432 bytes)
    TCP: Hash tables configured (established 131072 bind 65536)
    TCP reno registered
    UDP hash table entries: 512 (order: 2, 16384 bytes)
    UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
    NET: Registered protocol family 1
    Trying to unpack rootfs image as initramfs...
    rootfs image is not initramfs (read error); looks like an initrd
    Freeing initrd memory: 152K
    opp_add: no hwmod for hsi, cannot add OPPs.
    unable to add OPP 98304000 Hz for hsi
    opp_add: no hwmod for hsi, cannot add OPPs.
    unable to add OPP 96000000 Hz for hsi
    opp_add: no hwmod for hsi, cannot add OPPs.
    unable to add OPP 96000000 Hz for hsi
    ipu-power ipu0: Test of writing to the device message log,done from ipu_pm_init
    ipu-power initialized ipu, major: 252, minor: 0
    sdp4430_wifi_init: start
    omap-iommu omap-iommu.0: ducati registered
    omap-iommu omap-iommu.1: tesla registered
    iovmm-omap initialized ducati, major: 251, base-minor: 0
    iovmm-omap initialized tesla, major: 251, base-minor: 1
    omap-remoteproc omap-remoteproc.0: omap_rproc_probe: adding rproc tesla
    omap-remoteproc omap-remoteproc.0: omap-rproc initialized tesla, major: 250, base-minor: 0
    omap-remoteproc omap-remoteproc.1: omap_rproc_probe: adding rproc ducati-proc0
    omap-remoteproc omap-remoteproc.1: omap-rproc initialized ducati-proc0, major: 250, base-minor: 1
    omap-remoteproc omap-remoteproc.2: omap_rproc_probe: adding rproc ducati-proc1
    omap-remoteproc omap-remoteproc.2: omap-rproc initialized ducati-proc1, major: 250, base-minor: 2
    highmem bounce pool size: 64 pages
    ashmem: initialized
    VFS: Disk quotas dquot_6.5.2
    Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
    msgmni has been set to 1314
    SMC: Secure device detected, enabling SMC driver
    Registering char device tf_driver (122:0)
    alg: No test for stdrng (krng)
    io scheduler noop registered
    io scheduler deadline registered
    io scheduler cfq registered (default)
    OMAP DSS rev 4.0
    OMAP DISPC rev 4.0
    OMAP DSI rev 3.0
    OMAP DSI2 rev 3.0
    Enter hdmi_init()
     boxer : boxer_lcd_init called , line 337
     boxer : boxer_spi_probe called , line 309
    boxer: spi setup returned : 0
     boxer : boxer_panel_probe called , line 130
    omap_smartreflex_disable_reset_volt: omap_sr struct for sr_core not found
    omap_smartreflex_enable: omap_sr struct for sr_core not found
    Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
    omap-hsuart.0: ttyO0 at MMIO 0x4806a000 (irq = 104) is a OMAP UART0
    console [ttyO0] enabled
    omap-hsuart.1: ttyO1 at MMIO 0x4806c000 (irq = 105) is a OMAP UART1
    omap-hsuart.2: ttyO2 at MMIO 0x48020000 (irq = 106) is a OMAP UART2
    omap-hsuart.3: ttyO3 at MMIO 0x4806e000 (irq = 102) is a OMAP UART3
    brd: module loaded
    loop: module loaded
    android init
    android_probe pdata: c0563eb8
    android_bind
    android_bind_config
    android_usb gadget: android_usb ready
    f_adb init
    android_register_function adb
    f_mass_storage init
    fsg_probe pdev: c0563c00, pdata: c0563ea8
    android_register_function usb_mass_storage
    android_usb gadget: Mass Storage Function, version: 2009/09/11
    android_usb gadget: Number of LUNs=2
     lun0: LUN: removable file: (no medium)
     lun1: LUN: removable file: (no medium)
    adb_bind_config
    input: gpio-keys as /devices/platform/gpio-keys/input/input0
    input: omap-keypad as /devices/platform/omap-keypad/input/input1
    ft5x06_init() - FT I2C Touchscreen Driver (Built Nov 11 2011 @ 12:35:26)
    ft5x06_probe() - FT5x06 found on I2C bus.
    ft5x06_reset_panel_via_gpio() - Toggling GPIO 39 to reset the Touch Panel...
    input: ft5x06-i2c as /devices/platform/i2c_omap.2/i2c-2/2-0038/input/input2
    ft5x06_initialize() - sysfs_create_group() succeeded.
    kxtf9 1-000f: WHO_AM_I = 0x01
    input: kxtf9_accel as /devices/virtual/input/input3
    using rtc device, twl_rtc, for alarms
    twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
    twl_rtc twl_rtc: Power up reset detected.
    twl_rtc twl_rtc: Enabling TWL-RTC.
    i2c /dev entries driver
    Linux video capture interface: v2.00
    max17042: max17042_init ...
    max17042: max17042_probe ...
    max17042: next history save at 4294936863
    max17042: max17042_probe > IRQ is 225
    max17042 GPIO pin read 1
    max17042: max17042_device_power_on ...
    max17042: max17042_hw_init ...
    max17042:  BATTERY      Detected!
    config = 0x2214
    Valert = 0xff9b
    Salert = 0xff05
    config = 0x2214
    config = 0x2214
    shdntimer = 0x0002
    max17042: max17042_verify ...
    max17042 1-0036: Version = 0x0092
    max17042 1-0036: support ver. 1.0.0 enabled
    MAX8903: Charger registering!
    MAX8903: Charger Initializing...
    MAX8903: Request CHARGER FLT IRQ successfully!
    MAX8903: Charger detected at boot = 0
    MAX8903: USB_EVENT_NONE
    OMAP Watchdog Timer Rev 0x00: initial timeout 60 sec
    cpuidle: using governor ladder
    cpuidle: using governor menu
    omap_pwm_led omap_pwm_led: OMAP PWM LED (lcd-backlight) at GP timer 11/0
    Registered led device: lcd-backlight
    [BL set power] 1
    logger: created 64K log 'log_main'
    logger: created 256K log 'log_events'
    logger: created 64K log 'log_radio'
    logger: created 64K log 'log_system'
    proc4430_drv_initializeModule
    omap-devicehandler omap-devicehandler.0: omap_devh_probe: adding devh Tesla
    omap-devh initialized Tesla, major: 241, base-minor: 0
    omap-devicehandler omap-devicehandler.1: omap_devh_probe: adding devh SysM3
    omap-devh initialized SysM3, major: 241, base-minor: 1
    omap-devicehandler omap-devicehandler.2: omap_devh_probe: adding devh AppM3
    omap-devh initialized AppM3, major: 241, base-minor: 2
    omap3epd-sound: Audio SoC init
    Found Board EVT 2.1-ABE support Enabled
    asoc: null-codec-dai <-> MultiMedia1 LP mapping ok
    asoc: null-codec-dai <-> MultiMedia2 mapping ok
    tlv320aic3100_init: Unable get gpio for CODEC POWER 101
    mmc0: new high speed DDR MMC card at address 0001
    mmcblk0: mmc0:0001 SEM16G 14.8 GiB 
     mmcblk0:
    Alternate GPT is invalid, using primary GPT.
     p1 (xloader) p2 (bootloader) p3 (recovery) p4 (boot) p5 (rom) p6 (bootdata) p7 (factory) p8 (system) p9 (cache) p10 (media) p11 (userdata)
    mmc1: host does not support reading read-only switch. assuming write-enable.
    mmc1: new high speed SD card at address 9dfe
    mmcblk1: mmc1:9dfe SD02G 1.83 GiB 
     mmcblk1: p1 p2 p3 p4
    ##-tlv320aic3100_init
    Created the sysfs Files for Audio Driver
    Page 4 has 41 Coefficient Values 
    Page 8 has 61 Coefficient Values 
    Updated Page 8 DAC Coefficient Control Reg for Adaptive Mode
    asoc: tlv320aic3100-dai <-> omap-mcbsp-dai.1 mapping ok
    input: OMAP4_ACCLAIM_ABE Headset Jack as /devices/platform/soc-audio/sound/card0/input4
    ALSA device list:
      #0: OMAP4 Acclaim AIC3100 ABE
    Netfilter messages via NETLINK v0.30.
    nf_conntrack version 0.5.0 (14615 buckets, 58460 max)
    CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
    nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
    sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
    ctnetlink v0.93: registering with nfnetlink.
    xt_time: kernel timezone is -0000
    ip_tables: (C) 2000-2006 Netfilter Core Team
    arp_tables: (C) 2002 David S. Miller
    TCP cubic registered
    Initializing XFRM netlink socket
    NET: Registered protocol family 10
    lo: Disabled Privacy Extensions
    Mobile IPv6
    IPv6 over IPv4 tunneling driver
    sit0: Disabled Privacy Extensions
    ip6tnl0: Disabled Privacy Extensions
    NET: Registered protocol family 17
    NET: Registered protocol family 15
    ThumbEE CPU extension supported.
    omap_hwmod: Initialize debugfs support
    Power Management for TI OMAP4.
    prcm_clear_statdep_regs: Clearing static depndencies
    CPUidle for CPU0 registered
    CPUidle for CPU1 registered
    sr_init: No PMIC hook to init smartreflex
    smartreflex smartreflex.0: omap_smartreflex_probe: SmartReflex driver initialized
    smartreflex smartreflex.1: omap_smartreflex_probe: SmartReflex driver initialized
    smartreflex smartreflex.2: omap_smartreflex_probe: SmartReflex driver initialized
    Disabling unused clock "auxclk4_src_ck"
    Disabling unused clock "usb_phy_cm_clk32k"
    Disabling unused clock "ocp2scp_usb_phy_ick"
    Disabling unused clock "ocp2scp_usb_phy_phy_48m"
    Disabling unused clock "hdq1w_fck"
    Disabling unused clock "gpmc_ick"
    Disabling unused clock "gpio4_dbclk"
    Disabling unused clock "efuse_ctrl_cust_fck"
    VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
     boxer : boxer_panel_enable called , line 232
     boxer : boxer_panel_start called , line 151
    regulator_init_complete: disabling VANA
    twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:01 UTC (946684801)
    omap_vout omap_vout: : registered and initialized video device 0
    omap_vout omap_vout: : registered and initialized video device 1
    omap_vout omap_vout: : registered and initialized video device 2
    omap_wb: registered and initialized wb device 4 [v4l2]
    RAMDISK: gzip image found at block 0
    RAMDISK: EOF while reading compressed data
    uncompression error
    EXT3-fs (mmcblk1p2): error: couldn't mount because of unsupported optional features (240)
    EXT2-fs (mmcblk1p2): error: couldn't mount because of unsupported optional features (240)
    EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)
    VFS: Mounted root (ext4 filesystem) on device 179:18.
    devtmpfs: mounted
    Freeing init memory: 212K
    init: /init.omap4430.rc: 1: invalid command 'echo'
    init: /init.omap4430.rc: 25: invalid command 'echo'
    init: /init.omap4430.rc: 25: invalid command 'echo'
    init: /init.omap4430.rc: 25: invalid command 'echo'
    omapfb omapfb: Unknown ioctl 0x40044620
    EXT4-fs (mmcblk0p8): mounted filesystem with ordered data mode. Opts: errors=panic
    MAX8903: Charger Unplugged!
    EXT4-fs (mmcblk0p11): recovery complete
    EXT4-fs (mmcblk0p11): mounted filesystem with ordered data mode. Opts: errors=panic
    EXT4-fs (mmcblk0p9): recovery complete
    EXT4-fs (mmcblk0p9): mounted filesystem with ordered data mode. Opts: errors=panic
    EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
    init: cannot execve('/system/etc/install-recovery.sh'): Permission denied
    init: cannot find '/system/bin/uim-sysfs', disabling 'uim'
    $ omap-remoteproc omap-remoteproc.0: omap_rproc_open: dev num 0, name tesla, count 1
    omap-remoteproc omap-remoteproc.1: omap_rproc_open: dev num 1, name ducati-proc0, count 1
    omap-remoteproc omap-remoteproc.2: omap_rproc_open: dev num 2, name ducati-proc1, count 1
    platform_mem_setup : status [0x0]
    platform_setup : status [0x0]
    proc_mgr_setup : status [0x0]
    sharedregion_setup : status [0x0]
    omap mailbox rev 0.0
    notify_ducatidrv_setup : status [0x0]
    notify_setup : status [0x0]
    ipu_pm_setup : status [0x0]
    nameserver_setup : status [0x0]
    nameserver_get_handle failed! status = 0xfffffffe
    gatemp_setup : status [0x0]
    gatepeterson_setup : status [0x0]
    nameserver_get_handle failed! status = 0xfffffffe
    messageq_setup : status [0x0]
    nameserver_get_handle failed! status = 0xfffffffe
    heapbufmp_setup : status [0x0]
    nameserver_get_handle failed! status = 0xfffffffe
    heapmemmp_setup : status [0x0]
    nameserver_get_handle failed! status = 0xfffffffe
    listmp_setup : status [0x0]
    transportshm_setup : status [0xa7a000]
    nameserver_remotenotify_setup : status [0x0]
    _platform_setup : status [0x0]
    omap-remoteproc omap-remoteproc.0: omap_rproc_open: dev num 0, name tesla, count 1
    omap-remoteproc omap-remoteproc.1: omap_rproc_open: dev num 1, name ducati-proc0, count 1
    omap-remoteproc omap-remoteproc.2: omap_rproc_open: dev num 2, name ducati-proc1, count 1
    omap_hwmod: ipu: failed to reset in 10000 usec
    omap-iommu omap-iommu.0: ducati: version 2.1
    proc4430_attach num_mem_entries = 6
    proc_mgr_attach:proc_mgr_handle->num_mem_entries = 6
    proc4430_attach num_mem_entries = 6
    proc_mgr_attach:proc_mgr_handle->num_mem_entries = 6
    _platform_read_slave_memory successful! status = 0x0, proc_id = 2, addr = 0xc580, m_addr = 0xf160c580, size = 0x20
    _platform_read_slave_memory successful! status = 0x0, proc_id = 2, addr = 0xc5a0, m_addr = 0xf160c5a0, size = 0x30
    _platform_write_slave_memory successful! status = 0x0, proc_id = 2, addr = 0xc580, m_addr = 0xf160c580, size = 0x20
    omap-remoteproc omap-remoteproc.1: omap_rproc_ioctl
    ipc_proc_sync_start failed: status [0xffffffff]
    ipc_attach : ipc_proc_sync_start failed [0xffffffff]
    ipc_attach failed! status = 0xffffffff
    ipc_proc_sync_start failed: status [0xffffffff]
    ipc_attach : ipc_proc_sync_start failed [0xffffffff]
    ipc_attach failed! status = 0xffffffff
    ipc_proc_sync_start done
    ipc_proc_sync_start : status [0x0]
    gatemp_attach : status [0x0]
    sharedregion_attach : status [0x0]
    sharedregion_get_ptr : status [0x0]
    notify_attach : status [0x0]
    ipu_pm_attach : status [0x0]
    sharedregion_get_ptr : status [0x0]
    nameserver_remotenotify_attach : status [0x0]
    sharedregion_get_ptr : status [0x0]
    messageq_attach : status [0x0]
    ipc_proc_sync_finish : status [0x0]
    SMC: SecureCRC=0xCFDC2A68
    Disabling non-boot CPUs ...
    CPU1: shutdown
    SMC PA: INFO 00000001 00:00:00.000 ------ ------  --------------- Booting... (t=00:00:22.311) SMCXG01.04p8.31489     /PlayReady Integration
    SMC PA: INFO 00000002 00:00:00.043 ------ ------  --------------- Booted
    Enabling non-boot CPUs ...
    CPU1: Booted secondary processor
    CPU1 is up
    FWRAM memory driver v1.0
    _platform_read_slave_memory successful! status = 0x0, proc_id = 1, addr = 0x34b980, m_addr = 0xf224b980, size = 0x20
    _platform_read_slave_memory successful! status = 0x0, proc_id = 1, addr = 0x34b9a0, m_addr = 0xf224b9a0, size = 0x30
    _platform_write_slave_memory successful! status = 0x0, proc_id = 1, addr = 0x34b980, m_addr = 0xf224b980, size = 0x20
    omap-remoteproc omap-remoteproc.2: omap_rproc_ioctl
    ipc_proc_sync_start failed: status [0xffffffff]
    ipc_attach : ipc_proc_sync_start failed [0xffffffff]
    ipc_attach failed! status = 0xffffffff
    ipc_proc_sync_start failed: status [0xffffffff]
    ipc_attach : ipc_proc_sync_start failed [0xffffffff]
    ipc_attach failed! status = 0xffffffff
    ipc_proc_sync_start done
    ipc_proc_sync_start : status [0x0]
    gatemp_attach : status [0x1]
    sharedregion_attach : status [0x0]
    sharedregion_get_ptr : status [0x0]
    notify_attach : status [0x0]
    ipu_pm_attach : status [0x0]
    sharedregion_get_ptr : status [0x0]
    nameserver_remotenotify_attach : status [0x0]
    sharedregion_get_ptr : status [0x0]
    messageq_attach : status [0x0]
    ipc_proc_sync_finish : status [0x0]
    Registered user-space process for DEV_SYS_ERROR event in SysM3
    Registered user-space process for DEV_SYS_ERROR event in AppM3
    Registered user-space process for DEV_WATCHDOG_ERROR event in AppM3
    Registered user-space process for DEV_WATCHDOG_ERROR event in SysM3
    SMC PA: INFO 00000003 00:00:02.277 P-0001 T-000D System --------- Mounting partition 0...
    SMC PA: INFO 00000004 00:00:02.361 P-0001 T-000D System --------- File system mounted successfully in partition 0
    SMC PA: INFO 00000005 00:00:02.375 P-0001 T-000D System --------- Mounting partition 1...
    SMC PA: INFO 00000006 00:00:02.390 P-0001 T-000D System --------- File system mounted successfully in partition 1
    warning: `zygote' uses 32-bit capabilities (legacy support in use)
    kxtf9 1-000f: IRQ TILT [2]
    
    $ CPU1: shutdown
    CPU1: Booted secondary processor
    CPU1: shutdown
    Sleep APPM3
    Sleep SYSM3
    CPU1: Booted secondary processor
    CPU1: shutdown
    CPU1: Booted secondary processor
    CPU1: shutdown
    CPU1: Booted secondary processor

    Partition1: BOOT/LBA/Files: MLO, u-boot.bin,new.flashing_boot.img
    Partition2: EXT4:uncompressed ramdisk.img

    It booted and did not panic. this is a huge sucess.
    7
    SUCCESS SUCCESS SUCCESS with CUSTOM Kernel+ CUSTOM Ramdisk, UART NOP BYPASS

    Hi All,

    As I had mentioned yesterday/today early morning, By bypassing the SEC_ENTRY check I was able to run stock kernel with out any problem. And as I had mentioned then even thou it is a indirect way of verifying possibility of custom kernels, it should still open the flood gate for custom kernels (with UART access for NoW ;-).

    Now I have actually verified by RUNNING a CUSTOM Kernel which I compiled along with a CUSTOM Ramdisk (with adb enabled - look at last few lines), which you can know from

    a) the kernel version line while booting, which contains the machine used for compiling (Obviously I have redacted part of my name ;-),

    b) as well as the size of the kernel and ramdisk images which is different from the stock img files, because this contains both a custom kernel as well as custom ramdisk from me.

    SO IT IS SUCCESS with CUSTOM KERNELS+ CUSTOM RAMDISKS, using the uboot commands which I had mentioned in my older post.

    UART DUMP including UBoot commands
    --------------------------------------------------


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

    4157440 bytes read
    OMAP44XX SDP # md.l 80e84794 1; md.l 80e847fc 1; mw.l 80e84794 e1a00000; mw.l 80e847fc e1a00000; md.l 80e84794 1; md.l 80e847fc 1
    80e84794: eb0030f1 .0..
    80e847fc: eb0030d7 .0..
    80e84794: e1a00000 ....
    80e847fc: e1a00000 ....
    OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; mw.l 80e847a0 e1a00000; md.l 80e84808 1; md.l 80e847a0 1
    80e84808: 1a00000a ....
    80e847a0: 1a000004 ....
    80e84808: e1a00000 ....
    80e847a0: e1a00000 ....
    OMAP44XX SDP # booti 0x81000000
    kernel @ 80088000 (2693828)
    ramdisk @ 81080000 (1455055)
    Initrd start : 81080000 , Initrd end : 811e32afAcclaim Board.

    Starting kernel ...

    Linux version 2.6.35.7 (hREDACkvc@HCU1) (gcc version 4.5.4 (Ubuntu/Linaro 4.5.3-9ubuntu1) ) #1 SMP PREEMPT Wed Jan 4 02:43:18 IST 2012
    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
    On node 0 totalpages: 245760

    ..... Chopped ...............

    omapfb omapfb: Unknown ioctl 0x40044620
    init: Unable to open persistent property directory /data/property errno: 2
    enabling adb
    adb_open
    android_usb gadget: high speed config #1: android

    SO ALL OF YOU out there ITHCING to experiment with Custom Kernels and What not, Go ahead and enjoy the freedom to do so on NOOK TABLET (with UART access for NoW ;-)
    7
    PARTIAL SUCCESS BYPASSING SEC CHECK using NOP

    Hi

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