[DISCUSSION] on the boot loader [CRACKED!] - Barnes & Noble Nook Tablet

Alright, now that Adamoutler finally posted (I was waiting on that) I can now explain what we're going to try to do. You all know the unbrickable mod for a few samsung devices? The guy who did that wants to help us out but he needs a nook tablet. Anyway, what it does is completely disable hardware security and allows the flashing of a new bootloader. That's about as simple as I can make it. I would love to see this happen so hopefully, we can make it.
Question is, who's giving up a tablet?
Note:
Code:
This is not a thread to come in and complain saying that you're going to take it back. That's not our problem nor is it our concern. We need a place where we can have organized information about the bootloader and you telling us "I HATE IT, I need to return it!" doesn't help that.

---

If someone (me) wanted to get involved in this, how would I go about doing so? I know enough about linux, but nothing about Android programming. Is there somewhere I can start learning? I'd like to contribute to this if I am able.

---

http://forum.xda-developers.com/showthread.php?t=1366215
+
http://forum.xda-developers.com/showthread.php?t=1378919
I think you can through the service mode to replace the keys which the employee to sign the firmware and tested.

---

hobbit19 said:
http://forum.xda-developers.com/showthread.php?t=1366215
+
http://forum.xda-developers.com/showthread.php?t=1378919
I think you can through the service mode to replace the keys which the employee to sign the firmware and tested.
Click to expand...
Click to collapse
According to information from TI about the M-Shield security features of this chip, the "secure on-chip keys (E-Fuse) are OEM-specific, one-time-programmable keys accessible only from inside the secure environment for authentication and encryption". Protecting against that kind of key replacement is a big part of how this chip was designed. Finding out the private is likely to be the only way to create valid signed images of our own
Here is the source for that quote.

---

Indirect said:
Botnets are typically used under illegal reasons / methods. Im not talking about [email protected], im talking about stormworm, etc.
Sent by breaking the sound barrier
Click to expand...
Click to collapse
I know what you mean, but what _I_ mean is that botnets CAN be used for other things than illegal hacking and malicious intent. They can replace a supercomputer, as [email protected] proves. I think I have seen a similar initiatives for cancer research and DNA research, though I don't know the names of those projects.

---

notes
Hopefully this doesn't lead to any red herrings. I haven't been looking at this stuff very long.
"arm.com" has some info on the processor.
TI licensed the processor design from ARM. It's an ASIC, not really a cpu chip.
You have to agree to a non-disclosure to see the docs on arm.com.
After reading about it, not sure that the dual cpu is actually getting used like folks think. There may be two systems actually running.
The arm docs hint that it may be the hash key that actually gets stored on the asic not a private key and that there may be more than one. TI may have designed in their own protocol which is the M-Shield trademark.
TI doesn't exactly give out much info on it. The ARM site is a lot more informative. It doesn't cost anything to access it other than giving away your email address and agreeing to the nondisclosure.
In particular look for these documents:
DDI0406C_arm_architecture_reference_manual.pdf
DEN0013B_cortex_a_series_PG.pdf (chapter 26)
PRD29-GENC-009492C_trustzone_security_whitepaper.pdf
You can also review the source code for the tablet.
See the following exerpts:
distro\x-loader\lib\board.c
image.image = 2;
image.val = 99;
SEC_ENTRY_Std_Ppa_Call ( PPA_SERV_HAL_BN_CHK , 1 , &image );
if ( image.val == 0 )
{
/* go run U-Boot and never return */
printf("Starting OS Bootloader from %s ...\n", boot_dev_name);
((init_fnc_t *)CFG_LOADADDR)();
}
distro\u-boot\common\cmd_bootm.c
function do_bootm
...
U32 SEC_ENTRY_Std_Ppa_Call (U32 appl_id, U32 inNbArg, ...);
\x-loader\board\omap4430sdp\omap4430sdp.c
...
There are several calls to the SEC_ENTRY_Std_Ppa_Call function.
One (or two) for each image block being loaded.
I think these are the calls to the security layer..
SEC_ENTRY_Std_Ppa_Call ( PPA_SERV_HAL_BN_CHK ,...
They took the crc32 validation out in various places in the code. I suspect that if it is a signed key that if the image doesn't process out to the end key, then the crc2 would have failed anyway.
Has anyone actually checked what the "key" is? Could it be a crc or checksum?
The "_BN_" I assume is for barnes and noble.
Looking at "omap4_hs.h", it looks like that function can do a callback into the secure area and execute up to 32 different functions, though I'm guessing from the list in the file that BN only added two - INIT and CHK.
There is also a reference in that file to "Development CEK". Could this be the private key? Not the hash, just one part of the key? I'm by no means up on crypto algorithms.
/*
Defines from MShield-DK 1.2.0 api_ppa_ref.h
Make sure these align with the existing services in PPA.
*/
// Number of APIs
#define NB_MAX_API_HAL 32
// command / api keys
PPA_SERV_HAL_CPAUTOLOAD
PPA_SERV_HAL_CPINIT
PPA_SERV_HAL_CPSWRV
PPA_SERV_HAL_CPMSV
PPA_SERV_HAL_CPREPORT
PPA_SERV_HAL_CPCEK
PPA_SERV_HAL_TEST_API
PPA_SERV_HAL_BN_INIT
PPA_SERV_HAL_BN_CHK
/* Development CEK */
#define CEK_3 0x01234567 //127_96
#define CEK_2 0x89ABCDEF // 95_64
#define CEK_1 0x11121314 // 63_32
#define CEK_0 0x15161718 // 31_0
Another question I have, what level of GPL does android use?
The simple fact that they linked in the M-Shield function calls may be enough to force the release of that source as well. The latest GPL has a pretty nasty copy left. It may be in that archive already too. I haven't gotten through much of it yet.
And is it true that this tablet has a different wifi chip and thus doesn't have the fm and bluetooth available to it?
The brute force idea might work except that you'd have to do it on a nook tablet. You have to validate a data block using that function call.
Figuring out how to automate it through that security layer might be a bit troublesome. If you could call that function directly, maybe, but I suspect that it is only accessible from one side of the architecture. But that might also be why the tablet has so much memory dedicated to B&N and not split evenly. Maybe the bigger chunk of the memory is all in the secure side?
I have to say the OMAP4 is a pretty neat layout. Has a huge potential for corporate ethical abuse but technically it really is cool. They are going through a lot of hoops to keep this tablet locked down. I found one whitepaper on the netflix issue. Netflix apparently has a whole massive requirements list and this was the first tablet to meet it. I'm not sure netflix isn't overvaluing their product. There are other ways they could have done this versus locking the whole tablet down. They could have put the netflix app as a service in the secure side and just signed that part of the application. They could have still allowed the secondary bootloader in the unsecure area to be whatever the user wanted. I don't think they thought through the ethical notions of it all. But maybe they did and they just want to control something like apple is doing. Apple was defeated once by a lower cost, open architecture. History will repeat itself. It's a shame B&N's didn't go that route instead. If it wasn't for this one issue, they would have had a much better platform to work from than the fire.

---

Asking others for the info / ideas on bootloader isn't related to development. Hence moved to general
cheers,

---

I've been sitting back watching this thread for a while now. It's time to stop this foolishness. First off, the first post was started with absolutely no information.. basically 'you know what would be cool?'.. then the rest of the discussion has been a bunch of randomness. Why has not a single person mentioned the datasheets for the processor or memory? Why has Boone posted a memory dump of IROM? This thread contains nothing useful.
UnBrickable mod is the way to go. Put a device in my hands and ill enable it to boot from USB or sdcard. The device uses a hardware initiates boot chain. This chain can be broken at the hardware level.
This is an omap4430 device right?
Give me a device. Rebellos and I will locate the boot mode 5 pin which unlocks the boot from one NAND. We will then require an interceptor bootloader which is where Rebellos specializes. Once we hardware unlock the device and the interceptor bootloader is in place, the device will accept an insecure bootloader flash.

---

Adam, I can try and get you a nook tablet.
Also, I was waiting for you to post that. I wanted to leave this up to the community to see what could be thought of. Surprised hardware modification never came up. :|

---

AdamOutler said:
I've been sitting back watching this thread for a while now. It's time to stop this foolishness. First off, the first post was started with absolutely no information.. basically 'you know what would be cool?'.. then the rest of the discussion has been a bunch of randomness. Why has not a single person mentioned the datasheets for the processor or memory? Why has Boone posted a memory dump of IROM? This thread contains nothing useful.
UnBrickable mod is the way to go. Put a device in my hands and ill enable it to boot from USB or sdcard. The device uses a hardware initiates boot chain. This chain can be broken at the hardware level.
This is an omap4430 device right?
Give me a device. Rebellos and I will locate the boot mode 5 pin which unlocks the boot from one NAND. We will then require an interceptor bootloader which is where Rebellos specializes. Once we hardware unlock the device and the interceptor bootloader is in place, the device will accept an insecure bootloader flash.
Click to expand...
Click to collapse
I figured youd be here when the final specs on the Nexus Prime were released, and they used the OMAP4460 which is ironically very simmalir to the OMAP4430.
Thanks for your help and let us know if theres anything we can help you with.

---

Just for your all's information, Adam will have one in a day or two it has already been shipped.

---

AdamOutler said:
Give me a device. Rebellos and I will locate the boot mode 5 pin which unlocks the boot from one NAND. We will then require an interceptor bootloader which is where Rebellos specializes. Once we hardware unlock the device and the interceptor bootloader is in place, the device will accept an insecure bootloader flash.
Click to expand...
Click to collapse
I'm curious what you're getting at here.
SYSBOOT[5] selects between boot lists that put external type devices first and internal type devices first. I don't have a NT anymore, but I suspect the boot list is 0b010110, or USB->UART->MMC1->MMC2. Setting SYSBOOT[5] high would change the order to MMC2->USB->UART->MMC1.
All the above boot modes, and all others requiring a config header will need to pass the signature check before the OMAP will boot it.
The only boot mode that doesn't do config header checks is fast external boot (NORflash style), and the TRM has this to say:
The fast external boot is a special memory booting mode, possible only on GP devices. It consists of a blind jump to a code in an external XIP memory device connected to GPMC CS0. Fast external booting is set up by means of the SYSBOOT configuration pins and lets customers create their own booting code.
Click to expand...
Click to collapse
Not applicable of course since this is an HS part, and it would be painful to wire up external memory to boot this way.
Now, if you were to strip out the secure headers from the MLO and u-boot and throw them on a GP 4430 platform like a Pandaboard, you could start hunting for an attack. I can't remember if this u-boot reads any variables from unsecured parts of the flash, but if so there might be some buffer overflow magic waiting to happen.
Not trying to crap on your plans, just making sure you know the score before you commit to this.

---

Hardware mod
JoeM01 said:
Can this in fact be replicated by someone who is NOT necessarily a dev, but isn't afraid of cracking open a device and going to work with a soldering iron?
Click to expand...
Click to collapse
It depends ...
Assuming for the purpose of discussion that all you need to do is (un)ground an external pin, the difficulty can range from:
Getting access to a ball-grid-array device on a multi-layer board (effectively impossible).
Lifting a pin on a surface-mount chip (easy with the right tools and some skill).
Cutting a trace or soldering a jumper (easy with the right tools and some skill).
(Un)grounding at a solder pad pair (easy).
While the last is not likely, it happens. A case in point:
When IBM released a parallel port board for the original IBM PC, they also released the schematic in the technical reference manual for the PC. The schematic showed that the data buffer buffer chip was bidirectional (74LS374), but its ^OE (output-enable) pin was grounded (active-low logic), in effect making the parallel port output-only.
When the clone-makers replicated the parallel port from the IBM schematic, they all replaced the 74LS374 chip with one that was not bidirectional (a 74LS274, as I recall), saving a tiny bit of money.
However, you you actually had one of IBM's parallel port cards, you noticed that the ground trace on the 74LS374 was not grounded next to the chip (as would normally be expected), but ran a couple inches across the board to a "via", and then grounded in a short trace run. That "via" was exactly 0.1" away from another "via" that was connected to an "unused" bit on the control chip. In other words, a simple trace cut of the final ground run, followed by the installation of standard 0.1' spacing header pins (or a simple jumper) at the "via"s, would convert the parallel port to be bidirectional. Which I did at the time.
Several years later, when IBM modified their BIOS to support bidirectional parallel port operation, they introduced a new parallel port card. The above modification to the old ones worked, but all the clone parallel cards were obsolete.
So, I would not put it outside the realm of possibility that B&N provided a solder pad to be able to disable the signed bootloader feature.
I would also not put it outside the realm of possibility that instead, the hardware modification is very, very difficult, even with the right tools.
Then there is the software issue still to be fixed. Certainly worthy of investigation, but don't get your hopes too high (especially before Christmas).

---

The best way to think of this hardware unlock, is that the nook is like a building, there are lots of rooms we can get into, but there are also rooms that we cannot. What I assume is adam will get into those rooms, and there might be ways to turn off the power to certain rooms, and or put something in the water. This might allow us to make a software mod that will effect the rooms .
rooms .

---

pokey9000 said:
I'm curious what you're getting at here.
SYSBOOT[5] selects between boot lists that put external type devices first and internal type devices first. I don't have a NT anymore, but I suspect the boot list is 0b010110, or USB->UART->MMC1->MMC2. Setting SYSBOOT[5] high would change the order to MMC2->USB->UART->MMC1.
All the above boot modes, and all others requiring a config header will need to pass the signature check before the OMAP will boot it.
The only boot mode that doesn't do config header checks is fast external boot (NORflash style), and the TRM has this to say:
Not applicable of course since this is an HS part, and it would be painful to wire up external memory to boot this way.
Now, if you were to strip out the secure headers from the MLO and u-boot and throw them on a GP 4430 platform like a Pandaboard, you could start hunting for an attack. I can't remember if this u-boot reads any variables from unsecured parts of the flash, but if so there might be some buffer overflow magic waiting to happen.
Not trying to crap on your plans, just making sure you know the score before you commit to this.
Click to expand...
Click to collapse
I know the score. We had the same problem to deal with on the Hummingbird processor. What we ended up doing is exploiting a memory jump and redirecting the boot sequence. Rebellos can explain the inner working of the Hummingbird Interceptor Bootloader. Performing a total secure boot would tax the processor greatly and I believe that they likely just have a check in place on the first few bytes. It is possible to modify a bootloader to jump to a memory location which is unsecure. Using this technique, it may be possible to run Galaxy Nexus bootloader or Kindle bootloaders on the device.
So, lets get started with a IROM dump.
I need someone with a rooted device to get a memory dump for me please. This will be a snapshot of the live memory running on the device.
in order to do this:
place this binary on your internal storage http://blog.maurus.be/wp-content/uploads/viewmem
use market app "Mount /system (rw/ro)" https://market.android.com/details?id=com.beansoft.mount_system to mount your system folder RW
use market app "terminal emulator" https://market.android.com/details?id=jackpal.androidterm and type the following
Code:
su
cat /sdcard/viewmem > /system/bin/viewmem
chmod 1777 /system/bin/viewmem
exit terminal and restart terminal app
Now Viewmem is setup.
run this to get a dump
Code:
su
viewmem 0x40030000 0xC000>/sdcard/40030000Dump
and
Code:
viewmem 0x40028000 0xC000>/sdcard/40028000Dump
This will place two 48kb (or 0xC000 in hexidecimal length) files on your sdcard called ########Dump. Put these files onto your desktop into a zip form and upload them here.
I need both of these dumps because the processor manual has an obvious error in it... So I'm asking for the values for the 4460 processor as documented and the 4430 processor which may be the same... however they are documented differently.
These are Internal ROM boot dumps. They are important to figure out what is going on inside a on boot up and may reveal secrets. I'll try to get some strings and other data from these dumps and then I'll pass them over to Rebellos for analysis.

---

Doing the memory dump now.
Got this error on the first one:
[INFO] Reading 49152 bytes at 0x40030000...
[1] Bus error viewmem 0x40030000 0xC000 >/sdcard/40030000Dump
Only the 2nd one dumped properly.
http://dl.dropbox.com/u/15069134/40028000Dump.zip

---

AdamOutler said:
I know the score. We had the same problem to deal with on the Hummingbird processor. What we ended up doing is exploiting a memory jump and redirecting the boot sequence. Rebellos can explain the inner working of the Hummingbird Interceptor Bootloader. Performing a total secure boot would tax the processor greatly and I believe that they likely just have a check in place on the first few bytes. It is possible to modify a bootloader to jump to a memory location which is unsecure. Using this technique, it may be possible to run Galaxy Nexus bootloader or Kindle bootloaders on the device.
So, lets get started with a IROM dump.
I need someone with a rooted device to get a memory dump for me please. This will be a snapshot of the live memory running on the device.
in order to do this:
place this binary on your internal storage http://blog.maurus.be/wp-content/uploads/viewmem
use market app "Mount /system (rw/ro)" https://market.android.com/details?id=com.beansoft.mount_system to mount your system folder RW
use market app "terminal emulator" https://market.android.com/details?id=jackpal.androidterm and type the following
Code:
su
cat /sdcard/viewmem > /system/bin/viewmem
chmod 1777 /system/bin/viewmem
exit terminal and restart terminal app
Now Viewmem is setup.
run this to get a dump
Code:
su
viewmem 0x40030000 0xC000>/sdcard/40030000Dump
and
Code:
viewmem 0x40028000 0xC000>/sdcard/40028000Dump
This will place two 48kb (or 0xC000 in hexidecimal length) files on your sdcard called ########Dump. Put these files onto your desktop into a zip form and upload them here.
I need both of these dumps because the processor manual has an obvious error in it... So I'm asking for the values for the 4460 processor as documented and the 4430 processor which may be the same... however they are documented differently.
These are Internal ROM boot dumps. They are important to figure out what is going on inside a on boot up and may reveal secrets. I'll try to get some strings and other data from these dumps and then I'll pass them over to Rebellos for analysis.
Click to expand...
Click to collapse
Adam,
If no one has done this by the time i get home, I will do it for you. I will be on IRC tonight for some of the night and will be able to do whatever you need.

---

I just did it loglud, no worries.

---

I'm seeing the following strings in the boot dumps:
Code:
pGpGpGpG
@ABCDEGKJ
CHMMCSD
CHFLASH
CHRAM
PRIMAPP
X-LOADER
CHSETTINGS
KEYS
ISSW
It's not much to go on, but I'd expect to see something on UART from this.
Both of the files are the same. 49.2kB. http://dl.dropbox.com/u/15069134/40028000Dump.zip
however, those are just the complete strings... there's more..
Code:
Texas Instruments
Nokia
Motorola
OMAP4430
NOKIA USB ROM
BLANK
OMAP4430 N/A
N/A
PCB
PCI
R&D
2nd
CH
HLO
MLO
ULO
This NOKIA USB ROM looks interesting.

---

That's so strange i wonder what it is pointing to because from what i see there's no a single Nokia part in the entire device. You think its just the rom driver they use to flash the OMAP's Rom?