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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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.
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
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
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 [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
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
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
Maybe someone from FSF could provide legal guidance on this issue.
http://www.fsf.org/about/contact.html
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
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...
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
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
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 :-)
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
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
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:
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
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
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
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
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
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,
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,
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
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
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
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
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,
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
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).
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
-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
-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
: 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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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.
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
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,
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
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
-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
--- 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
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.
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
84 matches
Mail list logo
