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

This is a technical question for Western Digital drives, without using paid pro tools. I am doing this with my own program and scripting. So let's say I have ROM and RAM access, and have brought the drive up in kernel mode with no modules loaded, and have raw SA read access via CHS (but not write access, which is my goal, to be able to write to SA). So I can read from SA and get modules, but I don't know where to load them in RAM as an overlay. There must be a way from either ROM or RAM to find the proper location to load a module as an overlay. Or if there is a magic way to enable writing to SA when in kernel mode, I would accept that also.

The last overlay component has a size of 0xC8FC bytes. There is a corresponding entry in the table of load points. This would suggest that this overlay component would be loaded into RAM at address 0xFFE3DA88.

Assuming no-one knows, or is willing to divulge, the answer to your question, I would dump the RAM in "normal mode" and then locate the load point of module 11h (the loader).

Next I would refer to the ROM and determine the size and memory address of each section. Most sections will be compressed, so they cannot simply be extracted from the ROM (unless you know the compression algorithm). Instead I would carve each decompressed ROM section out of the RAM dump.

Finally I would search the decompressed code/data for the load address of module 11h. Hopefully this will be located within some data structure (eg a table of load points).

Please explain how a RAM load address can be much greater than the size of RAM. The RAM address of 0xFFE3DA88 would indicate a RAM size of 4GB. I am seeing some of this in my test ROM blocks, where it indicates load positions that don't make any sense, considering the RAM size is 2MB. They also don't make any sense even with the high bits stripped off. Things just don't add up

The SDRAM is mapped into a small area of the MCU's 4GB address space, as is the kernel code. The MCU's address space is also used by memory mapped peripheral devices.

ARM architecture also allows for addresses to be remapped after booting, so that can complicate matters.

Unoccupied address ranges may be "aliased". That is, you will read the same data from two different address ranges if the uppermost address bits are not decoded.

You could determine the locations of the data buffers by writing a unique pattern to each sector, eg "LBA nnnnnnnn". Then read 1000 or 10000 sectors, say, or at least enough to fill the cache, and then dump the RAM.

On EVO840, the 512-MB DRAM is available in the address space at 0x80000000 so it goes to 0x9fffffff and there are SRAMs at other locations like from 0x00000000 to 0x00020000I created an interactive visualisation of the memory, when you move with the mouse over the table on the right side, you can see the memory region highlighted: http://www2.futureware.at/~philipp/ssd/ ... Q.dec.html

Okay, that makes some sense to me. On my test drive I am starting to read ram at 0x8000000, and reading until it repeats to get the size, which in my test drive case is 2MB. I never even thought about memory mapping. This is not going to be as easy as I hoped.

All I want to do is be able to write to the SA... I just wish it was possible to write the SA with CHS as easy as it is to read, but the result is the dreaded aborted command. As many times as I have thought it and then prevailed, I may just be in over my head this time. I am only willing to spend a limited amount of time and effort on this. Time for some testing to see where I stand...

I am no longer pursuing this, as I have found that I can't access the drives in kernel mode via USB. My hopes and dreams of this have been ended, case closed.

True.

This was reported several times now on WDMarvel forum as well. People do get intro trouble when running ARCO on USB only PCBs drives if they don't convert to SATA as the USB-ATA pass-through will not work if the drive drops to safe mode.

Also when you do read/write modules BY ID using VSC you don't specify the C/H/S in PBA so MAYBE and this is a BIG MAYBE .... it could be that there are a VSC that will load the perm overlay to RAM without the need to specify the address to where on RAM you do need to load the overlay ....

Idead would be that ROM code + Overlay code would have tables needed for the drive to know where to load that overlay on RAM. I think that there are a good possibility that the VSC is something like the standard ATA load microcode command and the stuff that you load + the code in ROM decide the place on RAM that will be used to load the code instead of you to specify that on the VSC....

This was reported several times now on WDMarvel forum as well. People do get intro trouble when running ARCO on USB only PCBs drives if they don't convert to SATA as the USB-ATA pass-through will not work if the drive drops to safe mode.

I don't have any USB only drives other than the two SED locked drives, so I cannot confirm if it is possible or not on one of the ones that is not encrypted. I do know that I have two older passports that are just SATA with a USB adapter board, and I can communicate with them via USB when they are in kernel mode. In Linux is it possible to claim a USB interface and perform raw commands, which is how I did that.

But none of that matters, as my goal was the SED locked drives, and they don't work like that.

Who is online

Users browsing this forum: No registered users and 0 guests

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