WD2000JD problem

[louis]

ok..i have some results. I try to read track -1 for each one of the 4 heads. I get the same result for each one. the VSC command it's ended by the device with abort flag end error flag set. note that I must wait 30secs for the device to abort..conform ata specs. In this way I can catch the error from the device. see below.

Here's the output for read_pchs(device, out_buff, 0, (-1), 1, SPT); read_pchs(x,x,head,track,start sector,number of sectors)

The p2 an p3 forms the 4byte track number, which is -1,
p4 it's the head number; here it's set to 0; if I set it to something else than 0-3 the function returns error..invalid head! which is ok.

set_wd_vsc_mode(ON)
set_wd_vsc_mode: OK
send_wd_cmd() (command=000C)(p1=0001)(p2=FFFF) (p3=FFFF) (p4=0000) (p5=0001) (p6=000A)
send_wd_cmd: error register is on. aborting...
Drive Error Register: 0004
No Address Mark = 0
No Media or Media Error = 0
Command Aborted = 1
No Media or Media Error = 0
ID mark not Found = 0
No Media or Media Error = 0
Uncorrectable Data Error= 0
Bad Sectors = 0
ATA Registers:
ATA_ERROR = 0004
ATA_NSECTOR = 0041
ATA_SECTOR = 0043
ATA_LCYL = 0000
ATA_HCYL = 0000
ATA_DRV_HEAD = 00A0
ATA_STATUS = 0051
Drive Status register: 0051
Drive Busy = 0
Drive Ready = 1
ATA_SR_DF = 0
Seek Complete = 1
Data Request = 0
ATA_SR_CORR = 0
ATA_SR_IDX = 0
Error = 1
VSC error code not decoded for : 0x4341
wd_read_pchs: send_wd_cmd failed, aborting
set_wd_vsc_mode(OFF)
set_wd_vsc_mode: OK

During the execution...which takes just about 30secs..the drive starts spinning..and as I described earlier, I have 4 rounds of 2 clicks..+ one final click. It happens the same for each head starting from 0 to 3.

Unfortunately I don't know what that error means. Perhaps someone could help.

[louis]

VSC error code not decoded for : 0x4341

ATA_NSECTOR = 0041
ATA_SECTOR = 0043

Maybe related ?

Those are ATA ports..2 bytes each.
Yes...that's how the error code it's computed for VSC commands (ATA_SECTOR<<8+ATA_NSECTOR). The problem is what it means since it doesn't appear in my wd error list.

Do you have a working WD drive to test with ?

I have 1Tb one, but it's plugged into sata port... and I only operate with my software on ide ports. I don't want to play around on that one
I'll try to buy a used one to test the code. But I could bet that it will work on a good drive.

That error code could solve the case. Or not

[louis]

yes, that's the list

I have that demo wdr..and I found another one called wdr4.0 which looks the same...nothing more. Runs only XP or lower..due to "privileged instructions".

what's funny is that if I try to read head 4 which doesn't exist...the error code it's on that list.

Code:

VSC error code decoded: 0xB007 -->> VSCE_INV_HEAD_NUM

Last edited by louis on March 5th, 2013, 19:39, edited 1 time in total.

[louis]

Yes my friends

Attachments

wdr-4.0.rar

(483.77 KiB) Downloaded 773 times

[louis]

it's one there...which test all heads reading SA on the heads dialog window.

[louis]

Here-s the dump made from my evolving app. Its identical with the one from wdr.

Very little compression...for the rar compared to .bin I see. I wonder what's the compression alg. inside the rom file...

Definitely there must be a loader builtin MCU which ...unpack and loads the ROM to RAM.

Is there a way to test the RAM?

Attachments

buccanan.zip

(125.55 KiB) Downloaded 480 times

[louis]

WDC WD3000JB-00KFA0-08-05J08-WD-WCAMR3501171

ROM attached

Just for comparing purpose.

If you believe me I have that rom on my desktop. Looked at it few days ago.

As for sediv..it doesn't start on Hiren's XP nor my default OS w7

[louis]

I'm learning some ollydbg scripting
I'm waiting for the donor, but it's mostly a 2-3 week job. It comes from USA.

[Friedrich]

Yes my friends

I downloaded it but my Norton internet security 2012 detects file WDR.exe as "WS.Reputation.1"
I uploaded the file to http://www.virustotal.com and this is the report log:
https://www.virustotal.com/it/file/ab12 ... 362749184/

as you can see, of 46 antivirus 4 detect it as a virus.
I don't really trust this program

[louis]

It has some marks inside...seems that someone unpacked it (don't know who..I just found it on the net while searching)...lordpe&imprec are known tools which marks "fixed" PE

Get a packer...pack notepad.exe then test it at virustotal...you'll be surprised what you'll find

Sediv it's also a biatch. It's Themid-ed. It doesn't run on W7..nor XP form USB. Under wmvare the protector doesn't allow the execution. So I couldn't test the program. usually this happens on small tools too few tested or not tested at all on other OS's that the programmer works.

[louis]

Also read here :

marvell-88i6745n-jtag-t20324-20.html

Interesting

yeah...so the first code executed inside MCU from the "ROM firmware" file it's he "kernel loader" described here:

Code:

Header of "kernel loader" is on 0x00000000 of Flash (physical addr: 0xfff00000)
in size of 0x20 with CHK
---------------------------
0x5a ;Header ID
04,0,0 ;?
0xd,0xc,0,0 ;=0x00000c0d size of "kernel loader" + CHK
0xc,0xc,0,0 ;=0x00000c0c size of "kernel loader"
0x20,1,0,0 ;=0x00000120 start of "kernel loader" data in FLASH (physical addr 0xfff00120)
0x80,0xa,1,0 ;=0x00010a80 physical addr where "kernel loader" have to be loaded
0x80,0xa,1,0 ;=0x00010a80 physical addr of execute start once "kernel loader" is loaded
0,0,0 ;?
0xd1 ;Header ID CHK 8-bit cheksum of first 0x1f bytes of "kernel loader" header

For this case bootstrap loads "kernel loader" to addr: 0x0x00010a80 in size 0x00000c0c
calculate 8 bit cheksum and compare with next byte (offset + 0x00000c0c)

So when you open the ROM file..the first 0x20bytes are the "kernel loader". If this is corrupted (CRC error) you have to listen the serial port etc...

[louis]

For someone who knows stuff..it may be a stupid question...but the ATA implementation on the device side..shouldn't be handled by the ROM firmware? So if we hava a f.ed rom..no chance to fix it via VSC.

By the way, there's a smart VSC command which returns a 512bytes structure of device Status. if I call it immediately when the error reg is on..I have inside that structure..the error code I computed few posts ago: 0x4341. the structure It's mostly empty which it's obvious since we are in kernel mode.

Code:

VSC Status
-----------
Format Version                               = 1
VSC Implementation, Minor                    = 1
VSC Implementation, Major                    = 4
Max Action Code Supported                    = 47
Last Cmd Type                                = VSC Key CMD
Last Cmd Register                            = 0xB0
Last VSC Cmd Action Code                     = 0x0C

Last Feature Register                        = 0xD6
Last Sector Count Register                   = 0x1
Last Sector Number Register                  = 0xBE
Last Cylinder Register                       = 0xFFFFC24F
Last LBA High                                = 0x0
Last Device Control Register                 = 0x68
Last Device/head Register                    = 0xA0
Last Task File Response                      = 0x104
Extended Error                               = 0x4341
Extended Error Description                   = ()
Secondary Error Code                         = 0x0
Host Connection Speed                        = NOT SUPPORTED
APM Level                                    = 0x0

Sectors Xfer Pending to/from drive           = 0 (0x0)
Last Task File Data                          = 0x81
DLG_II Status                                = 0x0

That topic discuss the "internal" ROM corruption. But what's happening with the external ROM. It's there a way to flash it in place?

Yeah, with JTAG you can debug the MCU. With IDA you can even disassemble the ROM code (ARM opcodes) and see nice graphs with branches..where who calls etc.

[louis]

I have gathered the infos by dex into a struct. The wd Rom.bin headers table to some data blocks...32 bytes each header..seems to be the same on the few bios-es I've opened in a hex-editor.

Code:

typedef struct Dir32SecBiosHeader
{
   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 dir_size;               //Directory Size without checksum byte
   int dir_Size;               // -``- + CKS
   int dir_start;               //The offset in this file where dir starts
   int vir_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
}Dir32SecBiosHeader;

I'll write a function to traverse all the headers and do a CRC check on all code blocks. The problem is that I don't know how to parse the modules at the EOF...adaptives etc for the 128kb roms which doesn't have te ROYL signature at the beginning of the header.

[louis]

yes. if ROM dump via VSC doesn't work..and you get a copy with the SOIC8..you wil be able to test it

I'm doing experiments.

[louis]

CRC on rom block table seems to be ok on my .bin

Now I came across the following problem. How the heck should I get the ROM MODS at the end of the bios file? I know that there are 2 version..one having 24byte header and one with 48 bytes in which ROYL are the first 4 bytes. For the second version I could scan for the ROYL sign to find the header, but again, that header doesn't contain any size information about the MOD..only the name ID and the length in sectors.

[louis]

I've implemented the VSC command which queries a specific MODule. Somthing like VSC_getmodule(int iModID) ->a file mod_id.bin similar to using key file for MHDD starting with 0x8, 0,1, MOD_ID...

My bios has the old header's format...without ROYL mark. This command returns the MODS from BIOS firmware...and an error for the mods in SA (VSC error code decoded: 0x3701 -->> FM_ERR_DIR)

In this way I managed to get the 4 mods i can see at the end of the ROM.bin:
0A - head map
0D - firmware version
30 - Service Area translator
47 - Service Area adaptives

But I've done that..by inspecting the rom end..getting from there the mod's ID to pass to VSC. I know that in the ROYL ROM there's another MOD called 0xb - ROM module directory..which contains the list of mods present in the firmware's last bytes...which contain the exact position in the rom file..and the sizes of each ROM MOD. But my ROM it's the old version type which doesn't contain the rom mod directory. I assume that the ROM's mod number and position/size for each one is hard-coded in rom.bin executable code...since it knows how to find those mod's..for the getmodule VCS command.

Last edited by louis on March 10th, 2013, 13:17, edited 4 times in total.

[louis]

I've done the test you asked. With the PCB totally separated from the hdd (but PC powered and connected to sata) I can read the rom exactly as before with my app. So no difference between the PCB in hand or mounted to the HDD. off course I must wait about 30 secs because that's the ATA standard ...max waiting time in which the MCU tries to read the platters and reports busy state.

[louis]

Wdr doesn't like w7 and I have too may windows opened to reboot now

It should work. It works on the same principle. ATA commands directly to hdd's controller.

So the more I study the more it becomes clear. You can control and access the PCB as long as you have a valid firmware inside which can handle ATA commands. If you flash an incompatible fw. on a PCB and that code crashes inside the mcu during initialization, you won't be able to access the PCB via software because it won't respond to any commands..it won't be seen (to be seen means..it neds to reply to ATA cmds sent by software). Then you'll need to do a external writing to rom...via unsoldering.. etc.

I believe that CON1 is the gate trough which wd handle all this situations. They have custom loaders and perhaps they short some pins there to make the bootstrap start what they want.

Had a look at that link "death to blabla" ...they put the bootstrap in a mode shorting a point (which on my PCB oesn't exist) which accepts commands through the PC's com port, not loading any ROM content (internal or external); then they send 2 files...one which performs rom erase...and one which is called repeatedly with chunks of 16k from the rom.bin appended at the end...until the entire rom file is processed. Both files seems to have a 32 bytes header, but only for the the first file is sent. Who wrote those file they use...a real guru I assume that they hacked the kernel code..found the ports and what it's needed when the VSC erase/write the new firmware. but the more important stuff is that they found the protocol...how to fetch the code sent through com to mcu...so that the MCU to execute that code. "grab this code and execute it"

[louis]

CRC on rom block table seems to be ok on my .bin

Yes..all code blocks indicated in the rom starting header are fine. I could bet it's fine..because rom code works..the hdd it's detected as much as the rom code allows not having the SA infos.
I don't know at this moment how to do the CRC on the MODS located inside the rom. If, how I previously said, I Found a way to download each one, I still cannot do the CRC because I don't know the size of any mod downloaded from the rom. I get a multiple of 512bytes chunk of data..for any..and as I see..at the end of the rom...they are smaller. I should try it like this..because 0 padded zones doesn't matter on the crc; but it's not right...the size must be a must...and I believe that it's hard-coded inside the rom exec code...not in another mod (0xb) like on ROYL firmware.

I'll wait for the donor. After that..I'll ask locally how much will they charge for a head-swap. With the right tools it's a 10min op. The problem it's after that with the head alignment. I could bet that the preamp it's dead.

Meanwhile...I ordered a programmer with that soic8 clip...on aliexpress but seems that doesn't want to accept my cc damn.

[louis]

Found a nice VSC command. ReadMemory(address, size). I can dump the 0xffff0000 aka the bootstrap...if that's the address on my marvel; or the unpacked blocks of code described in the table at the beginning of the rom.bin