Log in

View Full Version : VxD Problem

seVin
April 19th, 2006, 23:56
Im having a problem with a vxd that reboots my system when I run olly. Any suggestions?
Kayaker
April 20th, 2006, 02:54
Cool, a modern day vxd. Are you sure it's the vxd that's detecting/rebooting and not the user app? If so you'll have to disassemble the vxd and see if there's any unusual activity. I can't think offhand of any Int tricks a la frogsice that might be used to detect an attached ring 3 debugger. There may other ways though, either using VMM calls or undocumented tricks. As for rebooting, there is for example a Reboot_Processor VMM call. Do you think this is a deliberate debugger detection issue, or just a quirk that crashes the system?

Kayaker
Maximus
April 20th, 2006, 05:00
As long as it is done at r3, place a breakpoint on some instruction of ExitWindowsEx, or in the Privilege lookup/set functions (looking for the Shutdown privilege). I cannot believe an app can kill windows in other way -it would be illegal, no matter if they detect a breach attempt.

Regards,
Maximus

edit---
Quote:
Cool, a modern day vxd.
seVin
April 20th, 2006, 19:50
Pretty sure that the vxd is rebooting through a keyboard control function. It is a debugger detection issue.
Kayaker
April 20th, 2006, 22:21
Disassembling the vxd in IDA still seems to be the way to go. If it's doing a keyboard reboot you may be able to recognize that as a classic IN OUT sequence, I forget the exact combination but I think we may have discussed that before here or you can google for the instructions. If found it may lead you straight back to the detection itself.

It's also possible the detection is done quietly in ring3 and a flag is set for the vxd to handle the consequences. I just checked my old Win98 kernel32.dll and IsDebuggerPresent existed even then. If not directly called the same check could be done surreptitiously if the programmer understood the relevant Win9x structures.

Taking a look at Crackproof Your Software by Pavol Cerven, which outlines many of the 'older' Win9x detection methods for Sice, TRW etc., there is also this one for example for a usermode debugger:

xor eax,eax
mov al, fs:[20h]
;reads a value. If the value is other than 0, a debugger is active

There is no further description given and I don't know what fs:[20] in Win9x user mode points to, but it's possible it's also valid in ring0, or again could be used 'secretly' in ring3 and that information passed to the vxd.

I don't know if the debug register DR7 detection trick is valid for a usermode debugger, but again it's something to keep an eye out for if used in the vxd.


If you're not familiar with vxd programming and don't have the original Win9x DDK, you can check the Virtual Machine Manager Services (VMM) Help file I uploaded here many moons ago. It will provide a summary of the vxd API calls you may encounter to help you pull out the real programming stuff from any possible detection tricks.

http://www.woodmann.com/forum/showthread.php?p=9026

Kayaker
Maximus
April 21st, 2006, 07:37
[20] contains the pointer to the Thread Context structure used by the debugger when you are debugging a thread. Set it as 0 and if the app is debugged it will...
The in/out sequence... mmh... it was about door 61h or 52h, dont remember well right now, however it were discussed around as a quirk method for resetting unsafely .

"DR7 detection trick" which trick? Do you mean checking if the hw breakpoints local/Global are active? The GD flag? It is impossible to set hw breaks in 9x for usermode debuggers, you can detect that way only sice, i think.

Regards,
Maximus
blabberer
April 21st, 2006, 09:52
fs:20 contains debugcontext flags in 9x

Code:


union                       // 1Ch (NT/Win95 differences)

{

    struct  // Win95 fields

    {

        WORD    TIBFlags;           // 1Ch

        WORD    Win16MutexCount;    // 1Eh

        DWORD   DebugContext;       // 20h

        DWORD   pCurrentPriority;   // 24h

        DWORD   pvQueue;            // 28h Message Queue selector

    } WIN95;



    struct  // WinNT fields

    {

        DWORD unknown1;             // 1Ch

        DWORD processID;            // 20h

        DWORD threadID;             // 24h

        DWORD unknown2;             // 28h

    } WINNT;

} TIB_UNION2;



PVOID*  pvTLSArray;         // 2Ch Thread Local Storage array


i recently saw this being used in the honeylux malware
it checks fs:[23] and looks if it was 0
if we are running in 9x it seems
byte ptr fs:[23] cant be 0
it is some where in the shared segment aka 0x80######
and as far as nt in concerned
the pids being multiples of four wouldnt ever become so high a value
so as to occupy that byte

looked like a calculated risk to me but was new to see that being used in there i looked around a lot to find why the heck some one is using byte ptr fs:[23] and at last landed on this matt pietreks artcle

http://www.microsoft.com/msj/archive/s2cea.htm#fig1

have fun