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.



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.

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.



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

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.

Yes my friends

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

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?

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

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.

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

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.

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



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

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.



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.

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.


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.

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.

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.

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.

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.

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"

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.

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