From what I understand, there are 3 ways to do copy protection in WINE (at least for copy protection that needs a kernel driver to work): 1.Implement a WINE implementation of that kernel driver (in the same way various stock windows kernel drivers have been implemented). Problem with this is that there is a big DMCA risk (which is why AFAIK its been rejected) 2.Implement a fake NTOSKRNL that has just the entrypoints for accessing and loading copy protection drivers (the set of kernel calls needed by the copy protection drivers is only a very small subset of the total set of kernel calls and AFAIK none of them are hardware related) or 3.Implement a proper kernel driver loader (i.e. one that would sit in the windows kernel and do the same sort of thing as that ndiswrapper and that ntfs.sys loader do)
What is the current state of copy protection work for WINE? Which of these 3 options do the developers intend to follow? (I remember someone posted some actual code for option 2 but I dont remember if anything happened with it)
Jonathan Wilson wrote:
From what I understand, there are 3 ways to do copy protection in WINE (at least for copy protection that needs a kernel driver to work): 1.Implement a WINE implementation of that kernel driver (in the same way various stock windows kernel drivers have been implemented). Problem with this is that there is a big DMCA risk (which is why AFAIK its been rejected)
This will never be done, apart from the DMCA it would require a new driver for each new build of every copy protection system in the world
2.Implement a fake NTOSKRNL that has just the entrypoints for accessing and loading copy protection drivers (the set of kernel calls needed by the copy protection drivers is only a very small subset of the total set of kernel calls and AFAIK none of them are hardware related)
This is what I'm doing, the safedisc 1 driver works quite well with it, some ring 0 emulation is needed but that also works quite well and isn't much of an issue.
or 3.Implement a proper kernel driver loader (i.e. one that would sit in the windows kernel and do the same sort of thing as that ndiswrapper and that ntfs.sys loader do)
This would be a real pain as it would mean implementing the windows binary driver interface in the kernel, it would also not be very portable.
Ivan.
-
Ivan Leo Puoti -
Jonathan Wilson