Re: [Bug 9484] Program refuses to run because of ProtectCD/ ProtectDISC copy-protection
On Mon, Mar 24, 2008 at 1:02 PM, Austin English <[EMAIL PROTECTED]> wrote: > > On Mon, Mar 24, 2008 at 12:51 PM, James Hawkins <[EMAIL PROTECTED]> wrote: > > On 3/24/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > http://bugs.winehq.org/show_bug.cgi?id=9484 > > > > > > > > > --- Comment #9 from Austin English <[EMAIL PROTECTED]> 2008-03-24 > > 12:43:54 --- > > > Can anyone test this in wine 0.9.58? Some other copy protections are > > working > > > better, and if this isn't working yet, we might want to delay it to > > wine 1.2... > > > > > > > What's the point of having a blocker list if we keep deferring those > > bugs? Granted not every bug in the list deserves a spot, but we need > > to knuckle down and get these bugs fixed. When we get closer to the > > release date, we can get a better idea of which bugs are not feasible > > to fix before the release. Until that point, this bug list needs to > > receive top priority. > > > > -- > > James Hawkins > > > > I was going through a few of the 1.0 bugs that haven't been tested in > a while. Since it has no demo, I can't personally test it, and was > trying to see if any progress has been made in the past few months (as > has been with SafeDisc). While it is certainly hard to tell if it can > be fixed by 1.0, having someone test it and see how much closer we are > to fixing it is the first step in figuring that out. > No objection there. My point about deferring bugs stands though. -- James Hawkins
Re: [Bug 9484] Program refuses to run because of ProtectCD/ ProtectDISC copy-protection
On Mon, Mar 24, 2008 at 12:51 PM, James Hawkins <[EMAIL PROTECTED]> wrote: > On 3/24/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > http://bugs.winehq.org/show_bug.cgi?id=9484 > > > > > > --- Comment #9 from Austin English <[EMAIL PROTECTED]> 2008-03-24 > 12:43:54 --- > > Can anyone test this in wine 0.9.58? Some other copy protections are > working > > better, and if this isn't working yet, we might want to delay it to wine > 1.2... > > > > What's the point of having a blocker list if we keep deferring those > bugs? Granted not every bug in the list deserves a spot, but we need > to knuckle down and get these bugs fixed. When we get closer to the > release date, we can get a better idea of which bugs are not feasible > to fix before the release. Until that point, this bug list needs to > receive top priority. > > -- > James Hawkins > I was going through a few of the 1.0 bugs that haven't been tested in a while. Since it has no demo, I can't personally test it, and was trying to see if any progress has been made in the past few months (as has been with SafeDisc). While it is certainly hard to tell if it can be fixed by 1.0, having someone test it and see how much closer we are to fixing it is the first step in figuring that out.
Re: [Bug 9484] Program refuses to run because of ProtectCD/ ProtectDISC copy-protection
On 3/24/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > http://bugs.winehq.org/show_bug.cgi?id=9484 > > > --- Comment #9 from Austin English <[EMAIL PROTECTED]> 2008-03-24 12:43:54 > --- > Can anyone test this in wine 0.9.58? Some other copy protections are working > better, and if this isn't working yet, we might want to delay it to wine > 1.2... > What's the point of having a blocker list if we keep deferring those bugs? Granted not every bug in the list deserves a spot, but we need to knuckle down and get these bugs fixed. When we get closer to the release date, we can get a better idea of which bugs are not feasible to fix before the release. Until that point, this bug list needs to receive top priority. -- James Hawkins
Re: Adding Bugzilla keyword for Copy-protection/Debugger issues
On Thursday 29 November 2007 14:00:00 Ben Hodgetts (Enverex) wrote: > Just a thought but it may be a good idea to add a keyword to Bugzilla > for issues related to debuggers or copy-protection, that would help > group them all together as at the moment there seem to be many bugs > related to breakages from obscure debugger protections or things like > GameGuard. It's much cleaner than the hated meta bug idea and is easier > to implement. > > Just a thought. > > Ben H. I think that is a great idea. Alexander N. Sørnes
Adding Bugzilla keyword for Copy-protection/Debugger issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a thought but it may be a good idea to add a keyword to Bugzilla for issues related to debuggers or copy-protection, that would help group them all together as at the moment there seem to be many bugs related to breakages from obscure debugger protections or things like GameGuard. It's much cleaner than the hated meta bug idea and is easier to implement. Just a thought. Ben H. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHTrfQuqCUopk11kIRAhDnAJ4iGkr6bUk1/FPUFrrdzlsnqC5dDwCfd2r5 WDylDKMPprC22RtEwYG01o4= =fLJB -END PGP SIGNATURE-
Re: Copy protection
Tim Schmidt wrote: On 10/6/06, Kai Blin <[EMAIL PROTECTED]> wrote: On Friday 06 October 2006 10:19, Tim Schmidt wrote: > Again, works for me. I believe the only part missing for this case is > the simulation. Of course, there's the added possibility that apps > will go mucking about with data other apps care about, in which case a > per-executable simulated device would be best. Wouldn't that break on Windows, too? If I have have two apps that muck about in my mbr, I expect them both to work, so they better do whatever they do in a sane way. I don't see how this would be different for a simulated drive. Yeah. you're right. I just don't trust every app that mucks about with the MBR to be courteous and correct ;) --tim Messing with the MBR might be the windows way, but last time I looked, even windows apps cannot access the HD directly. In Linux, any access by a user app to the MBR should never happen, except maybe by cfdisk,lilo grub and friends. Certainly NOT a wine application. No one in their right mind would run wine as root, knowing how many viruses windows has. I would suggest that these applications are not actually writing to the MBR, but instead there is a bug in wine causing it to happen. The only way to fix this whole MBR issue, is to find an application with copy protection, and actually get it to work. We will then have 100% accurate data regarding what feature we would actually need in wine to allow these copy protected applications to be compatible with wine. End the speculation. James
RE: Copy protection
Tim Schmidt wrote: > Again, works for me. I believe the only part missing for this case is > the simulation. Of course, there's the added possibility that apps > will go mucking about with data other apps care about, in which case a > per-executable simulated device would be best. Wouldn't such a combination of two apps mess up under real Windows too? I mean if they both write to the boot block or whatever on the disk device directly and change the same offsets then it's going to be a mess. Why should Wine be able to deal better with that than real Windows? Rolf Kalbermatter
Re: Copy protection
On 10/6/06, Kai Blin <[EMAIL PROTECTED]> wrote: On Friday 06 October 2006 10:19, Tim Schmidt wrote: > Again, works for me. I believe the only part missing for this case is > the simulation. Of course, there's the added possibility that apps > will go mucking about with data other apps care about, in which case a > per-executable simulated device would be best. Wouldn't that break on Windows, too? If I have have two apps that muck about in my mbr, I expect them both to work, so they better do whatever they do in a sane way. I don't see how this would be different for a simulated drive. Yeah. you're right. I just don't trust every app that mucks about with the MBR to be courteous and correct ;) --tim
Re: Copy protection
On Friday 06 October 2006 10:19, Tim Schmidt wrote: > Again, works for me. I believe the only part missing for this case is > the simulation. Of course, there's the added possibility that apps > will go mucking about with data other apps care about, in which case a > per-executable simulated device would be best. Wouldn't that break on Windows, too? If I have have two apps that muck about in my mbr, I expect them both to work, so they better do whatever they do in a sane way. I don't see how this would be different for a simulated drive. Cheers, Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpZWlG9OAh1p.pgp Description: PGP signature
Re: Copy protection
On 10/6/06, Vincent Povirk <[EMAIL PROTECTED]> wrote: On 10/5/06, Tim Schmidt <[EMAIL PROTECTED]> wrote: > An application you are running (Application Name) is attempting to > access a disk in a potentially unsafe way. Would you like it to > access a safe virtual disk instead? > > Yes No A dialog like this would only serve to confuse people. If a setting is needed, it can default to the "safe" case. People who really know what they are doing (and therefore might want to use such an option) can modify the registry. Works for me. Assuming modification of the appropriate registry setting is doable through winecfg. Is this really about having raw access to drive letters? If it is, the answer is simple: allow raw access if the drive letter has a device associated with it. If it doesn't (c: doesn't), then either don't allow it or simulate it. That easily covers both cases since copy protection would presumably work on c: and disk utilities would work with real disks. Again, works for me. I believe the only part missing for this case is the simulation. Of course, there's the added possibility that apps will go mucking about with data other apps care about, in which case a per-executable simulated device would be best. If it's really about what drives the program can see and not drive letters, then you need to store the information of which raw devices (/dev/hdX or an image file somewhere) the program sees independently of the drive letters. It sounds to me like it's more trouble than it's worth then to make disk utilities run in Wine. It doesn't seem to be something a lot of people want to do. It's not something they should want to do if it's with disks that they care about. And, well, virtual machines are much more suited to this than Wine is. So if copy protection wants to do things to physical hard disks rather than drive letters for some reason, I say simulate them and make copy protection happy. Again, no arguments. I just want to see apps work. --tim
Re: Copy protection
On 10/5/06, Tim Schmidt <[EMAIL PROTECTED]> wrote: An application you are running (Application Name) is attempting to access a disk in a potentially unsafe way. Would you like it to access a safe virtual disk instead? Yes No A dialog like this would only serve to confuse people. If a setting is needed, it can default to the "safe" case. People who really know what they are doing (and therefore might want to use such an option) can modify the registry. Is this really about having raw access to drive letters? If it is, the answer is simple: allow raw access if the drive letter has a device associated with it. If it doesn't (c: doesn't), then either don't allow it or simulate it. That easily covers both cases since copy protection would presumably work on c: and disk utilities would work with real disks. If it's really about what drives the program can see and not drive letters, then you need to store the information of which raw devices (/dev/hdX or an image file somewhere) the program sees independently of the drive letters. It sounds to me like it's more trouble than it's worth then to make disk utilities run in Wine. It doesn't seem to be something a lot of people want to do. It's not something they should want to do if it's with disks that they care about. And, well, virtual machines are much more suited to this than Wine is. So if copy protection wants to do things to physical hard disks rather than drive letters for some reason, I say simulate them and make copy protection happy. -- Vincent Povirk
Re: Copy protection
On 10/5/06, Vassilis Virvilis <[EMAIL PROTECTED]> wrote: How about a loopback device in linux? This is potentially already possible to do with wine. I use loopbacked CD images, so loopbacked MBR's should be easy enough, with no change to wine. Just set the device node link for the device to the loopback device node of the image you mounted ... etc. So no changes really required here, but I have no idea on the problems people face with the MBR access stuff.
Re: Copy protection
To clarify my thoughts, and throw this out there... Here's how I'm imagining this working: Assuming there's no problem intercepting the raw disk i/o attempts, the first time an app attempts a raw disk access, Wine can throw a popup (I know, I hate them too) with something like the following text: An application you are running (Application Name) is attempting to access a disk in a potentially unsafe way. Would you like it to access a safe virtual disk instead? Yes No Pressing "Yes" results in nice, safe behavior. Pressing "No" runs winecfg opened to the "Drives" tab, with perhaps an added checkbox "Allow potentially unsafe raw access" for each (relevant) drive. --tim
Re: Copy protection
On 10/5/06, Christoph Frick <[EMAIL PROTECTED]> wrote: the #2 folks are proficient enough with their systems to know what they are doing. the #1 folks hope to get away from the world of #2 things they are forced on the windows world when they change to unix. Not nescessarily. I'm thinking specifically of some of the more exotic forensic data-recovery software. Think Joe User (Joe Friday?) prefers to use *nix, however, the software he uses to simplify gathering all the various data he needs for an investigation (could be law-related, could be an intrusion, etc.) runs only on Windows. It'd be nice to grab an image of the drive with dd and work with it on his Linux machine. Just a note... this might be possible today... I believe setting up raw disk access for an actual disk or a file is possible under Wine currently... It would be nice to handle this case in a somewhat more regular-person-friendly way - and it's logical to include handling of sandboxed raw disk access in the same way. --tim
Re: Copy protection
On 10/5/06, Mike McCormack <[EMAIL PROTECTED]> wrote: UML has a COW (copy-on-write) layer [1]. If we had something like this, conceivable we could allow Wine to read raw disks (or the COW file), then write back to the COW file. QEMU has nice support for several different COW and sparse formats... might be a slightly friendlier place to borrow code from than UML. --tim
Re: Copy protection
Mike McCormack wrote: Tim Schmidt wrote: It sounds like a general framework for routing these kind of raw disk i/o would be useful... probably configurable by app would be most useful. UML has a COW (copy-on-write) layer [1]. If we had something like this, conceivable we could allow Wine to read raw disks (or the COW file), then write back to the COW file. It would be even nicer if the Linux kernel supported that in a general way... Mike [1] http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-7.html How about a loopback device in linux? .bill
Re: Copy protection
On Thu, Oct 05, 2006 at 04:25:38AM -0400, Tim Schmidt wrote: > What we're talking about here is a class of applications that expect > raw (or nearly-raw) disk access: > > - copy-protection that writes mysterious things to or near the MBR > - various utility software (virus scanners, disk defragmenters, > forensic tools, etc.) > - other possibilities? IMHO you can rule out #2. the majority of people using wine want to use their last few remaining apps they have no counterpart for unix and all their games. all these are copy-protection-pestered. the #2 folks are proficient enough with their systems to know what they are doing. the #1 folks hope to get away from the world of #2 things they are forced on the windows world when they change to unix. so #1 is definetly something that should be done with "files" - not "disks" - to prevent the masses from fiddling with /dev/sda permissions or running WINE as root. for the "law" point of view - i though about it from the comments of yesterdays discussion. reducing this to the plain thing i guessed so far: - assuming windows dont let anyone write directly to the disk the app has to gain some higher privs first - as this is no go for most of the admins out there i assume this apps install their .sys files all over the place and run as "drivers" so they get that extra privs granted - so here comes my big blank: once they have the privs: do the drivers actually work the machine or are they still using the win-api for stuff like writing to the disk? if the winapi is used i would asume there is no law-problem other than all the law problem "we allready have". but if they directly access the machine - can we actually intercept it? -- cu pgpOhf6R810Jt.pgp Description: PGP signature
Re: Copy protection
Tim Schmidt wrote: It sounds like a general framework for routing these kind of raw disk i/o would be useful... probably configurable by app would be most useful. UML has a COW (copy-on-write) layer [1]. If we had something like this, conceivable we could allow Wine to read raw disks (or the COW file), then write back to the COW file. It would be even nicer if the Linux kernel supported that in a general way... Mike [1] http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO-7.html
Re: Copy protection
It sounds like a general framework for routing these kind of raw disk i/o would be useful... probably configurable by app would be most useful. thoughts? I agree, a sandbox system where the 'litter box' (a sand box to put all your crap) would hold potentialy dangerous direct disk accesses to the MBR or close to it. it might be worth making one per app and making sure that you can't just read the contents so obscure it in some way as to allow us to prove that we're out for compatability and not piracy.
Re: Copy protection
On 10/5/06, Christoph Frick <[EMAIL PROTECTED]> wrote: and its very unlikely, that a sane person would WINE allow writing to the MBR (or close to it). right? OK... This discussion is veering off somewhat, but I believe it's heading in a fairly constructive direction. What we're talking about here is a class of applications that expect raw (or nearly-raw) disk access: - copy-protection that writes mysterious things to or near the MBR - various utility software (virus scanners, disk defragmenters, forensic tools, etc.) - other possibilities? Some of these tools - the forensic tools and copy-protected apps especially - would be nice if they worked on Wine. The two have different needs though... Presumably the forensic tools would be working on real drives - or copies of real drives. They need actual access. The copy-protection schemes do potentially dangerous things to actual drives - they need to be sandboxed in virtual drives that appear real. It sounds like a general framework for routing these kind of raw disk i/o would be useful... probably configurable by app would be most useful. thoughts?
Re: Copy protection
On Wed, Oct 04, 2006 at 07:10:41PM +0200, Kopfgeldjaeger wrote: > 2. raw disk access normally requires root rights. It's very unlikely > that Alexandre would permit anything which requires to run wine as root > (even if those are only additional features) and its very unlikely, that a sane person would WINE allow writing to the MBR (or close to it). right? -- cu pgpvVoCevT3GP.pgp Description: PGP signature
Re: Copy protection
On 10/4/06, H. Verbeet <[EMAIL PROTECTED]> wrote: On 04/10/06, Jesse Allen <[EMAIL PROTECTED]> wrote: > Guys, Wine programs can write to the MBR already with correct permissions... I think that should read "with wrong permissions" :-) Yes, very wrong from a security standpoint :P
Re: Copy protection
Le mercredi 04 octobre 2006 à 21:14 +0100, Martin Owens a écrit : > It's a very very bad idea, I don't understand why linux doesn't > protect normal users corrupting the disk at byte level that just seems > really bad for security. Every distro does AFAIK. However if people mess with their user's rights or don't understand why running user applications as root is dangerous there is nothing Linux can do against it. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Copy protection
On 04/10/06, Jesse Allen <[EMAIL PROTECTED]> wrote: Guys, Wine programs can write to the MBR already with correct permissions... I think that should read "with wrong permissions" :-)
Re: Copy protection
On Wed, Oct 04, 2006 at 09:41:16AM -0500, Tom Spear wrote: > > I agree that we shouldn't write to the MBR, but I definitely think that we > should get some legal guidance before we proceed with writing anything to a > file (in this case), because If it isn't a silly question, which part of the mbr sector do the games think they can access? Especially for write ? Having written the mbr code that NetBSD uses - which could validly be in sector zero of the boot disk of a windows systesm - I'm not at all certain there any bytes that can usefully be used. David -- David Laight: [EMAIL PROTECTED]
Re: Copy protection
It's a very very bad idea, I don't understand why linux doesn't protect normal users corrupting the disk at byte level that just seems really bad for security. On 10/4/06, Aaron Slunt <[EMAIL PROTECTED]> wrote: Jesse Allen wrote: > Guys, Wine programs can write to the MBR already with correct > permissions... > > http://bugs.winehq.org/show_bug.cgi?id=4672 > > > I hope nobody needs to explain why that's a very bad idea...
Re: Copy protection
Jesse Allen wrote: Guys, Wine programs can write to the MBR already with correct permissions... http://bugs.winehq.org/show_bug.cgi?id=4672 I hope nobody needs to explain why that's a very bad idea...
Re: Copy protection
On 10/4/06, Karsten Anderson <[EMAIL PROTECTED]> wrote: why not just implement the write to MBR? figure out how the copy protector does it and just implement it. as long as you know what you're doing and where the O/S stores its stuff you should be alright. put a few warnings on the instaeller and whatnot that this might be risky, and then let the user decide for himself :) Guys, Wine programs can write to the MBR already with correct permissions... http://bugs.winehq.org/show_bug.cgi?id=4672
Re: Copy protection
Maybe someone from FSF could provide legal guidance on this issue. http://www.fsf.org/about/contact.html
Re: Copy protection
Hi, Karsten Anderson wrote: > why not just implement the write to MBR? figure out how the copy > protector does it and just implement it. as long as you know what > you're doing and where the O/S stores its stuff you should be alright. > put a few warnings on the instaeller and whatnot that this might be > risky, and then let the user decide for himself :) 1. I don't think that it's really the MBR, because it's 512 Bytes are already too cramped with the partition table and the boot loader. Chances to break those things are too high. Maybe it's really an (unused) sector after the MBR, but even than: 2. raw disk access normally requires root rights. It's very unlikely that Alexandre would permit anything which requires to run wine as root (even if those are only additional features) Greetings KGJ
Re: Copy protection
On Wednesday 04 October 2006 09:25, Karsten Anderson wrote: > why not just implement the write to MBR? The user running Wine more than likely won't have such write access to the disk. Only root would be able to do that, and running Wine as root is far from encouraged. Plus, fooling around with the MBR like that is quite dangerous.
Re: Copy protection
Quoting EA Durbin <[EMAIL PROTECTED]>: What makes copy protection problematic to circumvent is not the math or the technical stuff, it is the laws protecting it :-( how does cedega do it? They license the code for the copy protection detection from the likes of macrovision. -- Darragh "Nothing's foolproof to a sufficently talented fool" Email service provided by the NUI, Galway Computer Society
Re: Copy protection
What makes copy protection problematic to circumvent is not the math or the technical stuff, it is the laws protecting it :-( how does cedega do it?
Re: Copy protection
why not just implement the write to MBR? figure out how the copy protector does it and just implement it. as long as you know what you're doing and where the O/S stores its stuff you should be alright. put a few warnings on the instaeller and whatnot that this might be risky, and then let the user decide for himself :) On 10/4/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote: > what keeps some nosy haxx0r from looking in the MBR (or some blocks > later) if he wants to find out about the copy protection? if they store > data like this unprotected (e.g. crypting them) then this is just > security-by-obscurity (which is no security at all). Copy protection IS security by obscurity from a cryptography point of view ;-) http://en.wikipedia.org/wiki/Kerckhoffs'_principle The thing is that the user HAS to be able to decrypt the movie / game / whatever and use it, so in some form he HAS to have the keys. The only thing that can be hidden is the algorithm and the location of the keys(sort of part of the algorithm). This can't work from a mathematical point of view. What makes copy protection problematic to circumvent is not the math or the technical stuff, it is the laws protecting it :-(
Re: Copy protection
> what keeps some nosy haxx0r from looking in the MBR (or some blocks > later) if he wants to find out about the copy protection? if they store > data like this unprotected (e.g. crypting them) then this is just > security-by-obscurity (which is no security at all). Copy protection IS security by obscurity from a cryptography point of view ;-) http://en.wikipedia.org/wiki/Kerckhoffs'_principle The thing is that the user HAS to be able to decrypt the movie / game / whatever and use it, so in some form he HAS to have the keys. The only thing that can be hidden is the algorithm and the location of the keys(sort of part of the algorithm). This can't work from a mathematical point of view. What makes copy protection problematic to circumvent is not the math or the technical stuff, it is the laws protecting it :-( pgpnJxzYMqQW6.pgp Description: PGP signature
Re: Copy protection
On Wed, Oct 04, 2006 at 04:09:51PM +0100, Martin Owens wrote: > Anyone techinicaly adept could find the MBR, it's the 1st sector on > the disk, this isn't about boot records but the MBR which is in a > known place. I recon you could use linux tools on your windows hard > drive to retrieve it easy. you could also use debug.exe (or was it com) shipping with dos/windows. might even be there in current version? -- cu pgp5dkeVDq5Dd.pgp Description: PGP signature
Re: Copy protection
On 10/4/06, Jonathan Ernst <[EMAIL PROTECTED]> wrote: Le mardi 03 octobre 2006 à 15:51 -0500, Tom Spear a écrit :[...]>>> I'm by no means an expert on copyright law or copy protection, but I> think that using any method other than writing directly to the MBR > with those copy protection measures would be illegal because writing> to a file (registry, wine-only proprietary db or any other type of> file) as opposed to writing to the mbr like the copy protection is > supposed to could potentially reveal data that the copy protection> companies don't want being revealed, and therefore that would end up> making wine a possible target for aiding circumvention. Sure there > are tools out there that crackers use that read the mbr and store it> in a file, so that they can circumvent the copy protection, but that> has nothing to do with wine.This doesn't require cracker tools, reading a MBR using standard tools like dd is as easy as reading a file or registry.JonathanGood point. I'll shut up now lol.-- ThanksTomCheck out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://www.imvu.com/catalog/web_registration.php?userId=1547373
Re: Copy protection
On Wed, Oct 04, 2006 at 09:41:16AM -0500, Tom Spear wrote: > I should add that I just thought about this and realized that we > _could_ always just encrypt the contents of the file as it is written > and read, so that we can actually get somewhere, and not be exposing > sensitive data at the same time, but it's just a thought. Anyone care > to comment on that? what keeps some nosy haxx0r from looking in the MBR (or some blocks later) if he wants to find out about the copy protection? if they store data like this unprotected (e.g. crypting them) then this is just security-by-obscurity (which is no security at all). the difference in the people able to read this data is just "total fool" to "fool" ;) on the other hand you have your point with the way a court might sees things. i think there is more of a problem with data theft. once i grab your .wine/drives/c:/.windows-mbr file i might end up with your ps/dw/... keys. its not even a problem to guess the location of that file. assuming that the key is there stored directly - finding WINE users with a legal and running copy of this software and the machine WFO to grab it... i guess i a better off with a hit-and-run in the local software store to get the software or just install some crack. -- cu pgp80jdg58o81.pgp Description: PGP signature
Re: Copy protection
Technically yes, but the difference is that VMware actually writes _everything_ into that one file vs wine proposing to write just what is written to the boot sector into a file.. The reason it is different, is because it is much more difficult (if not impossible) to tell what is boot sector and what isnt if you have a file that contains an entire drive's worth of data. Anyone techinicaly adept could find the MBR, it's the 1st sector on the disk, this isn't about boot records but the MBR which is in a known place. I recon you could use linux tools on your windows hard drive to retrieve it easy.
Re: Copy protection
Le mardi 03 octobre 2006 à 15:51 -0500, Tom Spear a écrit : [...] > > > I'm by no means an expert on copyright law or copy protection, but I > think that using any method other than writing directly to the MBR > with those copy protection measures would be illegal because writing > to a file (registry, wine-only proprietary db or any other type of > file) as opposed to writing to the mbr like the copy protection is > supposed to could potentially reveal data that the copy protection > companies don't want being revealed, and therefore that would end up > making wine a possible target for aiding circumvention. Sure there > are tools out there that crackers use that read the mbr and store it > in a file, so that they can circumvent the copy protection, but that > has nothing to do with wine. This doesn't require cracker tools, reading a MBR using standard tools like dd is as easy as reading a file or registry. Jonathan signature.asc Description: Ceci est une partie de message numériquement signée
Re: Copy protection
On 10/3/06, Martin Owens <[EMAIL PROTECTED]> wrote: On 10/3/06, Michael [Plouj] Ploujnikov <[EMAIL PROTECTED]> wrote:> > I'm by no means an expert on copyright law or copy protection, but I think> > that using any method other than writing directly to the MBR with those copy > > protection measures would be illegal because writing to a file (registry,> > wine-only proprietary db or any other type of file) as opposed to writing to> > the mbr like the copy protection is supposed to could potentially reveal > > data that the copy protection companies don't want being revealed, and> > therefore that would end up making wine a possible target for aiding> > circumvention. Sure there are tools out there that crackers use that read > > the mbr and store it in a file, so that they can circumvent the copy> > protection, but that has nothing to do with wine.>We should allow are technical solutions to be bogged down with the EUCD, we are clearly protected for making a compatible program and Ithink we should strive to introduce the protection under the technicalmeans we have available.the fact that we allow the copy protection to work at all proves we have no malicious intent.It would clearly be dangerous to write to the MBR and I would notrecommend us doing so.I agree that we shouldn't write to the MBR, but I definitely think that we should get some legal guidance before we proceed with writing anything to a file (in this case), because 1) as we have seen all too often lately, the US court system doesn't always see things the way everyone else does (cf NSA wiretapping bill(s)). and2) see previous emails about why writing _only_ the MBR to a file could be a sticky mess for some of us. I should add that I just thought about this and realized that we _could_ always just encrypt the contents of the file as it is written and read, so that we can actually get somewhere, and not be exposing sensitive data at the same time, but it's just a thought. Anyone care to comment on that? -- ThanksTomCheck out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://www.imvu.com/catalog/web_registration.php?userId=1547373
Re: Copy protection
On 10/3/06, Michael [Plouj] Ploujnikov <[EMAIL PROTECTED]> wrote: > I'm by no means an expert on copyright law or copy protection, but I think> that using any method other than writing directly to the MBR with those copy> protection measures would be illegal because writing to a file (registry, > wine-only proprietary db or any other type of file) as opposed to writing to> the mbr like the copy protection is supposed to could potentially reveal> data that the copy protection companies don't want being revealed, and > therefore that would end up making wine a possible target for aiding> circumvention. Sure there are tools out there that crackers use that read> the mbr and store it in a file, so that they can circumvent the copy > protection, but that has nothing to do with wine.Could you not say the same thing for vmware or any other virtualharddrive application?Technically yes, but the difference is that VMware actually writes _everything_ into that one file vs wine proposing to write just what is written to the boot sector into a file.. The reason it is different, is because it is much more difficult (if not impossible) to tell what is boot sector and what isnt if you have a file that contains an entire drive's worth of data. -- ThanksTomCheck out this new 3D Instant Messenger called IMVU. It's the best I have seen yet!http://www.imvu.com/catalog/web_registration.php?userId=1547373
Re: Copy protection
On 10/3/06, Michael [Plouj] Ploujnikov <[EMAIL PROTECTED]> wrote: > I'm by no means an expert on copyright law or copy protection, but I think > that using any method other than writing directly to the MBR with those copy > protection measures would be illegal because writing to a file (registry, > wine-only proprietary db or any other type of file) as opposed to writing to > the mbr like the copy protection is supposed to could potentially reveal > data that the copy protection companies don't want being revealed, and > therefore that would end up making wine a possible target for aiding > circumvention. Sure there are tools out there that crackers use that read > the mbr and store it in a file, so that they can circumvent the copy > protection, but that has nothing to do with wine. We should allow are technical solutions to be bogged down with the EUCD, we are clearly protected for making a compatible program and I think we should strive to introduce the protection under the technical means we have available. the fact that we allow the copy protection to work at all proves we have no malicious intent. It would clearly be dangerous to write to the MBR and I would not recommend us doing so.
Re: Copy protection
I'm by no means an expert on copyright law or copy protection, but I think that using any method other than writing directly to the MBR with those copy protection measures would be illegal because writing to a file (registry, wine-only proprietary db or any other type of file) as opposed to writing to the mbr like the copy protection is supposed to could potentially reveal data that the copy protection companies don't want being revealed, and therefore that would end up making wine a possible target for aiding circumvention. Sure there are tools out there that crackers use that read the mbr and store it in a file, so that they can circumvent the copy protection, but that has nothing to do with wine. Could you not say the same thing for vmware or any other virtual harddrive application? -- () ASCII Ribbon Campaign /\ - against HTML mail & vCards
Re: Copy protection
Hello > Sure there are tools out there that crackers use > that read the mbr and store it in a file, so that they can circumvent the > copy protection, but that has nothing to do with wine. IANAL but curcumventing for personal use using generic tools (wich wine is) and with no bad intentions can't be treated on the same level as using specific tools to break such protection. Do remember that most EULA's (for games and commercial programs) do not allow decompiling/recompiling the code, not using the program under a different operating system. IMHO the best possible thing to do is to ask an lawyer for an interpretation. -- Best regards Wojciech Arabczyk
Re: Copy protection
On 10/3/06, Robert Lunnon <[EMAIL PROTECTED]> wrote: On Tuesday 03 October 2006 02:18, James Courtier-Dutton wrote:> Martin Owens wrote:> >> Re Copy Protection.> >>> >> be quite hard to make this work I think?> >> > It would be quite dangerous to make this work. > >> > What about creating a file say with a fake data map, wine thinks it's> > the direct access to the hard drive where all this information is> > held. all we do is add the place where the data starts and the data > > thats stored. it would be slower but it would get around the dangers> > while keeping the interface the same.>> The easiest way round this is to simply recognise the executable with > the copy protection, and simply install a hook to catch the appropriate> file system or registry calls and divert them to a special handling> routine to satisfy the application. The difficulty would come from > actually implementing the "copy protection" part. I.e. Preventing the> wine user from copying the software.>> JamesWhy not just use a sparse database, IE when the write happens, record the program name, offset, length and data and on a read to that offset andlength, return the same data. Using the program name and offset as the lookupkey means you can even support multiple programs writing to the same space and you don't then need to handle space management (Can emulate an emptydisk). You could even use the registry.BobI'm by no means an expert on copyright law or copy protection, but I think that using any method other than writing directly to the MBR with those copy protection measures would be illegal because writing to a file (registry, wine-only proprietary db or any other type of file) as opposed to writing to the mbr like the copy protection is supposed to could potentially reveal data that the copy protection companies don't want being revealed, and therefore that would end up making wine a possible target for aiding circumvention. Sure there are tools out there that crackers use that read the mbr and store it in a file, so that they can circumvent the copy protection, but that has nothing to do with wine. -- ThanksTomCheck out this new 3D Instant Messenger called IMVU. It's the best I have seen yet!http://www.imvu.com/catalog/web_registration.php?userId=1547373
Re: Copy protection
On 10/3/06, Robert Lunnon <[EMAIL PROTECTED]> wrote: Part 3 Applies, however it could be read as being permissible for the purpose of implementing a compatible interface. IE for the purpose of making the copy protection work under Wine. I think it would be much safer to make the protection work from a circumvention point of view. IANAL More defensible? Certainly. Advisable? Of course. Strictly necessary as per the letter of the law? I suppose it's up to interpretation (what law isn't?), but the way I read it, Wine is completely protected - being that 'enabling interoperability of an independently created computer program with other programs' is it's sole purpose for existing. So, in summary, I pretty much agree entirely. --tim
Re: Copy protection
On Tuesday 03 October 2006 02:18, James Courtier-Dutton wrote: > Martin Owens wrote: > >> Re Copy Protection. > >> > >> be quite hard to make this work I think? > > > > It would be quite dangerous to make this work. > > > > What about creating a file say with a fake data map, wine thinks it's > > the direct access to the hard drive where all this information is > > held. all we do is add the place where the data starts and the data > > thats stored. it would be slower but it would get around the dangers > > while keeping the interface the same. > > The easiest way round this is to simply recognise the executable with > the copy protection, and simply install a hook to catch the appropriate > file system or registry calls and divert them to a special handling > routine to satisfy the application. The difficulty would come from > actually implementing the "copy protection" part. I.e. Preventing the > wine user from copying the software. > > James Why not just use a sparse database, IE when the write happens, record the program name, offset, length and data and on a read to that offset and length, return the same data. Using the program name and offset as the lookup key means you can even support multiple programs writing to the same space and you don't then need to handle space management (Can emulate an empty disk). You could even use the registry. Bob
Re: Copy protection
On Tuesday 03 October 2006 02:56, Tim Schmidt wrote: > On 10/2/06, Marcus Meissner <[EMAIL PROTECTED]> wrote: > > We can't, this kind of circumvention is likely to be illegal in the US. > > The relevant portion of the DMCA reads as follows: > (http://thomas.loc.gov/cgi-bin/query/F?c105:6:./temp/~c105bzNC4v:e11559:) > >`(2) No person shall manufacture, import, offer to the public, > provide, or otherwise traffic in any technology, product, service, > device, component, or part thereof, that-- > > `(A) is primarily designed or produced for the purpose of > circumventing a technological measure that effectively controls access > to a work protected under this title; > > `(B) has only limited commercially significant purpose or > use other than to circumvent a technological measure that effectively > controls access to a work protected under this title; or > > `(C) is marketed by that person or another acting in > concert with that person with that person's knowledge for use in > circumventing a technological measure that effectively controls access > to a work protected under this title. > > I believe we don't match A, B, or C. Further, > >`(f) REVERSE ENGINEERING- (1) Notwithstanding the provisions of > subsection (a)(1)(A), a person who has lawfully obtained the right to > use a copy of a computer program may circumvent a technological > measure that effectively controls access to a particular portion of > that program for the sole purpose of identifying and analyzing those > elements of the program that are necessary to achieve interoperability > of an independently created computer program with other programs, and > that have not previously been readily available to the person engaging > in the circumvention, to the extent any such acts of identification > and analysis do not constitute infringement under this title. > > `(2) Notwithstanding the provisions of subsections (a)(2) and > (b), a person may develop and employ technological means to circumvent > a technological measure, or to circumvent protection afforded by a > technological measure, in order to enable the identification and > analysis under paragraph (1), or for the purpose of enabling > interoperability of an independently created computer program with > other programs, if such means are necessary to achieve such > interoperability, to the extent that doing so does not constitute > infringement under this title. > > `(3) The information acquired through the acts permitted under > paragraph (1), and the means permitted under paragraph (2), may be > made available to others if the person referred to in paragraph (1) or > (2), as the case may be, provides such information or means solely for > the purpose of enabling interoperability of an independently created > computer program with other programs, and to the extent that doing so > does not constitute infringement under this title or violate > applicable law other than this section. > > Appears to grant specific permission for the kinds of work the Wine > devs need to do. > > --tim Part 3 Applies, however it could be read as being permissible for the purpose of implementing a compatible interface. IE for the purpose of making the copy protection work under Wine. I think it would be much safer to make the protection work from a circumvention point of view. Bob
Re: Copy protection
On 10/2/06, Marcus Meissner <[EMAIL PROTECTED]> wrote: We can't, this kind of circumvention is likely to be illegal in the US. The relevant portion of the DMCA reads as follows: (http://thomas.loc.gov/cgi-bin/query/F?c105:6:./temp/~c105bzNC4v:e11559:) `(2) No person shall manufacture, import, offer to the public, provide, or otherwise traffic in any technology, product, service, device, component, or part thereof, that-- `(A) is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title; `(B) has only limited commercially significant purpose or use other than to circumvent a technological measure that effectively controls access to a work protected under this title; or `(C) is marketed by that person or another acting in concert with that person with that person's knowledge for use in circumventing a technological measure that effectively controls access to a work protected under this title. I believe we don't match A, B, or C. Further, `(f) REVERSE ENGINEERING- (1) Notwithstanding the provisions of subsection (a)(1)(A), a person who has lawfully obtained the right to use a copy of a computer program may circumvent a technological measure that effectively controls access to a particular portion of that program for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs, and that have not previously been readily available to the person engaging in the circumvention, to the extent any such acts of identification and analysis do not constitute infringement under this title. `(2) Notwithstanding the provisions of subsections (a)(2) and (b), a person may develop and employ technological means to circumvent a technological measure, or to circumvent protection afforded by a technological measure, in order to enable the identification and analysis under paragraph (1), or for the purpose of enabling interoperability of an independently created computer program with other programs, if such means are necessary to achieve such interoperability, to the extent that doing so does not constitute infringement under this title. `(3) The information acquired through the acts permitted under paragraph (1), and the means permitted under paragraph (2), may be made available to others if the person referred to in paragraph (1) or (2), as the case may be, provides such information or means solely for the purpose of enabling interoperability of an independently created computer program with other programs, and to the extent that doing so does not constitute infringement under this title or violate applicable law other than this section. Appears to grant specific permission for the kinds of work the Wine devs need to do. --tim
Re: Copy protection
On Mon, Oct 02, 2006 at 05:18:57PM +0100, James Courtier-Dutton wrote: > Martin Owens wrote: > >>Re Copy Protection. > >> > >>be quite hard to make this work I think? > > > >It would be quite dangerous to make this work. > > > >What about creating a file say with a fake data map, wine thinks it's > >the direct access to the hard drive where all this information is > >held. all we do is add the place where the data starts and the data > >thats stored. it would be slower but it would get around the dangers > >while keeping the interface the same. > > > > > The easiest way round this is to simply recognise the executable with > the copy protection, and simply install a hook to catch the appropriate > file system or registry calls and divert them to a special handling > routine to satisfy the application. The difficulty would come from > actually implementing the "copy protection" part. I.e. Preventing the > wine user from copying the software. We can't, this kind of circumvention is likely to be illegal in the US. Ciao, Marcus
Re: Copy protection
On 10/2/06, James Courtier-Dutton <[EMAIL PROTECTED]> wrote: The easiest way round this is to simply recognise the executable with the copy protection, and simply install a hook to catch the appropriate file system or registry calls and divert them to a special handling routine to satisfy the application. The difficulty would come from actually implementing the "copy protection" part. I.e. Preventing the wine user from copying the software. Since we're not getting cooperation from the copy protection software houses, I don't think that's a major goal of this work. We'd like _copy protected_ software to work with Wine, who cares if the _copy protection_ software actually works beyond allowing the program to run? --tim
Re: Copy protection
Martin Owens wrote: Re Copy Protection. be quite hard to make this work I think? It would be quite dangerous to make this work. What about creating a file say with a fake data map, wine thinks it's the direct access to the hard drive where all this information is held. all we do is add the place where the data starts and the data thats stored. it would be slower but it would get around the dangers while keeping the interface the same. The easiest way round this is to simply recognise the executable with the copy protection, and simply install a hook to catch the appropriate file system or registry calls and divert them to a special handling routine to satisfy the application. The difficulty would come from actually implementing the "copy protection" part. I.e. Preventing the wine user from copying the software. James
Re: Copy protection
Re Copy Protection. be quite hard to make this work I think? It would be quite dangerous to make this work. What about creating a file say with a fake data map, wine thinks it's the direct access to the hard drive where all this information is held. all we do is add the place where the data starts and the data thats stored. it would be slower but it would get around the dangers while keeping the interface the same.
Re: Copy protection
Am Montag, 2. Oktober 2006 04:49 schrieb Vitaliy Margolen:
> EA Durbin wrote:
> >> So the short story is that copy protection support is the
> >> gating issue here, and it's a serious PITA.
> >
> > What specifically keeps most copy protection from working with wine?
> > Why does it work in some applications, such as Star Wars Jedi Academy
> > and not others?
>
> There are several types of copy protection. Those that use kernel
> drivers do not work on Wine because ... Wine has no kernel to load those
> drivers into. We will need at least ntoskrnl.exe implemented because
> it's more of a "dll" then exe and all drivers import number of functions
> from it.
>
> Of course we can only emulate "kernel" to some point. But even that
> would be enough for drivers that only check for debugger presence and
> nothing else.
>
As far as I know, the Flex copy protection scheme used by, for example,
Photoshop and ZBrush also writes a key somewhere on the harddisk. Not on the
file system, but somewhere in the unused space after the MBR IIRC. It should
be quite hard to make this work I think?
Ciao,
Willie
--
Willie Sippel
| Tritium Studios
// | __
///| http://www.tritium-studios.com
<[EMAIL PROTECTED]>
Re: Copy protection
EA Durbin wrote: >> So the short story is that copy protection support is the >> gating issue here, and it's a serious PITA. >> > > What specifically keeps most copy protection from working with wine? > Why does it work in some applications, such as Star Wars Jedi Academy > and not others? > There are several types of copy protection. Those that use kernel drivers do not work on Wine because ... Wine has no kernel to load those drivers into. We will need at least ntoskrnl.exe implemented because it's more of a "dll" then exe and all drivers import number of functions from it. Of course we can only emulate "kernel" to some point. But even that would be enough for drivers that only check for debugger presence and nothing else. Vitaliy
Copy protection
So the short story is that copy protection support is the gating issue here, and it's a serious PITA. What specifically keeps most copy protection from working with wine? Why does it work in some applications, such as Star Wars Jedi Academy and not others?
Re: HAL and Copy Protection
Ok, I just verified that HAL works perfectly fine for what we want. In fact, it does make thing easier for people as you don't have to mess with those device symlinks :) I don't suspect anything wrong with GCC 4.xx now, as I think the ubuntu package is compiled with 4.0.3. I think the report on that may have been a very early version 4 or a buggy distro. However, since I encountered no trouble, I don't know what's wrong with at least with one person's ubuntu... Jesse
Re: HAL and Copy Protection
On 8/7/06, Marcus Meissner <[EMAIL PROTECTED]> wrote: HAL should be of no importance here, there will be no visible difference to static CDROM configuration. Otherwise, no clue. Ciao, Marcus I just remembered that these new distros with HAL also have GCC 4.xx. I remember that it has been traced to be a cause of a problem with copy protection before when using wine compiled with it. You could be right that HAL has nothing to do it. I will check it all out when I get that version of GCC running too. Jesse
Re: HAL and Copy Protection
On 8/7/06, Marcus Meissner <[EMAIL PROTECTED]> wrote: HAL should be of no importance here, there will be no visible difference to static CDROM configuration. Otherwise, no clue. Ciao, Marcus I'm going to try setting up ubuntu with HAL on a spare machine and see what it does. I use slack and I don't want to change what I got already. It will take some time to download and hook up the machine, so that's why I asked here first. Jesse
Re: HAL and Copy Protection
On Sun, Aug 06, 2006 at 02:32:23PM -0700, Jesse Allen wrote: > On 8/6/06, Marcus Meissner <[EMAIL PROTECTED]> wrote: > >On Tue, Aug 01, 2006 at 11:25:12AM -0700, Jesse Allen wrote: > >> Does anyone have HAL and SecuRom copy protection working? I'm starting > >> to get support questions with people using HAL and I'm not sure how to > >> help them. I need information now that HAL support is in Wine on > >> whether SecuRom works with it and how to get it to work as I don't > >> have HAL. > >HAL as in the Freedesktop.org HAL or the Windows HAL? > Freedesktop's HAL. HAL should be of no importance here, there will be no visible difference to static CDROM configuration. Otherwise, no clue. Ciao, Marcus
Re: HAL and Copy Protection
On 8/6/06, Marcus Meissner <[EMAIL PROTECTED]> wrote: On Tue, Aug 01, 2006 at 11:25:12AM -0700, Jesse Allen wrote: > Does anyone have HAL and SecuRom copy protection working? I'm starting > to get support questions with people using HAL and I'm not sure how to > help them. I need information now that HAL support is in Wine on > whether SecuRom works with it and how to get it to work as I don't > have HAL. HAL as in the Freedesktop.org HAL or the Windows HAL? Ciao, Marcus Freedesktop's HAL.
Re: HAL and Copy Protection
On Tue, Aug 01, 2006 at 11:25:12AM -0700, Jesse Allen wrote: > Does anyone have HAL and SecuRom copy protection working? I'm starting > to get support questions with people using HAL and I'm not sure how to > help them. I need information now that HAL support is in Wine on > whether SecuRom works with it and how to get it to work as I don't > have HAL. HAL as in the Freedesktop.org HAL or the Windows HAL? Ciao, Marcus
Re: HAL and Copy Protection
On 8/1/06, Jesse Allen <[EMAIL PROTECTED]> wrote: On 8/1/06, Martin Owens <[EMAIL PROTECTED]> wrote: > the important part is not that HAL supports SecuRom (which it won't IMHO) > but if wine can use the direct access to the hardware in order to allow > securom to work through wine. > > Yes, that is correct. However I'm not sure if Wine interprets the HAL events correctly, or HAL overrides the important settings for correct hardware access. It's hard to know without having HAL on my system to look at. To be clearer, I'm wondering about Wine's HAL code.
Re: HAL and Copy Protection
On 8/1/06, Martin Owens <[EMAIL PROTECTED]> wrote: the important part is not that HAL supports SecuRom (which it won't IMHO) but if wine can use the direct access to the hardware in order to allow securom to work through wine. Yes, that is correct. However I'm not sure if Wine interprets the HAL events correctly, or HAL overrides the important settings for correct hardware access. It's hard to know without having HAL on my system to look at.
HAL and Copy Protection
Does anyone have HAL and SecuRom copy protection working? I'm starting to get support questions with people using HAL and I'm not sure how to help them. I need information now that HAL support is in Wine on whether SecuRom works with it and how to get it to work as I don't have HAL. Jesse
Re: Copy Protection & WINE
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.
Copy Protection & WINE
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)
Re: Copy Protection
Dustin Navea wrote: Guys, bug 2895 got me thinkin.. If we only support a handful of games that use copy protection, shouldnt we file a bug in Bugzilla and append that to 1434 (Get games working perfectly)? That way we can attach any copy protection related bugs to this metabug? Yes I think it's a good idea. Ivan.
Copy Protection
Guys, bug 2895 got me thinkin.. If we only support a handful of games that use copy protection, shouldnt we file a bug in Bugzilla and append that to 1434 (Get games working perfectly)? That way we can attach any copy protection related bugs to this metabug? If you are agreeable to to that, I will go ahead and file it. Dustin
Re: Warcraft 3 Copy Protection (regression?)
Brian Gunlogson wrote: Warcraft 3 will not run without a crack after the following commit: http://www.winehq.org/hypermail/wine-cvs/2004/03/0093.html If no one wants to tackle this immediately I'd like to fix it. Any ideas? Brian G. I don't know whether the difference was something about the version of WC3, or because I'd just upgraded to a 2.6 kernel, or because of the Wine version (20040309), but having upgraded Wine to 20040505 it no longer works. Some work was done to load the copy protection drivers, it would be very nice to get this working again. Can you try wine-20040408 to see if it works with that version? You can then pinpoint the regression by running CVS regression testing, instructions are at http://www.winehq.com/site/docs/wine-devel/cvs-regression Ivan. I think this is a message I posted some time ago, which turned out to be user error(sheepish grin) - although in figuring that out I did find another bug which was since fixed:-). Anyway, as far as I'm aware it's currently fine (though copy protection only works if winver is set to one of the NT line). Aneurin Price
Re: Warcraft 3 Copy Protection (regression?)
Warcraft 3 will not run without a crack after the following commit: http://www.winehq.org/hypermail/wine-cvs/2004/03/0093.html If no one wants to tackle this immediately I'd like to fix it. Any ideas? Brian G. > > I don't know whether the difference was something about the version of WC3, or > > because I'd just upgraded to a 2.6 kernel, or because of the Wine > > version (20040309), but having upgraded Wine to 20040505 it no longer works. > Some work was done to load the copy protection drivers, it would be very nice to > get this working again. Can you try wine-20040408 to see if it works with that > version? You can then pinpoint the regression by running CVS regression testing, > instructions are at http://www.winehq.com/site/docs/wine-devel/cvs-regression > > Ivan. ___ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com
Re: [ros-general] Re: copy protection - was: Re: Is it time for playing games on WINE?
Hi, On Tue, 11 Nov 2003 03:05:55 +0100, KJK::Hyperion wrote: > At 02.11 11/11/2003, Steven Edwards wrote: > >>Further run fails for Captive as 'secdrv.sys' is somehow broken driver as > >>it does not provide any way to mount a filesystem. :-? > > secdrv isn't a filesystem, nor a volume driver. This was just a joke, sorry for the confusion. ... > >>>- RtlUnwind > >>> This is a part of undocumented SEH (Structured Exception Handling) > >>implemented by ReactOS while fixed by Captive and partially combined > >>with native 'ntoskrnl.exe'. > > RtlUnwind is documented (altough its use isn't recommended), and > implemented by ReactOS Although ReactOS implements SEH it is compatible only with ReactOS code while is binary incompatible with SEH as being used by 'ntfs.sys'. Unfortunately Vizzini still did not merge the patches. Regards, Lace -- Jan Kratochvil; Captive: free r/w NTFS Filesystem; http://www.jankratochvil.net/
Re: [ros-general] Re: copy protection - was: Re: Is it time for playing games on WINE?
At 02.11 11/11/2003, Steven Edwards wrote: Further run fails for Captive as 'secdrv.sys' is somehow broken driver as it does not provide any way to mount a filesystem. :-? secdrv isn't a filesystem, nor a volume driver. Filesystems and volume drivers, in Windows NT, are special, and secdrv is neither. It's a trivial driver that just processes CREATE, CLOSE and DEVICE_CONTROL requests - Captive is kind of overkill, as it's mostly an implementation of the cache manager. Secdrv could be easily integrated in the Wine driver architecture with minimal glue code (e.g. to convert the DeviceIoControl() parameters to an IRP + I/O stack location) (A)Synchronous/(Non)Alertable IRPs (I/O Request Packet) can be tricky although it is generally solved by ReactOS/Captive and it is questionable how much it is perused by 'secdrv.sys' IRP handling code. secdrv.sys is mostly a twisted maze of function calls and decoding routines. As a driver it's completely unremarkable: all it does is reading the DEVICE_CONTROL parameters from the current I/O stack location and completing the IRP with IoCompleteRequest. It's clearly a mere matter of a hundred lines of code to emulate the environment it needs We are still having trouble loading SecDrv.sys on native ROS. hardcode the major version to 4, the minor version to 0 and the build number to 1381, and it will run. Trust me on this one - RtlUnwind > This is a part of undocumented SEH (Structured Exception Handling) implemented by ReactOS while fixed by Captive and partially combined with native 'ntoskrnl.exe'. RtlUnwind is documented (altough its use isn't recommended), and implemented by ReactOS We have a new SEH implementation that is not merged yet. The implementation we have is patent friendly as it implement SEH totaly differntly by using macros kind of like WINE. it's patent-unencumbered as it doesn't allocate exception registrations on the stack (actually, the code me and Filip keep bouncing on the lists does use the stack, but only because we need to try it on Windows. Using the heap or pools rather than the stack is a matter of redefining two macros)
Re: [ros-general] Re: copy protection - was: Re: Is it time for playing games on WINE?
At 18.17 09/11/2003, Steven Edwards wrote: The problem is how emulate windows kernel internal behavior (ie assembly tips as NtCurrentTeb) We have been looking in to loading this driver under ReactOS and all of the functions are implemented but it still returns STATUS_UNSUCESSFULL. I think that the imports of "PsGetVersion and NtBuildNumber" might have something to do with it. the driver reads the system's version, build number and service pack, and fails to load on an unknown platform, but it otherwise ignores the information. Furthermore, its runtime requirements are very limited - I estimate an evening of work at most to run it on Wine, since we already have: - a PE loader - support for SEH - a DDK The driver works under my Windows NT 4 laptop but not ReactOS. We may just have to hard code the values to match NT 4 and it could work. I believe this is the case
Re: copy protection - was: Re: Is it time for playing games on WINE?
Hello Jan! --- Jan Kratochvil <[EMAIL PROTECTED]> wrote: > Hi, > > On Mon, 10 Nov 2003 20:19:45 +0100, Raphaël Junqueira wrote: > ... > > > BTW, I have got as far with loading secdrv.sys as crashing on > unimplemented > > > IoCreateDevice. I believe the Io* functions will be the biggest > problems. > > It is no problem loading it and initializing it by Captive NTFS for > GNU/Linux: > http://www.jankratochvil.net/project/captive/ > > ./captive-cmdline --load-module=/tmp/ntoskrnl.exe > --filesystem=/tmp/secdrv.sys --debug-messages /dev/null > > (some trivia extensions done before a moment are currently only in > CVS: > > http://cvs.jankratochvil.net/viewcvs/*checkout*/captive/README?rev=HEAD > section 'CVS Bleeding Edge' > ) > > 'secdrv.sys' creates devices: > "\Device\AscKmd" (symlinked to "\DosDevices\AscKmd") > "\Device\Secdrv" (symlinked to "\DosDevices\Secdrv") > > It returns STATUS_SUCCESS afterwards. The log can be seen at > http://www.jankratochvil.net/priv/secdrv/secdrv-init-onlysecdrv.log > > I used secdrv.sys > http://www.jankratochvil.net/priv/secdrv/secdrv.sys > md5: bb6fbebebbd14429021f2851a60d8546 > > downloaded by Google from > http://www.kids-station.com/game/Patrician2/secdrv.sys > > Further run fails for Captive as 'secdrv.sys' is somehow broken > driver as it > does not provide any way to mount a filesystem. :-? > > Currently the example above requires 'ntoskrnl.exe' of NT-5.1 (XP). > Tried Service Pack 1 Free Build and Service Pack 1 Checked Build. > It would not be needed for such simple driver as 'secdrv.sys' but > Captive > currently requires it for its 'ntfs.sys' emulation, reasons below: > > http://www.jankratochvil.net/project/captive/doc/Details.html.pl#emulmeth_fs > > > The next step is to combine Captive with Wine to be able to run the > W32 > userland application with 'secdrv.sys'. Captive ported only the W32 > kernel part > of ReactOS to the GNU/Linux environment, no W32 userland code is > present there. Hmm. We really shouldnt need to make much changes to WINE to use Captive I would think. Once Captive+SevDrv and WINE are running you should have full access to the CDROM drive. > > Well, i don't think implementing simple (stupid?) Io* functions > will be > > diffcult. > > (A)Synchronous/(Non)Alertable IRPs (I/O Request Packet) can be tricky > although > it is generally solved by ReactOS/Captive and it is questionable how > much it is > perused by 'secdrv.sys' IRP handling code. We are still having trouble loading SecDrv.sys on native ROS. > > For me, the problem is what secdrv want to do with this functions > (maybe a > > voodoo test for safely check if the subsystem have a correct > behavior): > ... > > - - RtlUnwind > > This is a part of undocumented SEH (Structured Exception Handling) > implemented > by ReactOS while fixed by Captive and partially combined with native > 'ntoskrnl.exe'. I still have some suspections on the correctness of > the current > implementation but it works fine for 'ntfs.sys'. We have a new SEH implementation that is not merged yet. The implementation we have is patent friendly as it implement SEH totaly differntly by using macros kind of like WINE. Its looking good! Thanks Steven __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: copy protection - was: Re: Is it time for playing games on WINE?
Hi, On Mon, 10 Nov 2003 20:19:45 +0100, Raphaël Junqueira wrote: ... > > BTW, I have got as far with loading secdrv.sys as crashing on unimplemented > > IoCreateDevice. I believe the Io* functions will be the biggest problems. It is no problem loading it and initializing it by Captive NTFS for GNU/Linux: http://www.jankratochvil.net/project/captive/ ./captive-cmdline --load-module=/tmp/ntoskrnl.exe --filesystem=/tmp/secdrv.sys --debug-messages /dev/null (some trivia extensions done before a moment are currently only in CVS: http://cvs.jankratochvil.net/viewcvs/*checkout*/captive/README?rev=HEAD section 'CVS Bleeding Edge' ) 'secdrv.sys' creates devices: "\Device\AscKmd" (symlinked to "\DosDevices\AscKmd") "\Device\Secdrv" (symlinked to "\DosDevices\Secdrv") It returns STATUS_SUCCESS afterwards. The log can be seen at http://www.jankratochvil.net/priv/secdrv/secdrv-init-onlysecdrv.log I used secdrv.sys http://www.jankratochvil.net/priv/secdrv/secdrv.sys md5: bb6fbebebbd14429021f2851a60d8546 downloaded by Google from http://www.kids-station.com/game/Patrician2/secdrv.sys Further run fails for Captive as 'secdrv.sys' is somehow broken driver as it does not provide any way to mount a filesystem. :-? Currently the example above requires 'ntoskrnl.exe' of NT-5.1 (XP). Tried Service Pack 1 Free Build and Service Pack 1 Checked Build. It would not be needed for such simple driver as 'secdrv.sys' but Captive currently requires it for its 'ntfs.sys' emulation, reasons below: http://www.jankratochvil.net/project/captive/doc/Details.html.pl#emulmeth_fs The next step is to combine Captive with Wine to be able to run the W32 userland application with 'secdrv.sys'. Captive ported only the W32 kernel part of ReactOS to the GNU/Linux environment, no W32 userland code is present there. > Well, i don't think implementing simple (stupid?) Io* functions will be > diffcult. (A)Synchronous/(Non)Alertable IRPs (I/O Request Packet) can be tricky although it is generally solved by ReactOS/Captive and it is questionable how much it is perused by 'secdrv.sys' IRP handling code. > For me, the problem is what secdrv want to do with this functions (maybe a > voodoo test for safely check if the subsystem have a correct behavior): ... > - - RtlUnwind This is a part of undocumented SEH (Structured Exception Handling) implemented by ReactOS while fixed by Captive and partially combined with native 'ntoskrnl.exe'. I still have some suspections on the correctness of the current implementation but it works fine for 'ntfs.sys'. Regards, Lace -- Jan Kratochvil; Captive: free r/w NTFS Filesystem; http://www.jankratochvil.net/
Re: copy protection - was: Re: Is it time for playing games on WINE?
On Fri, 7 Nov 2003 05:59, Alexandre Julliard wrote: > The DMCA does not require copyright violation, what is illegal is > "circumventing" the protection measure, it doesn't really matter if > the replacement code has the same functionality or not. Decryption is a different matter - that's banned whether it is done for the purpose of providing the same functionality or not. Providing identical functionality to correctly implement other mechanisms not involving decryption is not as much of a problem.
Re: copy protection - was: Re: Is it time for playing games on WINE?
On Thu, 6 Nov 2003 20:00, Shachar Shemesh wrote: > I don't get it. As far as I understand, so long as the code in the Wine > archives does not allow running copied discs, we are not violating the > DMCA. If someone else takes Wine code and modifies it, that's where the > DMCA violation happens. I briefly checked the area of the US Code covering this last week, and based on my non-thorough reading you are correct, as long as you're not acting in concert with the person who modifies it.
Re: copy protection - was: Re: Is it time for playing games on WINE?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le Lundi 10 Novembre 2003 16:18, Robert Shearman a écrit : > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of Raphaël Junqueira > > Sent: 10 November 2003 08:05 > > To: Lionel Ulmer; Marcus Meissner > > Cc: Alexandre Julliard; Wine Devel > > Subject: Re: copy protection - was: Re: Is it time for playing games on > > WINE? > > > > Well it's not really easy as the NT_HEADER only declare: > > Characteristics: 0306 > > EXECUTABLE_IMAGE > > LINE_NUMS_STRIPPED > > 32BIT_MACHINE > > DEBUG_STRIPPED > > > > So we can only use the file extension (and maybe the imported > > libs, .sys files > > using kernel libs) to use the good "dll-entry" between .sys and > > .exe files :( > > > > I don't think Alexandre will love the hack to support this :) > > I think IMAGE_OPTIONAL_HEADER::Subsystem will be what we're looking for. Good, i haven't seen it :) > BTW, I have got as far with loading secdrv.sys as crashing on unimplemented > IoCreateDevice. I believe the Io* functions will be the biggest problems. Well, i don't think implementing simple (stupid?) Io* functions will be diffcult. For me, the problem is what secdrv want to do with this functions (maybe a voodoo test for safely check if the subsystem have a correct behavior): - - RtlQueryRegistryValues - - KeTickCount - - MmIsAddressValid - - RtlUnwind > Rob Regards, Raphael -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/r+TTp7NA3AmQTU4RAqA2AJ0WB5ajJMW2zuRc/+HGb+8Lm+F9QgCfTQd/ MzO3tng4IwHnQYfVFqyMXHE= =IJlJ -END PGP SIGNATURE-
RE: copy protection - was: Re: Is it time for playing games on WINE?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Raphaël Junqueira > Sent: 10 November 2003 08:05 > To: Lionel Ulmer; Marcus Meissner > Cc: Alexandre Julliard; Wine Devel > Subject: Re: copy protection - was: Re: Is it time for playing games on > WINE? > > Well it's not really easy as the NT_HEADER only declare: > Characteristics: 0306 > EXECUTABLE_IMAGE > LINE_NUMS_STRIPPED > 32BIT_MACHINE > DEBUG_STRIPPED > > So we can only use the file extension (and maybe the imported > libs, .sys files > using kernel libs) to use the good "dll-entry" between .sys and > .exe files :( > > I don't think Alexandre will love the hack to support this :) I think IMAGE_OPTIONAL_HEADER::Subsystem will be what we're looking for. BTW, I have got as far with loading secdrv.sys as crashing on unimplemented IoCreateDevice. I believe the Io* functions will be the biggest problems. Rob
Re: copy protection - was: Re: Is it time for playing games on WINE?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Le Lundi 10 Novembre 2003 08:11, Marcus Meissner a écrit : > On Fri, Nov 07, 2003 at 07:46:58PM +0100, Lionel Ulmer wrote: > > On Fri, Nov 07, 2003 at 10:32:02AM +, Mike Hearn wrote: > > > Lionel, could QEMU be used here? I guess the driver expects to have > > > kernel level access to the machine, so we could either: > > > > Well, as I have no idea how .SYS loading working and how it interfaces > > with the kernel, I cannot comment here. > > The newer .SYS files are just PE libraries. They have smaller section > alignments, but otherwise they look just like normal DLLs. > > They reference hal.dll, ntoskrnl.exe, etc. as imports. > > The main hook into them is the DRIVER_OBJECT struct. On initialisation you > call the DLL entry procedure with > DriverEntry(DRIVER_OBJECT*, UNICODE_STRING *name); > if I read > http://msdn.microsoft.com/library/en-us/kmarch/hh/kmarch/drvrrtns_6r76.asp > correctly. > > The DRIVER_OBJECT struct then gets filled with the function pointers the > driver supports. > http://msdn.microsoft.com/library/en-us/kmarch/hh/kmarch/k112_6jaq.asp for > a read. > > The patches I posted should allow loading of these driver dlls. > However, the start function is still called PE User DLL style, which > needs to be fixed. Well it's not really easy as the NT_HEADER only declare: Characteristics: 0306 EXECUTABLE_IMAGE LINE_NUMS_STRIPPED 32BIT_MACHINE DEBUG_STRIPPED So we can only use the file extension (and maybe the imported libs, .sys files using kernel libs) to use the good "dll-entry" between .sys and .exe files :( I don't think Alexandre will love the hack to support this :) > Ciao, Marcus Regards, Raphael -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/r0asp7NA3AmQTU4RAqNaAKCcxIwFn+TJEFbFAJ8BwkW6eCEt8gCfeNOn PKTSTc/YTHkd9tCbtvmr9Zw= =QWb6 -END PGP SIGNATURE-
Re: copy protection - was: Re: Is it time for playing games on WINE?
On Fri, Nov 07, 2003 at 07:46:58PM +0100, Lionel Ulmer wrote: > On Fri, Nov 07, 2003 at 10:32:02AM +, Mike Hearn wrote: > > Lionel, could QEMU be used here? I guess the driver expects to have > > kernel level access to the machine, so we could either: > > Well, as I have no idea how .SYS loading working and how it interfaces with > the kernel, I cannot comment here. The newer .SYS files are just PE libraries. They have smaller section alignments, but otherwise they look just like normal DLLs. They reference hal.dll, ntoskrnl.exe, etc. as imports. The main hook into them is the DRIVER_OBJECT struct. On initialisation you call the DLL entry procedure with DriverEntry(DRIVER_OBJECT*, UNICODE_STRING *name); if I read http://msdn.microsoft.com/library/en-us/kmarch/hh/kmarch/drvrrtns_6r76.asp correctly. The DRIVER_OBJECT struct then gets filled with the function pointers the driver supports. http://msdn.microsoft.com/library/en-us/kmarch/hh/kmarch/k112_6jaq.asp for a read. The patches I posted should allow loading of these driver dlls. However, the start function is still called PE User DLL style, which needs to be fixed. Ciao, Marcus
Re: copy protection - was: Re: Is it time for playing games on WINE?
Hello,
--- Raphaël_Junqueira <[EMAIL PROTECTED]> wrote:
> it is simple, only a PE module who work on kernel mode using os APIs:
>
> - -=(FeniX as [EMAIL PROTECTED])-(on tty2)-(at 13:39:31)=-
> -={$:'~'}=->winedump dump -j import
> /mnt/win_c2/windows/system32/drivers/
> secdrv.sys
> Contents of "/mnt/win_c2/windows/system32/drivers/secdrv.sys": 27440
> bytes
>
> Import Table size: 40
> offset 25404 ntoskrnl.exe
> Hint/Name Table: 6364
> TimeDataStamp: (Thu Jan 1 01:00:00 1970)
> ForwarderChain:
> First thunk RVA: 0260 (delta: 4294967295 0x)
> Ordn Name
>252 IoDeleteSymbolicLink 644a
>251 IoDeleteDevice 63b4
>247 IoCreateSymbolicLink 63c6
>243 IoCreateDevice 63de
>720 RtlInitUnicodeString 63f0
>687 RtlEqualUnicodeString 6408
>519 NtBuildNumber 6420
>760 RtlQueryRegistryValues 6430
>599 PsGetVersion 63a4
>434 KeTickCount 6462
>479 MmIsAddressValid 6470
>792 RtlUnwind 6492
> 54 ExAllocatePoolWithTag 649e
> 66 ExFreePool 64b6
>325 IofCompleteRequest 64c4
>
> Done dumping /mnt/win_c2/windows/system32/drivers/secdrv.sys
>
> The problem is how emulate windows kernel internal behavior (ie
> assembly tips
> as NtCurrentTeb)
We have been looking in to loading this driver under ReactOS and all of
the functions are implemented but it still returns STATUS_UNSUCESSFULL.
I think that the imports of "PsGetVersion and NtBuildNumber" might have
something to do with it. The driver works under my Windows NT 4 laptop
but not ReactOS. We may just have to hard code the values to match NT 4
and it could work.
If we can get it to load on ROS it will be up to you guys to figure out
a way to adapt ROS+WINE to play nice together. =)
Thanks
Steven
__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
Re: copy protection - was: Re: Is it time for playing games on WINE?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le Friday 07 November 2003 19:46, Lionel Ulmer a écrit :
> On Fri, Nov 07, 2003 at 10:32:02AM +, Mike Hearn wrote:
> > Lionel, could QEMU be used here? I guess the driver expects to have
> > kernel level access to the machine, so we could either:
>
> Well, as I have no idea how .SYS loading working and how it interfaces with
> the kernel, I cannot comment here.
>
> Note that a low level kernel presentation by ReactOS people would be a nice
> thing to have at Wineconf :-)
>
> Lionel
it is simple, only a PE module who work on kernel mode using os APIs:
- -=(FeniX as [EMAIL PROTECTED])-(on tty2)-(at 13:39:31)=-
-={$:'~'}=->winedump dump -j import /mnt/win_c2/windows/system32/drivers/
secdrv.sys
Contents of "/mnt/win_c2/windows/system32/drivers/secdrv.sys": 27440 bytes
Import Table size: 40
offset 25404 ntoskrnl.exe
Hint/Name Table: 6364
TimeDataStamp: (Thu Jan 1 01:00:00 1970)
ForwarderChain:
First thunk RVA: 0260 (delta: 4294967295 0x)
Ordn Name
252 IoDeleteSymbolicLink 644a
251 IoDeleteDevice 63b4
247 IoCreateSymbolicLink 63c6
243 IoCreateDevice 63de
720 RtlInitUnicodeString 63f0
687 RtlEqualUnicodeString 6408
519 NtBuildNumber 6420
760 RtlQueryRegistryValues 6430
599 PsGetVersion 63a4
434 KeTickCount 6462
479 MmIsAddressValid 6470
792 RtlUnwind 6492
54 ExAllocatePoolWithTag 649e
66 ExFreePool 64b6
325 IofCompleteRequest 64c4
Done dumping /mnt/win_c2/windows/system32/drivers/secdrv.sys
The problem is how emulate windows kernel internal behavior (ie assembly tips
as NtCurrentTeb)
Best Regards,
Raphael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/rOnQp7NA3AmQTU4RAtQ5AJ99fd0sys8VnKiAoq6RktXUBW1m/gCfZh/j
ryAQ5sOXI+ZpgNFFKQfkq3M=
=yMii
-END PGP SIGNATURE-
Re: copy protection - was: Re: Is it time for playing games on WINE?
Hiya Lionel, --- Lionel Ulmer <[EMAIL PROTECTED]> wrote: > On Fri, Nov 07, 2003 at 10:32:02AM +, Mike Hearn wrote: > > Lionel, could QEMU be used here? I guess the driver expects to have > > kernel level access to the machine, so we could either: > > Well, as I have no idea how .SYS loading working and how it > interfaces with > the kernel, I cannot comment here. > > Note that a low level kernel presentation by ReactOS people would be > a nice > thing to have at Wineconf :-) We will see what we can put together for wineconf =) I have been following this thread for a while so I have to speak up about the DMCA issues you guys have been discussing. It is in the ReactOS Projects interest to have a working safedisk driver also so we might be able to work together on something. There has been work at loading Windows filesystem drivers using ReactOS in the past so I dont see safedisk being that big of a deal. http://www.jankratochvil.net/project/captive/ Copying the safedisk driver from Windows and loading it in ReactOS should just work as we have the same design microsoft does. Adapting that to work on Linux+ReactOS you would need to talk to Jan. Still the better method is for us to write our own safedisk driver from scratch but I am not sure that this wont violate the DMCA. IMHO the WINE project should adopt the defence the xbox-linux and the ReactOS projects have: "Everything done on this project is for the sole purpose of writing interoperable software under Sect. 1201 (f) Reverse Engineering exception of the DMCA." We will still have the legal battle to fight one day but I think you will win if you reimplement safedisk and use this as your argument. One day WINE, ReactOS and other project are going to get taken to court over the DMCA. This is a given. The question is do you want it to be over this? Is gamming support in WINE and ReactOS important enough to you? Thanks Steven __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: copy protection - was: Re: Is it time for playing games on WINE?
On Fri, Nov 07, 2003 at 10:32:02AM +, Mike Hearn wrote: > Lionel, could QEMU be used here? I guess the driver expects to have > kernel level access to the machine, so we could either: Well, as I have no idea how .SYS loading working and how it interfaces with the kernel, I cannot comment here. Note that a low level kernel presentation by ReactOS people would be a nice thing to have at Wineconf :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: copy protection - was: Re: Is it time for playing games on WINE?
Mike Hearn <[EMAIL PROTECTED]> writes: > Alexandre - do these options sound sane? I would suggest investigating the problems before we start designing the solutions... -- Alexandre Julliard [EMAIL PROTECTED]
Re: copy protection - was: Re: Is it time for playing games on WINE?
On Thu, 2003-11-06 at 23:54, Alexandre Julliard wrote: > The usual technique: run the app, see what breaks, implement the > missing feature/fix the bug, retry. The first thing of course is to > investigate how to support loading the needed driver. Lionel, could QEMU be used here? I guess the driver expects to have kernel level access to the machine, so we could either: * Use enough magic and voodoo to make the driver think it's in kernel mode when actually it's in userland. Maybe the instruction emulation tricks we currently use for broken Win9x apps would work here? * Write a "wine for drivers". There is prior art in this area, it could be done, but might be an awful lot of work. * Maybe use QEMU to allow the driver to be run in a VM. Even if we can't invoke code directly here, RPC shims would work, I doubt a copy protection driver has high throughput requirements. Alexandre - do these options sound sane? thanks -mike
Re: copy protection - was: Re: Is it time for playing games on WINE?
On Thursday 06 November 2003 03:31 pm, Geoff Thorpe wrote: > War crime tribunals, environmental protection treaties, privacy > legislation, ... the ability to let chilling effects meet little or no > significant organised obstacle has become the trademark of a certain > breed of "freedom-loving" people. Bruce Schneier once said that the "war > on drugs" was the root password to the US constitution. I think they > changed the password recently to use "terrorism" instead of "drugs", but > it's still much the same dance - ridiculous legislation is ushered in in > the name of "protecting rights" when in fact it is invariably used to > achieve quite the opposite. The issue is not whether you exercise a > personal disobedience to it, because Wine itself certainly can't, but > whether something can be done to aid efforts to overturn these laws. In > the mean time, (and as long as people in the US are involved in Wine,) > we're stuck with them. Here here! It is really unfortunate that wine is another victim of the DMCA, but I'd rather Alexandre played it safe, lest we be made an "example." If some rebellious individuals want to contribute these sorts of patches, as sort of an act of civil disobedience, I suggest they post them to /freenet/. Once the DMCA is eliminated (one can hope...), then A can reconsider. -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: copy protection - was: Re: Is it time for playing games on WINE?
>"the Copyright Office ruled that the DMCA does not block software >developers from using reverse engineering to circumvent digital >protection of copyright material if they do so to achieve >interoperability with an independently created computer program." So some people in the US do believe in freedom, IMHO this solves the issue.
Re: copy protection - was: Re: Is it time for playing games on WINE?
>In the mean time, (and as long as people in the US are involved in Wine,) >we're stuck with them. Not is we publish (Host) wine outside the US.
Re: copy protection - was: Re: Is it time for playing games on WINE?
>I don't get it. As far as I understand, so long as the code in the Wine >archives does not allow running copied discs, we are not violating the >DMCA. If someone else takes Wine code and modifies it, that's where the >DMCA violation happens. Right, I think a lot of people would be happy to host the code, only that codeweavers can'thost wine anymore, and we use sourceforge (You an just publish binaries, but we can maybe ask if we can if we host the source somewhere else), but until wine doesn't allow to run copyed discs, I don't see the problem, Of course, the sode may be easy to change, but if you put it like that then cd recorders should be illegal too.
Re: copy protection - was: Re: Is it time for playing games on WINE?
"Ann and Jason Edmeades" <[EMAIL PROTECTED]> writes: > [Ever had the feeling you regret asking a question...] > > Possibly another question for Alexander then - Realistically do you believe > that we can ever support copy protection, and if so how? I definitely think we can support it yes. It's just a matter of being compatible enough; that code is a Windows app, it works under Windows, so there's no theoretical reason it cannot be made to work. All it takes is someone motivated enough to implement it properly. > If we can work out how to load the driver in question (which remember is > safedisk specific, there's others) then are we ok to put dodgy hacks in wine > to ensure the driver gets the results it is expecting? Dodgy hacks are not OK here any more than anywhere else, but adding a proper implementation of the required features is fine. > Possibly a follow on > question then is how are we supposed to work out what the driver is > expecting, ie is debugging it a way to go? The usual technique: run the app, see what breaks, implement the missing feature/fix the bug, retry. The first thing of course is to investigate how to support loading the needed driver. -- Alexandre Julliard [EMAIL PROTECTED]
Re: copy protection - was: Re: Is it time for playing games on WINE?
[Ever had the feeling you regret asking a question...] Possibly another question for Alexander then - Realistically do you believe that we can ever support copy protection, and if so how? If we can work out how to load the driver in question (which remember is safedisk specific, there's others) then are we ok to put dodgy hacks in wine to ensure the driver gets the results it is expecting? Possibly a follow on question then is how are we supposed to work out what the driver is expecting, ie is debugging it a way to go? Sorry, not being obstructive - I want to stick the the techically achievable goals. Jason
Re: copy protection - was: Re: Is it time for playing games on WINE?
Hi there, On November 6, 2003 02:18 pm, Shachar Shemesh wrote: > Alexandre Julliard wrote: > >So the question is whether the code in question is "circumventing" the > >protection or not. > > If the code in Wine still doesn't allow unprotected CDs from running, > there can be no problem. > > >I think you would have a hard time convincing > >someone that a dummy driver that returns magic values is not > >circumventing part of the copy protection, even if the resulting > >behavior is identical to the original. > > If the resulting behaviour is that copied CDs don't work, while > original ones do, there is no circumvention (the mechanism that > protects access to a copyrighted work is still in place). > > If this driver works with a CD, regardless of whether it was or was not > copied, then we have a problem, yes. Of course, IANAL, YANAL, and MOUANLE (Most Of Us Are Not Lawyers Either). However I think the point here, and it seems to be Alexandre's reading of it too if I understood the thrust of his post, is that the "protection mechanism" here is a backdoor between the driver and the kernel that ensure, in the windows environment, that Microsoft (and whoever produce the driver) control your use of the protected CD. You cannot put a "virtualisation" layer in between the application using this "protection mechanism" such that it no longer has any assurance that the protection mechanism is authentic. In a sense, the protection procedure *can* be circumvented, which means it *has* been. Yeah this is totally ridiculous, but the DMCA is totally ridiculous. We won't have difficulty finding common ground there. :-) > Remeber, the "chilling effect" is when we let the DMCA control what we > do further than what it was meant to do to begin with. I can't see > anyone taking you to court saying "look, it's true that with Wine you > can't do anything that you can't do without, but it's an unlicensed > version, so it's a DMCA violation". War crime tribunals, environmental protection treaties, privacy legislation, ... the ability to let chilling effects meet little or no significant organised obstacle has become the trademark of a certain breed of "freedom-loving" people. Bruce Schneier once said that the "war on drugs" was the root password to the US constitution. I think they changed the password recently to use "terrorism" instead of "drugs", but it's still much the same dance - ridiculous legislation is ushered in in the name of "protecting rights" when in fact it is invariably used to achieve quite the opposite. The issue is not whether you exercise a personal disobedience to it, because Wine itself certainly can't, but whether something can be done to aid efforts to overturn these laws. In the mean time, (and as long as people in the US are involved in Wine,) we're stuck with them. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/
Re: copy protection - was: Re: Is it time for playing games on WINE?
Shachar Shemesh <[EMAIL PROTECTED]> writes: > If the code in Wine still doesn't allow unprotected CDs from running, > there can be no problem. No, it's not that simple. By providing a replacement driver, you are circumventing a technical measure controlling access to the work. The fact is that without the driver you don't get access, and with the dummy Wine driver you do; since the dummy Wine driver is not an "authorized" way to get access it's circumvention. It doesn't matter at all whether it lets you use copied CDs or not. Besides, I don't see how you could possibly prove that our implementation does exactly the same thing as the original one. Maybe the original doesn't only prevent copied CDs, maybe it also checks the phase of the moon or whatever, you have no way to make sure the protection is implemented correctly. > That's because of what DeCSS does. DeCSS is the circumvention device > itself. It takes an encrypted DVD and produces unencrypted MPEGs. For > example - I'm pretty sure that if you statically link Xine with > libdecss, you will get a binary that is perfectly legal (region codes > non-withstanding). I'm not so sure. Since it decrypts DVDs in a way that is not authorized by the copyright holder, technically it's circumvention. It doesn't matter whether it lets you infringe copyright or not. > Remeber, the "chilling effect" is when we let the DMCA control what we > do further than what it was meant to do to begin with. I can't see > anyone taking you to court saying "look, it's true that with Wine you > can't do anything that you can't do without, but it's an unlicensed > version, so it's a DMCA violation". Actually I think this is pretty likely. Nobody is going to go to the trouble of investigating exactly what the driver does, when it's much easier to simply send the lawyers and get rid of it; especially when we are dealing with a company like Macrovision that makes a living selling this snake oil^H^H^H^H^H^H^Hcopy protection stuff. This is why it's important to not only make sure it is legal, but also make sure it looks obviously legitimate to a casual observer. The dummy driver fails that test. -- Alexandre Julliard [EMAIL PROTECTED]
Re: copy protection - was: Re: Is it time for playing games on WINE?
Alexandre Julliard wrote: Shachar Shemesh <[EMAIL PROTECTED]> writes: I don't get it. As far as I understand, so long as the code in the Wine archives does not allow running copied discs, we are not violating the DMCA. If someone else takes Wine code and modifies it, that's where the DMCA violation happens. The DMCA does not require copyright violation, what is illegal is "circumventing" the protection measure, it doesn't really matter if the replacement code has the same functionality or not. For example it's illegal to decrypt your own DVDs with DeCSS, but it's legal to do it with an "approved" player, even though they are of course both running the exact same algorithm. Yes it's absurd, but that's the way the law is written. So the question is whether the code in question is "circumventing" the protection or not. If the code in Wine still doesn't allow unprotected CDs from running, there can be no problem. I think you would have a hard time convincing someone that a dummy driver that returns magic values is not circumventing part of the copy protection, even if the resulting behavior is identical to the original. If the resulting behaviour is that copied CDs don't work, while original ones do, there is no circumvention (the mechanism that protects access to a copyrighted work is still in place). If this driver works with a CD, regardless of whether it was or was not copied, then we have a problem, yes. If this becomes a real issue, I can offer to host the Wine sources in a DMCA free country. I'm sure you'll all agree with me that the sources are the only prolematic part (if a given binary does not allow copied discs to run, it cannot be said to be infringing). No, a binary is problematic too. The DeCSS exe is just as illegal as the source. That's because of what DeCSS does. DeCSS is the circumvention device itself. It takes an encrypted DVD and produces unencrypted MPEGs. For example - I'm pretty sure that if you statically link Xine with libdecss, you will get a binary that is perfectly legal (region codes non-withstanding). It doesn't strip away (circumvent) the protection, it's just a player (i.e. - used the same way as it was meant to be used). I'm not sure how legal the source for that will be, but like I said, I think I can provide a place where the sources should be safe. Personally, I think the sources should also be legal, so long as we don't place a prominant #ifdef that, if set, produces a circumvention device. Remeber, the "chilling effect" is when we let the DMCA control what we do further than what it was meant to do to begin with. I can't see anyone taking you to court saying "look, it's true that with Wine you can't do anything that you can't do without, but it's an unlicensed version, so it's a DMCA violation". -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/
Re: copy protection - was: Re: Is it time for playing games on WINE?
Shachar Shemesh <[EMAIL PROTECTED]> writes: > I don't get it. As far as I understand, so long as the code in the > Wine archives does not allow running copied discs, we are not > violating the DMCA. If someone else takes Wine code and modifies it, > that's where the DMCA violation happens. The DMCA does not require copyright violation, what is illegal is "circumventing" the protection measure, it doesn't really matter if the replacement code has the same functionality or not. For example it's illegal to decrypt your own DVDs with DeCSS, but it's legal to do it with an "approved" player, even though they are of course both running the exact same algorithm. Yes it's absurd, but that's the way the law is written. So the question is whether the code in question is "circumventing" the protection or not. I think you would have a hard time convincing someone that a dummy driver that returns magic values is not circumventing part of the copy protection, even if the resulting behavior is identical to the original. OTOH you can make a pretty good case that a generic "Windows driver loader" is not circumventing anything, it's just doing what any Windows replacement is supposed to do. > If this becomes a real issue, I can offer to host the Wine sources in > a DMCA free country. I'm sure you'll all agree with me that the > sources are the only prolematic part (if a given binary does not allow > copied discs to run, it cannot be said to be infringing). No, a binary is problematic too. The DeCSS exe is just as illegal as the source. -- Alexandre Julliard [EMAIL PROTECTED]
Re: copy protection - was: Re: Is it time for playing games on WINE?
Geoff Thorpe wrote: [snip] subject to trivial circumvention. I can't see how this can be done without requiring a DMCA violation in Wine, the O/S kernel, or requiring the copying of a closed-source driver that *itself* is irreplacable (choosing to load it from Wine and say "don't edit this Wine code to circumvent the commercial driver" in a C comment won't jive). Perhaps I've misunderstood something about the copy-protection model here, but the law itself seems to preclude a general open source solution, no matter how you slice it. [snip] How about interoperability? See: http://maccentral.macworld.com/news/2003/10/30/lexmarkcase/ "the Copyright Office ruled that the DMCA does not block software developers from using reverse engineering to circumvent digital protection of copyright material if they do so to achieve interoperability with an independently created computer program." regards, Jakob
