Re: Duplicate relocations in DLL
I think it's actually the second case you mentioned. I'm pasting an excerpt from 'objdump -x' of the dll. The issue happens with bgm.dll from the game Hotline Miami. Regards and sorry for the long paste below, Alessandro Pignotti --- bgm.dll: formato del file pei-i386 bgm.dll architettura: i386, flag 0x0103: HAS_RELOC, EXEC_P, D_PAGED indirizzo di partenza 0x6d741000 Characteristics 0x230e executable line numbers stripped symbols stripped 32 bit words debugging information removed DLL PE File Base Relocations (interpreted .reloc section contents) Virtual Address: 1000 Chunk size 268 (0x10c) Number of fixups 130 ... Virtual Address: 2000 Chunk size 296 (0x128) Number of fixups 144 ... Virtual Address: 3000 Chunk size 336 (0x150) Number of fixups 164 ... Virtual Address: 4000 Chunk size 296 (0x128) Number of fixups 144 ... Virtual Address: 5000 Chunk size 112 (0x70) Number of fixups 52 ... Virtual Address: 6000 Chunk size 12 (0xc) Number of fixups 2 ... Virtual Address: 7000 Chunk size 228 (0xe4) Number of fixups 110 ... Virtual Address: 8000 Chunk size 356 (0x164) Number of fixups 174 ... Virtual Address: 1000 Chunk size 268 (0x10c) Number of fixups 130 ... Virtual Address: 2000 Chunk size 296 (0x128) Number of fixups 144 ... Virtual Address: 3000 Chunk size 336 (0x150) Number of fixups 164 ... Virtual Address: 4000 Chunk size 296 (0x128) Number of fixups 144 ... Virtual Address: 5000 Chunk size 112 (0x70) Number of fixups 52 ... Virtual Address: 6000 Chunk size 12 (0xc) Number of fixups 2 ... Virtual Address: 7000 Chunk size 228 (0xe4) Number of fixups 110 ... Virtual Address: 8000 Chunk size 356 (0x164) Number of fixups 174 ... On 16 May 2013, at 16:34, Jonas Maebe wrote: On 15 May 2013, at 16:31, Alessandro Pignotti wrote: Packaged with a game, I found a peculiar DLL which has duplicate blocks in the relocation table. I mean that the same pages are relocated twice and this of course breaks the DLL. I'm not sure about what could be a right way to support such (broken) DLLs. A possibility would be to keep track of already relocated pages and skip them if needed. Suggestions are welcome. I've just asked a colleague of mine about this and according to him it's perfectly legal in Windows to have multiple relocation blocks for the same section, in which case Windows will also fixup everything twice. So simply ignoring such relocations is normally wrong. Which dll from which game is this? Addendum: he just realised that you may be talking about multiple base relocation arrays for a single page (arrays that contain the offsets of the instructions that need fixing up), which would indeed be strange. Still, it would be interesting to know which dll it is. Thanks, Jonas
Re: Duplicate relocations in DLL
Wine does not seem to even try to load DLLs at their preferred address. Still, I'm not sure this is actually bad and I think Win8 forces randomization of the layout anyway, Alessandro He believes that this was done on purpose to break Wine and other non- Windows environments. It's an interface to BASS/fmod, and these libraries supposedly have very strict licensing requirements that require you to pay per platform you want to support. By constructing the dll this way it will always (with the caveat mentioned above) run on Windows, but not under Wine (unless the preferred load address is available and Wine loads it there, but there are no guarantees for that; I don't even know whether Wine tries to do this). As to the best solution: not sure. Current Wine behaviour matches that of Windows, it's the unavailable preferred load address that triggers the problem. Jonas
Duplicate relocations in DLL
Hi everyone, Packaged with a game, I found a peculiar DLL which has duplicate blocks in the relocation table. I mean that the same pages are relocated twice and this of course breaks the DLL. I'm not sure about what could be a right way to support such (broken) DLLs. A possibility would be to keep track of already relocated pages and skip them if needed. Suggestions are welcome. Regards, Alessandro Pignotti
Re: [PATCH] Support a protection scheme which reset the GS selector - v2
On 2013-02-07 17:00, Alessandro Pignotti wrote: +opcode=(unsigned char*)context-Eip; +if (*opcode==0x65 /* GS segment instruction prefix */ +context-SegGs!=ntdll_get_thread_data()-gs) Segment-override prefix may be preceded by repeat or operand-size override prefixes. So instruction that refers to GS-segment doesn't always starts with 0x65. ...and by the lock prefix actually. I've sent a new version of the patch which accounts for the various prefixes Alessandro
Re: [PATCH] Support for game DRM which overwrite the GS segment selector
Il giorno sab, 02/02/2013 alle 12.10 +0100, Austin English ha scritto:
On Jan 31, 2013 8:15 AM, Alessandro Pignotti
alexpigna@gmail.com wrote:
Hi again,
I've quickly implemented the aforementioned idea of fixing the
segment
in the segfault handler when needed. I'm attaching my proposed
patch.
Alessandro
Il giorno mer, 30/01/2013 alle 16.44 +0100, Alessandro Pignotti ha
scritto:
Hi everyone,
I'm trying to get a specific game which employs a seemingly custom
protection scheme to work. The DRM does various bad things as
usual, but
a very bad one is manipulating to GS segment selector and setting
it to
a NULL segment. The GS segment is used by libc though in various
ways
(stack protection and syscall support, and probably others).
I managed to get the activation procedure to go further and
further by
enclosing each offending syscall using the following 2 macros.
#define SAFE_GS_START \
do { \
wine_set_gs(ntdll_get_thread_data()-gs); \
do
#define SAFE_GS_END \
while(0); \
} while(0)
Still, this method is very cumbersome since system calls happens
in many
places even outside of ntdll. Fixing the GS is also needed to
support
sigsetjmp which is used by wine's exception handling.
I'd like to ask for feedback about what would be a sane way of
supporting this application. A possible solution would be to
modify
wine's segfault handler to check if the instruction has a GS
prefix
(0x65 IIRC) and try to execute the instruction again after fixing
the
GS.
Please keep me in CC since I'm not subscribed to the ML.
Regards,
Alessandro Pignotti
Out of curiosity, what game is this? What protection does Protection
ID show it uses?
It's report as StarForce 32 Bit v5.70.040.000. The game is 'Of Orcs And
Men', the problem is also reported in wine forums
http://forum.winehq.org/viewtopic.php?f=2t=17609
Alessandro
Support for game DRM which overwrite the GS segment selector
Hi everyone,
I'm trying to get a specific game which employs a seemingly custom
protection scheme to work. The DRM does various bad things as usual, but
a very bad one is manipulating to GS segment selector and setting it to
a NULL segment. The GS segment is used by libc though in various ways
(stack protection and syscall support, and probably others).
I managed to get the activation procedure to go further and further by
enclosing each offending syscall using the following 2 macros.
#define SAFE_GS_START \
do { \
wine_set_gs(ntdll_get_thread_data()-gs); \
do
#define SAFE_GS_END \
while(0); \
} while(0)
Still, this method is very cumbersome since system calls happens in many
places even outside of ntdll. Fixing the GS is also needed to support
sigsetjmp which is used by wine's exception handling.
I'd like to ask for feedback about what would be a sane way of
supporting this application. A possible solution would be to modify
wine's segfault handler to check if the instruction has a GS prefix
(0x65 IIRC) and try to execute the instruction again after fixing the
GS.
Please keep me in CC since I'm not subscribed to the ML.
Regards,
Alessandro Pignotti
[PATCH] Support for game DRM which overwrite the GS segment selector
Hi again,
I've quickly implemented the aforementioned idea of fixing the segment
in the segfault handler when needed. I'm attaching my proposed patch.
Alessandro
Il giorno mer, 30/01/2013 alle 16.44 +0100, Alessandro Pignotti ha
scritto:
Hi everyone,
I'm trying to get a specific game which employs a seemingly custom
protection scheme to work. The DRM does various bad things as usual, but
a very bad one is manipulating to GS segment selector and setting it to
a NULL segment. The GS segment is used by libc though in various ways
(stack protection and syscall support, and probably others).
I managed to get the activation procedure to go further and further by
enclosing each offending syscall using the following 2 macros.
#define SAFE_GS_START \
do { \
wine_set_gs(ntdll_get_thread_data()-gs); \
do
#define SAFE_GS_END \
while(0); \
} while(0)
Still, this method is very cumbersome since system calls happens in many
places even outside of ntdll. Fixing the GS is also needed to support
sigsetjmp which is used by wine's exception handling.
I'd like to ask for feedback about what would be a sane way of
supporting this application. A possible solution would be to modify
wine's segfault handler to check if the instruction has a GS prefix
(0x65 IIRC) and try to execute the instruction again after fixing the
GS.
Please keep me in CC since I'm not subscribed to the ML.
Regards,
Alessandro Pignotti
From 35d5b875c7ca63845ddb68f1036f58d31ff4957e Mon Sep 17 00:00:00 2001
From: Alessandro Pignotti a.pigno...@sssup.it
Date: Wed, 30 Jan 2013 17:09:15 +0100
Subject: [PATCH] Restore the GS selector when crashing (if needed)
---
dlls/ntdll/signal_i386.c |8
1 file changed, 8 insertions(+)
diff --git a/dlls/ntdll/signal_i386.c b/dlls/ntdll/signal_i386.c
index 4a83a70..8e9e46b 100644
--- a/dlls/ntdll/signal_i386.c
+++ b/dlls/ntdll/signal_i386.c
@@ -1863,6 +1863,14 @@ static void segv_handler( int signal, siginfo_t *siginfo, void *sigcontext )
return;
}
+/* special handling for segment faults of the GS segment */
+unsigned char* opcode=(unsigned char*)EIP_sig(context);
+if (get_trap_code(context) == TRAP_x86_PROTFLT *opcode==0x65)
+{
+GS_sig(context)=ntdll_get_thread_data()-gs;
+return;
+}
+
rec = setup_exception_record( context, stack, fs, gs, raise_segv_exception );
if (rec-ExceptionCode == EXCEPTION_STACK_OVERFLOW) return;
--
1.7.10.4
Advice about a new project, and similarity to Wine's start
Hi everyone, first of all congratulations. The current maturity of Wine is really, really impressive. Thanks for your work. Let's introduce myself, I'm the author of the Lightspark project (http://lightspark.sf.net): a modern, open source, flash player implementation. The project is currently in a very good shape, featuring scripting support, a JIT compiler and OpenGL accelerated rendering. But, although the core VM is mostly complete, a huge part of the runtime library is still missing. I'm asking advice here because this is probably a condition similar to the one faced by early Wine developers. I'm currently pretty confused about the roadmap of my project. Although some interest gathered after the announcement of the 0.3.0 release and some bug reports appeared I've not yet managed to gather the needed community feedback. Moreover, beside supporting the most popular flash applications (e.g. YouTube, which is mostly supported), I've no idea about what to do later and how to prioritize features. So my question is: how did Wine choose the feature set to support first? Did people use the early releases of Wine, even if they were missing features? Is the AppDB software available for use on other projects? Any misc advice? Thanks a lot for your help. and sorry for the quite OT message, Alessandro Pignotti signature.asc Description: This is a digitally signed message part.
Wine and virus security
Hi everyone, I've seen recently a discussion about securing a host running wine denying write access out of wine home using SElinux. I think that this feature would be easily enough implemented by wine itself, maybe by letting the user set access permission on wine drives c: d: etc and enforcing then in CreateFile calls. Are there any other APIs that should be considered apart CreateFile? Greetings, Alessandro Pignotti -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 Encrypted mails are welcome pgp6p7fyAP0cw.pgp Description: PGP signature
Re: Game road to 1.0
Hi, I'm actually working on DirectPlay implmentation, i'm first fixing a bit of thing around dplayx, so that we can use native dpwsockx (the dplay service provider) with builtin dplayx. After that i'm going to reimplement dpwsockx from scratch using the info from Kai Blins work on the protocol. Regards, Alessandro Pignotti -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 Encrypted mails are welcome pgpQmQ3qF6ZEr.pgp Description: PGP signature
DIB engine and cairo
Hi everyone, i'm not a dib engine nor a cairo expert, so i don't know if this is totally crazy. Anyway, could it be possible to use cairo as a backend for our dib engine? cairo support drawing on image buffers, that should be device indipendent and rendered client side. Regards, Alessandro Pignotti -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 Encrypted mails are welcome pgp7KXD42jkD3.pgp Description: PGP signature
wined3d: The sims regression
Hi, I've noticed that commit 12252d058914a66f40e976484cc7d8aa52ffca47 on the git tree causes a regression in the sims, making characters flipped upside down. It's seems to me that the y axis is flipped. I hope this helps Bye Alessandro Pignotti -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 Encrypted mails are welcome pgp4EZv1Xbd40.pgp Description: PGP signature
Re: DirectPlay should initialize The session guid when creating a session
On Monday 29 January 2007 14:26, Kai Blin wrote: On Sunday 28 January 2007 20:38, Tomas Carnecky wrote: From Microsoft DirectX SDK Documentation it seems that directplay should initialize the instance guid on session creation, this trivial patch does that. Two questions: 1. Does windows do this, too? You can't rely on the MS SDK Documentation, always look what windows does and do it likewise. In many cases, a wine test should be written to verify the behavior. 2. Does it solve anything? A bug, a problem with an application? Right now, it doesn't, as Wine doesn't _have_ a working DirectPlay implementation. However, Alessandro contacted me some time ago and was interested in starting to implement it. As I'm still busy working on figuring out the wire protocol used for dplay, I didn't get around to look at the programming side of things much. Alex, what are you currently trying to do? I figure it would make sense to kill the needed dll overrides for dplay dlls one by one, dplayx.dll might be a good start to do so. I'll be happy to help you with writing a test case for your current patch. Cheers, Kai I'm now trying to get my dpwsock.dll to work with native dplayx to figure out how the service provider implementation is expected to receive session data. Thanks a lot Bye -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe Public GPG Key ID 0x650B3ED9 on subkeys.gpg.net Key Fingerprint 6243 AAD3 E3EC 52D8 DFAA 2A2F 9FCD 0457 650B 3ED9 Encrypted mail are welcome pgpanrEjIdHX4.pgp Description: PGP signature
Directplay Sevice Provider
Hi everyone, i'm taking a look at wine's directplay implementation. From the the wiki i've seen that there are efforts to understand the directplay protocol. But it seems to be be quite a difficult task. Would not be a better idea to implement a wine directplay service provider with our own protocol, not compatible with microsoft tcp/ip service provider, but portable and usable on both windows and linux? Bye Pignotti Alessandro -- Vi Veri Veniversum Vivus Vici -Dr. Faustus - Marlowe
