Thoughts on reverse engineering firmware to enable scrambled reads?

I am returning to this topic because I am also interested in it. I myself have a drive without scrambled mode, but I couldn't find a way to modify the firmware

I asked him about it and he couldn't help it. Nevertheless, maybe this project would somehow help decode the names of functions in the software for the drive? - https://github.com/quarkslab/binbloom

I haven't thought about this for a while, but I'm looking for an excuse to get going on a nice RE project, so maybe I'll look into it again as I have time. Full disclosure, though: I'm not remotely good at RE. At all. I haven't even done any serious assembly language work in years.

In any case, my suspicion is that there are definitely people around who have done enough reversing on CD/DVD drive firmwares to be able to do something like this in a jiffy, but a lot of those people are probably long gone to working on newer projects.

But, at least for older drives that don't bother with any kind of encryption / signature for the firmware, it should be possible to pretty easily modify any behavior that's present in the firmware. One issue is going to be that some behavior is surely happening at a lower level. For example, I suspect the actual descrambling on most drives would be done in hardware just using a scrambling table and an XOR. However, something like blocking 0xBE from working on data discs is probably (?) handled at the firmware level. Thus, while maybe it wouldn't be possible to directly play with the descrambling code, it might be possible just to bypass the check that disallows 0xBE on data discs.

It may even be the case that someone out there has a debug firmware that allows manipulating memory values in the drive. If that were the case, it maybe would be as simple as just using such a firmware and then sending a debug command to alter the memory region holding the TOC after a disc was inserted. I.e., change it so that the drive thinks the data track is an audio track.

I would imagine at least some parts of this are doable without huge effort for someone who knows what they're doing. Unfortunately, that someone is not me. But, I'm willing to take another look at it, especially if someone gets some leads.

Thanks for the info! Last time I just picked a random old drive I had lying around to play with, and I'll probably do the same this time when I take a look at it. This gives me one more option if it turns out to be running an odd chipset. IIRC, the last one I looked at was an Intel 8501 ISA firmware, but that was, again, just because that's what I happened to have lying around.

As a general note for this thread, a potentially useful document on firmware reversing is available on Archive (https://web.archive.org/web/20101225174 … rmware.pdf). It's specifically about reversing a DVD firmware to make it region free, but a lot of what it describes would need to be done for a project like this as well. It has specific notes about locating the code within the firmware that handles A3 and A4 operations. While those aren't operations we'd likely be concerned about, locating them would likely provide insight to the general structure of the code and provide a starting point for locating and modifying code that handles other operations (like 0xBE potentially).