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@winehq.org Reporter: michael@fds-team.de CC: focht@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.