Switch to full style
In-depth technology research: finding new ways to recover data, accessing firmware, writing programs, reading bits off the platter, recovering data from dust.

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 a reply

Where in RAM to load overlays for WD drives

September 22nd, 2018, 12:59

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.

Re: Where in RAM to load overlays for WD drives

September 22nd, 2018, 16:54

At present I'm watching this thread:

viewtopic.php?f=1&t=37418

Transient overlay (TRANSOVL) 0x411 appears to specify its own RAM load points in a table. The overlay consists of several components, each of which is loaded into a separate area of RAM.

Code:
Offset(h) 00       04

00000000  524F594C 03003000  ROYL..0.
00000008  1104E300 7F946EF8
00000010  30303136 30303744  0016007D
00000018  07070700 000030A1
00000020  00000000 00000000
00000028  00000000 00000000
00000030  380F00F0 680200F0   start of table of load addresses ?
00000038  00DE0210 68020000
00000040  88DAE3FF FCC80000   FFE3DA88 + C8FC
00000048  88E00290 D00C0000   9002E088 + CD0 = 9002ED58
00000050  58ED0290 F0860000   9002ED58
          ^^^^^^^^ ^^^^^^^^
          address  size

00000058  5452414E 534F564C  TRANSOVL   <- first overlay component


00000288  55555555 AAAAAAAA  UUUUªªªª   <- second overlay component ???
00000290  4563686F 53746172  EchoStar
00000298  20445354 33003400   DST3.4.


0000FC88  F84910B5 01EB0010   <- start of last overlay component
........
0001C580  C32601EA 00000000   <- end of last overlay component

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.

Re: Where in RAM to load overlays for WD drives

September 22nd, 2018, 19:59

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

Re: Where in RAM to load overlays for WD drives

September 24th, 2018, 20:27

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 :? :?:

Re: Where in RAM to load overlays for WD drives

September 24th, 2018, 20:37

You are confusing RAM with address space.

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.

I can help you locate the decompressed ROM sections if need be.

Re: Where in RAM to load overlays for WD drives

September 25th, 2018, 12:02

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 0x00020000
I 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

Re: Where in RAM to load overlays for WD drives

September 25th, 2018, 18:39

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

Re: Where in RAM to load overlays for WD drives

September 27th, 2018, 19:16

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

Re: Where in RAM to load overlays for WD drives

September 30th, 2018, 13:52

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.
Post a reply