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/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 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, kai Dot blin At gmail Dot com 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, 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
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
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
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/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
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
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
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
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 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
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
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, 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
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, 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
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
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
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
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 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
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
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 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
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
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
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
Maybe someone from FSF could provide legal guidance on this issue. http://www.fsf.org/about/contact.html
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
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
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
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
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
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 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
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 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 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 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, lengthand 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
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
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
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
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
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
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
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
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, 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
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
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.
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.
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?
-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 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?
Hi, On Mon, 10 Nov 2003 20:19:45 +0100, Raphal 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 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?
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: [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: [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: 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?
Geoff Thorpe wrote: On November 5, 2003 01:00 am, Jonathan Wilson wrote: Basicly as long as our code: A.cant run copied safedisk disks (perfect copies and no-cd cracks aside) and B.cant be modified to run copied safedisk disks (e.g. by disabling some parts of the WINE code that performed checks) then I think that we would probobly not be violating the DMCA (although IANAL) This is slippery ground. Given that Wine is open source (and moreover, very clearly laid-out, non-obfuscated, *structured* code), you can't possibly satisfy (A) and (B) in such a way that they aren't easy to bypass (ie. such that I can't simply comment out a couple of lines of code and type make). 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. 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). Shachar -- 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?
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: 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?
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?
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?
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?
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?
None whatsoever, the driver reimplementation is clearly a DMCA violation. The proper way to do that is to somehow load the driver and let it perform all the checks it wants to perform; a dummy driver that returns magic values to bypass the checks is not acceptable. From what I know about copy protection, they basicly work as follows: 1.There is special code that is designed to detect the presense of a debugger such as SoftIce 2.There is special code to read special hidden information from the CD (and if it doesnt exist or isnt correct, reject the CD as copied) and 3.There are modifications to the exe file/game code (e.g. encrypted code or messed up Import Address Tables or whatever else), sometimes relying on the hidden CD data, sometimes not. From looking at the posted safedisk-dmca.diff and from looking at secrdv.sys in IDA pro it would appear that the primary purpose of secdrv.sys is to allow access to areas in kernel mode not normally accessable to userland code, more specificly, its used to check certain things for the presense of a kernel level debugger (e.g. SoftIce). The actual copy protection code is (as far as I know, correct me if I am wrong) contained in various dlls and other code (including code thats inside the game exe itself) that operates in userland and sends IOCTLs to the CDROM drive to get the secret data back. Basicly as long as our code: A.cant run copied safedisk disks (perfect copies and no-cd cracks aside) and B.cant be modified to run copied safedisk disks (e.g. by disabling some parts of the WINE code that performed checks) then I think that we would probobly not be violating the DMCA (although IANAL) If someone wants to disagree with me or has evidence refuting my statements (legally or technically, please do post here or mail me.
Re: copy protection - was: Re: Is it time for playing games on WINE?
El mié, 05 de nov de 2003, a las 00:50, Raphaël Junqueira escribio: Alexandre, is there any chance of this code *ever* being excepted into the wine tree? None whatsoever, the driver reimplementation is clearly a DMCA violation. The proper way to do that is to somehow load the driver and let it perform all the checks it wants to perform; a dummy driver that returns magic values to bypass the checks is not acceptable. Why about trying to get this driver working on top of current ntdll ? All drivers accesses should pass by kernel calls no ? Hmm, really loading/running the driver we will only move the magic a bit lower. If i have understood correctly what secdrv.sys does, it simply checks if there is a debugger running. So, in some point it will have to ask to the core (wine): secdrv.sys = is there a debugger running there? wine = Here?? Noo!!!, how can you think so? ;) I think that we should ask to a lawyer, because we could be sitting a bad precedent, about what can be implemented, and what can't :/ Regards, Carlos. -- ___ _ \ | / Consulting | . |._ _ _| | ___ ___ ___http://www.andago.com | || ' |/ . |_ |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano ___'/ | \ -_) __/\__ \ -_) [ [EMAIL PROTECTED] ]\___|_| / _/\_\___| [ [EMAIL PROTECTED] ] http://www.ePSXe.com
Re: copy protection - was: Re: Is it time for playing games on WINE?
On Wednesday 05 November 2003 6:00 am, you wrote: None whatsoever, the driver reimplementation is clearly a DMCA violation. The proper way to do that is to somehow load the driver and let it perform all the checks it wants to perform; a dummy driver that returns magic values to bypass the checks is not acceptable. Basicly as long as our code: A.cant run copied safedisk disks (perfect copies and no-cd cracks aside) and B.cant be modified to run copied safedisk disks (e.g. by disabling some parts of the WINE code that performed checks) then I think that we would probobly not be violating the DMCA (although IANAL) I agree. It would appear that secdrv.sys is not an essential part to the decrypting process. If it were then there would be loads of secdrv-hacked.sys type files floating around the internet. In actual fact, most people seem to be able to decrypt the contents without touching this file. Rob
Re: copy protection - was: Re: Is it time for playing games on WINE?
On November 5, 2003 01:00 am, Jonathan Wilson wrote: Basicly as long as our code: A.cant run copied safedisk disks (perfect copies and no-cd cracks aside) and B.cant be modified to run copied safedisk disks (e.g. by disabling some parts of the WINE code that performed checks) then I think that we would probobly not be violating the DMCA (although IANAL) This is slippery ground. Given that Wine is open source (and moreover, very clearly laid-out, non-obfuscated, *structured* code), you can't possibly satisfy (A) and (B) in such a way that they aren't easy to bypass (ie. such that I can't simply comment out a couple of lines of code and type make). As we've seen with encryption regulations in the past, the issue of control-circumvention law dissolves in the face of open-source software. Moreover, in the face of (L)GPL open-source software, it dissolves by *design* - you can not withhold source-code if you want to release binaries. IIRC, this was one of the major stumbling blocks for Transgaming and the Wine/LGPL debate - they have copyprotection support that they legally can not dream of releasing source for. Some argue that binaries are a form of source code anyway, and that you can read them in the sense that you can interpret and modify their operation. However, the lawyers seem reasonably comfortable with that argument - they call it reverse engineering and it's bad(tm). It is my personal opinion that this legal anomaly with copyleft is no accident - Microsoft (and the RIAA) lobby harder than most, and laws that are impossible to abide by in open source are good laws for lawyers and their preferred clients, and bad for disreputable communists (as we most surely must be if we don't feel like trading binaries commercially). But I digress. What you've said about putting safedisk support into Wine is analogous to saying (a few years ago) that you could add an open-source encrypted filesystem to the O/S by only allowing the use of 40-bit cipher keys to satisfy export regulations. The fact that any dolt with gcc and a text-editor can type s/40/128/g makes that an insufficient defense, unfortunately. Somewhere in the callstack between the application and the kernel's CD driver needs to be something that is closed-source and not 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. FWIW: as far as I can tell, the majority of americans would not support this sort of legal framework if it was explained to them (especially if they were shown a DVD using some of the xine skins), and apparently the US is a democracy with enormous pride in free speech and other convenient catch-phrases, but these flavours of legally bullying continue to pick up steam and the US is starting to repress itself on a scale they have so often criticised in other nations. sigh But I'm digressing, again. Sorry. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/
Re: copy protection - was: Re: Is it time for playing games on WINE?
Zsolt Rizsanyi wrote: So this is what I think that the status of copy protection is. If I'm wrong somewhere then please correct me. Hi, Yea I think your correct.. here is his post... http://www.winehq.com/hypermail/wine-patches/2002/04/0194.html And our last exchange: Zsolt http://www.winehq.com/hypermail/wine-devel/2002/12/0462.html And Patrik Stridvall's reply http://www.winehq.com/hypermail/wine-devel/2002/12/0461.html To quote Patrick Correct, it didn't support SafeDisc 2. However I think that at least part of it was accepted. Anyway the reason that some part was not not accepted was not DMCA related. Okay If its not the DCMA then why has this code not been accepted?? In Laurent Pincharts words safedisc-dmca.diff contains the code which *might* infringe the DMCA. In my opinion it doesn't, but I'm not a lawyer. So.. Alexandre, is there any chance of this code *ever* being excepted into the wine tree? If not what would need to be done for exceptence to take place? If this code has a snowballs chance in hell of ever being excepted into the tree then please let me and the others here know Or better yet.. if Jer, has a lawyer who is setting around looking at his secretaries back end.. He could ask him what his thoughts on this would be, and this whole discussion could come to a... well lets only hope a happy end.. Please reply.. As I hate spam but i'm not over spamming to get a reply ;) Tom Regards Zsolt
Re: copy protection - was: Re: Is it time for playing games on WINE?
but this brings fort the legal issues. If the re-implemented driver only allows the user to play the game, and not to make a perfect copy of the CD, there is no legal issue.
Re: copy protection - was: Re: Is it time for playing games on WINE?
On Tue, 2003-11-04 at 15:13, Ivan Leo Murray-Smith wrote: but this brings fort the legal issues. If the re-implemented driver only allows the user to play the game, and not to make a perfect copy of the CD, there is no legal issue. I don't think there's any legal issue anyway. There are no laws against cracking copy protection unless you're in the states and it's got encryption. Now, pirating stuff *after* you broke the protection is illegal of course, but we have nothing to do with that, and besides, in practice I doubt it'd help anybody who did want to pirate stuff.
Re: copy protection - was: Re: Is it time for playing games on WINE?
El mar, 04 de nov de 2003, a las 16:13, Ivan Leo Murray-Smith escribio: but this brings fort the legal issues. If the re-implemented driver only allows the user to play the game, and not to make a perfect copy of the CD, there is no legal issue. I think that the actual status is even worse, because now only the people with a modified exe can to use wine to run it (what includes to the pirates, but not to the people who owns the original :( Regards, Carlos. -- ___ _ \ | / Consulting | . |._ _ _| | ___ ___ ___http://www.andago.com | || ' |/ . |_ |/ . |/ . \__ GNU/Linux |_|_||_|_|\___|___|\_. |\___/ _ \ __|\ \ / Carlos A. Lozano ___'/ | \ -_) __/\__ \ -_) [ [EMAIL PROTECTED] ]\___|_| / _/\_\___| [ [EMAIL PROTECTED] ] http://www.ePSXe.com
Re: copy protection - was: Re: Is it time for playing games on WINE?
It might be possible to reverse engineer the current safedisc 1 and 2 protections and include the code in wine. The problem is that the new version (a snapshot of it was used at the time in flashpoint) is less nice. Nowadays when you for example use a crack the game works or doesn't work. The new safedisc is really nasty. When you apply a crack (or perhaps our upcoming safedisc driver) the game starts up no matter if the crack is really correct or not. During the game you will know if the crack was correct or not. When you play using an incorrect crack the game will slowly become unplayable. For example the keys to finish the level will disappear or you can't aim anymore.. Perhaps the solution is to write a wrapper to load secdrv.sys and friends. Perhaps in a way like that ntfs emulation project works (it uses a reactos kernel) or perhaps using an emulator like qemu. -- NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++
Re: copy protection - was: Re: Is it time for playing games on WINE?
Tom [EMAIL PROTECTED] writes: Alexandre, is there any chance of this code *ever* being excepted into the wine tree? None whatsoever, the driver reimplementation is clearly a DMCA violation. The proper way to do that is to somehow load the driver and let it perform all the checks it wants to perform; a dummy driver that returns magic values to bypass the checks is not acceptable. -- Alexandre Julliard [EMAIL PROTECTED]
Re: copy protection - was: Re: Is it time for playing games on WINE?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le Tuesday 04 November 2003 23:07, Alexandre Julliard a écrit : Tom [EMAIL PROTECTED] writes: Alexandre, is there any chance of this code *ever* being excepted into the wine tree? None whatsoever, the driver reimplementation is clearly a DMCA violation. The proper way to do that is to somehow load the driver and let it perform all the checks it wants to perform; a dummy driver that returns magic values to bypass the checks is not acceptable. Why about trying to get this driver working on top of current ntdll ? All drivers accesses should pass by kernel calls no ? Regards, Raphael -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/qDtXp7NA3AmQTU4RAoGCAJ45FqUXiU1FaJeeu/C0hBQr0ezoMwCeM/4K Y79dFQZ0pETZun5dAsbA8ow= =YU1H -END PGP SIGNATURE-
Re: copy protection - was: Re: Is it time for playing games on WINE?
--- Roderick Colenbrander [EMAIL PROTECTED] wrote: Perhaps the solution is to write a wrapper to load secdrv.sys and friends. Perhaps in a way like that ntfs emulation project works (it uses a reactos kernel) or perhaps using an emulator like qemu. Yes it should be possibe to adapt the work of Jan Kratochvil's Captive NTFS project to let you load the safedisk driver under Linux rather than the Windows NTFS driver. I have not tested loading the safedisk driver under ReactOS but I dont see why it wouldn't work. http://www.jankratochvil.net/project/captive/ 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?
When you play using an incorrect crack the game will slowly become unplayable. Like this we can be sure that the reimplemented driver is perfect or a bit buggy. Also, some people may prefer the idea of a open source safe disc driver more that the idea of loading the proprietary one.
Re: copy protection - was: Re: Is it time for playing games on WINE?
On Wed, 5 Nov 2003 02:29, Mike Hearn wrote: I don't think there's any legal issue anyway. There are no laws against cracking copy protection unless you're in the states and it's got encryption. You want to be careful here. There's also laws in Australia against bypassing a technological protection measure. Actually, the laws are against manufacturing a circumvention device (as well as some other commercial conduct in relation to such devices). If Wine included software that checked and used the copyright protection information on the CD, there would be no problem, but if it were to fake it without checking the CD, there would be problems with some activities in Australia. On the other hand, *using* a circumvention device is legal. See: Sony v Stevens [2003] FCAFC 157 http://www.austlii.edu.au/au/cases/cth/FCAFC/2003/157.html And the Copyright Act 1968 (Cth) ss10, 116A http://scaleplus.law.gov.au/html/pasteact/0/244/top.htm As for cracking the copy protection by modifying the code, that is creating a derivative work, which is also potentially infringing, but this will depend on some fairly fiddly details of laws that will vary a lot from one country to another.
