yashsingh1/xdaforums huggingface dataset:
[Barnes & Noble Nook Tablet] AdamOutler:
alright..

2850081 bytes read
kernel @ 80088000 (2682952)
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
�Ramdisk image has been corrupted , cannot boot

Simply unpacking and repacking the ramdisk changed it

-rw-rw-r-- 1 adam adam 158633 2012-01-02 11:41 newramdisk.img
-rw-rw-r-- 1 adam adam 159456 2012-01-02 11:41 ramdisk.img

I searched the flashingboot.img file for the ramdisk size in hexidecimal and did not get any results. Any recommendations?
[Barnes & Noble Nook Tablet] hkvc:
With the new flashing_boot.img in SD card.

Stop the uboot at the uart prompt, then

Try the sample uboot memory command sequence what I have explained in a previous post (for Ramdisk check bypass) and see if the location contains what I am assuming it should contain. If so overwrite it.

Next, As you are trying the sd card flashing_boot.img, change the mmcinit and booti commands from my original post to the new one specified below.

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

Even thou the ramdisk won't be copied fully, atleast it should pass the security check i.e shouldn't fail security check.

Update1: If this works, then from my previous, post you can take the offset of the ramdisk_size from the structure definition (it is at offset 16 in the file) and update the same in the flashing_boot.img. However initially for checking if NOP succeeded or not, this is not required.

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 matches the actual ramdisk. Then update the 0x10 offset of new img file with new ramdisk size.
[Barnes & Noble Nook Tablet] DeanGibson:
Correction !

I screwed up the order of the files in the last command; it should be:

cat ../zImage ../newramdisk.img >newflashing_boot.img

zImage should be first.

To answer your other question in the thread: Yes, a simple unpack/repack gives a different size (possibly due to using a different tool?).

I don't know if that's a factor in any problem (you can verify that by unpack/repack, and then reattaching the repack to zImage and see if it boots). However, if I pack/unpack (to a separate directory) an image and then do a "diff -r" on the two directories, there are no differences. So that means that the "repack" works, but the open question is, is the different size of the repack an issue?

Sorry for my screwup (and my screwed up private messages this morning)!
[Barnes & Noble Nook Tablet] hkvc:
If my offset wrong, get 16 bytes of dump around my specified offset, see you tomorrow

Hi Adamoutler,

90% the NOP based bypass logic which I have told, should work.

Also most probably the uboot mem commands which I have specified should work and more importantly the offsets which I have mentioned should be right.

If the specified offset 0x80e84808 contains wrong data/code, then as specified, provide 8 bytes before and 8 bytes after this offset (0x80e84808), then I will have a look into the binary and see what it maps to and inturn identify the correct offsets to patch.

I have to go offline now and go to sleep as tomorrow I have a early morning meeting. See you tomorrow and good luck. And thanks for moding ur NookTab for uart and running these.
[Barnes & Noble Nook Tablet] hkvc:
NOP Based BOOT BYPASS using UART access - new thread

Hi,

I have created a new thread for my NOP based BOOT Bypass logic, for people with UART access to NookTab. So that all the discussions and documentation corresponding to that particular mechanism of bootloader bypass can be in 1 seperate thread.

http://xdaforums.com/showthread.php?p=20964652
[Barnes & Noble Nook Tablet] hkvc:
SUCCESS SUCCESS SUCCESS with Modified Ramdisk

Hi All,

I just wanted to let everyone following this thread know that I have succeeded in booting with a modified RAMDISK using my simple NOP BYPASS logic.

The details are in the new thread I created to document this method.

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

and inturn I assume this post, (have to check, new to xda)

http://xdaforums.com/showthread.php?p=20975194

For impatient the short answer is =>

mmcinit 0; fatload mmc 0:1 0x81000000 new.recovery.img;

md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; md.l 80e84808 1; md.l 80e847a0 1

booti 0x81000000

NOTE: This assumes you have UART access to NookTab
[Barnes & Noble Nook Tablet] AdamOutler:
I think you meant to say:

#OMAP SECURITY BYPASS
#Copyright (C) 2012 hkvc

# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
mmcinit 0; fatload mmc 0:1 0x81000000 new.recovery.img;
md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; md.l 80e84808 1; md.l 80e847a0 1
booti 0x81000000

;)

Awesome work.
[Barnes & Noble Nook Tablet] CelticWebSolutions:
Does this mean we are good to go with modified roms or is it just a step closer to being able to?
[Barnes & Noble Nook Tablet] silentheero:
I think this is a step closer. We will be able to soon create 2.2-2.3 roms for the tab, but I think HC and ICS are still out of the question until we can replace the kernel and get the sec checks to pass it or bypass the sec checks.

Adam is still working on bypassing the sec checks, which would be the best choice, but hkvc's work is a great second choice!

Thanks to the both of you for your work!

I would be helping out, but I'm still raising funds. Soon, I think!
[Barnes & Noble Nook Tablet] hkvc:
Hi Adamoutler,

Unless

a) BN had not given such a closed Device (when I brought it on first day (for my self and for a friend of mine, who hardly buys stuff) with the faith that they will keep it open like Nook Color and Nook Simple touch) and inturn the retard decision of nuking sideloading

b) You and Others hadn't put this thread in place

c) The XDA moderators hadn't moved this from development to general (I don't see the need for it really, any development starts with ideas/concepts and this thread to me should have been seen has the ideation phase of solutions initially rather than moving it out of development)

I wouldn't have got the josh/kick to give a crack at it.

So thanks to you all and all these events.

And FINALLY to BN for actually giving a OPEN DEVICE when you look beyond the beauties, even thou the Outward appearance was CLOSED. IF it was a conscious decision of theirs or their developers, I thank them a 100 times, otherwise, I hope they keep slipping such things thro the cracks in their new products every once in a while

DONT understand why all the DEVICE MAKERS want to make such CLOSED devices these days, Majority of todays technically good people got here because they were able to tinker with the internals of the devices and s/w before long and understand it fully in every sense. With out it, we lose such good stimulus for people around, and even these Companies will find it hard to get good people in the long long run easily, if they only expose easy or simple programing languages to developers.

Sure have a locked device, but do allow people who want to experiment, the freedom to experiment by voiding the warranty if necessary legally.

ALSO I want to Thank TI (and its people) for BeagleBoard and PandaBoard and hope fully their NXTGEN Board with A15 (when it comes out, I am waiting ...), for keeping the tinkering spirit alive thro your efforts with these Open Boards.

Ignore my rant above and thanks to you all at XDA for such a lovely forum.
[Barnes & Noble Nook Tablet] sungod88:
This is awesome, I can say yea I was there when 3 dudes made it possible to do what we want with the nook tablet. You guys are awesome and congrats to hk for the bypass. Now let's get us some roms!
[Barnes & Noble Nook Tablet] CelticWebSolutions:
That’s great news! just a decent 2.3 rom is more than good enough to get these things working properly :)

Like has been said, thanks to everyone involved and lets hope a replacement rom comes out soon to get rid of all this stupid BN theming! Hopefully in the process it will allow us to have full Market access too :)

Keep up the good work and if there is anything any of us can offer to help you along I'm sure we'll all be glad to help where we can :)
[Barnes & Noble Nook Tablet] hkvc:
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 above seems to indicate that we should be able to run custom kernels on the NookTab if we have access to UART, and obviously, if the above set of commands are applied.

Bit more, but only minimal sufficient details in my thread on NOP BYPASS.

http://xdaforums.com/showthread.php?t=1425044
[Barnes & Noble Nook Tablet] Montisaquadeis:
So we as consumers are going to have to hardmod our nook tabs for uart access to be able to run a different kernel and in the proccess be able to access different and hopefully updated roms for our device using? At least thats what I am getting with the way things are looking at this time.
[Barnes & Noble Nook Tablet] AdamOutler:
As I said on page 1.

The hardware is locked at the hardware level. A hardware mod will be required. I've located some microchips which may be able to do the job. They cost $2 each. After programming, they will require 2 screws to be removed and 4 wires to be soldered.

I'm definately looking at this because any software solution we have come up with can be patched... however, we can always use the pre-signed xloader and u-boot from an sdcard and force the device to do our bidding.
[Barnes & Noble Nook Tablet] CelticWebSolutions:
hardware mods are all well and good for those of us that don't mind opening things up and soldering onto their pride and joy. The vast majority won't want to do that though so a software alternative will always be better even if it can be more potchy and chance getting the loophole closed by BN
[Barnes & Noble Nook Tablet] AdamOutler:
I agree.

We need a signed xloader or U-Boot for that. If you can get a blaze board Xloader with the Barnes and Nobel key, we can make it happen.

Our only current option is to exploit the available UART. I might just make an evil corperation frontend out of it... something like screwBarnesAndNobleAndTheirLockedBootloader.com. maybe then they will release the Xloader just to spite me.

BarnesAndNobel only has to release an unlocked bootloader and noone profits from the sale of goods and services to fix their product. I hope they are reading this.
[Barnes & Noble Nook Tablet] CelticWebSolutions:
Some how I doubt they are, and even if they did I don't think they currently care :(
[Barnes & Noble Nook Tablet] Zippy Dufus:
Barns and Nobel have another issue to consider in addition to safeguarding the Netflix stream - Microsoft. MS is currently suing B&N for their use of Android and B&N must be applauded for standing up to MS unlike Samsung, HTC, and many other hardware vendors who the racketeering MS has managed to extort a fee of between $5 and $15 dollars per Android device they sell. MS hates low-cost computing devices because they cannot bury the cost of their O/S in them. If (or rather when) the Nook Tablet can be fully modded, this will set a new benchmark in computing price/performance. But this is for another thread and let's not get this thread closed down.

I am avidly following these threads but it is going a little beyond me technically particularly with the discussion of UART.

Questions:

Is my understanding correct that the bootloader is almost circumvented with a modified ramdisk running and a modified kernel very close?

Also, does it look likely that this can be done without hardware modification?

BTW - great work devs! And sorry for the spurious post - but this is getting me excited! I have a Nook Color running Cyanogen 7 and it is fantastic.
[Barnes & Noble Nook Tablet] AdamOutler:
seemed to work

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

5678619 bytes read
OMAP44XX SDP # md.l 80e84794 1; md.l 80e847fc 1; mw.l 80e84794 e1a00000; mw.l 81
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 81
80e84808: 1a00000a ....
80e847a0: 1a000004 ....
80e84808: e1a00000 ....
80e847a0: e1a00000 ....
OMAP44XX SDP # booti 0x81000000
booti: bad boot image magic
OMAP44XX SDP # mmcinit 0; fatload mmc 0:1 0x81000000 new.hdr.img;
WARNING: voltage error, before MMC1 power reset

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

3204974 bytes read
OMAP44XX SDP # md.l 80e84794 1; md.l 80e847fc 1; mw.l 80e84794 e1a00000; mw.l 81
80e84794: e1a00000 ....
80e847fc: e1a00000 ....
80e84794: e1a00000 ....
80e847fc: e1a00000 ....
OMAP44XX SDP # md.l 80e84808 1; md.l 80e847a0 1; mw.l 80e84808 e1a00000; mw.l 81
80e84808: e1a00000 ....
80e847a0: e1a00000 ....
80e84808: e1a00000 ....
80e847a0: e1a00000 ....
OMAP44XX SDP # booti 0x81000000
kernel @ 80088000 (2682952)
ramdisk @ 81080000 (510447)
Initrd start : 81080000 , Initrd end : 810fc8cfAcclaim Board.

Starting kernel ...

Linux version 2.6.35.7 (build@dhabuildimage17) (gcc version 4.4.1 (Sourcery G++1
CPU: ARMv7 Processor [411fc093] revision 3 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP4430 ACCLAIM
[Barnes & Noble Nook Tablet] Entropy512:
I assume when you said AT-Mini, you meant ATTiny - Unfortunately this most likely might require a Mega, only because of the following:

1) UARTs are fairly rare on the ATTiny line (the 2313 is the only one I know of with a UART)

2) Because of 1), ATTinys with UARTs tend to be unobtainum or as expensive (if not moreso) than ATMegas with similar UART capabilities - believe me, a year or so ago I did a LOT of ATTiny/ATMega pricing to try and find the lowest cost-per-node of a device capable of receiving DMX... It proved far cheaper to have one device receive DMX and offload it to multiple cheaper devices via another bus (SPI or I2C) - since the cheap Tiny48s have hardware I2C but no UART.

While software "bitbang" UART is possible, if you are going for 115.2k, you need a hardware UART. :(

Not being able to find strings is not a guarantee that encryption is in play - keep in mind that most Linux kernels AND initramfses are compressed.

Unfortunately, unless you find some header "magic numbers" indicating standard compression (look for gzip headers and such - search around for initramfs extraction/repacking techniques and scripts), it's really hard to tell the difference between "compressed" and "encrypted" - both have the end result of removing redundancy in the data, flattening the histogram if you do a byte-by-byte histogram analysis.
[Barnes & Noble Nook Tablet] hkvc:
POLL - SHould I Exploiting a fundamental BUG in secure boot chain - TODO or NOT do

Hi,

If someone has gone thro my posts over the last few days, and read between the lines and all the info I have put out there, there is a mechanism to achieve secure boot chain breaking with out uart access or even .... but I have purposefully kept it bit spread out and indirect because I am of the opinion that I should use it for a FUTURE PRODUCT, because NOOKTAB is already sufficiently OPEN in all sense, and still there is the KERNEL MODULE PATH to exploit/experiment.

Give your feedbacks and vote on the poll.

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

Based on all the feedbacks and polls as well as further thinking on my part and may be bit more experimentation, I will take a call on whether to specify the flaw directly or provide a alternate method (may be using Kernel module) or ....
[Barnes & Noble Nook Tablet] hkvc:
SUCCESS SUCCESS SUCCESS with CUSTOM Kernel+ CUSTOM Ramdisk, UART NOP BYPASS

Hi All,

Yesterday night, I had verified the possibility of Custom Kernel on NOOKTAB with UART access indirectly (why indirect, it is in my other post). However now I have actually run a img file with my Custom Kernel and Custom Ramdisk and successfully run it on Nook Tab with my earlier mentioned UBoot Commands.

I was 90% sure of this yesterday night itself, however for any skeptics out there, as well as to be 100% sure I have cross verified it directly myself. I will upload the simple c program and shell scripts I wrote for unpacking and repacking the BN Android img files shortly in my NOP BYPASS thread. Nothing special in these scripts or program, I am uploading just in case someone wants to use it.
[Barnes & Noble Nook Tablet] CelticWebSolutions:
So realistically we're good to go then? If you can already run custom ramdisk and kernel we could possibly run a custom rom with a modified gingerbread or with the different kernel we could have HC or ICS ? or am I totally missing something here? If that's the case the other security flaw you have mentioned can be held onto until it's required for something later on instead of releasing it now?
[Barnes & Noble Nook Tablet] cfoesch:
Except the UART has to be attached at every boot.
[Barnes & Noble Nook Tablet] CelticWebSolutions:
Oh... that’s no use if you're away from a computer. I'm guessing it's like a tethered jailbreak on an iPhone then. Not practical for people who use their tablet away from a computer which in my opinion is why many people have the tablet in the first place, easily portable. Shame :( Thought somebody had cracked it then!
[Barnes & Noble Nook Tablet] AdamOutler:
Grand news here: http://bookclubs.barnesandnoble.com/t5/forums/postsuccesspage/board-id/NTIdeas/message-id/266

Status of "Release open-ended, signed xLoader" was changed to acknowledged. This is wonderful news... However, what am I going to do with all these ATTinys I ordered?

Lets hope we see this one through.. They can easily disable M-Shield extensions from the xLoader and remove our ability to exploit netflix though... Oh well... It would be a good marketing move for them because if we keep up at our current rate, I foresee some major hacking in areas they don't want us. Releasing a signed xLoader would keep us moving in the path of least resistance and development would be focused on AOSP Android 4.0, Cyanogenmod and other areas.

Don't get me wrong, I'm still interested in persuing a crack that would let us use the M-Shield functionality, but I'd probly be the only one..
[Barnes & Noble Nook Tablet] hkvc:
Thats good news, and the secret can remain secret too :-) and linboothkvc

Hi AdamOutler/All,

That is wonderfull news you have there from BN side. Hopefully they will come to their senses and open up the Device. I am sure, quite a lot of people on xda will be happy to sacrifice netflix to gain a open device.

Lets hope for the best.

NOTE: I have also started on my linboothkvc (minimal kexec with out kexec - how wants kexec by the way ;-). The going will be bit slow, as I have some work coming up in next few days. But I will try and spend some time on it, if nothing turns up from BN side over next few days or weeks.
[Barnes & Noble Nook Tablet] cfoesch:
Quite agreed. They can release an unlocked bootloader that doesn't let us use the netflix app, and "hurrah!" We won't be working crosswise to them keeping netflix closed while we're just trying to run a custom ROM.

Most of the people who are interested in running a custom ROM don't care much about HD netflix anyways. We're crazy computer geeks who already have a 21" monitor, and a 30" LCD TV to watch HD content.
[Barnes & Noble Nook Tablet] The_Joe:
If I didnt know better I would fear that you were looking in my window!

I have my 30 inch LCD right next to my 21" inch monitor, the laptop near by them, your post made me laugh.

I would 100% support b&n removing the ability to stream HD netflix (Even more so if I could still steam normal netflix) if it meant an un-locked tablet. Anyone that said Adam was not going to get anywhere trying the front door was very wrong.
[Barnes & Noble Nook Tablet] clnook:
Acknowledged doesn't mean they'll necessarily do anything....I wouldn't hold my breath. Full speed ahead on all other fronts I say.
[Barnes & Noble Nook Tablet] AdamOutler:
You're right. However, at least this means its been triaged and it's no longer New and unacknowledged. I'm still working.

And what's this about 21 and 30 inch? I have Dual 23/20 inch monitors and a 50" plasma TV for my media center next to that. I find Plasma to be much more appealing to the eye than LCD/LED technology.
[Barnes & Noble Nook Tablet] dang69:
Excellent reflections Adam. This is the point when BN can decide if they want to remain engaged with the dev community or be cut out entirely. If I was Netflix I'd be saying "release the xloader to keep some form of control". By not releasing it BN is forcing a level of development which jeopardizes netflix security. If they really want to honor the commitment to netflix they'll release it. If I was them I'd release it pretty darn quick judging by what's going on in other threads.
[Barnes & Noble Nook Tablet] Indirect:
The funny part is, by not releasing, they have no way to know who uses our form of hacks as they are easily reversed while with an insecure loader, they can have it install an app or system log that nook techs can identify...
[Barnes & Noble Nook Tablet] hkvc:
Enable debug clocks (trace & STM)

Hi Adamoutler/All,

I remember you mentioning that you were not able to get anything on JTAG on NookTab. However sometime back when I was configuring my custom kernel for NookTab, I noticed this configuration entry for Omap4.

It seems to indicate that even if this is not enabled, there is a way to enable the same using defugfs at runtime. I think debugfs is enabled in NookTab (if not you can always run a custom kernel now :-), so you may want to search around based on this to see, how to get it enabled at runtime, so that you can use ur JTAG modded NookTab fruitfully hopefull ;-)

CONFIG_OMAP4_PMD_CLKS_ENABLE:

Select this option to enable l3_instr_ick, l3_main_3_ick and

ocp_wp_noc_ick at boot-time, which are needed for debugging on OMAP4.

Even without this option set it is possible to enable these clocks

at run-time via debugfs.
[Barnes & Noble Nook Tablet] AdamOutler:
The point of JTAG is to be used on a fully dead device. We have UART to debug the uboot and kernel. The thing is, we need a way to activate the JTAG chain from the hardware level. I suppose we could do that manually with registers, but that would be a pita. We need to get a the official flashing_boot.img. Even one of these mod chips would be way more cost effective than JTAG.

Generally, for developers, we want to stay away from JTAG,its a one-time repair option for the most part.
[Barnes & Noble Nook Tablet] Loglud:
So one of the things that i have been reading is about the boot.img, which can be repackaged with the kernel that is included in the recovery. you can pull them appart and using mkbootimg we can create a new boot img. Its also possable to use second init to load a new ram disk into memory. I have an idea on getting android to boot a stock 2.3 rom, but we will have to use the existing kernel (not a huge issue)