All times are UTC - 5 hours [ DST ]


Forum rules


Please do not post questions about data recovery cases here (use this forum instead). This forum is for topics on finding new ways to recover data. Accessing firmware, writing programs, reading bits off the platter, recovering data from dust...



Post new topic Reply to topic  [ 35 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Marvel Bootstrap analysis
PostPosted: March 14th, 2013, 5:58 
Offline

Joined: August 22nd, 2011, 15:43
Posts: 214
Location: Romania
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 :P 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:
File comment: Bootstrap128k
mem_FFFF0000_FFFF2000.zip [48.27 KiB]
Downloaded 919 times
Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 14th, 2013, 7:08 
Offline
User avatar

Joined: December 19th, 2006, 8:49
Posts: 10828
Location: Portugal
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...

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 14th, 2013, 9:29 
Offline
User avatar

Joined: September 29th, 2005, 12:02
Posts: 3430
Location: Chicago
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

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 14th, 2013, 12:19 
Offline

Joined: August 22nd, 2011, 15:43
Posts: 214
Location: Romania
Spildit wrote:
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 :D

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


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 15th, 2013, 3:35 
Offline

Joined: March 7th, 2009, 12:43
Posts: 993
Location: Angel Data Recovery
-------


Attachments:
boot switches.JPG
boot switches.JPG [ 63.72 KiB | Viewed 55284 times ]

_________________
Angel Data Recovery
Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 15th, 2013, 8:49 
Offline
User avatar

Joined: September 29th, 2005, 12:02
Posts: 3430
Location: Chicago
The numbers are usually different on different models

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 17th, 2013, 9:05 
Offline

Joined: March 11th, 2012, 12:36
Posts: 27
Location: china
:D Good job ,but if only use Static analysis, it is very difficult!


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 26th, 2013, 6:04 
Offline

Joined: May 26th, 2004, 15:46
Posts: 11
Location: Belarus
Quote:
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 :?:

_________________
I'm sorry, I'm allergic to bullshit. © I, Robot
HDD Robot my personal page


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 26th, 2013, 6:33 
Offline

Joined: August 22nd, 2011, 15:43
Posts: 214
Location: Romania
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. :)


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 26th, 2013, 7:04 
Offline

Joined: May 26th, 2004, 15:46
Posts: 11
Location: Belarus
Quote:
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!

_________________
I'm sorry, I'm allergic to bullshit. © I, Robot
HDD Robot my personal page


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 26th, 2013, 7:59 
Offline

Joined: August 22nd, 2011, 15:43
Posts: 214
Location: Romania
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.


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 26th, 2013, 8:24 
Offline

Joined: May 26th, 2004, 15:46
Posts: 11
Location: Belarus
Quote:
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?

_________________
I'm sorry, I'm allergic to bullshit. © I, Robot
HDD Robot my personal page


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 26th, 2013, 8:49 
Offline

Joined: August 22nd, 2011, 15:43
Posts: 214
Location: Romania
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.


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 26th, 2013, 9:09 
Offline

Joined: May 26th, 2004, 15:46
Posts: 11
Location: Belarus
Quote:
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..
Quote:
or we need some kind of code block to be downloaded

So, we need some thing like SystemL.dll

_________________
I'm sorry, I'm allergic to bullshit. © I, Robot
HDD Robot my personal page


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 26th, 2013, 9:17 
Offline

Joined: August 22nd, 2011, 15:43
Posts: 214
Location: Romania
migann wrote:
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. :)


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 26th, 2013, 9:35 
Offline

Joined: May 26th, 2004, 15:46
Posts: 11
Location: Belarus
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 :wink: I'll plan to build one of JTAG interfaces and to play with it a little

_________________
I'm sorry, I'm allergic to bullshit. © I, Robot
HDD Robot my personal page


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 26th, 2013, 10:12 
Offline
User avatar

Joined: September 29th, 2005, 12:02
Posts: 3430
Location: Chicago
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

_________________
SAN, NAS, RAID, Server, and HDD Data Recovery.


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 26th, 2013, 10:16 
Offline

Joined: August 22nd, 2011, 15:43
Posts: 214
Location: Romania
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 ;)


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 26th, 2013, 21:35 
Offline

Joined: March 11th, 2012, 12:36
Posts: 27
Location: china
louis wrote:
migann wrote:
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;


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: May 17th, 2013, 17:07 
Offline

Joined: August 22nd, 2011, 15:43
Posts: 214
Location: Romania
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:
bs.png
bs.png [ 27.66 KiB | Viewed 54723 times ]
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 35 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group