<p dir="ltr">On Jan 31, 2013 8:15 AM, "Alessandro Pignotti" <<a href="mailto:alexpigna.dev@gmail.com">alexpigna.dev@gmail.com</a>> wrote:<br>
><br>
> Hi again,<br>
><br>
> I've quickly implemented the aforementioned idea of fixing the segment<br>
> in the segfault handler when needed. I'm attaching my proposed patch.<br>
><br>
> Alessandro<br>
><br>
> Il giorno mer, 30/01/2013 alle 16.44 +0100, Alessandro Pignotti ha<br>
> scritto:<br>
> > Hi everyone,<br>
> ><br>
> > I'm trying to get a specific game which employs a seemingly custom<br>
> > protection scheme to work. The DRM does various bad things as usual, but<br>
> > a very bad one is manipulating to GS segment selector and setting it to<br>
> > a NULL segment. The GS segment is used by libc though in various ways<br>
> > (stack protection and syscall support, and probably others).<br>
> ><br>
> > I managed to get the activation procedure to go further and further by<br>
> > enclosing each offending syscall using the following 2 macros.<br>
> ><br>
> > #define SAFE_GS_START \<br>
> >     do { \<br>
> >         wine_set_gs(ntdll_get_thread_data()->gs); \<br>
> >         do<br>
> ><br>
> > #define SAFE_GS_END \<br>
> >         while(0); \<br>
> >     } while(0)<br>
> ><br>
> > Still, this method is very cumbersome since system calls happens in many<br>
> > places even outside of ntdll. Fixing the GS is also needed to support<br>
> > sigsetjmp which is used by wine's exception handling.<br>
> ><br>
> > I'd like to ask for feedback about what would be a sane way of<br>
> > supporting this application. A possible solution would be to modify<br>
> > wine's segfault handler to check if the instruction has a GS prefix<br>
> > (0x65 IIRC) and try to execute the instruction again after fixing the<br>
> > GS.<br>
> ><br>
> > Please keep me in CC since I'm not subscribed to the ML.<br>
> ><br>
> > Regards,<br>
> > Alessandro Pignotti</p>
<p dir="ltr">Out of curiosity, what game is this? What protection does Protection ID show it uses?</p>