[Bug 40143] New: bleem! 1.4 wants to switch to ring 0 kernel mode using a call gate

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=40143

            Bug ID: 40143
           Summary: bleem! 1.4 wants to switch to ring 0 kernel mode using
                    a call gate
           Product: Wine
           Version: 1.9.3
          Hardware: x86
               URL: http://web.archive.org/web/20010607095803/http://www.b
                    leem.com/files/demo-v1_4.exe
                OS: Linux
            Status: NEW
          Keywords: download, obfuscation
          Severity: normal
          Priority: P2
         Component: -unknown
          Assignee: wine-bugs at winehq.org
          Reporter: michael at fds-team.de
                CC: focht at gmx.net
      Distribution: ---

After fixing bug 36013 the application is getting a bit crazy:

003F74E7   52               PUSH EDX
003F74E8   237E 50          AND EDI,DWORD PTR DS:[ESI+50]
003F74EB   E8 BB54237E      CALL krnl386.UnMapLS
003F74F0   83E0 FE          AND EAX,FFFFFFFE
003F74F3   50               PUSH EAX
003F74F4   E8 A052237E      CALL krnl386.MapLS 
003F74F9   A3 C0743F00      MOV DWORD PTR DS:[3F74C0],EAX
003F74FE   6A 01            PUSH 1
003F7500   6A 00            PUSH 0
003F7502   68 29002A00      PUSH 2A0029
003F7507   E8 184A247E      CALL krnl386.VxDCall // int31 - allocate LDT entry
003F750C   A3 C4743F00      MOV DWORD PTR DS:[3F74C4],EAX

UnMapLS leaks the address of the local descriptor table on Windows 9X. The LDT
seems to be directly mapped into the user process and the application now tries
to get a segment ptr for the LDT (not sure why though?). After getting a
pointer, it allocates a new LDT entry and saves the segment index in 0x3F74C4.
Now it is getting interesting:

003F7516   1E               PUSH DS
003F7517   8E1D C2743F00    MOV DS,WORD PTR DS:[3F74C2]
003F751D   C700 FFFF0000    MOV DWORD PTR DS:[EAX],0FFFF
003F7523   C740 04 009BCF00 MOV DWORD PTR DS:[EAX+4],0CF9B00
003F752A   1F               POP DS

The application changes the data segment to the segment containing the LDT
table and starts changing the just allocated LDT entry. If you decode the
written values you get the following LDT entry: (type = 11011, dpl = 00,
present = 1, limithigh = 1111, sys = 0, reserved_0 = 0, default_big = 1,
granularity = 1). This means it wants to map the whole 4GB range of memory as
ring 0 (dpl = 0) code segment. You might already get an idea what the
application is trying to do.

After this bleem gets a second LDT entry using the same trick a second time:

003F752A   1F               POP DS
003F752B   6A 01            PUSH 1
003F752D   6A 00            PUSH 0
003F752F   68 29002A00      PUSH 2A0029
003F7534   E8 EB49247E      CALL krnl386.7E63BF24
003F7539   A3 C8743F00      MOV DWORD PTR DS:[3F74C8],EAX
003F753E   25 F8FF0000      AND EAX,0FFF8
003F7543   8B15 C2743F00    MOV EDX,DWORD PTR DS:[3F74C2]
003F7549   B9 EC753F00      MOV ECX,3F75EC
003F754E   66:8BD1          MOV DX,CX

However this time it doesn't want to get a code segment:

003F7551   1E               PUSH DS
003F7552   8E1D C2743F00    MOV DS,WORD PTR DS:[3F74C2]
003F7558   8910             MOV DWORD PTR DS:[EAX],EDX
003F755A   66:B9 00EC       MOV CX,0EC00
003F755E   8948 04          MOV DWORD PTR DS:[EAX+4],ECX
003F7561   1F               POP DS

If you decode the written LDT entry, you will see that this is a call gate to
switch from ring 3 to ring 0. Afterwards the application uses the call gate to
switch to kernel mode and does funny stuff like:

003B194D   CD20 61000100    VxDCall _CopyPageTable
[...]
003B1AC3   CD20 28010100    VxDCall _PageCommitPhys

I am pretty sure that we don't want and can't support this in Wine. I therefore
close this as WONT FIX and just create this bug report so that no one else
tries to debug this a second time.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.