Exception Handling: More Compatible With NT To Satisfy Shrinker

Robert Shearman rob at codeweavers.com
Mon Oct 31 14:05:34 CST 2005


Shrinker does a number of things that depend on the layout of 
instructions in the exception handler:
1. It delibrately causes an exception to transfer execution to its 
exception handler.
2. It retrieves the return address from the stack.
3. It calls ReadProcessMemory to read the 8 bytes around the call to the 
handler (starting at movl 24(%ebp), %ecx and ending on the first byte of 
movl %fs:(0),%esp.
4. It looks at the "call *%ecx" instruction and if isn't exactly this, 
then it fails with "Dispatcher Initialisation Error 03".
5. It looks at the prefix to the "movl 24(%ebp),%ecx" and if it isn't a 
move instruction it fails as above.
6. It looks at the prefix to the "movl %fs:(0),%esp" instruction and if 
it isn't prefixed with %fs then it fails as above.
7. It replaces the instructions in (4) and (5) with a jump to its code 
using a WriteProcessMemory call.
8. It uses GetProcAddress(hntdll, "LdrAccessResource") and scans the 
first few bytes of the function for a call instruction. If it doesn't 
find one then it fails with "Dispatcher Initialisation Error 13".
9. It replaces the instruction in (8) again with a call to its code 
using WriteProcessMemory.
10. It then runs successfully.

This patch attempts to get Shrinker working up to (7). A further patch 
will make LdrAccessResource compatible with what it needs and hopefully 
get all Shrinker'd apps running (it got the one I was working on running).

Make the call exception handler function more compatible with NT and 
with what Shrinker expects.

Rob Shearman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: shrinker1.diff
Type: text/x-patch
Size: 3313 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-patches/attachments/20051031/8e1abefb/shrinker1.diff

More information about the wine-patches mailing list