redump.info Forum

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.

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.

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.

Code: Select all

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

Code: Select all

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