I know a lot of people really want newer versions of photoshop (CS, CS2) to work with wine, myself included, so I opened up a feature request on Adobe's Photoshop forum, first with the intent to lobby for a Linux version, but then had the idea that maybe it would be more realistic to get Photoshop to work in Linux via Wine, possibly via having some sort of collaboration between the two dev groups. A reply I got on their messageboard is actually from a dev, and I suggested to him that they work with the Wine devs on this, as it seems much more realistic and possible than a Linux port.
So I'm sending this to you guys as a heads up that this might be a good opportunity to get in contact with the Adobe people about getting some ideas on getting Photoshop working in Wine. Here's the link to the thread: http://www.adobeforums.com/cgi-bin/webx/.3bc1d4af/7
maybe someone could reply and say Hi at least and say to Chris (that's the guy) that you'd be receptive to some input from Adobe on this. I can only see this as a win-win situation for everyone, Linux users for getting Photoshop working, and Adobe for the admiration of the Linux community and the possibility of new revenue that might be available to them via new sales of the software. Sorry to drop in from out of nowhere on this, but I thought the opportunity seemed to good to not say anything. So long and thanks for wine, it's awesome :)
Karsten
Hey Karsten,
Is there any other way to see the thread? It requires a login. ATM, I think its great that PhotoShop 7 runs near perfectly under Wine, but it would be fantastic if CS and CS2 versions ran just as smoothly.
Hiji
----- Original Message ---- From: Karsten Anderson karstenanderson@gmail.com To: wine-devel@winehq.org Sent: Saturday, September 30, 2006 11:51:43 PM Subject: Adobe Photoshop idea
I know a lot of people really want newer versions of photoshop (CS, CS2) to work with wine, myself included, so I opened up a feature request on Adobe's Photoshop forum, first with the intent to lobby for a Linux version, but then had the idea that maybe it would be more realistic to get Photoshop to work in Linux via Wine, possibly via having some sort of collaboration between the two dev groups. A reply I got on their messageboard is actually from a dev, and I suggested to him that they work with the Wine devs on this, as it seems much more realistic and possible than a Linux port.
So I'm sending this to you guys as a heads up that this might be a good opportunity to get in contact with the Adobe people about getting some ideas on getting Photoshop working in Wine. Here's the link to the thread: http://www.adobeforums.com/cgi-bin/webx/.3bc1d4af/7
maybe someone could reply and say Hi at least and say to Chris (that's the guy) that you'd be receptive to some input from Adobe on this. I can only see this as a win-win situation for everyone, Linux users for getting Photoshop working, and Adobe for the admiration of the Linux community and the possibility of new revenue that might be available to them via new sales of the software. Sorry to drop in from out of nowhere on this, but I thought the opportunity seemed to good to not say anything. So long and thanks for wine, it's awesome :)
Karsten
Sorry! Try this: http://www.adobeforums.com/cgi-bin/webx/.3bc1d4af
If that doesn't work, just go to:
http://www.adobe.com/support/forums/index.html Click Photoshop / Imageready Click Photoshop Windows Click Feature requests (the 2nd thread in the list) Click "Time for a Linux version?" (the thread)
register with the site and reply :) thanks..
On 10/1/06, Hiji hijinio@yahoo.com wrote:
Hey Karsten,
Is there any other way to see the thread? It requires a login. ATM, I think its great that PhotoShop 7 runs near perfectly under Wine, but it would be fantastic if CS and CS2 versions ran just as smoothly.
Hiji
----- Original Message ---- From: Karsten Anderson karstenanderson@gmail.com To: wine-devel@winehq.org Sent: Saturday, September 30, 2006 11:51:43 PM Subject: Adobe Photoshop idea
I know a lot of people really want newer versions of photoshop (CS, CS2) to work with wine, myself included, so I opened up a feature request on Adobe's Photoshop forum, first with the intent to lobby for a Linux version, but then had the idea that maybe it would be more realistic to get Photoshop to work in Linux via Wine, possibly via having some sort of collaboration between the two dev groups. A reply I got on their messageboard is actually from a dev, and I suggested to him that they work with the Wine devs on this, as it seems much more realistic and possible than a Linux port.
So I'm sending this to you guys as a heads up that this might be a good opportunity to get in contact with the Adobe people about getting some ideas on getting Photoshop working in Wine. Here's the link to the thread: http://www.adobeforums.com/cgi-bin/webx/.3bc1d4af/7
maybe someone could reply and say Hi at least and say to Chris (that's the guy) that you'd be receptive to some input from Adobe on this. I can only see this as a win-win situation for everyone, Linux users for getting Photoshop working, and Adobe for the admiration of the Linux community and the possibility of new revenue that might be available to them via new sales of the software. Sorry to drop in from out of nowhere on this, but I thought the opportunity seemed to good to not say anything. So long and thanks for wine, it's awesome :)
Karsten
Karsten Anderson wrote:
I know a lot of people really want newer versions of photoshop (CS, CS2) to work with wine, myself included, so I opened up a feature request on Adobe's Photoshop forum, first with the intent to lobby for
As an fyi, we care deeply about having CS and CS2 work, and have been unable to support them, entirely due to the form of copy protection used.
The same is true for the >= MX 2004 versions formerly of Macromedia.
Unfortunately, last time I checked, for all that Adobe is interested, they aren't willing to switch to a different copy protection format. Further, the copy protection vendors are *completely* terrified of working with Wine.
They're so terrified, they can't even be calmed enough to explain things. Of course, it doesn't help that we have to start by explaining that we can't sign an NDA because of our need to publish our work under the LGPL...
So the short story is that copy protection support is the gating issue here, and it's a serious PITA.
But Alexandre promises me he'll have it done Real Soon Now (TM).
Cheers,
Jeremy
Wow... looks like Chris, and other members of that forum are 'actively hostile' to the Linux community. The difference in tone between this thread and that, about the same topic, is incredible.
--tim
yeah.. it's surprising they'd turn down another revenue stream so vehemently
On 10/1/06, Tim Schmidt timschmidt@gmail.com wrote:
Wow... looks like Chris, and other members of that forum are 'actively hostile' to the Linux community. The difference in tone between this thread and that, about the same topic, is incredible.
--tim
On 10/1/06, Karsten Anderson karstenanderson@gmail.com wrote:
yeah.. it's surprising they'd turn down another revenue stream so vehemently
When M$ is done killing off McAfee, Symantec, Norton and all the other security firms.
http://www.washingtonpost.com/wp-dyn/content/article/2006/09/27/AR2006092701... http://ca.today.reuters.com/news/newsArticle.aspx?type=technologyNews&st...
Sony is up the creek as well? : http://www.electricsistahood.com/reviews/2006/09/do-math-will-sony-go-broke....
The Zune will give the iPod a migraine : http://www.itp.net/news/details.php?id=22195&category=
Sun Microsystems, Novel, Corel and countless others are soon to be known as ... Who ?
In the end M$ will become bored and need someone to kill off for sheer joy and adulation. And this is when they will jump on Adobe like white on rice, and when this happens "and mind you it will" they will be a much kinder gentler company and *vehemently* seek any revenue stream on our blue planet. :-)
Just my $0.02 on the future of Adobe and friends..............
Tom
----- Original Message ---- From: Tom Wickline twickline@gmail.com To: Karsten Anderson karstenanderson@gmail.com Cc: wine-devel@winehq.org Sent: Tuesday, October 3, 2006 4:46:22 AM Subject: Re: Adobe Photoshop idea
<snip>
Sun Microsystems, Novel, Corel and countless others are soon to be known as ... Who ?
Sun Microsystems can't be killed. Many of the world's infrastructure literally relies on them (though, it's not quite evident from the end user standpoint.) The only way they would go away is if they were bought out, and then, the Sun name was axed.
Hiji
On 10/3/06, Hiji hijinio@yahoo.com wrote:
Sun Microsystems can't be killed. Many of the world's infrastructure literally relies on them (though, it's not quite evident from the end user standpoint.) The only way they would go away is if they were bought out, and then, the Sun name was axed.
What's the old addage? No one's indispensible.
--tim
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?
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
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
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.
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
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
On 10/2/06, Marcus Meissner marcus@jet.franken.de 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
On Tuesday 03 October 2006 02:56, Tim Schmidt wrote:
On 10/2/06, Marcus Meissner marcus@jet.franken.de 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 ofcircumventing a technological measure that effectively controls access to a work protected under this title;
`(B) has only limited commercially significant purpose oruse 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 inconcert 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 ofsubsection (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 underparagraph (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
On 10/3/06, Robert Lunnon bobl@optushome.com.au 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
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
On 10/3/06, Robert Lunnon bobl@optushome.com.au 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.
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
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.
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.
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?
On 10/3/06, Michael [Plouj] Ploujnikov ploujj@gmail.com 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.
On 10/3/06, Martin Owens doctormo@gmail.com wrote:
On 10/3/06, Michael [Plouj] Ploujnikov ploujj@gmail.com 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.
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)). and 2) 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?
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.
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%27_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 :-(
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 stefandoesinger@gmx.at 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%27_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 :-(
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.
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
Maybe someone from FSF could provide legal guidance on this issue. http://www.fsf.org/about/contact.html
On Wed, Oct 04, 2006 at 07:10:41PM +0200, Kopfgeldjaeger wrote:
- 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?
On 10/5/06, Christoph Frick frick@sc-networks.de 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?
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.
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
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
On 10/5/06, Vassilis Virvilis vasvir@iit.demokritos.gr 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.
On 10/5/06, Mike McCormack mike@codeweavers.com 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
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?
On 10/5/06, Christoph Frick frick@sc-networks.de 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
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
On 10/5/06, Tim Schmidt timschmidt@gmail.com 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.
On 10/6/06, Vincent Povirk madewokherd+d41d@gmail.com wrote:
On 10/5/06, Tim Schmidt timschmidt@gmail.com 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
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
On 10/6/06, Kai Blin kai.blin@gmail.com 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
Tim Schmidt wrote:
On 10/6/06, Kai Blin kai.blin@gmail.com 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
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
On 10/4/06, Karsten Anderson karstenanderson@gmail.com 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...
Jesse Allen wrote:
Guys, Wine programs can write to the MBR already with correct permissions...
I hope nobody needs to explain why that's a very bad idea...
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 tonglebeak@gmail.com wrote:
Jesse Allen wrote:
Guys, Wine programs can write to the MBR already with correct permissions...
I hope nobody needs to explain why that's a very bad idea...
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.
On 04/10/06, Jesse Allen the3dfxdude@gmail.com wrote:
Guys, Wine programs can write to the MBR already with correct permissions...
I think that should read "with wrong permissions" :-)
On 10/4/06, H. Verbeet hverbeet@gmail.com wrote:
On 04/10/06, Jesse Allen the3dfxdude@gmail.com 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
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?
Quoting EA Durbin ead1234@hotmail.com:
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.
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
On 10/3/06, Michael [Plouj] Ploujnikov ploujj@gmail.com 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 virtual harddrive 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.
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.
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?
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
On 10/4/06, Jonathan Ernst jonathan@ernstfamily.ch 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.
Jonathan
Good point. I'll shut up now lol.
-
Aaron Slunt -
Chris Robinson -
Christoph Frick -
Darragh Bailey -
David Laight -
EA Durbin -
H. Verbeet -
Hiji -
James Courtier-Dutton -
Jeremy White -
Jesse Allen -
Jonathan Ernst -
Kai Blin -
Karsten Anderson -
Kopfgeldjaeger -
Marcus Meissner -
Martin Owens -
Michael [Plouj] Ploujnikov -
Mike McCormack -
Robert Lunnon -
Rolf Kalbermatter -
Stefan Dösinger -
Tim Schmidt -
Tom Spear -
Tom Wickline -
Vassilis Virvilis -
Vincent Povirk -
Vitaliy Margolen -
Willie Sippel -
Wojciech 'arab' Arabczyk