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  [ 34 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: September 19th, 2013, 10:07 
Offline
User avatar

Joined: September 29th, 2005, 12:02
Posts: 3561
Location: Chicago
louis wrote:
l
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);

If you have SPI flash (aka 8-pin flash chip) that can be the answer
0xFFF00000 is mapped address of built-in flash

Hint: SPI commands are very well documented

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


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: September 19th, 2013, 11:33 
Offline
User avatar

Joined: December 4th, 2012, 1:35
Posts: 3844
Location: Adelaide, Australia
This is all very interesting. I don't know a lot about hard drive firmware, but I can follw the general gist of it.

On a similar theme, would you have an idea how to debug an x86 motherboard? There is no debugging available in the custom OS, the code is hard to decompile because no sourcecode, and IDA doesn't understand the custome .exe.s and minimal driver files.

The OS calls the BIOS and hardware directly.

I am wondering if I can also use openOCD somehow on the cpu to watch execution. Usually with embedded stuff you can watch the serial port for Linux messages but this isn't Linux, and no debug messages, well not on the standard serial port.

Any ideas?

note - the os doesn't run on any virtual machines or x86 emu's that I have tried.


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

Joined: August 22nd, 2011, 15:43
Posts: 209
Location: Romania
Doomer wrote:
If you have SPI flash (aka 8-pin flash chip) that can be the answer
0xFFF00000 is mapped address of built-in flash

Hint: SPI commands are very well documented


in this last case, yes, the pcb has 8pin external flash.

if I want to upload firmware to either internal/external rom using serial protocol, from pc to pcb, I must know the MCU internal "flash write" protocol. a loader must be coded, with the flash image attached at the end. this loader, once executed inside mcu, should write the image to the flash.


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: September 19th, 2013, 22:32 
Offline

Joined: August 22nd, 2011, 15:43
Posts: 209
Location: Romania
here it's the ida project for the last posts. don't take it as good since there are a lot of guesses and perhaps mistakes.

I have added 3 blocks of code to the project:
1. BOOTSTRAP = the code which exist in MCU before any flash. this loads the KLOAD code, or runs xmodem if kload fails.
2. KLOAD = the first block in firmware, known as "kernel loader"; this code has the unpacking code.
3. bk7 = block no 7 in firmware which handles the read flash VSC.

the bootstrap it's the first code exec by the MCU..and it starts at 0xFFFF0000 as standard ARM architecture specs. I have named the function Bootstrap_EntryPoint. there are the first instructions executed. then the stack pointer it's initialized SP, =0x4004000 ; then it checks some config bits at port 0x10008012

AND R0, R0, #7 (this will keep in R0 only first 3 bits)
0x7 means 00000111; we have 2^3 = 8 possibilities

if it's 0x4 (00000100) it does something with a dead end.
if it's 3 (00000011) it does something with a dead end.
else it goes to the 8_CASES_SWITCH

0.if R0 it's 0 (all bits 0) it runs so called -> find_kernel_loader which reads the flash and try to run the block Z; on errors in this function...xmodem function (terminal) will be called and the mcu will listen the serial port (the jumpers on the pcb) for some code to fix it; also, if bit 6 in config port it's set if kload fails the another function it's called for uploading code to fix the problem. I named it load_external_block; in this case I don't know the protocol...but it ends reading some code at 0xFF000000.
in find_kernel_loader, from bits 4-5 (config bits) = 2^2=4 variants.. a variable will be stored at 0x400000C which can be 14,28,32,19
1. if R0 it's 1...load_external_block will be called again; tried this in debugger but it remains in an endless loop somewhere in the func. since I don't know what to deliver :)
-. case 5(it exec the code at 0xFE800000),6 (it exec the code at 0xFFF00000),7 (it exec the code at 0x00000000).
-. default goes to terminal

so..3,4 were taken before; 0,1, 5,6,7 in switch. it result that default it's 2 (00000010) :) if we have second bit set in config port, the bootstrap goes to terminal waiting our code. which is so..also in debugger.

I assume that something must be shorted on the pcb in a reasonable way. jumpers or something on CON1. since the board must be flashed by factory somehow. they set that second bit in some way then inject a firmware writer code through serial port (accessed on pcb jumpers)

Note:I do not intend to repair something. the pcb works fine. it's just for study.


Attachments:
wd2000jd60klb0.zip [609.88 KiB]
Downloaded 1077 times
Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: September 20th, 2013, 3:46 
Offline

Joined: August 22nd, 2011, 15:43
Posts: 209
Location: Romania
:idea: I found that in this case pins 32,34,36,38 on CON1 are bits 4,5,6,7 (not in this order) in config port. I need the lower 4 bits, especially the second bit to activate serial com.


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: September 20th, 2013, 15:20 
Offline

Joined: August 22nd, 2011, 15:43
Posts: 209
Location: Romania
tried various combinations on con1 with no luck. the jumper connectors reflect also in what I call Config Port. when I use jumpers there, I see some modifications in bits 8-11. usually the config word with first 3 jumpers set it's 0x800. when I take off some jumpers it becomes 0xC00 0xF00; when I make high pins on Con1 I get 0x810, 0x840..etc..so the bits [4-7] are touched.

I'm trying to find a way to activate terminal without a debugger. if I look better, there are only 2 ways of starting terminal, in bootstrap:
1. if the second bit in config port it's set. (since it's left as default on switch, at this moment I have doubts that it can be changed with some connections on pcb; the MCU's with "internal flash" doesn't have 2 resistors which makes some bits 1 where we need, so this is another reason I have doubts that those resistors can be override by another "shortcut".)
2. if kernel_loader fails mapping the firmware. in this last case, at the end of the function, there's also a check; the bit 6 in config port (which we can control!) it's checked. if it's set..then "terminal" start xmodem protocol (and we can deliver a loader to flash the firmware). if no...there's another helper_routine which at this moment I don't know what protocol uses.

so if we have a pcb with a bad firmware (not seen with with factory vsc), then we must make high the pin 36 on con1 so that the broken firmware enter in terminal func.

when you go with a broken hdd at the factory repair..I assume that they set the pin 36 high and listen the serial port for the xmodem protocol. if positive they upload a firmware fixer code, because the flash image it's damaged. else pretty sure, the pcb can be tested via factory software.


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: September 25th, 2013, 1:55 
Offline

Joined: August 22nd, 2011, 15:43
Posts: 209
Location: Romania
I've spent some time to figure how to connect to serial interface. I'm using PC's com port. I've got a rs232 to ttl convertor (max3232) in order to translate the 3.3v serial signals to something useful for PC's com port; in the end I couldn't find the pins to connect. the jumper's header doesn't emit any rx or tx signals when I switched to Terminal routine (xmodem)..by manipulating the code from jtag interface. I found some pins from the jumpers header, going straight into MCU (normally since they are used as IN to set some bits in "Config Port"). I found also the real TX,RX circuit (E7,E8 on this pcb), but this links 2 pins from MCU with 2 pins from SATA controller :?: . The Baud rate it's 38400 8N1. but how it's used since it doesn't have any useful pins to connect?


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: September 25th, 2013, 3:12 
Offline
User avatar

Joined: May 5th, 2004, 20:06
Posts: 2782
Location: England
TX/RX also used in SATA interface. Nothing to do with UART RS232

_________________
All went well until I plugged the drive in.


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: September 30th, 2013, 19:55 
Offline

Joined: March 8th, 2009, 22:44
Posts: 42
Location: the E.U.
After playing with two PCBs for a while they started talking to me bit by bit ;)

MCU's tested: 88i9146 and 88i9045
Speed: 115200 8N1

Have fun!


Attachments:
Marvell_terminal.jpg
Marvell_terminal.jpg [ 28.57 KiB | Viewed 18858 times ]
Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 4th, 2014, 7:13 
Offline

Joined: May 26th, 2004, 15:46
Posts: 8
Location: Belarus
fayn wrote:
After playing with two PCBs for a while they started talking to me bit by bit ;)
MCU's tested: 88i9146 and 88i9045
Speed: 115200 8N1
Have fun!

By this way it is possible to read and write RAM, so not a lot of fun...

_________________
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 4th, 2014, 7:34 
Offline

Joined: August 22nd, 2011, 15:43
Posts: 209
Location: Romania
guru wrote:
TX/RX also used in SATA interface. Nothing to do with UART RS232

maybe the serial interface it's somehow passed through sata chip...to the serial ata cable.

in this case, the xmodem code works with those 2 pins I indicated which are linked to the sata controller.


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 25th, 2014, 16:17 
Offline

Joined: February 17th, 2014, 15:53
Posts: 2
Location: North America
@louis
This is how I hooked up serial for my hard drive. The board contains a Marvell 88i9146 processor and con1 is the 38 pin version. Not sure what processor you have. The serial connection is brought out to the jumper header. I have JTAG connected and forced the drive into terminal mode by resetting PC. After that I had a prompt on the below configured serial port. The baud was set at 115200 8N1.

Attachment:
HD_Serial.jpg
HD_Serial.jpg [ 428.71 KiB | Viewed 18315 times ]


PCB Side of HD
-----------------
| 2 | 4 | 6 | 8 |
-----------------
| 1 | 3 | 5 | 7 |
-----------------
Top Side of HD

Pin 4: Black Jumper = GND
Pin 3: Blue Jumper = RxD
Pin 5: Green Jumper = TxD.

PS: My notes aren't so good. Rx and Tx maybe reversed. So try both ways.


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: March 25th, 2014, 16:31 
Offline

Joined: August 22nd, 2011, 15:43
Posts: 209
Location: Romania
Galena44 wrote:
@louis
Not sure what processor you have. The serial connection is brought out to the jumper header.

an old one..2005 :) . starting from that year they somehow standardized the firmware ..the module's names etc...to work with same VSC.


Top
 Profile  
 
 Post subject: Re: Marvel Bootstrap analysis
PostPosted: April 8th, 2015, 12:27 
Offline

Joined: April 8th, 2015, 12:25
Posts: 1
Location: Berlin
Hi!
As I understand from reading this forum thread there are 3 types of code :
1. BOOTSTRAP - the code which exist in MCU before any flash
2. kernel loader - the first block in firmware, code has the unpacking code.
3. other modules, to work with sATA and etc.
In any FW i have seen in this forum Z block have in header in second byte 0x04. other blocks have 0x01 or 0x03, which means some type of compress. But what about meaning of 0x02?
I just try to play with latter version of MC - 88i9446, and get a Z block with 0x02 type of compression. The data in this block does't seems to be a code.
If anyone have any idea about this?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 34 posts ]  Go to page Previous  1, 2

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 17 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