Re: SafeDisc v1.35.000 seems to not work 100% good, at least with Rayman 2.
On Fri, Jan 9, 2009 at 3:00 PM, Milan Kostić wrote: > Really, it works for first few levels, but in the middle of "The > Sanctuary of Stone and Fire" (and upper levels periodicaly) it start > to gives "head of Pirate":) (screenshot attached) and no more playing > is possibile. This is tried with old original CD and also with backup > CD. > > Tested with wine-1.1.12 (first version in which graphics and sound > are good), but actualy it needs only XP 'dinput.dll' native. And what > is funny it work in all "Windows" versions, but not in XP. > > So, if maybe someone interested in this, i can debug (just tell me > what can be usefull), give game saved states, etc. > > > > Report bugs at http://bugs.winehq.org, not wine-devel. -- -Austin
Re: Safedisc for 1.0+ ?
Darragh Bailey wrote: > There has been some movement in the past to split up the Safedisc bug > and deal with the individual versions separately. Would it be useful to > advance this? I'm certain that I have a number of games that listed as > apps affected by this bug that no longer have a problem. So I'm not sure > that it works well to maintain the same bug for all versions of > safedisc. I think that's a good idea
Re: Safedisc for 1.0+ ?
On Thu, Apr 24, 2008 at 09:57:39PM -0600, Vitaliy Margolen wrote: > TheBlunderbuss wrote: > > It has just occurred to me that safedisc copy protection (bug 219!) > > wasn't put on the Wine 1.0 task list. It's a pretty major bug and covers > > a wide range of programs, with a wide range of safedisc versions. > > Considering this, how should we plan for this implementation? > > > Some versions should work. Newer versions mos likely won't. But as usual in > these cases your mileage may vary. Since there are so many variables. > > Setting target for such bugs to 1.0 won't magically fix them. Nor will it > keep them from breaking. There has been some movement in the past to split up the Safedisc bug and deal with the individual versions separately. Would it be useful to advance this? I'm certain that I have a number of games that listed as apps affected by this bug that no longer have a problem. So I'm not sure that it works well to maintain the same bug for all versions of safedisc. -- Darragh "Nothing is foolproof to a sufficiently talented fool."
Re: Safedisc for 1.0+ ?
TheBlunderbuss wrote: > It has just occurred to me that safedisc copy protection (bug 219!) > wasn't put on the Wine 1.0 task list. It's a pretty major bug and covers > a wide range of programs, with a wide range of safedisc versions. > Considering this, how should we plan for this implementation? > Some versions should work. Newer versions mos likely won't. But as usual in these cases your mileage may vary. Since there are so many variables. Setting target for such bugs to 1.0 won't magically fix them. Nor will it keep them from breaking. Vitaliy.
Re: Safedisc support (was: Road to 1.0)
Stefan Dösinger wrote: > Am Sonntag 25 März 2007 17:33 schrieb Phil Costin: >> Also, just out of interest, would a working safedisc implementation >> provide the necessary underpinnings to support the hexalock copy >> protection system? (http://hexalock.co.il/) > I think the needed infrastructure is the same, but of course we will have > to do extra bugfixing for each copy protection scheme. > > That hexalock thing sounds pretty rootkitish. I suspect that the real > content of the cd is encrypted, with an unencrypted decryption program. > That decryption program installs a rootkit which catches and blocks copy > operations on the source files and hacks MS IE 6 to prevent copy and > paste. > > If they were not completely stupid I am afraid that thing will not work > unless we load the driver into the Linux kernel. If the same driver that > prevents copy operations does the decryption it will have to be hooked > into the Linux cdrom driver. Maybe with raw access the decryption can be > done to allow programs in wine to access the cd, but not Linux programs. > There is a wikipedia page about it, but it is only a copy of the website. > > Of course if they are stupid enough to store the protected content > unencrypted, then we only have to make the rootkit happy enough to give > the app its OK. > > Personally I cannot see how their copy protected CDRs can resist a simple > dd if=/dev/cdrom of=copy.iso You're right, the hexalock disc content is mostly encrypted. It's pretty nasty stuff really. -Phil
Re: Safedisc support (was: Road to 1.0)
Am Sonntag 25 März 2007 17:33 schrieb Phil Costin: > Also, just out of interest, would a working safedisc implementation provide > the necessary underpinnings to support the hexalock copy protection system? > (http://hexalock.co.il/) I think the needed infrastructure is the same, but of course we will have to do extra bugfixing for each copy protection scheme. That hexalock thing sounds pretty rootkitish. I suspect that the real content of the cd is encrypted, with an unencrypted decryption program. That decryption program installs a rootkit which catches and blocks copy operations on the source files and hacks MS IE 6 to prevent copy and paste. If they were not completely stupid I am afraid that thing will not work unless we load the driver into the Linux kernel. If the same driver that prevents copy operations does the decryption it will have to be hooked into the Linux cdrom driver. Maybe with raw access the decryption can be done to allow programs in wine to access the cd, but not Linux programs. There is a wikipedia page about it, but it is only a copy of the website. Of course if they are stupid enough to store the protected content unencrypted, then we only have to make the rootkit happy enough to give the app its OK. Personally I cannot see how their copy protected CDRs can resist a simple dd if=/dev/cdrom of=copy.iso pgpznJNmUYPKD.pgp Description: PGP signature
Re: Safedisc support (was: Road to 1.0)
On Sun, Mar 25, 2007 at 05:31:03PM +0300, Timo Jyrinki wrote: > Alexandre Julliard wrote: > >And if we delay it a bit more maybe we can slip in Safedisc > >support too... > > Regarding which, does anyone have more up-to-date code and/or > information regarding Safedisc support, than what is currently > on the brand new Wine wiki page: http://wiki.winehq.org/SafeDisc ? No. > Safedisc support seems to be a topic that is hacked upon by various > people every now and then, but it does not seem very coordinated. It'd > be great if the wiki page would help to report on who's working on what > etc., and maybe even provide usable patches for users to try. No, the people stopped hacking on it. Basically it needs: - virtual objects served by a windows kernel driver - access to these objects must work as to any other object It is likely that a large rewrite of the whole object handling in the Wine Server is necessary to accomplish a Alexandre accepted solution. Ciao, Marcus
Re: Safedisc support (was: Road to 1.0)
Also, just out of interest, would a working safedisc implementation provide the necessary underpinnings to support the hexalock copy protection system? (http://hexalock.co.il/) Timo Jyrinki wrote: > Alexandre Julliard wrote: >> And if we delay it a bit more maybe we can slip in Safedisc >> support too... > > Regarding which, does anyone have more up-to-date code and/or > information regarding Safedisc support, than what is currently > on the brand new Wine wiki page: http://wiki.winehq.org/SafeDisc ? > > Safedisc support seems to be a topic that is hacked upon by various > people every now and then, but it does not seem very coordinated. It'd > be great if the wiki page would help to report on who's working on what > etc., and maybe even provide usable patches for users to try. > > -Timo
Re: Safedisc support (was: Road to 1.0)
Alexandre Julliard wrote: And if we delay it a bit more maybe we can slip in Safedisc support too... Regarding which, does anyone have more up-to-date code and/or information regarding Safedisc support, than what is currently on the brand new Wine wiki page: http://wiki.winehq.org/SafeDisc ? Safedisc support seems to be a topic that is hacked upon by various people every now and then, but it does not seem very coordinated. It'd be great if the wiki page would help to report on who's working on what etc., and maybe even provide usable patches for users to try. -Timo
Re: safedisc
--- Saulius Krasuckas <[EMAIL PROTECTED]> wrote: > * On Mon, 21 Nov 2005, Vitaliy Margolen wrote: > > * Monday, November 21, 2005, 4:54:56 PM, Ivan Leo > Puoti wrote: > > > Raphael Junqueira asked on bugzilla what the > safedisc status is. > > > Currently it works fine, and I believe what we > have is more or less > > > ready for CVS. However Vitaly told me Alexandre > didn't like the object > > > manager Vitaly wrote, mostly he didn't like > permanent objects, that > > > drivers depend on. > > > > Following Alexandre's suggestions I've managed to > get OM working without > > support for permanent objects. There will be some > modification required > > for ntoskrnl for that to work. I'm just about > finished integrating new > > OM into ntoskrnl tree and almost ready to give it > a try. > > > > As far as OM goes it's mostly finished and passes > all but two of om > > tests. Also it don't see any side-affects from it > either. All the > > programs I've tested work in the same way as they > were before. All named > > object moved to directories and using > RootDirectory part of > > OBJECT_ATTRIBUTES for create/open. > > > > Attached is the final revision of the directory > object implementation. > > If it looks ok I'm ready to send some patches > > Any updates on this? What lefts to be done for > ntoskrnl to enter the > tree? :) > I've waited so long for this mythical ntoskrnl.exe that "doesn't change NtDeviceIoControl()" and "uses IPCs" to finally enter CVS. Can you please mail around a sample of the code so we have some idea of how on earth it works, I'm dying to know... Thank you Damjan __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com
Re: safedisc
* On Mon, 21 Nov 2005, Vitaliy Margolen wrote: > * Monday, November 21, 2005, 4:54:56 PM, Ivan Leo Puoti wrote: > > Raphael Junqueira asked on bugzilla what the safedisc status is. > > Currently it works fine, and I believe what we have is more or less > > ready for CVS. However Vitaly told me Alexandre didn't like the object > > manager Vitaly wrote, mostly he didn't like permanent objects, that > > drivers depend on. > > Following Alexandre's suggestions I've managed to get OM working without > support for permanent objects. There will be some modification required > for ntoskrnl for that to work. I'm just about finished integrating new > OM into ntoskrnl tree and almost ready to give it a try. > > As far as OM goes it's mostly finished and passes all but two of om > tests. Also it don't see any side-affects from it either. All the > programs I've tested work in the same way as they were before. All named > object moved to directories and using RootDirectory part of > OBJECT_ATTRIBUTES for create/open. > > Attached is the final revision of the directory object implementation. > If it looks ok I'm ready to send some patches Any updates on this? What lefts to be done for ntoskrnl to enter the tree? :)
Re: safedisc
Monday, November 21, 2005, 4:54:56 PM, Ivan Leo Puoti wrote:
> Raphael Junqueira asked on bugzilla what the safedisc status is. Currently it
> works fine, and I
> believe what we have is more or less ready for CVS. However Vitaly
> told me Alexandre didn't like the
> object manager Vitaly wrote, mostly he didn't like permanent
> objects, that drivers depend on. I
> haven't talked to Alexandre about this but hopefully some reasonable solution
> can be found so we can
> get Vitaly's OM into wineserver (I mean my original implementation that uses
> pointers as handles
> also works, but things look better with a real OM). So let's try and trigger
> some community
> discussion, we are talking about the guts of wine after all. Vitaly, what's
> the OM status currently?
> Alexandre, what didn't you like about it?
Following Alexandre's suggestions I've managed to get OM working without
support for permanent objects. There will be some modification required
for ntoskrnl for that to work. I'm just about finished integrating new OM
into ntoskrnl tree and almost ready to give it a try.
As far as OM goes it's mostly finished and passes all but two of om
tests. Also it don't see any side-affects from it either. All the
programs I've tested work in the same way as they were before. All named
object moved to directories and using RootDirectory part of
OBJECT_ATTRIBUTES for create/open.
Attached is the final revision of the directory object implementation. If
it looks ok I'm ready to send some patches
Vitaliy
/*
* Server-side directory object management
*
* Copyright (C) 2005 Vitaliy Margolen
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
*/
#include "config.h"
#include "wine/port.h"
#include
#include
#include
#include
#include "windef.h"
#include "winternl.h"
#include "handle.h"
#include "request.h"
#include "process.h"
#include "unicode.h"
#include "wine/list.h"
#include "object.h"
#define HASH_SIZE 37
#define DIRECTORY_QUERY (0x0001)
#define DIRECTORY_TRAVERSE (0x0002)
#define DIRECTORY_CREATE_OBJECT (0x0004)
#define DIRECTORY_CREATE_SUBDIRECTORY (0x0008)
#define DIRECTORY_ALL_ACCESS (STANDARD_RIGHTS_REQUIRED | 0xF)
struct directory
{
struct object obj; /* object header */
struct list entries[HASH_SIZE]; /* array of hash entry lists */
};
static void directory_dump( struct object *obj, int verbose );
static struct object *directory_lookup_name( struct object *obj, struct
unicode_str *name,
unsigned int attr );
static const struct object_ops directory_ops =
{
sizeof(struct directory), /* size */
directory_dump, /* dump */
no_add_queue, /* add_queue */
NULL, /* remove_queue */
NULL, /* signaled */
NULL, /* satisfied */
no_signal,/* signal */
no_get_fd,/* get_fd */
directory_lookup_name,/* lookup_name */
no_close_handle, /* close_handle */
no_destroy/* destroy */
};
static void directory_dump( struct object *obj, int verbose )
{
struct directory *dir = (struct directory *)obj;
assert( obj->ops == &directory_ops );
fputs( "Directory ", stderr );
dump_object_name( obj );
if (verbose)
{
unsigned int i;
fputs( " entries:\n", stderr );
for (i = 0; i < HASH_SIZE; i++)
{
struct list *p = &dir->entries[i];
struct object_name *ptr;
LIST_FOR_EACH_ENTRY(ptr, p, struct object_name, entry)
{
fputs( " ", stderr );
dump_object_name( ptr->obj );
fputc( '\n', stderr );
}
}
}
else
fputc( '\n', stderr );
}
/* find an object by its name in a given directory; the refcount is incremented
* name - is a relative name */
static struct object *find_object_in_dir( struct directory *dir, const WCHAR
*name,
size_t len, unsigned int attr )
{
const struct list *list, *p;
if (!name || !len) return NULL;
list = &dir->entries[ get_name_hash( name, len ) % HASH_SIZE ];
Re: Safedisc 1 works on wine
Ivan Leo Puoti wrote: Finally we've got safedisc1 running on linux. Thanks go to Laurent Pinchart, Vitaliy Margolen, Brad DeMorrow, Marcus Meissner, and Alexandre for contributing time/code/ideas. Additionally thanks for pointers and suggestions from the ReactOS team. Ivan.
Re: Safedisc 1 works on wine
Oh, and here's an actualy in game shot, if you're a fan of the game you'll probably notice I'm out of practice. http://www003.portalis.it/115/wine/safediscworks2.png Ivan.
Re: Safedisc 1 works on wine
Tom Wickline wrote: Will this support versions 1.6.0 through version 1.50.20 ? 1.6.0 was the first version of safedisk, version 1.11.0 introduced secdrv.sys and NT support. And do you know if it supports "dplayerx.dll" and the second layer of encryption that is applied on the ICD that is in 1.50.20? 1.50.20 is the version we used to implement support in wine, so yes it supports secdrv.sys and dplayerx.dll and the encryption applied to the ICD. Ivan.
Re: Safedisc 1 works on wine
On 9/8/05, Ivan Leo Puoti <[EMAIL PROTECTED]> wrote: > Finally we've got safedisc1 running on linux. > Thanks go to *Laurent* Pinchart, Vitaliy Margolen, *Brad DeMorrow, > Marcus Meissner, and Alexandre for contributing time/code/ideas. > The code is 100% DMCA compliant and hopefully can be cleaned up to be > good enough for cvs over the coming days and weeks. > Two games have been tested, they both use the same version of safedisc > (don't ask how we know, we do) > http://www.kievinfo.com/images/wine/HoM3_1.jpg > http://www.kievinfo.com/images/wine/safediscworks.jpg Will this support versions 1.6.0 through version 1.50.20 ? 1.6.0 was the first version of safedisk, version 1.11.0 introduced secdrv.sys and NT support. And do you know if it supports "dplayerx.dll" and the second layer of encryption that is applied on the ICD that is in 1.50.20? I suppose the only way to find out is to test allot of software that spans all the revisions, just thought I would be lazy and ask Tom > > Ivan. > * > > >
Re: safedisc stuff
Stephen Torri wrote: I synced with CVS and applied your patch. I get a problem compiling dlls/ntdll/file.c: The problem was an operator error in failing to copy a file to the right location. I do get a real error, honest I do. fixme:ntdll:NtCreateFile failing because of error c00f fixme:file:CreateFileW Unable to create file L".\\Secdrv" (status c00e) This happens trying to play SSI Rites of War. This is normal, actually expected, safedisc open it just in case it's already running. Anyway, run the game once, you should get a crash. Then run it again immediately and you should get a splash screen if all goes well. Turn the ntoskrnl debug channel on just in case. Ivan.
Re: safedisc stuff
Hi, On Thu, Jun 02, 2005 at 07:45:25PM -0400, Stephen Torri wrote: > > I synced with CVS and applied your patch. I get a problem compiling > > dlls/ntdll/file.c: > > The problem was an operator error in failing to copy a file to the right > location. I do get a real error, honest I do. > > fixme:ntdll:NtCreateFile failing because of error c00f > fixme:file:CreateFileW Unable to create file L".\\Secdrv" (status > c00e) > > This happens trying to play SSI Rites of War. ntstatus.h: #define STATUS_NO_SUCH_DEVICE0xC00E #define STATUS_NO_SUCH_FILE 0xC00F Andreas Mohr
Re: safedisc stuff
> I synced with CVS and applied your patch. I get a problem compiling > dlls/ntdll/file.c: The problem was an operator error in failing to copy a file to the right location. I do get a real error, honest I do. fixme:ntdll:NtCreateFile failing because of error c00f fixme:file:CreateFileW Unable to create file L".\\Secdrv" (status c00e) This happens trying to play SSI Rites of War. Stephen
Re: safedisc stuff
On Wed, 2005-06-01 at 21:32 +0200, Ivan Leo Puoti wrote: > Hi guys, > Mike Hearn asked me to send the work in progress stuff, so here it is > (some stuff has been removed for legal reasons, so you can't run it in > a debugger). Some of it sucks (See QueryServiceStatus for the worst hack > ever, that doesn't even usually work), but the design should be more or > less ok. It needs lots of cleanup and optimisation. > > Ivan. I synced with CVS and applied your patch. I get a problem compiling dlls/ntdll/file.c: make[2]: Entering directory `/home/storri/src/wine/dlls/ntdll' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o file.o file.c file.c:68:36: wine/ntoskrnl_protocol.h: No such file or directory file.c: In function `NtCreateFile': file.c:145: error: `NTOSKRNL_CALL' undeclared (first use in this function) file.c:145: error: (Each undeclared identifier is reported only once file.c:145: error: for each function it appears in.) file.c:145: error: syntax error before "call" file.c:224: error: `call' undeclared (first use in this function) file.c:224: error: `GETDEVICEHANDLE' undeclared (first use in this function) file.c: In function `NtDeviceIoControlFile': file.c:885: error: `NTOSKRNL_CALL' undeclared (first use in this function) file.c:885: error: syntax error before "call" file.c:891: error: `IOCONTROL_CALL' undeclared (first use in this function) file.c:891: error: syntax error before "IoCall" file.c:892: error: `IOCONTROL_RET' undeclared (first use in this function) file.c:918: error: `call' undeclared (first use in this function) file.c:918: error: `IOCONTROL' undeclared (first use in this function) file.c:921: error: `IoCall' undeclared (first use in this function) file.c:934: error: `IoRet' undeclared (first use in this function) make[2]: *** [file.o] Error 1 Stephen
