Marvel Bootstrap analysis

[louis]

Well, I started this thread to uncover the hidden bootstrap code.

What's the Bootstrap?
It's a piece of executable code designed by the HDD vendor which runs inside the MCU (micro-controller the brain of your HDD's PCB), immediately after power-up the unit. It's a kind of boot-loader for windows. Basically, in a working HDD, it reads the rom flash image, and executes a portion of code described in a table at the very beginning of the flash.bin (rom image).
If you dump your PCB's flash image (ex using WDR tool) and open it in a hex editor (ex HxD) you'll notice a sort of table at the beginning, with a row length of 32 bytes.

The approximate description is here:

Code:

typedef struct 32ByteBlockBiosHeader
{
   byte ID;                  //[Byte 00] Header ID  0x5A it's called "kernel loader"...it loads and unpacks all the others...being executed by the MCU's bootstrap?
   byte type;               //[Byte 01]?? 1,3 compressed?
   short decomp_sizeH;  //[Bytes 02:03] higher 16bit of the decompressed size ??
   int block_Size;          //Directory Size + 1 checksum byte
   int block_size;           //Directory Size without checksum byte
   int block_start;          //The offset in this file where dir starts
   int block_addr;           //Mem addr Where the MCU's Bootstarp or the "kernel loader" (0x5a = first block-not compressed)  loads and unpack the data
   int entry_point;          //The EP for this directosy. Gets called if needs exec. if this is -1 won't be executed;
   byte UNK4[4];            //01 0A 00 00
   short decomp_sizeL;   //lower 16bit of the decompressed size
   byte pad;
   byte CKS;                 //checksum is calculated over all buffer but the crc byte
}32ByteBlockBiosHeader;

The ID of the first row it's 0x5A...we name-it "Kernel Loader". Basically, the Bootstrap maps the first entry in that table at the memory address vir_addr, then executes the entry_point.

But what if we have a defective PCB, with an incorrect rom image? (First, I must mention that in this situation, the HDD won't be seen by any software tool which communicates with the device using ATA commands. This means that the firmware must be in a certain degree of integrity.) The Bootloader will enter in another mode in which, it will accept data injection through a xmodem communication interface. AKA Windows terminal ...with some wires between COM and PCB

I have dumped my Bootstrap image using a tool made my myself (which uses VSC) Otherwise you could use a JTAG debugger to do the dump...If you manage to solder those wires Usually, on ARM MCU's the Bootstrap code it's mapped in memory at 0xFFFF0000 offset and it's small ...around 1000bytes on my PCB.
My PCB has stamped 2060-701336-003 REV A it's a 2005 WD 200Gb model. At this moment my PCB identifies as a WDC ROM..because I could bet it has the pre-amp dead. Another tip is that in this situation, you could use the PCB detached from the HDD, connected to PC, if you want to play with it, without putting another stress on the platter and internal stuff.

SO, As I said, the Bootstrap enters in a mode...in which accepts receiving data through a serial interface. To enter in this mode, some physical connections must be made. WD has on all PCB's (I believe) a CON1 connector. It's used perhaps for factory firmware upload/tests, and there I assume they have the links and what they need to put the bootstrap to factory mode.
However, some Chinese guys have found the link which enables the injection. I will concentrate on how the "terminal" function inside the Bootloader, works.

The functions implements a basic code which handles x-modem protocol. It sends 0x15 byte (NAK), waiting to receive data on serial port. It reads constantly to see if someone sends some data. If yes, then analyzes that data and take proper actions.

The injected data is sent as 128bytes packet with prefix consisting of a simple 3-byte header containing a <SOH> command character (0x01), a "block number" from 0-255, and the "inverse" block number-255 minus the block number
X-Modem <soh> 01 FE -data[128]-CRC. The "terminal", verifies if the data it's ok, responding with an ACK (0x6) or NAK for errors. For the first block, it maps the first 32 bits of the header described upper (yes, injected data must own a header) to some local variables, and keeps track of the Entry_point, maps the executable block to it's memory address from header, checks CRC etc. then wait for another packet.
If it receives <EOT> end of transmission, respond with ACK and executes the Injected code's Entry_point.

The headers members which count when injecting data, are the block_start, block_addr, entry_point, because the code will be executed and active as long as the RAM is powered..

I have attached my Bootstrap dump as an .ida project (nice graphs), with the terminal code reversed inside. I mention that The analysis it's made only statically, I haven't used any debugger.

Attachments

mem_FFFF0000_FFFF2000.zip

Bootstrap128k

(48.27 KiB) Downloaded 1985 times

[Doomer]

5A means it is a serial flash header. Majority of Marvell ARM-based MCUs use these headers
Other values
0x5A = Boot from Serial (SPI) flash
0x8B = Boot from NAND flash
0x78 = Boot from SATA device
0x9C = Boot from PEX interface
0x69 = Boot from UART0

[louis]

Very nice and great research !
Will be following this thread with great interest !
Did you fond the points to short on your pcb for the boot loader to enter x-modem mode or it does that by itself if the ROM have a crc error ?
Apart of figuring out where to connect the rx/tx to the com port you need to figure out how to enter on that modem mode...

From what I've seen the "terminal" loader function it's called in 2 places. One if some pins are shorted some way, and one if the "kernel loader" it's defect, if the previous condition it's not met. (assume CRC or not found, didn't investigate more on how could fail; see ida project). But the "kernel loader" it's only a small routine...which will do the bootstrap's job with the rest of the blocks in the flash header. What happens if "kernel loader" fails...we must study...but I believe that are the only 2 ways in which we will see the "terminal".
I haven't tried to short anything. However to try this you must have a JIT debugger (I don't have) and put a breakpoints when the Bootstrap read its config bits...or just hook the computer to suggested RX-TX ports and listen for some activity while trying the short stuff

@Doomer 10x for contribute. In this case, the "terminal function" doesn't care what's the signature of the injected code The injected code..must have a 32byte header with the fields I've already told..and the code after that.

[DR-Kiev]

-------

Attachments

[Doomer]

The numbers are usually different on different models

[flykiller]

Good job ,but if only use Static analysis, it is very difficult!

[migann]

The injected data is sent as 128bytes packet with prefix consisting of a simple 3-byte header containing a <SOH> command character (0x01), a "block number" from 0-255, and the "inverse" block number-255 minus the block number

So how about to send by this way (block-per-block) full ROM image?
Will it be unpacked to RAM and then started on properly way, or we need some kind of code block to be downloaded in first, then started and then get ROM image from terminal for flash it in ROM? Like SystemL.dll in UCommand or simular.

Have any ideas

[louis]

I have described already what happens. Get ida and look what terminal does. The Injected code it's written at the location marked in its header. Then the small terminal..execute the injected code's entry point, also indicated in the header. If you write the rom image to MCU's ram this doesn't mean that it will be written to the ROM chip. You have to know the rom write protocol, and write a loader (and point its EP to injected code header) which will be executed after injection and which will write the attached rom image to the rom chip.

so you'll have something like this:

[Injected code header]
[Small loader]
[Payload = rom firmware]

for the small loader, you should debug and reverse the code which writes your MCU's rom memory.

[migann]

If you write the rom image to MCU's ram this doesn't mean that it will be written to the ROM chip.

But does it starts after writing to RAM? I mean if it is, then we can (after image is started) use the SATA interfase to flash ROM image in ordinary way by sending it again thru interface for this once!

[louis]

If internal flash it's bad..then the bootstrap enters in "terminal" mode. also...if some resistors are populated..the bootstrap enters directly in terminal mode..without checking any rom image. now..from where do we start the discussion?

I'm afraid you can't bypass the bootstrap's code. if you have a debugger.. set a breakpoint on first bootstrap instruction..then copy the rom image to it's DRAM projection using debugger. then hit run. this should work if you can write the ram area..where rom it's mapped. (perhaps it's read only etc)

For the injected rom to work...you have to do all the things the bootstrap does until it makes the decision that the rom it's not good and enter the terminal ;or perhaps inject the the rom to its dram projection..and run again the bootstrap EP? you need a debugger to learn and discover what works or not. I don't have the necessary knowledge at this moment, nor the tools.

[migann]

If internal flash it's bad..then the bootstrap enters in "terminal" mode. also...

I`m ok with it, but not so shure how terminal mode works at all For my understanding, if boorstrap does not find flash image in ROM (external or internal, depending of config resistors), then it try to get them from serial interface. So, if image has been send, then boorstrap shuld start them.. Or where I wrong?

[louis]

bootstrap->does some stuff then:
check resistors.
if resistors not found...try to load the rom image (aka map the first block "kernel loader" in the rom image and execute it). if bad rom...start terminal;
if resistors found..start terminal;


when you try to inject the code via terminal..you see that some actions have been taken. terminal expects something..some code to execute. only the manufactures knows the MCU internals and know what to program and to sent to the terminal. the terminal doesn't wait for the ROM image! again...it waits for some code to fix it. that code... you have to write...

the terminal simply copies the injected code to a memory address and executes it. you cannot just send the rom image like it is because it won't work. the "kernel loader" from rom image must be loaded at a specific address to run, and that's done by the bootstrap only once...when it boots. the terminal doesn't do anything in this direction. that's why...you have to write a small loader to do that.

[migann]

the terminal doesn't wait for the ROM image! again...it waits for some code

Excellent, it quite clear for me now, I wrote about this variant before..

or we need some kind of code block to be downloaded

So, we need some thing like SystemL.dll

[louis]

So, we need some thing like SystemL.dll

call it "loader". in that case it contains the code for writing the flash. and I have strong feelings that it's MCU dependent.

[migann]

But from other side, the simular code block (for writing, erasing ROM) must be in ordinary rom image, but it is not so easy to find them at all, as well as a ROM blocks are packed. But may be the UCommand is a hint.. Any way, JTAG debugger and IDA disasm will needed for this mission I'll plan to build one of JTAG interfaces and to play with it a little

[Doomer]

WD drive could use external serial flash or internal parallel flash
Serial flash operates by SPI protocol and this protocol is very well documented, so it is relatively easy to create a loader to write ROM to the serial flash
Internal flash commands are vendor specific which makes them harder to analyze but this post should shed some light on it - marvell-88i6745n-jtag-t20324-40.html#p137145

BTW boot loader always has reading commands for both SPI and Internal flashes

[louis]

JTAG ...Yea, I have purchased one for myself..it's on the way to my home. The Rom write code it's inside rom's image...the VSC table. But it will be easy to find with a debugger. I'm building a tool with which I can dump the RAM with a vsc. Obviously, I can dump the unpacked blocks from the memory

[flykiller]

So, we need some thing like SystemL.dll

call it "loader". in that case it contains the code for writing the flash. and I have strong feelings that it's MCU dependent.

Good analysis.Can write but do not need to dependent on the MCU code, that code is based on the ARM7.

How to cacl 32ByteBlockBiosHeader?
int sum =0;
for (int i =0;i<0x1f;i++)
{
sum+=Buffers[i];
}
Buffer[0x1f]=(byte)sum;

[louis]

the few bytes of a ROYL bootstrap...

it reads a word from port 0x1C00A84E and check for the bit 13. if the bit it's set..it enters in console mode where you could r,w memory.

Attachments

[louis]

let's continue here this discussion

so, after setting up the hardware connections I was able to use openocd&ida to live debug the marvel mcu. it doesn't work quite like ollydbg since the work it's done via a client/server interface and the debugger isn't optimized for this kind of work. most of the time I was forced to do static analysis then step into debugger with a breakpoint set in cmd line and see how the flow goes. the bootstrap (0xFFFF0000 code) it's read only so there you could run only with hardware bp. ida fails stepping if you already have an active bp, so you may disable any other bps..before setting a new hardware one. also it fails with F8 on read only blocks since it's using "soft breakpoints" (I think),, better with F7.

the firmware I posted in the other thread has the bootstrap (rom code = Bootstrap) at 0xFFFF0000; this code starts the firmware loading by mapping the first block (Z block which it's not compressed (bit 0 of second byte it's 0)) in the firmware to offset in ram 0xF000 and then runs the code at 0xF000; in rom (bootstrap code) there are some useful functions, which will be called by other part of the firmware code, spread along the mcu address space. this is good because we can break-point those functions and catch it later. the Z code, once executed, it unpacks the all remaining blocks to ram. to study better we must dump/unpack all those blocks and make a project in ida...adding those blocks and mapping to the virtual offset as they were in MCU, so we can have a good analysis.

to study the unpacking function, I reversed the code in Z Block (so called Kernel Loader). In this firmware, the Flash it's not mapped to the address space (as in dejan's mcu 0xFFF00000...a later model) (from what I saw till now). all the access to flash is done live, by reading the Flash Port. the functions handling reading the flash port (port base 0x100080A0) are at the end of the bootstrap (0xFFFF0000); it's interesting that the other parts of firmware uses also these pieces of code. so when you exec the ReadRom VSC (vendor specific command) with a software...the code between the sata commands and firmware goes through these tiny functions.

I will give you a nice way to find quickly the function which handle the rom read/write. since this could take very long by analyzing dumped code, we must use a debugger with OpenOCD. also we connect the sata to the pc and use wdr or other tools (in my case..my own) to dump the rom with vsc. since the operation it's time consuming you will have time to halt the MCU from cmd line in OpenOCD. the chances to break into the read/write flash function are very high. from there you could start the reversing

in this particular firmware (2005 year) the flash read functions (used by vsc) seems to be in block 6 of the firmware. off-course..the tiny version used by the bootstrap can be found as I said at the end of the 0xFFFF0000

for who doesn't know, a port it's a dword address; in this case it has a base... ie 0x100080A0. if you want to send a read_flash command to the hardware, you must "init" the port, by setting some bit flags in it (at port base + a small number ie. 2,4,A etc). then setting the offset you want to read (a kind of pointer for a file read); then reading a byte at port base + a small number; the pointer gets incremented automatically on hardware side. when you finish, you must close the port by setting another flag. the firmware checks after each operation to see if error occurs (and sleeps sometime waiting for the commands to complete).

to make yourself an image of the ram space you must look at the mapping offset (0x10 offset) in each block's header; when you debug, you will know with approximation where you are.