Spinning mirrors

Since last weekend my Dell Latitude E6410 refuses to hibernate. It worked perfectly before, so I’m not sure what’s going on. OS is Windows 7 Professional x64. It won’t hibernate when the lid is closed, power button pressed or even Hibernate option is selected from the Start menu. What happens is – the screen switches off as it should, but immediately brightens a bit and the machine enters sleep mode instead of hibernating. It can then be woken up by mouse movement etc. Hiberfil.sys file is being created. I’ve looked into advanced power options – hybrid sleep is off, actions for lid closing and power button is ‘hibernate’. Event log does not show anything interesting. Nothing changes when I change the power plan or log on as a different user.

Tried suspend and hibernate from Backtrack installation – all works fine. I’m not in the mood debugging this problem now, too much other things to do…

~ ~ ~
Posted by omeg in hardware, troubleshooting, windows desktop

So, I’ve finally gathered some inner strength and created a blog. It became inconvenient to not have my own site when I wanted to publish something interesting. Well, I have had my own site or two for quite some time, but my laziness prevented me from making use of that. I relied on OpenRCE after I abandoned my old hand-crafted abomination of a site. Now I have this blog and I intend to use it! 😉

What can you expect to see here then? Posts about general programming (mostly C# nowadays), windows internals, reverse engineering/software protections, rants, personal thoughts – the usual stuff.  I’ll try to repost my old articles here if they are worth preserving.

~ ~ ~
Posted by omeg in blog

I wrote a simple process memory dumper recently. Actually, it started as a in-memory string replacer, but I’m only posting the dumper part for now – the rest is in a terrible mess. 😉

The dumper saves all process memory to a single file. It uses NTFS sparse files though, so any non committed memory range does not use physical disk space (sparse zeros). It also checks process handle for access entries limiting VM operations and can print a nice memory map. Nothing fancy, but just what I needed for some work.

It’s officially 32-bit only (DWORDs for addresses etc), but seems to somewhat work with 64-bit processes. I’ll do a proper 64-bit version later (maybe ;)).

Sample output:

c:\code\MemoryDump\Release>MemoryDump.exe explorer.exe v
 Searching for target process...
 Failed to open process 0x0: 0x57
 Failed to open process 0x4: 0x5
 [...]
 Checking target process' ACL for problematic entries...
 Opened \Device\HarddiskVolume3\Windows\explorer.exe as PID 0xb30
 Target process suspended, 31 threads
 Proceeding with memory dump

 Address   Size     Type    State   Protect
    10000:    10000 MAPPED  COMMIT  READ&WRITE
    20000:     2000 MAPPED  COMMIT  READONLY
    22000:     e000 0       FREE    NOACCESS
    30000:     4000 MAPPED  COMMIT  READONLY
    34000:     c000 0       FREE    NOACCESS
    40000:     2000 MAPPED  COMMIT  READONLY
    42000:     e000 0       FREE    NOACCESS
    50000:     1000 PRIVATE COMMIT  READ&WRITE
    51000:     f000 0       FREE    NOACCESS
    60000:    10000 PRIVATE COMMIT  READ&WRITE
    70000:     7000 MAPPED  COMMIT  READONLY
    77000:     9000 0       FREE    NOACCESS
 [...]
 77610000:     3000 IMAGE   COMMIT  READONLY
 77613000:  79cd000 0       FREE    NOACCESS
 7efe0000:     5000 MAPPED  COMMIT  READONLY
 7efe5000:    fb000 MAPPED  RESERVE 0
 7f0e0000:   f00000 PRIVATE RESERVE 0
 7ffe0000:     1000 PRIVATE COMMIT  READONLY
 7ffe1000:     f000 PRIVATE RESERVE 0

 Process resumed. Memory dumped to 2864.mem

Get source & binary here

~ ~ ~
Posted by omeg in code, reverse engineering, utility

Kernel debugger is a nice and nifty tool allowing us to do things not otherwise possible. Total control over debugged OS and all processes is the main reason to use it. However, there are some hiccups and obstacles that may disrupt our work. One of the most common is the case of intercepting user-mode exceptions with kernel-mode debugger.

Let’s assume we have windbg connected to the debuggee OS as a kernel mode debugger. What can we do to catch user-mode exceptions that interest us? First, there is the ‘Debug | Event Filters’ menu (or sx* commands) that controls debugger’s behavior when it does encounter an exception in debugged code. In short, ‘Execution – Enabled’ option tells the debugger to break on the specific exception. There is a catch though – it only works for kernel mode code ‘out of the box’. That is, if we enable breaks on ‘Illegal instruction’ and run some user-mode program on the debugged OS that generates it, windbg won’t break. Why? Well, we’re in the kernel debug mode after all.

How to make it work then? It’s pretty simple. All NT-based Windows systems support ‘Global Flags’ debugging mechanism in the kernel, which is a collection of system-wide debugging flags. From within windbg we can access it using ‘!gflag’ extension command. And one of the flags is ‘Break on exceptions’ – which means kernel debugger will be notified not only of kernel-mode exceptions, but also user-mode ones. Neat. To activate it, use ‘!gflag +soe’ windbg command.

Now all is well, we can see that windbg breaks on every exception in user-mode code. Or does it? There is still one special case that evades our cleverly laid traps. If the user-mode program A is being debugged (using user-mode Debug API) by user-mode program B, we (windbg running as a kernel-mode debugger) won’t get exceptions coming from program A – program B will get them instead. It’s a bit counter-intuitive, as one would think that a kernel-mode debugger should receive every exception before user-mode debuggers. That isn’t the case though, and it seems to be the design decision by Microsoft. All is not lost though – we can still force windbg to receive every and all exceptions before they get to any user-mode debugger in the debugged OS.

To learn how to do that, we need to dive deep into the Windows’ kernel function responsible for kernel-mode exception dispatching – KiDispatchException. This is the ‘main’ code responsible for deciding what to do with an exception that was encountered. It services both kernel-mode and user-mode exceptions, first- and second-chance ones, and most importantly – decides whether to notify kernel debugger about the event or not. Not all events are forwarded to kd (kernel debugger), as we’ve learned before. But because we are in control of the target system, we can modify the KiDispatchException routine to do our bidding – or routing ALL exceptions to kernel debugger first.

The exact details of the patch vary between systems, but structure of KiDispatchException function is pretty much the same. Using IDA to reverse engineer the kernel, studying Windows Research Kernel or ReactOS sources certainly helps. Disassembly of original KiDispatchException function along with the patch point from two Windows systems is provided below – 32-bit Windows XP Pro and 64-bit Windows 7 with all updates as of 2010-07-14. Modifying other kernels is left as an exercise to the reader. 🙂

Windows 7 64-bit
Windows XP 32-bit

~ ~ ~
Posted by omeg in reverse engineering, windows internals

Microsoft’s Visual C++ supports less and less of inline assembly in later versions, or not at all on x64 platform. However, it provides a hefty number of intrinsics that are basically equivalents of single instructions.

http://msdn.microsoft.com/en-us/library/x8zs5twb.aspx

Handy reference if you like writing low-level but somewhat portable code.

There are also architecture-specific intrinsics:
x86
x64

~ ~ ~
Posted by omeg in assembly, code

Simple yet not widely known trick. If your PE image has TLS callbacks, these callbacks can alter TLS table while executing. That means you can have one callback at the start, but if this callback adds some other callbacks, those will execute as well. There are few interesting possibilities, because PE loader doesn’t cache TLS table at the beginning of image load. 🙂

Sample code

; Self-modifying TLS callbacks
 ; This PE has only one TLS callback active at load time. 
 ; However, the callback executes 0x10 times because it modifies TLS table before returning.
 ; Copyleft (c) Omega Red 2007
 ; fasm source

 ; 32-bit executable
 format PE GUI
 entry start

 include '%fasminc%\win32a.inc'
 include '%fasminc%\macro\proc32.inc'
 ;------------------------------------------------
 section 'all' code data readable writable executable

 start:
     cinvoke     printf, buf, fmt, [count]
     invoke      msgbox, 0, buf, t_main, 0
     invoke      exit, 0
 ;------------------------------------------------
 tls_callback0:
     inc         dword [count]
     cmp         dword [count], 0x10     ; callback executed 0x10 times?
     jge         tls_end
     
     ; add another callback entry before returning
     mov         eax, [count]
     mov         dword [tls_callbacks+4*eax], tls_callback0
     
 tls_end:
     ret         0x0c
 ;------------------------------------------------
 t_main          db  'main',0
 buf             db  0x100   dup (0)
 fmt             db  'tls count: %d',0
 count           dd  0
 ;------------------------------------------------
 ; TLS directory
 ; !!! it's possible to change tls table WHILE IN TLS CALLBACK itself,
 ; fex you have only 1 tls at first, but this tls adds some more -
 ; those added will execute normally (table is not cached by loader)!
 align   0x10
 data 9  ; tls
 dd 0                ;Raw Data Start VA
 dd 0                ;Raw Data End VA
 dd tls_index        ;Address of Index
 dd tls_callbacks    ;Address of Callbacks
 dd 0                ;Size of Zero Fill
 dd 0                ;Reserved

 tls_index       dd  0
 tls_callbacks:      ; only one callback is present initially
                 dd  tls_callback0   ; callback proc
                 dd  0xff dup (0)    ; space reserved for more callback entries (but null at load time)
                 dd  0
 end data
 ;------------------------------------------------
 data import

 library user,   'user32.dll',\
         kernel, 'kernel32.dll'

 import  user,\
         printf, 'wsprintfA',\
         msgbox, 'MessageBoxA'

 import  kernel,\
         exit, 'ExitProcess'
 end data

~ ~ ~
Posted by omeg in assembly, code, windows internals

I haven’t seen this before in public but it’s possible I’m not the first one who researched this subject. I implemented similar code about year ago in my “ever unfinished” crackme, but since I doubt I’ll finish the crackme, here it goes.

The idea revolves about non-continuable exceptions, that is exceptions with EXCEPTION_NONCONTINUABLE flag set in exception record. Normally, if your SEH procedure gets such an exception, you’re basically screwed: you can’t return ‘continue execution’ status, and your process is going to be mercilessly killed. If you try to continue, you will get STATUS_NONCONTINUABLE_EXCEPTION thrown by Windows exception dispatcher – there is no way out. Or is there? 😉

What if we patch or hook windows exception dispatcher (in our process only) and just clear the noncontinuable bit if it’s present before dispatching the exception down to SEH? It turns out that it works as expected – we can now escape and continue even after originally non-continuable exception. Furthermore, debuggers seem to not really like it. Olly simply refuses to continue even if we clear the noncontinuable flag (but olly can’t even properly handle hardware BPs set in the code so who cares ;). Windbg fares a bit better, but still falls in an infinite loop (maybe more experienced users could overcome that). IDA seems to not handle the “rethrow” of division by zero exception at the end properly (but I hardly use IDA’s debugger, so others may have more luck). Also, it doesn’t properly run on WINE I heard, but more tests would be nice. 🙂

Anyway, it’s quite fun code, maybe it will be useful to someone. Below is the FASM source, and here is the source+exe.

;------------------------------------------------
 ; Invalid Disposition exception trick
 ; or making noncontinuable exception continuable ;)
 ; Copyleft (c) Omega Red 2007, 2008
 ; fasm source
 ;------------------------------------------------
 ; 32-bit executable
 format PE GUI
 entry start

 include '%fasminc%\win32a.inc'
 include '%fasminc%\macro\proc32.inc'
 ;------------------------------------------------
 struct EXCEPTION_POINTERS
     ExceptionRecord     dd  ?   ; ptr
     ContextRecord       dd  ?   ; ptr
 ends

 struct EXCEPTION_RECORD
     ExceptionCode           dd  ?
     ExceptionFlags          dd  ?
     NestedExceptionRecord   dd  ?
     ExceptionAddress        dd  ?
     NumberParameters        dd  ?
     ExceptionInformation    dd  15    dup (?)
 ends

 SIZE_OF_80387_REGISTERS         =   80
 MAXIMUM_SUPPORTED_EXTENSION     =   512

 struct FLOATING_SAVE_AREA
     ControlWord         dd  ?
     StatusWord          dd  ?
     TagWord             dd  ?
     ErrorOffset         dd  ?
     ErrorSelector       dd  ?
     DataOffset          dd  ?
     DataSelector        dd  ?
     RegisterArea        db  SIZE_OF_80387_REGISTERS dup (?)
     Cr0NpxState         dd  ?
 ends

 struct CONTEXT
     ContextFlags    dd  ?
     Dr0             dd  ?
     Dr1             dd  ?
     Dr2             dd  ?
     Dr3             dd  ?
     Dr6             dd  ?
     Dr7             dd  ?
     FloatSave       FLOATING_SAVE_AREA
     SegGs           dd  ?
     SegFs           dd  ?
     SegEs           dd  ?
     SegDs           dd  ?
     Edi             dd  ?
     Esi             dd  ?
     Ebx             dd  ?
     Edx             dd  ?
     Ecx             dd  ?
     Eax             dd  ?
     Ebp             dd  ?
     Eip             dd  ?
     SegCs           dd  ?
     EFlags          dd  ?
     Esp             dd  ?
     SegSs           dd  ?
     ExtendedRegisters   db MAXIMUM_SUPPORTED_EXTENSION dup (?)
 ends
 ;------------------------------------------------
 section 'code' code readable executable

 start:
 ;    int3
 ; install UEF
     invoke      SetUnhandledExceptionFilter, UnhandledExceptionFilter
 ; install SEH
     push        dword seh_handler
     push        dword [fs:0]
     mov         dword [fs:0], esp

     invoke      GetModuleHandle, _ntdll
     invoke      GetProcAddress, eax, _rre
 ; cause #UD exception which will set up hardware BPX on RtlRaiseException
     ud2
     nop

 ; cause divide error -> invalid disposition exception (normally noncontinuable )
     xor eax,eax
     div eax

 _end:
 ; delete SEH
     pop         dword [fs:0]
     add         esp, 4
     
     invoke      msgbox, 0, t9, t9, 0
     invoke      exit, 0
 ;------------------------------------------------
 proc seh_handler    ExceptionRecord, EstablisherFrame, ContextRecord, DispatcherContext
     push        ebx esi edi                         ; save win32 callback registers

     mov         ebx, [ExceptionRecord]
     mov         esi, [ContextRecord]
     mov         eax, [ebx+EXCEPTION_RECORD.ExceptionCode]

     cmp         eax, STATUS_ILLEGAL_INSTRUCTION     ; c000001d
     jne         seh_ss

     invoke      msgbox, 0, t2, t1, 0
     ; #UD: let's install BPX on RtlRaiseException
     push        [esi+CONTEXT.Eax]                   ; address here
     pop         [esi+CONTEXT.Dr0]
     mov         [esi+CONTEXT.Dr7], 0x00000101       ; enable local BPX on DR0
     add         [esi+CONTEXT.Eip], 2                ; skip UD2
     jmp         seh_end

 seh_ss:
     cmp         eax, STATUS_SINGLE_STEP             ; 80000004 - BPM or single step
     jne         seh_dz
     invoke      msgbox, 0, t3, t1, 0

     ; RtlRaiseException hook bpx ;]
     ; check if exception is noncontinuable - if it is, make it continuable
     mov         eax, [esi+CONTEXT.Esp]              ; get esp on RtlRaiseException entry
     mov         eax, [eax+4]                        ; get parameter - ptr to EXCEPTION_RECORD
     test        [eax+EXCEPTION_RECORD.ExceptionFlags], EXCEPTION_NONCONTINUABLE
     jz          seh_ss2                             ; continuable exception, ignore
     ; clear noncontinuable flag
     and         [eax+EXCEPTION_RECORD.ExceptionFlags], not EXCEPTION_NONCONTINUABLE
 seh_ss2:
     mov         [esi+CONTEXT.Dr7], 0                ; disable bpx so we don't loop forever
     jmp         seh_end
     
 seh_dz:
     cmp         eax, STATUS_INTEGER_DIVIDE_BY_ZERO
     jne         seh_id
     invoke      msgbox, 0, t4, t1, 0
     ; divide error, let's trigger noncontinuable condition
     mov         eax, 0xdeadc0de                     ; invalid disposition
     jmp         seh_end2

 seh_id:         ; invalid disposition handler (which should be made continuable by our hook ;)
     cmp         eax, STATUS_INVALID_DISPOSITION     ; c0000026
     jz          @f
     ; unknown exception, commit suicide ;]
     invoke      msgbox, 0, t8, t1, 0
     mov         eax, 1                              ; continue search (= effectively kill process)
     jmp         seh_end2
     
 @@: ; fix the condition that leaded to noncontinuable exception - divide error in this case
     invoke      msgbox, 0, t5, t1, 0
     mov         eax, [ebx+EXCEPTION_RECORD.NestedExceptionRecord]
     mov         eax, [eax-0x0c]    ; context pointer - ONLY IF EXCEPTION PARAMETERS ARE DIRECTLY BEFORE SEH FRAME!
     mov         [eax+CONTEXT.Eax], 0xdeadbeef   ; correct div ;)
     ; this exception is now continuable so we can go ahead

 seh_end:
     xor         eax, eax                            ; status: continue execution
 seh_end2:
     pop         edi esi ebx
     ret                                             ; proc macro takes care of stack balance
 endp
 ;------------------------------------------------
 UnhandledExceptionFilter:
     push        esi edi ebx

     ExceptionPointers   equ esp+0x10    ; EXCEPTION_POINTERS

     mov         eax, [ExceptionPointers]
     mov         ebx, [eax+EXCEPTION_POINTERS.ExceptionRecord]   ; exception info
     mov         esi, [eax+EXCEPTION_POINTERS.ContextRecord]     ; CPU state when exception occured
     mov         eax, [ebx+EXCEPTION_RECORD.ExceptionCode]       ; code

     cmp         eax, STATUS_INTEGER_DIVIDE_BY_ZERO
     jne         @f
     ; nothing for now - seh fixes context 2 frames back *o*
     ; well, we NEED to handle it here - I still don't know exactly why ZwRaiseException ignores SEH after nested exception and throws us here
     ; seems like some unwind is going on, since DRs are reverted to the state at previous (first) DIV error
     ; (that's actually good, because we don't need to reenable bpx manually)
     invoke      msgbox, 0, t7, t6, 0

     jmp         uef_end
 ;------------
 @@:
     ; unknown exception
     invoke      msgbox, 0, t8, t6, 0
 ;------------
 uef_end:
     mov         eax, -1 ; continue

     pop         ebx edi esi
     ret         4
 ;------------------------------------------------
 section 'data' data readable writable

 _ntdll      db  'ntdll.dll',0
 _rre        db  'RtlRaiseException',0
 t1          db  'SEH',0
 t2          db  'STATUS_ILLEGAL_INSTRUCTION',10,'Installing RtlRaiseException hook',0
 t3          db  'STATUS_SINGLE_STEP',10,'RtlRaiseException called',0
 t4          db  'STATUS_INTEGER_DIVIDE_BY_ZERO',10,'Returning invalid disposition',0
 t5          db  'STATUS_INVALID_DISPOSITION',10,'Fixing div and continuing',0
 t6          db  'UEF',0
 t7          db  'STATUS_INTEGER_DIVIDE_BY_ZERO',0
 t8          db  'Unknown exception',0
 t9          db  'Exiting properly, all is ok',0
 ;------------------------------------------------
 data import

 library user,   'user32.dll',\
         kernel, 'kernel32.dll'

 import  user,\
         msgbox, 'MessageBoxA'

 import  kernel,\
         GetProcAddress, 'GetProcAddress',\
         GetModuleHandle, 'GetModuleHandleA',\
         SetUnhandledExceptionFilter, 'SetUnhandledExceptionFilter',\
         exit, 'ExitProcess'
 end data
 ;------------------------------------------------

~ ~ ~
Posted by omeg in assembly, code, reverse engineering, windows internals

Totally forgot about this. Some time ago I’ve accidentally found an unhandled exception condition in kernel-mode GDI. Microsoft is aware of this but frankly they still didn’t fix it. Well, it may be not security issue, but who knows 😉

Offending function: win32k!NtUserGetDCEx or its user-mode wrapper, GetDCEx.
Crash condition: call it with all 0s before any desktops are created (I’m not 100% sure of this, but it seems to be the case).
Sample scenario: Create a DLL that calls GetDcEx(0,0,0) in DllMain. MessageBox works too (that’s how I first stumbled on it). Add the DLL to AppInit_DLLs registry key. Reboot. Upon next system start the DLL will be mapped into winlogon’s memory and the fatal function called before any windows are present. Boom, BSOD.

PROCESS_NAME:  winlogon.exe

 FAULTING_IP: 
 win32k!NtUserGetDCEx+29
 bf83c00f 8b4904          mov     ecx,dword ptr [ecx+4]

 EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
 ExceptionAddress: bf83c00f (win32k!NtUserGetDCEx+0x00000029)
    ExceptionCode: c0000005 (Access violation)
   ExceptionFlags: 00000000
 NumberParameters: 2
    Parameter[0]: 00000000
    Parameter[1]: 00000004
 Attempt to read from address 00000004

 ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

 READ_ADDRESS:  00000004 

 BUGCHECK_STR:  ACCESS_VIOLATION

 DEFAULT_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE

 LAST_CONTROL_TRANSFER:  from 8053ca28 to bf83c00f

 STACK_TEXT:  
 f88d9d50 8053ca28 00000000 00000000 00000003 win32k!NtUserGetDCEx+0x29
 f88d9d50 7c90eb94 00000000 00000000 00000003 nt!KiFastCallEntry+0xf8
 0006fb24 7e41e881 7e43a383 00000000 00000000 ntdll!KiFastSystemCallRet
 0006fddc 7e43a284 0006ff38 00000005 00000004 USER32!NtUserGetDCEx+0xc
 0006ff2c 7e4661d3 0006ff38 00000028 00000000 USER32!MessageBoxWorker+0x2ba
 0006ff84 7e4505f3 00000000 1000d9e8 1000b370 USER32!MessageBoxTimeoutW+0x7a
 0006ffa4 7e46634f 00000000 1000d9e8 1000b370 USER32!MessageBoxExW+0x1b
 0006ffc0 1000105f 00000000 1000d9e8 1000b370 USER32!MessageBoxW+0x45

Here’s the appropriate disassembly:

 bf83c003 a138a59abf      mov     eax,dword ptr [win32k!gptiCurrent (bf9aa538)]
 bf83c008 f6404b20        test    byte ptr [eax+4Bh],20h
 bf83c00c 8b483c          mov     ecx,dword ptr [eax+3Ch]
 bf83c00f 8b4904          mov     ecx,dword ptr [ecx+4] ds:0023:00000004=????????
 bf83c012 8b7108          mov     esi,dword ptr [ecx+8]

Interestingly, NtUserGetDC isn’t just a wrapper to the …Ex function. It has different code and isn’t vulnerable to this.

~ ~ ~
Posted by omeg in assembly, information security, reverse engineering, windows internals

During development of my unfinished crackme I encountered several interesting discrepancies in exception handling on various OS/vm configurations.

First of them caused my 32-bit code to run fine on 32-bit XP but crash on 64-bit XP. It was caused by difference in behavior of (Rtl)RaiseException: on 32-bit XP it captured full thread context, but on 64-bit XP it didn’t – debug registers were missing. And that caused problems, because I wanted to play with DRs in my SEH. 😉

Second “trick” is behavior of system exception dispatcher regarding DR6 and its status bits. Intel docs say that CPU itself never clears these bits after a hardware breakpoint occurs. 32-bit Windows clears them though, but it also depends whether OS is running in a VM or not…

Third glitch is similar to the old “prefetch queue” tricks. I didn’t have time to investigate it much – maybe its mechanism is completely different, but it surely looks familiar. Let’s say we execute UD2 instruction or cause exception in some other way. Then, in SEH handler, we set hardware breakpoint on instruction immediately following the one that caused exception. What will happen after return from SEH? It depends… On some systems bpx will be triggered, on some not… Adding single NOP between exception trigger and bpx target will ensure that bpx always hits.

Following table contains results of my experiments in various environments. Numbers after OS name indicate whether it’s 32 or 64-bit version, number after slash means that it’s running in VMware server on XP 32 or 64-bit host.

2k 32 = 32-bit 2k on real machine
xp 32/64 = 32-bit XP inside VM hosted on 64-bit XP

Most OSes were fully updated.

dr6 column shows whether OS clears DR6 status bits after hardware breakpoint hits.
context column shows whether (Rtl)RaiseException captures full CPU context or misses debug registers.
prefetch column shows the last test – whether the tricky breakpoint gets hit without “padding” nop or not.

 os           dr6       context  prefetch
 ----------------------------------------
 2k    32     clear     full     ?
 2k    32/32  preserve  full     hit
 2k    32/64  clear     full     hit
 xp    32     clear     full     hit
 xp    32/32  preserve  full     hit
 xp    32/64  preserve  full     hit
 xp    64     clear     partial  miss
 2k3   32     clear     partial  ?
 2k3   32/32  preserve  partial  miss
 2k3   32/64  preserve  partial  miss
 vista 32     clear     partial  ?
 vista 32/64  preserve  full     hit
 vista 64/64  clear     full?    hit

vista 64/64: In “context capturing” test I’ve got different results today than some time ago. Not sure what caused the difference – earlier test being run on pre-release build, maybe some updates…

FASM code for all examples

~ ~ ~
Posted by omeg in assembly, reverse engineering, windows internals