Drive: Matshita DVD-RAM UJ8B9
Disc used: http://redump.org/disc/484/

sarami has even started referencing the sheet to add support for more drives in DiscImageCreator for the raw dvd dump commands.

I was also trying this on my LG GH22LS30. Turns out I killed it. It got stuck at the first bruteforce stage, so I powercycled it mid-run. Which was a bad idea. The drive started to rapidly bang it's head against whatever wall is in the drive and refuses to read any disc since then, no matter if it is a DVD or a CD.

Well, at least I can say it died for science.

ASUS DRW-24B5ST
HL-DT-ST GH40F
HL-DT-ST GH41N
HL-DT-ST GH60N
LITE-ON eTDU108
LITE-ON iHAS120
Sony Optaric AD-7280S fw 1.01 and 1.60 (Same drive, different firmware)

Had to cancel ASUS on F1 values as they were going to take many hours and my desktop was lagging. System wouldn't shut down either until I pulled the SATA from the drive.

https://mega.nz/file/jLolGLyQ#pTEOKvjM1 … uL-JEQrG8s

Keep them coming!!

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

MrPepka wrote:

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 - http://redump.org/disc/84828/

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

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

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

- 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

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

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

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.