[DISCUSSION] on the boot loader [CRACKED!]

AdamOutler · Dec 13, 2011

jtbnet said:
From http://nookdevs.com/index.php?title=Portal:NookTablet&action=history it llooks like fattire setup this page and most of it's content... on here there is a boot log/file dump that seems to have been done from the uart/serial port so might want to ask fattire where this came from... this boot log is where I found the most promising info on the Wireless chip having it's driver init'd so would seem Bluetooth is present based on the chip... don't know what antenna pins are connected though....

I think the page you wanted to reference was here: http://nookdevs.com/index.php?title=Portal:NookTablet&oldid=22155

Here it is: http://paste.ubuntu.com/740881/ Very cool.

xloader starts from lines 1-3 which launches uboot (Bootloader).
Bootloader performs several checks. Initializes DRAM, UART, MMC, and max17042. max17042 is the Power Management Integrated Circiut.

The PMIC init is from lines 19-49.
I'm not sure what the values from 50-64 are, but they are loading and verifying data of some kind and line 64 says everything is verified on the PMIC.
Line 65 says the System On a Chip, OMAP4430 is 90% booted.
Line 66 shows efused board revision.
I'm not sure if lines 67 and 68 are waiting for initialization of the MMC or if the Uboot is some custom version.. Either way they don't seem relevant.
Line 70 begins reading of the PIT.
The pit is read from lines 71-81..

Code:

ptn 0 name='xloader' start=256 len=131072
ptn 1 name='bootloader' start=512 len=262144
ptn 2 name='recovery' start=1024 len=15728640
ptn 3 name='boot' start=32768 len=16777216
ptn 4 name='rom' start=65536 len=50331648
ptn 5 name='bootdata' start=163840 len=50331648
ptn 6 name='factory' start=262144 len=387973120
ptn 7 name='system' start=1019904 len=641728512
ptn 8 name='cache' start=2273280 len=446693376
ptn 9 name='media' start=3145728 len=1073741824
ptn 10 name='userdata' start=5242880 len=64991232

These lengths and starts don't seem to line up. I wonder why that is.

line 82-again an mmc read failed.. this is odd.

84 reads some bytes, but from where?
85 What is a BCB?
Lines 87-91 attempted to use a device but was unable
Line 92 booting into android.. I am wondering if this is the start of a new partition.. Maybe it is bootdata, or maybe it is simply loading the kernel.

93,94, more invalid reads

97, bootcnt 2.. This is obviously boot count and line 99 writes one byte, probly to increment boot count again.

line100 looks very interesting, like we might be able to get some sort of UART control over the device.
on 101-105 the kernel and swap is loaded
Kernel is started at line 107
A shell prompt is obtained at line 624! Awesome
And from there on all I have to say is cool story bro.. TMI.

This looks interesting. Any idea what he did to get to this point?

AdamOutler · Dec 13, 2011

I just received a PM..

150pilot said:
Found this here: USB to UART
Can I change the boot device order to use Uart instead of USB?
By adding a 3.3K Ohm resistor to R119 on the PandaBoard, the primary boot device will change from USB to UART. See the OMAP4430 TRM for sys_boot details and the PandaBoard Schematic for resistor options.

OMAP 4430 Schematics See page 6 for R119.

Some other links I found interesting:

http://www.omappedia.com/wiki/Android_eMMC_Booting

http://www.omappedia.com/wiki/Android_Build_Booting

Block Diagram

Charles Shay
aka 150pilot

A bit more on the partitions from http://www.omappedia.com/wiki/Android_eMMC_Booting

Code:

    MLO --> x-loader/MLO
    u-boot --> u-boot/u-boot.bin
    boot.img --> need to create using zImage + ramdisk.img
    recovery.img ---> need to create using zImage + ramdisk-recovery.img
    system.img --> $mydroid/out/target/product/<platform>/system.img
    cache.img -->
    userdata.img --> $mydroid/out/target/product/<platform>/userdata.img

jtbnet · Dec 13, 2011

silentheero said:
Ouch. You know- and I speak with the same knowledge that a caveman has about the inner workings of a Rolex- I was reading the white papers on the OMAP and it did mention about security measures that would lock down the chip in the event of suspicious tampering. Are you guys past this restriction or is that what borked you Loglud?

No trip of 'hidden' security measures... Just basic DON'T OVERWRITE the default recovery partition as it's required and NOT meant to be written to... Now we know... So an advance in knowledge due to loglud's effort and sacrifice... luckily he paid for extended warranty/insurance so just an 18 hr.s hiccup and royal pain/waste of time to return for him...

Loglud · Dec 13, 2011

jtbnet said:
No trip of 'hidden' security measures... Just basic DON'T OVERWRITE the default recovery partition as it's required and NOT meant to be written to... Now we know... So an advance in knowledge due to loglud's effort and sacrifice... luckily he paid for extended warranty/insurance so just an 18 hr.s hiccup and royal pain/waste of time to return for him...

I figured it would happen but im just having fun doing this.. ill get a new one tomorrow, and brick it again and then same thing...

Our greatest glory is not in never failing, but in rising every time we fall.
-- Confucius

AdamOutler · Dec 13, 2011

Loglud said:
Yeah dont do this its bad... I make 250$ brick

I have a couple of questions. I'm on a galaxy tab 7 so excuse my bad typing.

Will is enumerate usb with any key combinatios ?
What command did you execute?
Does it show any signs of life or just act like it has no battery ?
Can you just take it back to a barnes and noble store and get a new one?
Have you previously verified the validity of that file?
Is there actually a restore sd?

It would be helpful to find out if the same thing would happen by flashing the kernel partition.

Loglud · Dec 13, 2011

AdamOutler said:
I have a couple of questions. I'm on a galaxy tab 7 so excuse my bad typing.

Will is enumerate usb with any key combinatios ?
What command did you execute?
Does it show any signs of life or just act like it has no battery ?
Can you just take it back to a barnes and noble store and get a new one?
Have you previously verified the validity of that file?
Is there actually a restore sd?

It would be helpful to find out if the same thing would happen by flashing the kernel partition.

Yeah i wish i could fix it to fu** around with it more. Bur i havent had time. Adam i am on IRC if you want. I did your dd commands, and wrote over the block with a kernel, and mad a backup to an SD card. The validity was that i compiled it using the defs by BN.

Yeah i bought the accidental protection plan, so i can do what ever i want woot.

pokey9000 · Dec 13, 2011

AdamOutler said:
I think the page you wanted to reference was here: http://nookdevs.com/index.php?title=Portal:NookTablet&oldid=22155

Here it is: http://paste.ubuntu.com/740881/ Very cool.

That would be mine. For more good bedtime reading look at the #nookcolor logs between 11/16 and 11/17.

xloader starts from lines 1-3 which launches uboot (Bootloader).
Bootloader performs several checks. Initializes DRAM, UART, MMC, and max17042. max17042 is the Power Management Integrated Circiut.

That's the battery monitor. The TWL6030 or something like that is the PMIC.

The PMIC init is from lines 19-49.
I'm not sure what the values from 50-64 are, but they are loading and verifying data of some kind and line 64 says everything is verified on the PMIC.
Line 65 says the System On a Chip, OMAP4430 is 90% booted.

SOC = State Of Charge. This is where u-boot decides whether to finish booting or hang out while a flat battery charges.

Line 66 shows efused board revision.
I'm not sure if lines 67 and 68 are waiting for initialization of the MMC or if the Uboot is some custom version.. Either way they don't seem relevant.

This u-boot will probe for an MBR and then look for FAT in partition 1 before trying to boot from a GPT formatted flash. This is the fallout I guess.

Line 70 begins reading of the PIT.
The pit is read from lines 71-81..

Code:

ptn 0 name='xloader' start=256 len=131072
ptn 1 name='bootloader' start=512 len=262144
ptn 2 name='recovery' start=1024 len=15728640
ptn 3 name='boot' start=32768 len=16777216
ptn 4 name='rom' start=65536 len=50331648
ptn 5 name='bootdata' start=163840 len=50331648
ptn 6 name='factory' start=262144 len=387973120
ptn 7 name='system' start=1019904 len=641728512
ptn 8 name='cache' start=2273280 len=446693376
ptn 9 name='media' start=3145728 len=1073741824
ptn 10 name='userdata' start=5242880 len=64991232

These lengths and starts don't seem to line up. I wonder why that is.

starts are in 512b blocks, lengths are in bytes

line 82-again an mmc read failed.. this is odd.
84 reads some bytes, but from where?
85 What is a BCB?

bootloader control block. This is how Android tells the bootloader to go into recovery or do other stuff.

Lines 87-91 attempted to use a device but was unable
Line 92 booting into android.. I am wondering if this is the start of a new partition.. Maybe it is bootdata, or maybe it is simply loading the kernel.

93,94, more invalid reads

97, bootcnt 2.. This is obviously boot count and line 99 writes one byte, probly to increment boot count again.

line100 looks very interesting, like we might be able to get some sort of UART control over the device.

Yes, if you have a serial port you can stop u-boot and **** around.

on 101-105 the kernel and swap is loaded
Kernel is started at line 107
A shell prompt is obtained at line 624! Awesome
And from there on all I have to say is cool story bro.. TMI.

This looks interesting. Any idea what he did to get to this point?

Solder.

hwong96 · Dec 13, 2011

Line 441 Disabling unused clock "efuse_ctrl_cust_fck"
Does this mean efuse lock is not utilized?

AdamOutler · Dec 13, 2011

hwong96 said:
Line 441 Disabling unused clock "efuse_ctrl_cust_fck"
Does this mean efuse lock is not utilized?

eFuses are not always security related. Example.. the device uses eFuse to identify the manufacturer of the chip (texas Instruments) and the type of board PVT. Also, eFuses are used for storage of alot of other information... such as what parts of the processor are used, camera, face recognition, jpeg processing... each of these have a dedicated eFuse which the manufacturer may or may not choose to blow. If an eFuse is blown, then it will always be blown.

Keep this in mind. Just because it's eFused, does not mean it's secure. I have yet to see anything in the UART boot sequence, processor manual, or any other source relating to THIS device which states there is a hash or signature on the SoC in any shape or form... meaning it is likely that there is still hope to get a custom xLoader, bootloader and kernel on the device.

Loglud · Dec 13, 2011

hwong96 said:
Line 441 Disabling unused clock "efuse_ctrl_cust_fck"
Does this mean efuse lock is not utilized?

Ok i'm going to through something out there and hopefully it will rock all of your worlds.

There is no efuse for security.

on boot the devices displays the manufacture of Texas Instruments Inc. which is not 'N/A' As the user manual points out. If it was 'N/A' then we would be looking at an efuse, but since it is not, hate to say it but there is no efuse (the hate to say it is sarcasm)

Code:

Bus 002 Device 007: ID 0451:d00f Texas Instruments, Inc. 
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.10
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0        64
  idVendor           0x0451 Texas Instruments, Inc.
  idProduct          0xd00f 
  bcdDevice            0.00
  iManufacturer          33 
  iProduct               37 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          1 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              2 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0

27.4.5.3.6 USB Customized Descriptors
There are two parameters in USB descriptors that customers can define after the chip is created: vendor
ID (VID) and product ID (PID). The ROM code uses dedicated eFuses that hold VID and PID values.
Other parameters can also be changed based on the VID value. The ROM code has an encoded set of
parameters for customers who have defined their requirements before the ROM code has been done.
Table 27-33 lists the parameters that depend on the VID value.
Table 27-33. Customized Descriptor Parameters
Parameter Size (Bytes) Default Values (From eFuses) TI Default Values (From ROM)
Device ID code 2 0x0000 0x0000
Device class 1 0xFF 0xFF
Device subclass 1 0xFF 0xFF
Device protocol 1 0xFF 0xFF
Manufacturer String N/A Texas Instruments
Product String OMAP4430 OMAP4430
Serial number String See(1) See(1)
(1) The standard device descriptor indicates that the device has no serial number.
Figure 27-17 shows an additional customer parameter selection method

AdamOutler · Dec 13, 2011

I was talking to Luglod. His bricked device is enumerating in USB mode. This is a good thing. This means he bootstrap is actively seeking a upload from the peripheral PC. Read more here:

OMAP4430 processor manual said:
27.4.1 Booting Overview
27.4.1.1 Booting Types
Booting is the process of starting a bootstrap from one of the booting devices.
The ROM code has two functions for booting: Peripheral booting and memory booting.
• In peripheral booting, the ROM code polls a selected communication interface such as UART or USB,
downloads the executable code over the interface, and executes it in internal RAM. Downloaded
software from an external host can be used to program flash memories connected to the device. This
special case of peripheral booting is called preflashing; software downloaded for preflashing is called
the flash loader. The flash loader burns a new client application image in external flash memory. Initial
software is a generic term for bootstrap, downloaded software, and flash loader. After the image is
burnt, a software (warm) reset can be performed.
• In memory booting, the ROM code finds the bootstrap in permanent memories such as flash memory
or memory cards and executes it. This process is normally performed after a cold or warm device
reset.
The ROM code detects whether the device should download software from a peripheral interface (USB or
UART) by using the sys_boot[5:0] pin configuration. This mechanism encompasses initial flashing in
production (external memory is empty) and reflashing in service (external memory is already
programmed).

For those of you who weren't paying attention, Luglod attempted to flash a kernel into the recovery partition. The recovery partition is required for booting on this device... this is very odd... Anyways, the device won't boot now, however it is kicking the device into an apparent flashloader mode. This bootstrap allows the device to accept a flash over USB. We have the xLoader, Kernel, Recovery and System in the Factory.zip file.. We just need to figure out a way to feed the flashloader it's files. If anyone can get ahold of a working copy of usbload.. See here: http://pandaboard.org/content/usb-downloader-and-usb-second-stage-bootloader-omap4 it would be very helpful. I can't find a precompiled binary or compilable source anywhere. This is the program we need though.

AdamOutler · Dec 13, 2011

Loglud said:
Ok i'm going to through something out there and hopefully it will rock all of your worlds.

There is no efuse.

on boot the devices displays the manufacture of Texas Instruments Inc. which is not 'N/A' As the user manual points out. If it was 'N/A' then we would be looking at an efuse, but since it is not, hate to say it but there is no efuse (the hate to say it is sarcasm)

there are plenty of fuses.. Just none relating to security as far as I can see. The processor manual would have to specify that as a block of memory at a minimum.

From what I do see about M Shield, it appears to be a hardware-initiated chain-of-trust. it's purpose is to supply secure APIs for things like Netflix. I dont' think we need to even look at M Shield. It is irrelevatn.

Again, this is what we need... We need usbboot utility.. this tool is required to load firmware onto the device and bypass all bootloaders which enforce signatures on the next bootloader in line. http://pandaboard.org/content/usb-downloader-and-usb-second-stage-bootloader-omap4

HMG10 · Dec 13, 2011

AdamOutler said:
there are plenty of fuses.. Just none relating to security as far as I can see. The processor manual would have to specify that as a block of memory at a minimum.

From what I do see about M Shield, it appears to be a hardware-initiated chain-of-trust. it's purpose is to supply secure APIs for things like Netflix. I dont' think we need to even look at M Shield. It is irrelevatn.

Again, this is what we need... We need usbboot utility.. this tool is required to load firmware onto the device and bypass all bootloaders which enforce signatures on the next bootloader in line. http://pandaboard.org/content/usb-downloader-and-usb-second-stage-bootloader-omap4

I'm assuming someone has looked at this, as I know little of the process but found the info on the previous linked site by Adam. Probably nothing, but I thought it looked interesting:

PandaBoard Validation
Software
Kozio, Inc. (www.kozio.com) has made available free use of their kDiagnostics® Suite, for owners of PandaBoard. Users of the PandaBoard have an interactive guided tour of the inner workings of the board, along with a full design verification and hardware validation solution.

PandaBoard loads and runs kDiagnostics directly from a Secure Digital (SD) card. Users quickly have the power to explore and understand their PandaBoard, verify proper performance, and have full access and control of both low-level hardware and high-level functionality in real-time. kDiagnostics initializes devices, enables the configuration of memory, isolates and easily reproduces faults within minutes, and provides other features beyond the boundaries of traditional verification or validation approaches.

The download is immediately available directly from the Kozio website http://www.kozio.com/services-and-supports/downloads.

hwong96 · Dec 13, 2011

AdamOutler said:
there are plenty of fuses.. Just none relating to security as far as I can see. The processor manual would have to specify that as a block of memory at a minimum.

From what I do see about M Shield, it appears to be a hardware-initiated chain-of-trust. it's purpose is to supply secure APIs for things like Netflix. I dont' think we need to even look at M Shield. It is irrelevatn.

Again, this is what we need... We need usbboot utility.. this tool is required to load firmware onto the device and bypass all bootloaders which enforce signatures on the next bootloader in line. http://pandaboard.org/content/usb-downloader-and-usb-second-stage-bootloader-omap4

Here is the zip file. The tools folder has the USB c and h files

AdamOutler · Dec 14, 2011

Loglud said:
Yes those are them, well to be more specific he means he needs the binaries, what you linked is the uncompiled sources. If someone wants to compile the sources that would be grand.

Right. I tried compiling that source last week. It didn't compile for me.

pokey9000 · Dec 14, 2011

AdamOutler said:
I was talking to Luglod. His bricked device is enumerating in USB mode. This is a good thing. This means he bootstrap is actively seeking a upload from the peripheral PC. Read more here:

For those of you who weren't paying attention, Luglod attempted to flash a kernel into the recovery partition. The recovery partition is required for booting on this device... this is very odd... Anyways, the device won't boot now, however it is kicking the device into an apparent flashloader mode. This bootstrap allows the device to accept a flash over USB. We have the xLoader, Kernel, Recovery and System in the Factory.zip file.. We just need to figure out a way to feed the flashloader it's files. If anyone can get ahold of a working copy of usbload.. See here: http://pandaboard.org/content/usb-downloader-and-usb-second-stage-bootloader-omap4 it would be very helpful. I can't find a precompiled binary or compilable source anywhere. This is the program we need though.

FWIW, we are just noticing something similar on the Kindle Fire, which uses the same sort of GPT partitioning scheme. Flashing a non-stock recovery breaks our ability to get into fastboot in the bootloader. If I find anything out I'll pass it on here.

pokey9000 · Dec 14, 2011

Attached, host tools built for i686, aboot built for pandaboard.

It's not going to work since aboot isn't signed. usbboot will hang waiting for aboot to respond.

pokey9000 · Dec 14, 2011

Loglud said:
Ok i'm going to through something out there and hopefully it will rock all of your worlds.

There is no efuse for security.

I think hwong96's excerpt is pointing out that you can have TI fuse in your own custom descriptor information, so usb boot mode doesn't show up with the default TI descriptor. People seem to still be smoking the xbox360 crack in believing that efuse automatically means it's a security thing.

AdamOutler · Dec 14, 2011

pokey9000 said:
Attached, host tools built for i686, aboot built for pandaboard.

It's not going to work since aboot isn't signed. usbboot will hang waiting for aboot to respond.

Cool. thank you. Have you tried any-old signature? Have you tried the provided signing tool from the nook source?

Indirect · Dec 14, 2011

The efuse has nothing to do with security by itself on and device. Its how its implemented. It was made by ibm to be a quick programmable device.

Sent by breaking the sound barrier

[DISCUSSION] on the boot loader [CRACKED!]

Retired Senior Recognized Developer

Retired Senior Recognized Developer

Senior Member

Senior Member

Retired Senior Recognized Developer

Senior Member

Senior Member

Senior Member

Retired Senior Recognized Developer

Senior Member

Retired Senior Recognized Developer

Retired Senior Recognized Developer

Senior Member

Senior Member

Attachments

Retired Senior Recognized Developer

Senior Member

Senior Member

Attachments

Senior Member

Retired Senior Recognized Developer

Senior Member

Similar threads

Top Liked Posts