Question about WINE and adding the "low-level" CD access APIs...
Many copy protections use special tricks on the CDs (I dont know the details). Presumably these protections use some kind of lower-level API to access the data on the CD directly (instead of going through the file I/O calls). Currently TransGaming does something specific for each kind of copy protection to make it work. Would it be possible to implement these APIs in WINE and have them redirect to whatever low level APIs are provided by linux/x/whatever? That way (assuming the implementation was complete), any copy protection would work (i.e. when the protection says "give me this bit of data from the CD in this form", WINE hooks that, gets the relavent data and returns it to the application. Same could be said for protections that use the "boot blocks" to store licence data (such as CDilla Licence Manager), for those you could hook the "read from boot block" and "write to boot block" calls and store the data somewhere (preferably not the real boot block :) If someone can tell me what the low-level access that these protections use is actually called (i.e. what search term to use in MSDN to look for documentation etc) as well as info on whatever the relavent linux low-level access stuff would be, I can look at drawing up some kind of "here is how this could be done" document. Similar low-level hooks could be used to allow things like AudioCatalyst (program that converts audio-cd tracks to MP3 files) and anything else that does lower level access to CDs/DVDs than the high-level file I/O APIs and etc. (the day its possible to run Nero Burning Rom in WINE with no problems will be a great day indeed for the project :) If this isnt fesable for copy protection and so on, please explain why (I know nothing about copy protection or how to program the CD-ROM in win32) Basicly, I dont understand why there is a need for "protection-specific" code in WineX when you could emulate whatever the protection uses and appear just like real windows to the game...
If someone can tell me what the low-level access that these protections use is actually called (i.e. what search term to use in MSDN to look for documentation etc) as well as info on whatever the relavent linux low-level access stuff would be, I can look at drawing up some kind of "here is how this could be done" document.
I believe ASPI is a commonly used interface. Certainly on a game I tried last night, ASPI was used to try and do something with SecuROM.
Similar low-level hooks could be used to allow things like AudioCatalyst (program that converts audio-cd tracks to MP3 files) and anything else that does lower level access to CDs/DVDs than the high-level file I/O APIs and etc. (the day its possible to run Nero Burning Rom in WINE with no problems will be a great day indeed for the project :)
If you implemented low level CD routines, that'd be why you did so. But considering the wealth of Linux programs that are available for these tasks, it's not an especially high priority.
If this isnt fesable for copy protection and so on, please explain why (I know nothing about copy protection or how to program the CD-ROM in win32) Basicly, I dont understand why there is a need for "protection-specific" code in WineX when you could emulate whatever the protection uses and appear just like real windows to the game...
Basically, at least some copy protection systems attempt to load the Win32 equivalent of kernel modules. SafeDisc does this for instance in order to detect debuggers and .... well, who knows what else. If you use google power you can probably find the original analysis of how SafeDisc worked, basically lots of disassembly was required, as well as producing a user mode Wine version of the driver it used. So, implementing support for copy protection is not so simple. Wine cannot currently run native Win32 VxDs (or .drv files), they must be rewritten for Wine. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
Hi, Not that I don't know a lot about copy protections but what I know might help you a little. There are various different copy protections. The most popular I think is Safedisc followed by SecureRom. Atleast Safedisc uses some .vxd/.sys driver to do some stuff. Not exactly sure what it is doing. Something related to extracting the executable. Some time ago Laurent Pinchart tried to implement Safedisc version 1.x. He managed to get some games working but the code never made it into wine because of DMCA issues. (also one of the reasons Transgaming's cd code isn't open another is that they have some deals with Macrovision the makers of Safedisc) Check his work here: http://www.winehq.com/hypermail/wine-patches/2002/04/0194.html I don't know much about SecureRom other than that some Blizzard games use it. (and others) Your welcome to look into Safedisc (really lots of games atleast use it). You can try to port Laurent's work over to a recent Wine version and you can contact him for more info. Creating a driver for the newer Safedisc 2.x too would take lots of debugging.. Perhaps a better way is nowadays to find a way to load the Windows .sys/.vxd driver. In the past this was about impossible but now it might not be that hard anymore. To get this working an x86 emulator is needed with ring0 support or whatever it is. Recently a new x86 emulator called qemu popped up that is useable for this task I think. It can both emulate Linux x86 binaries (binary loader) and even simulate a Linux system. (it has a x86 emu library that can be used under the LGPL too) If interested check here: http://fabrice.bellard.free.fr/qemu/ I hope my little info helped, Roderick On Monday 14 July 2003 14:24, Jonathan Wilson wrote:
Many copy protections use special tricks on the CDs (I dont know the details). Presumably these protections use some kind of lower-level API to access the data on the CD directly (instead of going through the file I/O calls). Currently TransGaming does something specific for each kind of copy protection to make it work. Would it be possible to implement these APIs in WINE and have them redirect to whatever low level APIs are provided by linux/x/whatever? That way (assuming the implementation was complete), any copy protection would work (i.e. when the protection says "give me this bit of data from the CD in this form", WINE hooks that, gets the relavent data and returns it to the application. Same could be said for protections that use the "boot blocks" to store licence data (such as CDilla Licence Manager), for those you could hook the "read from boot block" and "write to boot block" calls and store the data somewhere (preferably not the real boot block :)
If someone can tell me what the low-level access that these protections use is actually called (i.e. what search term to use in MSDN to look for documentation etc) as well as info on whatever the relavent linux low-level access stuff would be, I can look at drawing up some kind of "here is how this could be done" document.
Similar low-level hooks could be used to allow things like AudioCatalyst (program that converts audio-cd tracks to MP3 files) and anything else that does lower level access to CDs/DVDs than the high-level file I/O APIs and etc. (the day its possible to run Nero Burning Rom in WINE with no problems will be a great day indeed for the project :)
If this isnt fesable for copy protection and so on, please explain why (I know nothing about copy protection or how to program the CD-ROM in win32) Basicly, I dont understand why there is a need for "protection-specific" code in WineX when you could emulate whatever the protection uses and appear just like real windows to the game...
Perhaps a better way is nowadays to find a way to load the Windows .sys/.vxd driver. In the past this was about impossible but now it might not be that hard anymore. To get this working an x86 emulator is needed with ring0 support or whatever it is. Recently a new x86 emulator called qemu popped up that is useable for this task I think. It can both emulate Linux x86 binaries (binary loader) and even simulate a Linux system. (it has a x86 emu library that can be used under the LGPL too) If interested check here: http://fabrice.bellard.free.fr/qemu/
You would need to write implementations for the internal kernel APIs, which are AFAIK non-existant in Wine. How many of us know how to write drivers for NT, let alone clone those APIs? Not many :( -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
If someone wants to implement the calls, likely the ReactOS guys are willing to help. If I'm right they are able to load some real Windows drivers nowadays. On Monday 14 July 2003 14:57, Mike Hearn wrote:
Perhaps a better way is nowadays to find a way to load the Windows .sys/.vxd driver. In the past this was about impossible but now it might not be that hard anymore. To get this working an x86 emulator is needed with ring0 support or whatever it is. Recently a new x86 emulator called qemu popped up that is useable for this task I think. It can both emulate Linux x86 binaries (binary loader) and even simulate a Linux system. (it has a x86 emu library that can be used under the LGPL too) If interested check here: http://fabrice.bellard.free.fr/qemu/
You would need to write implementations for the internal kernel APIs, which are AFAIK non-existant in Wine. How many of us know how to write drivers for NT, let alone clone those APIs? Not many :(
I don't know much about SecureRom other than that some Blizzard games use it. (and others)
OK, so I got a bit bored at work and did some research :) SecuRom looks like a very advanced kind of protection technology but thankfully one that shouldn't be very hard to emulate in Wine. Most of the information out there on it is obviously related to cracking it, or removing it from games. However, I did find one article that showed in detail how it was reverse engineered. So, how does this thing work? Well, basically Sony have a special (patented) technique used at the CD factory. They somehow encode a digital signature or key into the CDs in a way that normal CD copiers cannot duplicate. That prevents nasty pirates from copying the CD. When the game is run, it reads the CD to get this encryption key, then uses it to decrypt parts of the game. Pretty similar to SafeDisc in fact. The hard parts of these systems for poor old Wine is always the anti-reverse-engineering traps they put in. For instance with SafeDisc they loaded a kernel driver to try and prevent people attaching debuggers. Well, it seems that luckily SecuRom doesn't do this. To read the CD, it doesn't even try and control the CD drivers, instead it interrupts down into MSCDEX: I spare you the effort of finding how the program accesses the cdrom: it uses INT 31 with AH=03 (DPMI 0.9+ - SIMULATE REAL MODE INTERRUPT) to call MSCDEX interrupt. Wine already has some DOS emulation in it, so I think that wouldn't be too hard to do, maybe it already works. Exactly how it retrieves the key from the CD is something of a mystery, however other articles I found refer to performing various analyses upon the disk and getting graphs etc out of it, so presumably it is a bit like stenography. Luckily I don't think we don't care about that. The rest of this article, which you can find here: http://216.239.39.104/search?q=cache:vauzwpy1P9AJ:www.woodmann.com/fravia/se... is mostly about how to remove the protection. Although SecuRom is very complex, like I said, mostly it's there to stop reverse engineering. One technique it uses is to replace every call instruction in the code with a call to a jump table. It unwinds the stack to figure out where it was called from, then rewrites that part of the code before actually performing the call. It's a bit like the ELF PLT. I believe either current or future versions use something called "Metamorphosis" which dynamically rewrites and shuffles the code, basically it's a code obfustucator, it might even do it at runtime! The idea is to stop you disassembling the code (obviously). So, there we go. I expect it would not be all that hard to make Wine work with SecuRom at least, you just need to make the mapping between MSCDEX and the Linux low level CD routines. Unfortunately SafeDisc is a lot more popular, it seems. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center
Mike Hearn wrote:
I don't know much about SecureRom other than that some Blizzard games use it. (and others)
So, there we go. I expect it would not be all that hard to make Wine work with SecuRom at least, you just need to make the mapping between MSCDEX and the Linux low level CD routines.
Unfortunately SafeDisc is a lot more popular, it seems.
All, I posted the following in response to a similar question about a month ago and have received a few individual emails from people saying it worked for them, too. The short version is that in "NT" mode, some of these must use a different mechanism that Wine already supports. Cheers, -ajp
Re: Warcraft 3 Issues (RedHat 9)
Date: Mon Jun 09 2003 - 11:22:52 CDT
Ann and Jason Edmeades wrote:
Hiya,
Firstly I can only talk about wine, not winex as I really dont have a clue about that.
fixme:file:SetFileAttributesW (L"C:\\WINDOWS\\SYSTEM\\SIntf16.dll"):100 >attribute(s) not implemented. fixme:file:SetFileAttributesW (L"C:\\WINDOWS\\SYSTEM\\SIntf32.dll"):100 >attribute(s) not implemented. fixme:file:SetFileAttributesW (L"C:\\WINDOWS\\SYSTEM\\SIntfNT.dll"):100 >attribute(s) not implemented.
This is copy protection. Wine does not support this form of copy protection yet, so you need to find a nocd patch.
Actually, I have observed this working (without using a patch) for quite a long time as long as:
1) The Windows version is set to one of the "NT" ones 2) The ide-scsi option is NOT included when booting 3) The authentic CD-ROM is in the drive
Sometimes it hangs up after printing those three lines above, but killing the wine process and restarting it generally fixes it. Normally, there is a (longish) pause and a lot of CD-ROM activity after those lines are printed before the game screen comes up. If I have ide-scsi turned on, it just keeps accessing the CD-ROM until I kill the process.
I just tried the very latest from CVS and it crashed inside winmm.c until I disabled sound, but as it used to work perfectly (with -opengl anyway) I will go and find the update that broke that.
Cheers, -ajp
participants (4)
-
Alex Pasadyn -
Jonathan Wilson -
Mike Hearn -
Roderick Colenbrander