So I've been thinking. The 0xE7 those LG/Hitachi drives have is pretty interesting in the sense that unlike the READ BUFF and READ CACHE methods, you're definitely going one level lower and have full access to read the entire MN103 module's RAM. This can prevent a lot of issues that we've seen with raw dumps where you're at the mercy of what the drive seems necessary to store on the buffer and cache. But dumping memory intrigues me in the sense that somewhere in the contents of RAM ,in theory all values that make up the raw sector should be there, even more. I'm more intrigued with the idea that failed read contents are stored somewhere in RAM.
From my understanding, the way the method works is that you dump a given portion of the address space inside the MN103 module, in this case you read the contents of the starting offset where sector data is cached. Then you read the data stored one arbitrary block size at a time. This is neat!
There is one set back to the current method though. Currently, the memory region 0xE7 is dumping is a region where the sector data has already been processed by the drive. It's still scrambled and has EDC and sync info added to it, but no ECC. Some other routine on the drive most likely takes this data then descrambles, strips the EDC and sync data, and adds it onto the buffer where it's read by READ12 or whatever. However, the biggest drawback is that this region is also the result of a drive that has already experienced SCSI errors, so any sector that had an error of any kind will not show up at all in this buffered area in RAM.
However, does that data still exist but somewhere else in RAM? What about the ECC data, that has to be stored somewhere right?
I think the 0xE7 command has some untapped potential, but it's going to require analyzing a full memory dump of RAM when a sector has been read to get an understanding what data is there and what to expect. Then knowing the offsets, we can plot where to get the data for each raw sector from the drive and append it onto the drive's cache, and just read the cache.
The thing that makes it particularly interesting is that there might be some data returned to the drive when it attempts to read media that throws any kind of SCSI error. So when you read a bad sector, that raw initial read with no corrections done to it might still be there in its entirety complete with EDC and ECC, and sync data. There might even be C2 like status info stored somewhere there too. This means that bad or corrupt sectors can be read and returned to the user, which currently no drive can do that. What's even more, if a drive tries to read maybe even something that's not supposed to be easily read (like an Xbox/360 DVD), it might be possible to return the raw data that way too. Wii/GC raw sector data can also be returned in full by these drives in theory.
However I lack an 0xE7 drive to test with and I know next to nothing about issuing SCSI commands to drives and getting data back. I think what would be great right now, at least to start out with, is if we actually get a full RAM dump of the drive when it reads just one sector so we can dissect it. Since we have drives that return that RAW data already in some shape or form, its just a matter of searching for that data in a binary memory dump of RAM and noting the offsets to all the data. Then we can craft commands that specifically return data from those offsets to generate the raw data in full.
So I've been thinking. The 0xE7 those LG/Hitachi drives have is pretty interesting in the sense that unlike the READ BUFF and READ CACHE methods, you're definitely going one level lower and have full access to read the entire MN103 module's RAM. This can prevent a lot of issues that we've seen with raw dumps where you're at the mercy of what the drive seems necessary to store on the buffer and cache. But dumping memory intrigues me in the sense that somewhere in the contents of RAM ,in theory all values that make up the raw sector should be there, even more. I'm more intrigued with the idea that failed read contents are stored somewhere in RAM.
From my understanding, the way the method works is that you dump a given portion of the address space inside the MN103 module, in this case you read the contents of the starting offset where sector data is cached. Then you read the data stored one arbitrary block size at a time. This is neat!
There is one set back to the current method though. Currently, the memory region 0xE7 is dumping is a region where the sector data has already been processed by the drive. It's still scrambled and has EDC and sync info added to it, but no ECC. Some other routine on the drive most likely takes this data then descrambles, strips the EDC and sync data, and adds it onto the buffer where it's read by READ12 or whatever. However, the biggest drawback is that this region is also the result of a drive that has already experienced SCSI errors, so any sector that had an error of any kind will not show up at all in this buffered area in RAM.
However, does that data still exist but somewhere else in RAM? What about the ECC data, that has to be stored somewhere right?
I think the 0xE7 command has some untapped potential, but it's going to require analyzing a full memory dump of RAM when a sector has been read to get an understanding what data is there and what to expect. Then knowing the offsets, we can plot where to get the data for each raw sector from the drive and append it onto the drive's cache, and just read the cache.
The thing that makes it particularly interesting is that there might be some data returned to the drive when it attempts to read media that throws any kind of SCSI error. So when you read a bad sector, that raw initial read with no corrections done to it might still be there in its entirety complete with EDC and ECC, and sync data. There might even be C2 like status info stored somewhere there too. This means that bad or corrupt sectors can be read and returned to the user, which currently no drive can do that. What's even more, if a drive tries to read maybe even something that's not supposed to be easily read (like an Xbox/360 DVD), it might be possible to return the raw data that way too. Wii/GC raw sector data can also be returned in full by these drives in theory.
However I lack an 0xE7 drive to test with and I know next to nothing about issuing SCSI commands to drives and getting data back. I think what would be great right now, at least to start out with, is if we actually get a full RAM dump of the drive when it reads just one sector so we can dissect it. Since we have drives that return that RAW data already in some shape or form, its just a matter of searching for that data in a binary memory dump of RAM and noting the offsets to all the data. Then we can craft commands that specifically return data from those offsets to generate the raw data in full.