PDA

View Full Version : maybe a different approach to SecuROM et. al.


Darkelf
April 22nd, 2010, 13:05
Hi guys,

this evening while I went shopping for dinner, something came into my mind. It was about SecuROM or any other game copy protection out there. First of all, I was never into this DVD protection stuff so all of the following is just an intellectual game by now.
I wonder if it's possible to intercept and log the communication between a DVD drive and a game's exe (to be precise: the protection of the exe). If it's possible - and I strongly believe it is - then why not making an interlayer that hooks that communication and feed the protection with exactly the data that an original DVD would provide? I know, that protections check if a drive is just emulated, but that's not important, because I don't want to emulate a drive. I want to use a real drive and tamper the communication. That would have a lot of advantages. The original exe doesn't need to be unpacked, it would be possible to update the game without the need for a new No-DVD, one interceptor could serve any game by just feeding it another logfile and so on.
As I mentioned , I was never really into this stuff and maybe all I've written so far is just gibberish, but I would love to make this a real project. So, I'd like to hear your opinions. I don't want to ride a dead horse, but if you think it's possible, I'll do my very best.

Best regards
darkelf

FrankRizzo
April 22nd, 2010, 18:51
It SOUNDS feasible darkelf. Back in the DOS days, I saw it done with floppy based protections by hooking Int 13h. There was a nasty protection called Rob Northen's Copylock that did a bunch of stupid floppy tricks, and I saw a TSR that had the sector data in it, and when it asked for a specific sector, the TSR just copied it to the buffer. Worked like a charm.

Now, from my limited understanding, some of the DVD stuff is done with timing, and sector skew. Those might be a litter tougher, but by no means impossible. Look at the Xbox 360 hack. It started as an attack on the DVD BIOS. Same with the original Wii hack. So, it COULD be done.

I would recommend that you spend some time here (http://www.cdmediaworld.com/hardware/cdrom/cd_protections.shtml) boning up on how the various protections work, get a game with a simple one on it, and give it a shot!

evlncrn8
April 23rd, 2010, 08:05
sadly an idea already done - gamejackal (slysoft) uses the record/playback approach, sometimes it works, sometimes its hit and miss...

Darkelf
April 24th, 2010, 08:35
Aaaarghh, I'm cursed! Whenever I have an idea that sounds good, it turns out that somebody else had it before.
Well, it won't stop me this time. Even if some commercial tool exists, I can still try to make it on my own. It will be my spare time project for the next weeks (month?). It will surely take some time as I have to read a lot of stuff concering hooking and raw access to the drive, but even if I fail it wouldn't have been wasted time, because I will certainly learn alot while doing this.

FrankRizzo:
Thank you very much for the link and the encouragement.
It will be useful.

Best regards
darkelf

evlncrn8
April 26th, 2010, 10:13
actually, most is a deviceiocontrol hook with record / playback.. some parts need altered runtime (if its on someone elses pc for example...)

laola
April 28th, 2010, 07:14
a plain record/playback scheme would also fail to work in lots of cases. Copy protection these days evaluates reading timings caused by glass master manipulation that cannot be recreated using consumer hardware. In simple terms there are areas on the disc where e.g. pits and lands are noticeable larger than usual, resulting in slower reading and seeking. These density changes can be measured with high precision counters but of course the checking algorithm does not measure the same spots every time. Alcohol 120% used to measure the whole disc and create a density profile stored in the image file to solve that.

Another trick on optical media is to create small duplicate sector ranges. The sector "headers" are identical in both ranges, just not the user data in them. Thus reading them returns different results when seeking from one side or the other of the range into it.

That's also difficult to implement with plain record/playback.

I was imagining a small custom hardware hooking up to the IDE bus between drive and computer for such purposes a couple of years ago. It never went any further than some rough ideas though