Feature request - DVD mode - Bruteforce the 0x3C SCSI command when /raw is used for unknown drives.

[ehw]

Is your feature request related to a problem? Please describe. Currently, DIC has a fixed list of drives that support various methods of reading 'raw' data from the drive through various methods. For instance, certain LG/Hitachi drives support the E7 memory dump command, but many drives can support reading raw data through the 0x3C command like Lite-Ons and LG/ASUS drives. However, DIC will only allow /raw to be used if the drive is hard-coded into DIC to function leaving a lot of potential drives out without support.

Describe the solution you'd like I think DIC should attempt to brute force or automatically detect if a drive has support for reading with /raw by using brute-forcing methods to determine the right parameters that return data off the disc. Friidump includes an (unfortunately closed-sourced) called BruteForce3C which can brute force the 0x3C opcode by incrementing the command parameters until the drive returns data off the disc while the target drive has a DVD inserted. The program comes with a .cfg file that blacklists returns that are all 00s, as that would suggest that the drive has nothing on the cache/buffer. However, if the program returns a .bin containing non-zero data, it can potentially read raw data.

However, DIC could go one step further and implement this for drives that aren't hardcoded into the program. Here's how I imagine it can work:

1.) User uses /raw with their unsupported drive. 2.) If DIC determines that the drive is unsupported, try and see if the drive is an LG/Hitachi drive. see if E7 is present by using the opcode and return data where the first 4 bytes are 00 03 00 00. This would indicate PSN data for LBA 0, the first sector on the DVD. 3.) If E7 doesn't work, move on to brute forcing 0x3C. Alert the user that the drive is unsupported but that DIC will bruteforce for 0x3C. DIC will then increment the 2 parameters of 0x3C and return data from the drive as it reads LBA 0. If 0x3C returns 00, increment and move on to the next value. If it returns data, see if 00 03 00 00 are the first bytes present. If it is, that's the command for 0x3C to use for raw dumping. If you exhaust all values for 0x3C, the drive doesn't support reading with /raw, so stop DIC. DIC should let the user know what values it's trying or how long it will take to brute force. 4.) Next determine what data is being returned by the drive. This is a bit tricky as since drives can return different data, there are a few things you need to look for.

• raw dumps should always have sync information like a PSN number as the first 4 bytes for the sector. maybe read the next sector and see if it follows in sequence with LBA 0. Look at the usual offsets where the next PSN would be stored (2064 bytes away, 2384 bytes away, etc) and find the four bytes for the next PSN in the sequence from LBA 0. Once you determine how many bytes away the next LBA is, that's how many bytes per sector the drive is returning
• next, you need to determine if the resulting data is scrambled or unscrambled. I don't know of a safe way to determine this...do you?

5.) Once everything has been determined, dump the rest of the disc to a .raw file using the discovered 0x3C opcode.

Make sure everything is recorded in a log file.

Describe alternatives you've considered It would be nice to have DIC do this for the user, but I suppose you could always just include BruteForce3C with DIC and call it externally when /raw is used. I wish the source code were available, but I have a feeling this would be easy to implement in DIC anyway.

Additional context Grab BruteForce3C here. BruteForce3C.zip

For the record, here is what BruteForce3C does:

In case none of existing 'commands' work, use this program to determine your drive's READ BUFFER command parameters. By default Mode will be scanned from $00..$0f, Buffer ID from $00 to $ff. Mode range can be set from commandline. Full scan ($00..$ff) takes about 10 minutes to complete. All returned data different from $00 will be logged to files, but it's possible to configure masking behaviour by adding CRC32 values of unwanted data files to 'BruteForce3c.cfg' e.g. if drive returns a lot of similar files.

IMPORTANT: When scanning there should be readable (e.g. PC) DVD in drive!

If full scan completes but there were no files created, your drive either uses completely custom command for buffer acces (as e.g. Hitachi-LG drives do), in which case you could try to look it up in chipset documentation or find it by reverse engineering some of vendor's programs, such as firmware flashers, or it simply has none.

[saramibreak]

If someone find a new drive using the BruteForce3C.exe, I'll add it as whitelist.

[ehw]

If someone find a new drive using the BruteForce3C.exe, I'll add it as whitelist.

We're going through our collection of drives for another project so we'll be on the lookout.

Do you have a list of models that currently support /raw? I saw your post here:

http://forum.redump.org/post/59622/#p59622

But it only has E7 drives. Do you wanna compile a supported drive list with the supported output data somewhere?

[saramibreak]

Currently, DIC has a fixed list of drives that support various methods of reading 'raw' data from the drive through various methods.

DiscImageCreator_test.zip added set the command and size using your spreadsheet (https://docs.google.com/spreadsheets/d/1pu3oXHRJ_qlyXrsHUyXOzD5mNp7dU8rgrfVuRBLyQFA/edit?pli=1#gid=0).