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

In my previous topic (viewtopic.php?f=16&t=6562) I explained some basic stuff regarding firmwares. It's a few years old, and I saw that there were quite a few reactions of people who appreciated it, so I thought I'd share some more info.

My whole goal back then was to modify the information inside the firmware of a Western Digital SATA BEVS HDD. I wanted to do this, so people could use that drive in their XBOX 360. The thing was, microsoft would issue an identify command to the drive, so only microsoft's drive's would be compatible. I developed a tool back then, so people could buy a Western Digital, modify the firmware using my tool so they could use in their xbox 360. The tool I released was called "hddhackr" and here you can read some more about it: http://forums.xbox-scene.com/index.php?showtopic=601813 Read the textinfo inside the file to understand what it exactly does.

Today I thought I'd just sum up some of the information on how I did this.

Just like the creators of the PC3000 tool, I started to reverse engineer a Western Digital flashing tool, to find out what ATA commands Western Digital uses to read/write the drive's FW. What I found was that the first thing to do, was to issue a vendor specific command to the drive, to put it into 'firmware mode'. Without the drive being in this firmware mode, other firmware specific commands will just be rejected, so it's essential to first issue this command. I found that the command for this specific drive was 0x45, 0XB0, 0x0, 0x44, 0x57, 0xA0, 0x80. So, after issuing these bytes via ATA to the drive, the drive would be put into firmware mode.

Now, the firmware commands are actually SCT commands. SCT stands for "SMART Command Transport". Basically it's just a SMART way to deliver ATA commands to the drive. If you want to read more about SCT and how it can transport ATA commands, then you can do so here: http://www.t10.org/t13/docs2005/DT1701r5-SCT.pdf. The important thing is that first a a SCT command needs to be issued, telling the drive that a SCT packet including ATA command will come next. For this specific drive, that command was: 0xD6, 0x1, 0xBE, 0x4F, 0xC2, 0xA0.

So, after these 2 things have been done (putting the drive into FW mode via that ATA command and then telling the drive a SCT packet including the command is coming), it's time to send the command itself. Via assembly language it's just a matter of putting the address of the packet into SI, move 0x100 to CX (for 1 sector. For 2 sectors 0x200) and then copy the packet to the dataport. So it's actually the packet that contains the command itself. For this WD, the SCT packet would be 3 bytes: 0x8, read/write (1 or 2) and then the module ID. So to read module 0xD, the packet would be 0x8, 0x1, 0xD. (1 = read, 2 = write).

Then, the last thing would be to get the drive to actually execute that command. This would be done by sending another SCT packet. Starting with 0xD5 for read or 0xD6 for write, then the number of sectors, then 0xBF, 0x4F, 0xC2, 0xA0, 0xB0. See also point 4.3 here to see similarities: http://www.t10.org/t13/docs2005/DT1701r5-SCT.pdf

Would you consider enhancing HDDHackr to assist those people who have lost their UNDO.BIN file? Sometimes there is a backup copy of MOD 02 in the SA (in a different module). I have developed a workaround for restoring the drive's native capacity in the absence of the original UNDO.BIN, but this only works if the drive is still functional.

You know what, here's the full source code guys. It's really hackerish and ugly, haha, sorry for that but it's probably helpful, especially if you want to adapt it. It's really easy to make it dump every section of the SA for example.

BTW, never saw these ASCII's were 'WD', haha makes sense I'm pretty sure other WD drives use similar codes, maybe even the same. Here you go, enjoy

;So, we found the first 0 byte, now look for the first byte that is NOT zerotestzero: mov bx, sec2buff add bx, word [serialpos] add bx, word [serialzero] mov al, [bx]

cmp al, 0 jne nozero2

inc word [serialzero] jmp testzero

nozero2: ; now max size of serial is [serialzero] - 1

; so now calculate how long much space we need, thus see ; how long the serial from sec16 EX spaces in the end is ... ; algo: look at FIRST character of the string, check for a 'space', if so, ; check next. Needed size is 20 - number of spaces

; Check length of Modelstring from sec 16. Start at byte 40, look for first character that is NOT a space. ; Then check length of space in FW: Look for first zero byte and then for the first next NON zero byte after this one.

;so first check length of source string => find last byte that is NOT a space

;now cx contains port adress, see if we have had that adress before, if not, store it

cmp byte [pcount], 0 jz newpfound ;no entries in table, so store it

;now check if entry is in table already

mov byte [alreadystored], 0 ;this is the boolean we use to see if we found a match in the table mov ax,0 mov al, byte [pcount] ;save number of already stored ports to ax and use that as countertablelus: mov bx, portlist add bx, ax add bx, ax ;add two times, since we're using words, not bytes cmp word [bx-2], cx jne next

hi, aimtrading, i really admire your excellent work and efforts. I have been puzzled by a problem. i want to dump the firmware from my Western Digital WD5000AAKX-083CA Drive, but i don't know how to do it. Are there any tool available to do this? you have said 'Just like the creators of the PC3000 tool, I started to reverse engineer a Western Digital flashing tool, to find out what ATA commands Western Digital uses to read/write the drive's FW.' I was wondering what this Western Digital flashing tool is.Can you show me where to find this tool or send me one copy of it? I'm looking forward to your reply and thanks for reading this.

hi, aimtrading, i really admire your excellent work and efforts. I have been puzzled by a problem. i want to dump the firmware from my Western Digital WD5000AAKX-083CA Drive, but i don't know how to do it. Are there any tool available to do this? you have said 'Just like the creators of the PC3000 tool, I started to reverse engineer a Western Digital flashing tool, to find out what ATA commands Western Digital uses to read/write the drive's FW.' I was wondering what this Western Digital flashing tool is.Can you show me where to find this tool or send me one copy of it? I'm looking forward to your reply and thanks for reading this.

Hi !

The firmware of a WD drive is not just "Flash" code.

While there is some "Flash" or ROM code on the PCB (either on a ROM SPI Flash chip or embeded on the MCU) there is also code/modules on the platters. A way to gain access to those are by the use of expensive hardware/software tools as PC-3000 as stated by the OP :

hi, aimtrading, i really admire your excellent work and efforts. I have been puzzled by a problem. i want to dump the firmware from my Western Digital WD5000AAKX-083CA Drive, but i don't know how to do it. Are there any tool available to do this? you have said 'Just like the creators of the PC3000 tool, I started to reverse engineer a Western Digital flashing tool, to find out what ATA commands Western Digital uses to read/write the drive's FW.' I was wondering what this Western Digital flashing tool is.Can you show me where to find this tool or send me one copy of it? I'm looking forward to your reply and thanks for reading this.

Hi !

The firmware of a WD drive is not just "Flash" code.

While there is some "Flash" or ROM code on the PCB (either on a ROM SPI Flash chip or embeded on the MCU) there is also code/modules on the platters. A way to gain access to those are by the use of expensive hardware/software tools as PC-3000 as stated by the OP :

VSC just two cmd, one for transport ctrl code ,another for get the feedback data. and I think the ctrl code is valuable things to research.read rom ram flashcode,sa etc...all depend on factory ctrl code.

btw, asm is too complex to understand if translate to c or basic is great.

Who is online

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