[Bug 40143] New: bleem! 1.4 wants to switch to ring 0 kernel mode using a call gate
wine-bugs at winehq.org
wine-bugs at winehq.org
Sat Feb 13 14:03:38 CST 2016
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.
More information about the wine-bugs
mailing list