Dumping DVDs RAW - An ongoing investigation (we need your help!)

[ehw]

So a long time ago, there was some interest in exploring the possibility of dumping DVDs 'raw'. Meaning, scrambled dumps with error detection and correction data along with header information. Some of you may be aware that unlike CDs, drive's don't like to give out data to the user that isn't needed for the typical user, like error correction/detection data. So instead, drives just give you the corrected, 2048 byte user data already processed. This is kind of a problem in some cases as you have to trust that the drive is performing the error correction and detection properly, which occurs either at the firmware level or at the DSP level. Having the ability to look at the raw data has some advantages, but it's limited to how much control the drive gives to the user, which isn't a lot.

Currently we're exploring using the raw information provided by various DVD drives for trying to get as much data from the disc as possible. Since DVD drives traditionally don't like to give you any sector data unless it's 100% 'correct', for bad or hard to read discs it leaves a lot on the table.

Luckily, most drives out there have support for the READ BUFF SCSI command which can help spill some unintended data to the user on request. If you get the parameters just right, you can get the data that was read by the drive before it's returned to the user. Since we know what a raw DVD sector consists of, we can easily find the right parameters needed for the command to find the right combination that returns the data we want.

However, there's a catch.

Because READ BUFF is implemented at the firmware level, despite every drive having some level of support for the command, the command varies from vendor to vendor, drive to drive. So one combination of parameters might not necessarily return the data you want in one drive even if it worked on another drive model. The second issue is that drives will store only what's necessary for the drive's firmware itself to perform what it needs to do on the data that's read from the disc. As such, some drives return variable, but somewhat fixed/standard data sizes per sector. So even if the data is found using READ BUFF, you need to determine how much data is returned per sector that's stored. Sometimes 2366 bytes with some padding are stored, sometimes 2064, etc. Sometimes data can be returned already unscrambled, sometimes data can be stored scrambled but with only error detection data. Sometimes you get everything. It's a mess.

Luckily, we can bruteforce the READ BUFF command and figure out what will give us the expected data. There was a tool written in the past that used to do just this, however the source was never released and doesn't seem to work correctly. It also doesn't take into account the various other memory dumping commands that exist as well, like F1 and E7.

That's where you come in. We have a lot of drives already, but not everything. We would like to create a database and keep track of drives that return raw DVD sector data onto the cache and the SCSI command parameter combo that gives you the data, along with what's actually contained within that data. We made a super streamlined version of the program that you can run on Windows machine that will take care of everything for you. Here's how it works.

1.) Get a DVD, preferably something on Redump.org, and put it in a DVD drive you'd like to test. The disc must be a standard DVD, no Xbox, GC, Wii, etc! A normal PC game on a DVD, PS2, or maybe a DVD Video disc should be okay.
2.) Run the program. The program will ask which drive letter contains the disc to use.
3.) The program will then perform some tests for feature capabilities, and then will begin bruteforcing parameters for various memory dumping commands. The program uses an embedded python script with calls to sg3 tools to issue various SCSI commands to the target drive while the media is inserted.
4.) It may take a while, but when it's done, it will generate an "uploadme.zip" containing memory dump fragments and a log file. Upload the uploadme.zip file here!
5.) I'll look at the dump and I'll add it to the table below.


Spreadsheet:
https://docs.google.com/spreadsheets/d/ … li=1#gid=0

Source code:
https://github.com/hiddenpalaceorg/DVDRawBruteforce

Grab the tool here:
https://github.com/hiddenpalaceorg/DVDR … e/releases

If you guys have any questions feel free to post here. Hopefully the zip files it generates doesn't take up a lot of space, as hopefully you can add the attachments here. But feel free to use another upload site if it becomes too big...

NOTE: if during execution the program takes way too long, feel free to kill it and just upload what it generated. Since it's bruteforcing many combinations of values it could take at least an hour or two depending on how well the drive works.

NOTE2: Even if it doesn't look like it's doing anything while it scans for values of 3C, it's working. So don't kill it right away. It will only print when data is returned by the drive using the SCSI command, not for when the command passes/fails.

EDIT: Program requires cygwin be installed but should have the .dlls needed to use it standalone. Let me know if there are any issues. If you were having issues before and didn't say anything, grab the zip and try it again.

[Lugamo]

I got an error that appeared twice saying that "cygwin1.dll" was missing, and then the program closed.

[ehw]

I got an error that appeared twice saying that "cygwin1.dll" was missing, and then the program closed.

Redownload the zip and try again, it needs cygwin installed and I forgot to include some of the .dlls inside.

[Lugamo]

I got an error that appeared twice saying that "cygwin1.dll" was missing, and then the program closed.

Redownload the zip and try again, it needs cygwin installed and I forgot to include some of the .dlls inside.

Now it works. I'll reply again with whatever it generated once it finishes. This is the disc I'm dumping right now, with my LG WH14NS40.

[Deterous]

There was a tool written in the past that used to do just this, however the source was never released

Is there source for the new tool you've just linked?

Even if it doesn't look like it's doing anything while it scans for values of 3C, it's working

It would be nice to get an update as to where it's up to in the list of commands (even just "No sectors returned from 3C 08 __", i.e. a message every time a whole chunk of 256 commands were checked with nothing returned), so I can tell that *some* progress is happening and it isn't some hardware issue causing it to freeze.

[ehw]

There was a tool written in the past that used to do just this, however the source was never released

Is there source for the new tool you've just linked?

Even if it doesn't look like it's doing anything while it scans for values of 3C, it's working

It would be nice to get an update as to where it's up to in the list of commands (even just "No sectors returned from 3C 08 __", i.e. a message every time a whole chunk of 256 commands were checked with nothing returned), so I can tell that *some* progress is happening and it isn't some hardware issue causing it to freeze.

Source code:
https://github.com/hiddenpalaceorg/DVDRawBruteforce

New release, added a progress bar:
https://github.com/hiddenpalaceorg/DVDR … 2023-09-30

[Lugamo]

Source code:
https://github.com/hiddenpalaceorg/DVDRawBruteforce

New release, added a progress bar:
https://github.com/hiddenpalaceorg/DVDR … 2023-09-30

Have you considered adding a license?

Dump update: It has been stuck in F1 0C for a while now.

[ehw]

Source code:
https://github.com/hiddenpalaceorg/DVDRawBruteforce

New release, added a progress bar:
https://github.com/hiddenpalaceorg/DVDR … 2023-09-30

Have you considered adding a license?

Dump update: It has been stuck in F1 0C for a while now.

Not really, not interested for something like this.

BTW, if for whatever reason it seems like its way too slow (like 3+ hours) or seems like it stalled, feel free to stop it by using Ctrl+C and upload what you have. Some drives just don't like being bruteforced to that high value. I could probably restrain the values it's bruteforcing with but you never know if a vendor might be sneaky and put something at 3C FF FF or something, lol.

Had a couple of submissions already. Keep them coming! Tell your friends and spread the word and see if we can test as many drives as we can.

[Lugamo]

BTW, if for whatever reason it seems like its way too slow (like 3+ hours) or seems like it stalled, feel free to stop it by using Ctrl+C and upload what you have. Some drives just don't like being bruteforced to that high value. I could probably restrain the values it's bruteforcing with but you never know if a vendor might be sneaky and put something at 3C FF FF or something, lol.

Here you go. I will try with another DVD later.

[Edness]

Here's mine from a TSSTcorp SE-208DB.  Looks like 3C 02 00 returned 0x8BC bytes of scrambled sector data.  So did F1 84, which was offset by about 13.5 sectors (0x7800 bytes).  And F1 8A returned the PFI, funnily enough.
Disc used: [PC] FlatOut 2 (Europe) (En,Fr,De,Es,It) (Xplosiv)


Are PS2 discs also disallowed or not?  At first I started with a PS2 disc since I have way more of those on hand, but shortly after restarted with a PC disc.  I don't know if you look for specific patterns in testing, but my assumption was that maybe you expect the 0th sector to be empty, which is not the case on PS2 discs since those have the PlayStation 2 logo seen when booting a game XORed across the first 12 sectors.