Re: copy protection - was: Re: Is it time for playing games on WINE?
[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? If we can work out how to load the driver in question (which remember is safedisk specific, there's others) then are we ok to put dodgy hacks in wine to ensure the driver gets the results it is expecting? Possibly a follow on question then is how are we supposed to work out what the driver is expecting, ie is debugging it a way to go? Sorry, not being obstructive - I want to stick the the techically achievable goals. Jason
"Ann and Jason Edmeades" <us(a)the-edmeades.demon.co.uk> writes:
[Ever had the feeling you regret asking a question...]
Possibly another question for Alexander then - Realistically do you believe that we can ever support copy protection, and if so how?
I definitely think we can support it yes. It's just a matter of being compatible enough; that code is a Windows app, it works under Windows, so there's no theoretical reason it cannot be made to work. All it takes is someone motivated enough to implement it properly.
If we can work out how to load the driver in question (which remember is safedisk specific, there's others) then are we ok to put dodgy hacks in wine to ensure the driver gets the results it is expecting?
Dodgy hacks are not OK here any more than anywhere else, but adding a proper implementation of the required features is fine.
Possibly a follow on question then is how are we supposed to work out what the driver is expecting, ie is debugging it a way to go?
The usual technique: run the app, see what breaks, implement the missing feature/fix the bug, retry. The first thing of course is to investigate how to support loading the needed driver. -- Alexandre Julliard julliard(a)winehq.com
On Thu, 2003-11-06 at 23:54, Alexandre Julliard wrote:
The usual technique: run the app, see what breaks, implement the missing feature/fix the bug, retry. The first thing of course is to investigate how to support loading the needed driver.
Lionel, could QEMU be used here? I guess the driver expects to have kernel level access to the machine, so we could either: * Use enough magic and voodoo to make the driver think it's in kernel mode when actually it's in userland. Maybe the instruction emulation tricks we currently use for broken Win9x apps would work here? * Write a "wine for drivers". There is prior art in this area, it could be done, but might be an awful lot of work. * Maybe use QEMU to allow the driver to be run in a VM. Even if we can't invoke code directly here, RPC shims would work, I doubt a copy protection driver has high throughput requirements. Alexandre - do these options sound sane? thanks -mike
Mike Hearn <mike(a)theoretic.com> writes:
Alexandre - do these options sound sane?
I would suggest investigating the problems before we start designing the solutions... -- Alexandre Julliard julliard(a)winehq.com
On Fri, Nov 07, 2003 at 10:32:02AM +0000, Mike Hearn wrote:
Lionel, could QEMU be used here? I guess the driver expects to have kernel level access to the machine, so we could either:
Well, as I have no idea how .SYS loading working and how it interfaces with the kernel, I cannot comment here. Note that a low level kernel presentation by ReactOS people would be a nice thing to have at Wineconf :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Hiya Lionel, --- Lionel Ulmer <lionel.ulmer(a)free.fr> wrote:
On Fri, Nov 07, 2003 at 10:32:02AM +0000, Mike Hearn wrote:
Lionel, could QEMU be used here? I guess the driver expects to have kernel level access to the machine, so we could either:
Well, as I have no idea how .SYS loading working and how it interfaces with the kernel, I cannot comment here.
Note that a low level kernel presentation by ReactOS people would be a nice thing to have at Wineconf :-)
We will see what we can put together for wineconf =) I have been following this thread for a while so I have to speak up about the DMCA issues you guys have been discussing. It is in the ReactOS Projects interest to have a working safedisk driver also so we might be able to work together on something. There has been work at loading Windows filesystem drivers using ReactOS in the past so I dont see safedisk being that big of a deal. http://www.jankratochvil.net/project/captive/ Copying the safedisk driver from Windows and loading it in ReactOS should just work as we have the same design microsoft does. Adapting that to work on Linux+ReactOS you would need to talk to Jan. Still the better method is for us to write our own safedisk driver from scratch but I am not sure that this wont violate the DMCA. IMHO the WINE project should adopt the defence the xbox-linux and the ReactOS projects have: "Everything done on this project is for the sole purpose of writing interoperable software under Sect. 1201 (f) Reverse Engineering exception of the DMCA." We will still have the legal battle to fight one day but I think you will win if you reimplement safedisk and use this as your argument. One day WINE, ReactOS and other project are going to get taken to court over the DMCA. This is a given. The question is do you want it to be over this? Is gamming support in WINE and ReactOS important enough to you? Thanks Steven __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Friday 07 November 2003 19:46, Lionel Ulmer a écrit :
On Fri, Nov 07, 2003 at 10:32:02AM +0000, Mike Hearn wrote:
Lionel, could QEMU be used here? I guess the driver expects to have kernel level access to the machine, so we could either:
Well, as I have no idea how .SYS loading working and how it interfaces with the kernel, I cannot comment here.
Note that a low level kernel presentation by ReactOS people would be a nice thing to have at Wineconf :-)
Lionel
it is simple, only a PE module who work on kernel mode using os APIs: - -=(FeniX as fenix(a)DarkBluE)-(on tty2)-(at 13:39:31)=- -={$:'~'}=->winedump dump -j import /mnt/win_c2/windows/system32/drivers/ secdrv.sys Contents of "/mnt/win_c2/windows/system32/drivers/secdrv.sys": 27440 bytes Import Table size: 40 offset 25404 ntoskrnl.exe Hint/Name Table: 00006364 TimeDataStamp: 00000000 (Thu Jan 1 01:00:00 1970) ForwarderChain: 00000000 First thunk RVA: 00000260 (delta: 4294967295 0xffffffff) Ordn Name 252 IoDeleteSymbolicLink 644a 251 IoDeleteDevice 63b4 247 IoCreateSymbolicLink 63c6 243 IoCreateDevice 63de 720 RtlInitUnicodeString 63f0 687 RtlEqualUnicodeString 6408 519 NtBuildNumber 6420 760 RtlQueryRegistryValues 6430 599 PsGetVersion 63a4 434 KeTickCount 6462 479 MmIsAddressValid 6470 792 RtlUnwind 6492 54 ExAllocatePoolWithTag 649e 66 ExFreePool 64b6 325 IofCompleteRequest 64c4 Done dumping /mnt/win_c2/windows/system32/drivers/secdrv.sys The problem is how emulate windows kernel internal behavior (ie assembly tips as NtCurrentTeb) Best Regards, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/rOnQp7NA3AmQTU4RAtQ5AJ99fd0sys8VnKiAoq6RktXUBW1m/gCfZh/j ryAQ5sOXI+ZpgNFFKQfkq3M= =yMii -----END PGP SIGNATURE-----
Hello, --- Rapha�l_Junqueira <fenix(a)club-internet.fr> wrote:
it is simple, only a PE module who work on kernel mode using os APIs:
- -=(FeniX as fenix(a)DarkBluE)-(on tty2)-(at 13:39:31)=- -={$:'~'}=->winedump dump -j import /mnt/win_c2/windows/system32/drivers/ secdrv.sys Contents of "/mnt/win_c2/windows/system32/drivers/secdrv.sys": 27440 bytes
Import Table size: 40 offset 25404 ntoskrnl.exe Hint/Name Table: 00006364 TimeDataStamp: 00000000 (Thu Jan 1 01:00:00 1970) ForwarderChain: 00000000 First thunk RVA: 00000260 (delta: 4294967295 0xffffffff) Ordn Name 252 IoDeleteSymbolicLink 644a 251 IoDeleteDevice 63b4 247 IoCreateSymbolicLink 63c6 243 IoCreateDevice 63de 720 RtlInitUnicodeString 63f0 687 RtlEqualUnicodeString 6408 519 NtBuildNumber 6420 760 RtlQueryRegistryValues 6430 599 PsGetVersion 63a4 434 KeTickCount 6462 479 MmIsAddressValid 6470 792 RtlUnwind 6492 54 ExAllocatePoolWithTag 649e 66 ExFreePool 64b6 325 IofCompleteRequest 64c4
Done dumping /mnt/win_c2/windows/system32/drivers/secdrv.sys
The problem is how emulate windows kernel internal behavior (ie assembly tips as NtCurrentTeb)
We have been looking in to loading this driver under ReactOS and all of the functions are implemented but it still returns STATUS_UNSUCESSFULL. I think that the imports of "PsGetVersion and NtBuildNumber" might have something to do with it. The driver works under my Windows NT 4 laptop but not ReactOS. We may just have to hard code the values to match NT 4 and it could work. If we can get it to load on ROS it will be up to you guys to figure out a way to adapt ROS+WINE to play nice together. =) Thanks Steven __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
At 18.17 09/11/2003, Steven Edwards wrote:
The problem is how emulate windows kernel internal behavior (ie assembly tips as NtCurrentTeb) We have been looking in to loading this driver under ReactOS and all of the functions are implemented but it still returns STATUS_UNSUCESSFULL. I think that the imports of "PsGetVersion and NtBuildNumber" might have something to do with it.
the driver reads the system's version, build number and service pack, and fails to load on an unknown platform, but it otherwise ignores the information. Furthermore, its runtime requirements are very limited - I estimate an evening of work at most to run it on Wine, since we already have: - a PE loader - support for SEH - a DDK
The driver works under my Windows NT 4 laptop but not ReactOS. We may just have to hard code the values to match NT 4 and it could work.
I believe this is the case
On Fri, Nov 07, 2003 at 07:46:58PM +0100, Lionel Ulmer wrote:
On Fri, Nov 07, 2003 at 10:32:02AM +0000, Mike Hearn wrote:
Lionel, could QEMU be used here? I guess the driver expects to have kernel level access to the machine, so we could either:
Well, as I have no idea how .SYS loading working and how it interfaces with the kernel, I cannot comment here.
The newer .SYS files are just PE libraries. They have smaller section alignments, but otherwise they look just like normal DLLs. They reference hal.dll, ntoskrnl.exe, etc. as imports. The main hook into them is the DRIVER_OBJECT struct. On initialisation you call the DLL entry procedure with DriverEntry(DRIVER_OBJECT*, UNICODE_STRING *name); if I read http://msdn.microsoft.com/library/en-us/kmarch/hh/kmarch/drvrrtns_6r76.asp correctly. The DRIVER_OBJECT struct then gets filled with the function pointers the driver supports. http://msdn.microsoft.com/library/en-us/kmarch/hh/kmarch/k112_6jaq.asp for a read. The patches I posted should allow loading of these driver dlls. However, the start function is still called PE User DLL style, which needs to be fixed. Ciao, Marcus
-----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 +0000, Mike Hearn wrote:
Lionel, could QEMU be used here? I guess the driver expects to have kernel level access to the machine, so we could either:
Well, as I have no idea how .SYS loading working and how it interfaces with the kernel, I cannot comment here.
The newer .SYS files are just PE libraries. They have smaller section alignments, but otherwise they look just like normal DLLs.
They reference hal.dll, ntoskrnl.exe, etc. as imports.
The main hook into them is the DRIVER_OBJECT struct. On initialisation you call the DLL entry procedure with DriverEntry(DRIVER_OBJECT*, UNICODE_STRING *name); if I read http://msdn.microsoft.com/library/en-us/kmarch/hh/kmarch/drvrrtns_6r76.asp correctly.
The DRIVER_OBJECT struct then gets filled with the function pointers the driver supports. http://msdn.microsoft.com/library/en-us/kmarch/hh/kmarch/k112_6jaq.asp for a read.
The patches I posted should allow loading of these driver dlls. However, the start function is still called PE User DLL style, which needs to be fixed.
Well it's not really easy as the NT_HEADER only declare: Characteristics: 0306 EXECUTABLE_IMAGE LINE_NUMS_STRIPPED 32BIT_MACHINE DEBUG_STRIPPED So we can only use the file extension (and maybe the imported libs, .sys files using kernel libs) to use the good "dll-entry" between .sys and .exe files :( I don't think Alexandre will love the hack to support this :)
Ciao, Marcus
Regards, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/r0asp7NA3AmQTU4RAqNaAKCcxIwFn+TJEFbFAJ8BwkW6eCEt8gCfeNOn PKTSTc/YTHkd9tCbtvmr9Zw= =QWb6 -----END PGP SIGNATURE-----
-----Original Message----- From: wine-devel-admin(a)winehq.org [mailto:wine-devel-admin(a)winehq.org]On Behalf Of Raphaël Junqueira Sent: 10 November 2003 08:05 To: Lionel Ulmer; Marcus Meissner Cc: Alexandre Julliard; Wine Devel Subject: Re: copy protection - was: Re: Is it time for playing games on WINE?
Well it's not really easy as the NT_HEADER only declare: Characteristics: 0306 EXECUTABLE_IMAGE LINE_NUMS_STRIPPED 32BIT_MACHINE DEBUG_STRIPPED
So we can only use the file extension (and maybe the imported libs, .sys files using kernel libs) to use the good "dll-entry" between .sys and .exe files :(
I don't think Alexandre will love the hack to support this :)
I think IMAGE_OPTIONAL_HEADER::Subsystem will be what we're looking for. BTW, I have got as far with loading secdrv.sys as crashing on unimplemented IoCreateDevice. I believe the Io* functions will be the biggest problems. Rob
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Lundi 10 Novembre 2003 16:18, Robert Shearman a écrit :
-----Original Message----- From: wine-devel-admin(a)winehq.org [mailto:wine-devel-admin(a)winehq.org]On Behalf Of Raphaël Junqueira Sent: 10 November 2003 08:05 To: Lionel Ulmer; Marcus Meissner Cc: Alexandre Julliard; Wine Devel Subject: Re: copy protection - was: Re: Is it time for playing games on WINE?
Well it's not really easy as the NT_HEADER only declare: Characteristics: 0306 EXECUTABLE_IMAGE LINE_NUMS_STRIPPED 32BIT_MACHINE DEBUG_STRIPPED
So we can only use the file extension (and maybe the imported libs, .sys files using kernel libs) to use the good "dll-entry" between .sys and .exe files :(
I don't think Alexandre will love the hack to support this :)
I think IMAGE_OPTIONAL_HEADER::Subsystem will be what we're looking for.
Good, i haven't seen it :)
BTW, I have got as far with loading secdrv.sys as crashing on unimplemented IoCreateDevice. I believe the Io* functions will be the biggest problems.
Well, i don't think implementing simple (stupid?) Io* functions will be diffcult. For me, the problem is what secdrv want to do with this functions (maybe a voodoo test for safely check if the subsystem have a correct behavior): - - RtlQueryRegistryValues - - KeTickCount - - MmIsAddressValid - - RtlUnwind
Rob
Regards, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/r+TTp7NA3AmQTU4RAqA2AJ0WB5ajJMW2zuRc/+HGb+8Lm+F9QgCfTQd/ MzO3tng4IwHnQYfVFqyMXHE= =IJlJ -----END PGP SIGNATURE-----
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/
Hello Jan! --- Jan Kratochvil <lace(a)jankratochvil.net> wrote:
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.
Hmm. We really shouldnt need to make much changes to WINE to use Captive I would think. Once Captive+SevDrv and WINE are running you should have full access to the CDROM drive.
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.
We are still having trouble loading SecDrv.sys on native ROS.
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'.
We have a new SEH implementation that is not merged yet. The implementation we have is patent friendly as it implement SEH totaly differntly by using macros kind of like WINE. Its looking good! Thanks Steven __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
At 02.11 11/11/2003, Steven Edwards wrote:
Further run fails for Captive as 'secdrv.sys' is somehow broken driver as it does not provide any way to mount a filesystem. :-?
secdrv isn't a filesystem, nor a volume driver. Filesystems and volume drivers, in Windows NT, are special, and secdrv is neither. It's a trivial driver that just processes CREATE, CLOSE and DEVICE_CONTROL requests - Captive is kind of overkill, as it's mostly an implementation of the cache manager. Secdrv could be easily integrated in the Wine driver architecture with minimal glue code (e.g. to convert the DeviceIoControl() parameters to an IRP + I/O stack location)
(A)Synchronous/(Non)Alertable IRPs (I/O Request Packet) can be tricky although it is generally solved by ReactOS/Captive and it is questionable how much it is perused by 'secdrv.sys' IRP handling code.
secdrv.sys is mostly a twisted maze of function calls and decoding routines. As a driver it's completely unremarkable: all it does is reading the DEVICE_CONTROL parameters from the current I/O stack location and completing the IRP with IoCompleteRequest. It's clearly a mere matter of a hundred lines of code to emulate the environment it needs
We are still having trouble loading SecDrv.sys on native ROS.
hardcode the major version to 4, the minor version to 0 and the build number to 1381, and it will run. Trust me on this one
- RtlUnwind This is a part of undocumented SEH (Structured Exception Handling) implemented by ReactOS while fixed by Captive and partially combined with native 'ntoskrnl.exe'.
RtlUnwind is documented (altough its use isn't recommended), and implemented by ReactOS
We have a new SEH implementation that is not merged yet. The implementation we have is patent friendly as it implement SEH totaly differntly by using macros kind of like WINE.
it's patent-unencumbered as it doesn't allocate exception registrations on the stack (actually, the code me and Filip keep bouncing on the lists does use the stack, but only because we need to try it on Windows. Using the heap or pools rather than the stack is a matter of redefining two macros)
Hi, On Tue, 11 Nov 2003 03:05:55 +0100, KJK::Hyperion wrote:
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.
This was just a joke, sorry for the confusion. ...
- RtlUnwind This is a part of undocumented SEH (Structured Exception Handling) implemented by ReactOS while fixed by Captive and partially combined with native 'ntoskrnl.exe'.
RtlUnwind is documented (altough its use isn't recommended), and implemented by ReactOS
Although ReactOS implements SEH it is compatible only with ReactOS code while is binary incompatible with SEH as being used by 'ntfs.sys'. Unfortunately Vizzini still did not merge the patches. Regards, Lace -- Jan Kratochvil; Captive: free r/w NTFS Filesystem; http://www.jankratochvil.net/
participants (10)
-
Alexandre Julliard -
Ann and Jason Edmeades -
Jan Kratochvil -
KJK::Hyperion -
Lionel Ulmer -
Marcus Meissner -
Mike Hearn -
Raphaël Junqueira -
Robert Shearman -
Steven Edwards