copy protection - was: Re: Is it time for playing games on WINE?

Jan Kratochvil lace at jankratochvil.net
Mon Nov 10 15:43:42 CST 2003


Hi,

On Mon, 10 Nov 2003 20:19:45 +0100, Raphaël Junqueira wrote:
...
> > BTW, I have got as far with loading secdrv.sys as crashing on unimplemented
> > IoCreateDevice. I believe the Io* functions will be the biggest problems.

It is no problem loading it and initializing it by Captive NTFS for GNU/Linux:
	http://www.jankratochvil.net/project/captive/

./captive-cmdline --load-module=/tmp/ntoskrnl.exe --filesystem=/tmp/secdrv.sys --debug-messages /dev/null

(some trivia extensions done before a moment are currently only in CVS:
	http://cvs.jankratochvil.net/viewcvs/*checkout*/captive/README?rev=HEAD
		section 'CVS Bleeding Edge'
)

'secdrv.sys' creates devices:
	"\Device\AscKmd" (symlinked to "\DosDevices\AscKmd")
	"\Device\Secdrv" (symlinked to "\DosDevices\Secdrv")

It returns STATUS_SUCCESS afterwards. The log can be seen at
	http://www.jankratochvil.net/priv/secdrv/secdrv-init-onlysecdrv.log

I used secdrv.sys
	http://www.jankratochvil.net/priv/secdrv/secdrv.sys
	md5: bb6fbebebbd14429021f2851a60d8546

downloaded by Google from
	http://www.kids-station.com/game/Patrician2/secdrv.sys

Further run fails for Captive as 'secdrv.sys' is somehow broken driver as it
does not provide any way to mount a filesystem. :-?

Currently the example above requires 'ntoskrnl.exe' of NT-5.1 (XP).
Tried Service Pack 1 Free Build and Service Pack 1 Checked Build.
It would not be needed for such simple driver as 'secdrv.sys' but Captive
currently requires it for its 'ntfs.sys' emulation, reasons below:
	http://www.jankratochvil.net/project/captive/doc/Details.html.pl#emulmeth_fs


The next step is to combine Captive with Wine to be able to run the W32
userland application with 'secdrv.sys'. Captive ported only the W32 kernel part
of ReactOS to the GNU/Linux environment, no W32 userland code is present there.


> Well, i don't think implementing simple (stupid?) Io* functions will be 
> diffcult. 

(A)Synchronous/(Non)Alertable IRPs (I/O Request Packet) can be tricky although
it is generally solved by ReactOS/Captive and it is questionable how much it is
perused by 'secdrv.sys' IRP handling code.


> For me, the problem is what secdrv want to do with this functions (maybe a 
> voodoo test for safely check if the subsystem have a correct behavior):
...
> - - RtlUnwind

This is a part of undocumented SEH (Structured Exception Handling) implemented
by ReactOS while fixed by Captive and partially combined with native
'ntoskrnl.exe'. I still have some suspections on the correctness of the current
implementation but it works fine for 'ntfs.sys'.



Regards,
Lace

-- 
Jan Kratochvil; Captive: free r/w NTFS Filesystem; http://www.jankratochvil.net/



More information about the wine-devel mailing list