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

[Edness]

Three more drives from the one and only:

[ehw]

Added! Keep them coming.

olofolleola4 even submitted quite a few drives too.

[ehw]

More logs from two drives (SOHD-167T and SH-216BB)
BTW: Is it possible to add a function to the program code that allows the program to end when the drive is not responding? My SH-216BB hang up when reading 256 sectors (F1 I think). It happened twice and each time I had to restart the drive from the power supply. When the drive was suspended, the program was still waiting for a response from it. It would be nice if the program restarted the drive in such situations, or if the drive stopped responding after some time, it would terminate its operation

Hey out of curiosity what disc did you use in the SOHD-167T? What's "KULTOWE GRY 5"? Is this on redump? Do you have a scan of the disc, specifically the surface?

Curious if this is a recordable disc or something.

[MrPepka]

This is the disc
https://redump.info/disc/100941/

[ehw]

New version - 2023-11-26:
https://github.com/hiddenpalaceorg/DVDR … 2023-11-26

No need to retry what you've submitted, but use this version from now on. If anyone could update the linux version that'd be great.

[Edness]

I think there have actually been two different Linux versions made heh, but regardless - here's the updated version of the variant Jason098, Lazerdude and I use.

Tested my Plextor drive while I checking if the updated script works under Linux, even though it is on the spreadsheet already.

[ehw]

2023-12-10 - new version (dont use this)

Code: Select all

- Add interrupt handlers (CTRL+C) for scanning 3c/f1 values just in case drives hang or take too long.
- Added an experimental RAM dumper. This will take the first 3C opcode discovered that returned valid sector data with a valid PSN. This will try to dump 16MB with the command, which should be close to the start of DRAM. This process can also be interrupted with Ctrl+C. Note, how drives handle CDBs with invalid offsets is up to the drives I think. For my PX-716A, it didn't complain when I used a high offset value. Commonly, it should 'loop around' to the start of DRAM if the offset is beyond the size of available RAM but it might be up to the firmware so expect something to happen if they dont.
- Small spelling mistake changes.
- 3C bruteforce values are now stored in an array so that they can have some applicable use.

I expect some drives to not like the ram dumping, but if you have new dumps that aren't on the sheet feel free to test and submit.

EDIT: found a bug, the handlers werent actually returning what was stored in the arrays when the functions ended abruptly. need to make a change in order for that to work. stay tuned

EDIT 2: should be fixed with the following version.
2023-12-11 - new version (dont use this)

Code: Select all

- Fix bug with interrupt handlers so that contents of the discovered values array are retained after getting out of the function.
- Potentially fixed a bug where drives that don't rotate back to the beginning of memory when the offset is set too high and thus don't create the files for the memory dump occurs. I couldn't test this personally but I know someone tested a drive that this occurred.
- Moved mem_dump_3c to before bruteforcing f1 just in case bruteforcing f1 writes to cache.
- Reread lba 0 after f1 bruteforcing but before testing other commands just in case bruteforcing f1 wrote to the cache.

EDIT 3: third time's the charm. here's a new version
2023-12-11a - new version (dont use this)

Code: Select all

- Have the drive reread LBA 0 each iteration of F1 bruteforcing to see if I can prevent F1 from modifying data already on the cache.
- Change compression from .zip to .7z for better compression ratios.
- Add cleanup function to clear duplicate files.
- Print file hash (SHA256) for every file in the log.

EDIT 4: ugh
2023-12-12 - new version (dont use this)

Code: Select all

- Fix bug when no 3C values were found before using the 3C memory dumper.

EDIT 5: ughhh
2023-12-12a - new user (use this)
https://github.com/hiddenpalaceorg/DVDR … 023-12-12a

Code: Select all

- Reread LBA 0 because apparently there are values of 'read' buff that can actually alter the cache too! Yay!

[MrPepka]

More logs from two drives (SOHD-167T and SH-216BB)
BTW: Is it possible to add a function to the program code that allows the program to end when the drive is not responding? My SH-216BB hang up when reading 256 sectors (F1 I think). It happened twice and each time I had to restart the drive from the power supply. When the drive was suspended, the program was still waiting for a response from it. It would be nice if the program restarted the drive in such situations, or if the drive stopped responding after some time, it would terminate its operation

Hey out of curiosity what disc did you use in the SOHD-167T? What's "KULTOWE GRY 5"? Is this on redump? Do you have a scan of the disc, specifically the surface?

Curious if this is a recordable disc or something.

Hi
I had a moment so I came back to this thread, tried with another disc and it looks like the drive supports raw reading from opcode 3C 01 01
Tested with this disc - https://redump.info/disc/84828/

[A1RA]

TSST SH-S203D with SB00 firmware.
Disc used: https://redump.info/disc/4874/

Note: I used a modified version of the script by Edness that made it work on Linux.

[ehw]

Thanks!

Keep them coming!!