despoticruin

The time frame is mostly to avoid some annoying firmware locks on the drive. Also, that Dell drive is probably a Hitachi or a Liteon rebrand, they don’t make drives themselves. It shouldn’t matter much for reads, both manufacturers have good and bad drives.

All that being said give it a shot, worse case you still get read errors and you are back to square one.

The magic comes from hardware more than software, as others have mentioned you want a good burner to do the rips.

Sorry for the rabbit hole, but media archival is its own can of worms that would take hours to dive into, so in general you want an Asus DVD drive that’s internal, manufactured between 2004 and 2010, supports 52x CD speeds, doesn’t have light scribe, and has the DVD-RW logo on the front bezel. Those are usually the magic drives, and you are generally going to need modified firmware to do some of the more bizarre reads. The Asus BW-16D1HT does Blu-ray and multi region discs, for just DVDs look for one of the DRW-**** drives without light scribe (they have a laser assembly that is higher power to write with, but usually doesn’t have as clean of a signal in exchange, not the best for rips)

From there the software depends on your specific workflow. If you are just trying to recover clean disc rips then dd or ddrescue are going to be your friend. Get a disc image, mount it, use the data from the image instead of the disc. For archiving just the media look into MakeMKV, FFMPEG, and Handbrake for ways to encode the DVDs and audio into friendlier formats. Ffmpeg specifically can be scripted very easily and does audio just as well as video, it is the gold standard for transcoding media.

We need a drive that’s at least… Three times this size!

No, because that’s not how the matching works. Stuff in your data partition, as well as app data, is signed with those keys and hashed to the device. All of those bits do that hash on their own, and they all have to match up. When you change the main system partition then it’s signature has to match with the one generated when you set up your phone initially in the data partition.

Basically you have to have access to the data partition to disable the checks or change the signature, which needs your pin/passcode/fingerprint, and if you have that you don’t even need the phone, you dump the data partition and unlock it in an emulated android environment and exfiltrate data from there as if it was the original phone.

I also want to reiterate: A locked bootloader does not stop anyone from dumping your phone, emulating it, and brute forcing it, completely bypassing any rate-limiting on password attempts. By the time a bootloader lock even comes into play you can consider your phone completely compromised.

People here are also missing one part of the android security model. Yes, you can overwrite the system partition arbitrarily while leaving the data partition intact with an unlocked bootloader, that’s how updates work.

However, the moment you make any changes to that system partition it won’t match the developers signature and the apps on the system will throw an absolute fit. Look into building your own lineage ROM and flashing it over an official build, it’s an entire process that requires your data partition to be unlocked (ie. phone booted and pin entered) to keep your data, even without making changes.

Realistically it isn’t insecure, if you set a passcode your data is encrypted and if someone mitm attacks your rom you will immediately notice stuff breaking all over the place.

The whole bootloader locking is purely vendors trying to force you to buy new phones every few years instead of the user backporting security patches indefinitely, not any practical security for the end user.

That’s why they said revenue, not profit. You never go for the net. Always go for the gross.