Mysteries of win32k & GDI

**aionescu** · January 25th, 2008, 10:20

Thanks omega_red... I just found this thread and looked around Win32k.sys a bit last night and found four vulnerabilities, including the one you mentioned --Microsoft was wrong to assume this can only happen before Winlogon loads! (Sorry for being vague -- you know how disclosure works).

I sent reports to my friends over at MSFT, but these bugs are so fun I'd love to give a talk at Blackhat about them as soon as they release patches!

**dELTA** · January 26th, 2008, 03:46

Cool!

(Maybe I'll see you in Vegas then...

)

**omega_red** · January 29th, 2008, 06:05

Hehe, nice that you've found something interesting Alex. I suspected that this could be more serious, but I've never been much into the software vulnerabilities area. Any code execution stuff in there?

**Maximus** · January 29th, 2008, 10:00

rofl Win32 must be a gold-mine for bugs. Didnt even have the time to examine it...

Code:

EngDebugPrint(PCH MyPrefix, char *DebugMsg, va_list MyArgList)
{
  ULONG nBugCheck;
  char MyCool256byteBuffer[256];

  nBugCheck = BugCheckParameter2;
  DbgPrint(MyPrefix);
  vsprintf(MyCool256byteBuffer, DebugMsg, MyArgList);
  return DbgPrint(MyCool256byteBuffer);
}

I am curious to know what's happen if my DebugMsg is >256... will my OS bsod in mysterious ways?

being it a DEBUG function, it reinforces my idea that for working at M$ you are thoroughly tested thru an IQ test and taken if...

----edit
ouch, how can i make the code box bigger?!
----edit 2
* Every driver that uses this function i.e. in response to IOControls with string data or such might be used to access R0, of course.
* Every poor driver developer that output a string by this way is exposed to WTF! crashes...
* etc. etc.

**Kayaker** · February 11th, 2008, 01:10

Originally Posted by blabberer

playing a little with userkdx a little i accidently found that _w32threadifno type info is available in xp as well

Code:

lkd> dt  win32k!_W32THREAD -v -b e252eeb0
struct _W32THREAD, 10 elements, 0x28 bytes
   +0x000 pEThread         : 0x80e0db68
   +0x004 RefCount         : 1
   +0x008 ptlW32           : (null)
   +0x00c pgdiDcattr       : (null)
   +0x010 pgdiBrushAttr    : (null)
   +0x014 pUMPDObjs        : (null)
   +0x018 pUMPDHeap        : (null)
   +0x01c dwEngAcquireCount : 0
   +0x020 pSemTable        : (null)
   +0x024 pUMPDObj         : (null)

...and some months later... I found something that seems to confirm this structure definition of ETHREAD.Win32Thread is correct.

I was looking at some of the win32k!Eng*Semaphore functions, which is entirely the fault of Maximus

:

http://community.reverse-engineering.net/viewtopic.php?f=10&t=6647

Specifically I was trying to figure out why the offset HSemaphore+0x18 points to an ETHREAD structure in the function EngIsSemaphoreOwnedByCurrentThread.

While looking at EngAcquireSemaphore I saw that it increments W32THREAD.dwEngAcquireCount at 0x1C as posted by blabberer.

Code:

EngAcquireSemaphore(
    IN HSEMAPHORE  hsem
    );

:BF806E7A __stdcall EngAcquireSemaphore(x) proc...
:BF806E7A Resource        = dword ptr  8
:BF806E7A
:BF806E7A                 mov     edi, edi
:BF806E7C                 push    ebp
:BF806E7D                 mov     ebp, esp
:BF806E7F                 mov     ecx, [ebp+Resource] ; Resource
:BF806E82                 call    GreAcquireSemaphore(x)
:BF806E87                 call    ds:PsGetCurrentThread()
:BF806E8D                 push    eax
:BF806E8E                 call    ds:PsGetThreadWin32Thread(x) // returns ETHREAD.Win32Thread
:BF806E94                 test    eax, eax
:BF806E96                 jz      short loc_BF806E9B
:BF806E98                 inc     dword ptr [eax+1Ch] / W32THREAD.dwEngAcquireCount
:BF806E9B
:BF806E9B loc_BF806E9B:                           ; CODE XREF: EngAcquireSemaphore(x)+1C
:BF806E9B                 pop     ebp
:BF806E9C                 retn    4
:BF806E9C __stdcall EngAcquireSemaphore(x) endp

Unfortunately those Eng* functions can only be used from display drivers and not kernel mode drivers, so it's a little tricky to suss 'em out.

Kayaker

**blabberer** · February 12th, 2008, 11:50

Unfortunately those Eng* functions can only be used from display drivers and not kernel mode drivers, so it's a little tricky to suss 'em out.

if some fortunate or unfortunate soul tries to suss em out here is a little hack
to get all those sussed out information back to original win32k.sys 's PDB

so that windbg or livekd recognises them without any problems

1) you would need ddk or wdk or whatever rtm it is called nowadays
for the cl.exe and build environment

2) you would need a c file that contains the definitions like blah.c

you would need the following command to put your blah.c information into
microsofts pdb file

here is the command line

Code:

C:\win32kpdb>cl.exe /Zi /Gz /c /Fdwin32k.pdb /ID:\WINDDK\3790~1.183\inc\wxp /ID:
\WINDDK\3790~1.183\inc /ID:\WINDDK\3790~1.183\inc\crt /ID:\WINDDK\3790~1.183\inc
\ddk\wxp /ID:\WINDDK\3790~1.183\inc\hal\wxp /ID:\WINDDK\3790~1.183\inc\ifs\wxp /
ID:\WINDDK\3790~1.183\inc\mfc42 /ID:\WINDDK\3790~1.183\inc\wxp /ID:\WINDDK\3790~
1.183\inc\processor /ID:\WINDDK\3790~1.183\inc\ddk\wdm\wxp /D_X86_=1 tagthread.c

i used specific include paths specific to my setup of ddk your mileage may vary you would need to define _x86_ macro
tag thread.c is the file that contains the information that i added to win32k.sys file

whose contents at that time of experiment was

Code:

#include <ntddk.h>

typedef void  *POINTER;

typedef POINTER   PDESKTOPINFO;
typedef POINTER   PPROCESSINFO;
typedef POINTER   PTL;
typedef POINTER   PQ;
typedef POINTER   PKL;
typedef POINTER   PCLIENTTHREADINFO;
typedef POINTER   PDESKTOP;
typedef POINTER   PCLIENTINFO;
typedef POINTER   PSMS;
typedef POINTER   PMENUSTATE;
typedef POINTER   PTDB;
typedef POINTER   PWINDOWSTATION;
typedef POINTER   PSVR_INSTANCE_INFO;
typedef POINTER   PMOVESIZEDATA;
typedef POINTER   PSBTRACK;
typedef POINTER   PWND;
typedef POINTER   PIMC;
typedef POINTER   PQMSG;
typedef POINTER   PCLS;
typedef POINTER   PWOWPROCESSINFO;
typedef POINTER   PDESKTOPVIEW;
typedef POINTER   PCURSOR;
typedef POINTER   PW32JOB;
typedef POINTER   KERNEL_ULONG_PTR;

typedef PTHREADINFO;
typedef PHOOK;

typedef struct tagCLIENTTHREADINFO {
    UINT        CTIF_flags;
    WORD        fsChangeBits;           // Bits changes since last compared
    WORD        fsWakeBits;             // Bits currently available
    WORD        fsWakeBitsJournal;      // Bits saved while journalling
    WORD        fsWakeMask;             // Bits looking for when asleep
    LONG        timeLastRead;           // Time of last input read
} CLIENTTHREADINFO;


typedef struct tagPROCESSINFO {      //W32PROCESS;
 //***************************************** begin: USER specific fields
 PTHREADINFO     ptiList;                    // threads in this process
 PTHREADINFO     ptiMainThread;              // pti of "main thread"
 PDESKTOP        rpdeskStartup;              // initial desktop
 PCLS            pclsPrivateList;            // this processes' private classes
 PCLS            pclsPublicList;             // this processes' public classes
 PWOWPROCESSINFO pwpi;                       // Wow PerProcess Info

    PPROCESSINFO    ppiNext;                    // next ppi structure in start list
 PPROCESSINFO    ppiNextRunning;
 int             cThreads;                   // count of threads using this process info
    HDESK           hdeskStartup;               // initial desktop handle
    UINT            cSysExpunge;                // sys expunge counter
    DWORD           dwhmodLibLoadedMask;        // bits describing loaded hook dlls
 HANDLE          ahmodLibLoaded[CLIBS];      // process unique hmod array for hook dlls
 PWINDOWSTATION  prpwinsta; // process windowstation
 HWINSTA         hwinsta;                    // windowstation handle
    ACCESS_MASK     amwinsta;                   // windowstation accesses

 DWORD           dwHotkey;                   // hot key from progman
    HMONITOR        hMonitor;                   // monitor handle from CreateProcess
 PDESKTOPVIEW    pdvList;                    // list of desktop views
 UINT            iClipSerialNumber;          // clipboard serial number
 RTL_BITMAP      bmHandleFlags;              // per handle flags
 PCURSOR         pCursorCache;               // process cursor/icon cache
    PVOID           pClientBase;                // LEAVE THIS FOR HYDRA; offset to the shared section
    DWORD           dwLpkEntryPoints;           // user mode language pack installed

 PW32JOB         pW32Job;                    // pointer to the W32JOB structure

 DWORD           dwImeCompatFlags;           // per-process Ime Compatibility flags
 LUID            luidSession;                // logon session id
 USERSTARTUPINFO usi;                        // process startup info

#ifdef VALIDATEHANDLEQUOTA
 LONG lHandles;
#endif

#ifdef USE_MIRRORING
 DWORD           dwLayout;                   // the default Window orientation for this process
#endif

} PROCESSINFO;

typedef struct _HEAD {
 DWORD h; //HHOOK
 DWORD cLockObj;
} HEAD, *PHEAD;

typedef struct _THROBJHEAD {
 HEAD hdr;
 DWORD pti;
} THROBJHEAD, *PTHROBJHEAD;

typedef struct _DESKHEAD {
 DWORD rpdesk;
 DWORD pSelf;
} DESKHEAD, *PDESKHEAD;

typedef struct _THRDESKHEAD {
 THROBJHEAD tohdr;
 DESKHEAD dhdr;
} THRDESKHEAD, *PTHRDESKHEAD;


typedef struct tagHOOK {   /* hk */
 THRDESKHEAD     head;
 PHOOK           phkNext;
 int             iHook;              // WH_xxx hook type
 KERNEL_ULONG_PTR offPfn;
 UINT            flags;              // HF_xxx flags
 int             ihmod;
 PTHREADINFO     ptiHooked;          // Thread hooked.
 PDESKTOP        rpdesk;             // Global hook pdesk. Only used when
          //  hook is locked and owner is destroyed
#ifdef HOOKBATCH
 DWORD           cEventMessages;     // Number of events in the cache
 DWORD           iCurrentEvent;      // Current cache event
 DWORD           CacheTimeOut;       // Timeout between keys
 PEVENTMSG       aEventCache;        // The array of Events
#endif // HOOKBATCH
} HOOK;




typedef struct _THREADINFO {
    ULONG a[10];                   	 // W32THREAD
    PTL                 ptl;       	 // Listhead for thread lock list            +28
    PPROCESSINFO        ppi;       	 // process info struct for this thread        +2C
    PQ                  pq;        	 // keyboard and mouse input queue            +30
    PKL                 spklActive;   	 // active keyboard layout for this thread    +34
    PCLIENTTHREADINFO   pcti;      	 // Info that must be visible from client    +38
    PDESKTOP            rpdesk;
    PDESKTOPINFO        pDeskInfo; 	 // Desktop info visible to client            +40
    PCLIENTINFO         pClientInfo;	// Client info stored in TEB                +44
    ULONG               TIF_flags;  	// TIF_ flags go here.                        +48
    PUNICODE_STRING     pstrAppName;	// Application module name.                    +4C
    PSMS                psmsSent;    	// Most recent SMS this thread has sent
    PSMS                psmsCurrent;    // Received SMS this thread is currently processing
    PSMS                psmsReceiveList;// SMSs to be processed
    LONG                timeLast;       // Time, position, and ID of last message
    ULONG_PTR           idLast;
    int                 cQuit;
    int                 exitCode;
    HANDLE              hdesk;        // Desktop handle. Changed from "HDESK hdesk"
    int                 cPaintsReady;
    unsigned int        cTimersReady;
    PMENUSTATE          pMenuState;
    union {
        PTDB            ptdb;        	// Win16Task Schedule data for WOW thread
        PWINDOWSTATION  pwinsta;    	// Window station for SYSTEM thread
    };
    PSVR_INSTANCE_INFO  psiiList;   	// thread DDEML instance list
    ULONG               dwExpWinVer;
    ULONG               dwCompatFlags; 	// The Win 3.1 Compat flags
    ULONG               dwCompatFlags2; // new DWORD to extend compat flags for NT5+ features
    PQ                  pqAttach;    	// calculation variabled used in zzzAttachThreadInput()
    void*               ptiSibling;   	// Pointer to sibling thread info. Chnaged from "PTHREADINFO ptiSibling"
    PMOVESIZEDATA       pmsd;
    ULONG               fsHooks;    	// WHF_ Flags for which hooks are installed
    PHOOK               sphkCurrent;	// Hook this thread is currently processing
    PSBTRACK            pSBTrack;
    HANDLE              hEventQueueClient;
    PKEVENT             pEventQueueServer;
    LIST_ENTRY          PtiLink;      	// Link to other threads on desktop
    int                 iCursorLevel;   // keep track of each thread's level
    ULONG               b[2];        	//POINT           ptLast;
    PWND                spwndDefaultIme;// Default IME Window for this thread
    PIMC                spDefaultImc;  	// Default input context for this thread
    HANDLE              hklPrev;    	// Previous active. Changed from "HKL hklPrev"
    int                 cEnterCount;
    MLIST               mlPost;     	// posted message list.
    USHORT              fsChangeBitsRemoved;// Bits removed during PeekMessage
    WCHAR               wchInjected;    // character from last VK_PACKET
    ULONG               fsReserveKeys;  // Keys that must be sent to the active                +E0
    PKEVENT             *apEvent;       // Wait array for xxxPollAndWaitForSingleObject        +E4
    ACCESS_MASK         amdesk;         // Granted access                                    +E8
    unsigned int        cWindows;       // Number of windows owned by this thread            +EC
    unsigned int        cVisWindows;    // Number of visible windows on this thread            +F0
    PHOOK               aphkStart[CWINHOOKS];    // Hooks registered for this thread, local hook    +F4
    CLIENTTHREADINFO    cti;            // Use this when no desktop is available            +F8
} THREADINFO, *PTHREADINFO;

THREADINFO thinf;

this is how you do it

Code:

copy the win32k.pdb from symbol cache into a folder
copy this tagthread.c (this is crap i have changed many HWINSTA etc
symbols to ULONG to fool errors and test

and go to the build environment and pass the commandline

copy back the new win32k.pbd to symbol cache (remember save original
before replacing)

go to kd and do dt _win32k!_Threadinfo <some address> here

it should show some real information in formatted style

like below if you are successfull

result as follows

Code:



lkd> !ready
Processor 0: Ready Threads at priority 8
   THREAD ff5e3020  Cid 0350.0b64  Teb: 7ffad000 Win32Thread: e123adc0 READY
   THREAD 810c0020  Cid 0314.07b0  Teb: 7ff8d000 Win32Thread: 00000000 WAIT
   THREAD ffbad020  Cid 0314.0330  Teb: 7ffdb000 Win32Thread: e2107a50 WAIT
   THREAD ff98bcb0  Cid 0350.0c24  Teb: 7ffde000 Win32Thread: e245c400 WAIT
   THREAD ff5e3020  Cid 0350.0b64  Teb: 7ffad000 Win32Thread: e123adc0 READY
lkd> dt win32k!_Threadinfo e123adc0
win32k!_THREADINFO
  +0x000 a                : [10] 0xff5e3020 <--- this is w32thread
but i just took zairon post definition as it is to test
  +0x028 ptl              : (null)
  +0x02c ppi              : 0xe24db0c0
  +0x030 pq               : 0xe1080c18
  +0x034 spklActive       : 0xe20bcf08
  +0x038 pcti             : 0xbc662b18
  +0x03c rpdesk           : 0x810f0e10
  +0x040 pDeskInfo        : 0xbc630650
  +0x044 pClientInfo      : 0x7ffad6cc
  +0x048 TIF_flags        : 0x1000000
  +0x04c pstrAppName      : (null)
  +0x050 psmsSent         : (null)
  +0x054 psmsCurrent      : (null)
  +0x058 psmsReceiveList  : (null)
  +0x05c timeLast         : 0
  +0x060 idLast           : 0
  +0x064 cQuit            : 0
  +0x068 exitCode         : 40
  +0x06c hdesk            : (null)
  +0x070 cPaintsReady     : 0
  +0x074 cTimersReady     : 0
  +0x078 pMenuState       : (null)
  +0x07c ptdb             : (null)
  +0x07c pwinsta          : (null)
  +0x080 psiiList         : 0x00000400
  +0x084 dwExpWinVer      : 0
  +0x088 dwCompatFlags    : 0x10000
  +0x08c dwCompatFlags2   : 0
  +0x090 pqAttach         : 0xe153e8f8
  +0x094 ptiSibling       : (null)
  +0x098 pmsd             : (null)
  +0x09c fsHooks          : 0
  +0x0a0 sphkCurrent      : 0
  +0x0a4 pSBTrack         : 0x00000704
  +0x0a8 hEventQueueClient : 0xff9c3f40
  +0x0ac pEventQueueServer : 0xe153e9a4 _KEVENT
  +0x0b0 PtiLink          : _LIST_ENTRY [ 0xe1036e5c - 0x0 ]
  +0x0b8 iCursorLevel     : 0
  +0x0bc b                : [2] 0
  +0x0c4 spwndDefaultIme  : (null)
  +0x0c8 spDefaultImc     : (null)
  +0x0cc hklPrev          : (null)
  +0x0d0 cEnterCount      : 0
  +0x0d4 mlPost           : 0
  +0x0d8 fsChangeBitsRemoved : 0
  +0x0da wchInjected      : 0
  +0x0dc fsReserveKeys    : 0
  +0x0e0 apEvent          : (null)
  +0x0e4 amdesk           : 0
  +0x0e8 cWindows         : 0xf01ff
  +0x0ec cVisWindows      : 0
  +0x0f0 aphkStart        : [20] 0
  +0x140 cti              : 0
lkd>

have fun :)

**Kayaker** · February 12th, 2008, 21:13

Thanks blabberer. I remember you showing me this a while back, I think in reference to this thread actually, and I can vouch that it works great. Might be a nice way to attach some of Alex Ionescu's NDK undocumented headers to Windbg output capabilities.

**aionescu** · February 17th, 2008, 17:45

Problem is that the structure is out-of-date...see 'PtiLink'.

I've been using a similar trick of my own, but actually just load my module with a separate name, then I can do dt mymodule!_TYPE <ptr>.

You can use .reload with a PDB and a valid kmode address and it usually works.

**aionescu** · February 17th, 2008, 17:47

Not sure where you got that, but in IDA I see:

vsprintf_s

Which is the "safe" version, and the length is set to 256.

Originally Posted by Maximus

rofl Win32 must be a gold-mine for bugs. Didnt even have the time to examine it...

Code:

EngDebugPrint(PCH MyPrefix, char *DebugMsg, va_list MyArgList)
{
  ULONG nBugCheck;
  char MyCool256byteBuffer[256];

  nBugCheck = BugCheckParameter2;
  DbgPrint(MyPrefix);
  vsprintf(MyCool256byteBuffer, DebugMsg, MyArgList);
  return DbgPrint(MyCool256byteBuffer);
}

I am curious to know what's happen if my DebugMsg is >256... will my OS bsod in mysterious ways?

being it a DEBUG function, it reinforces my idea that for working at M$ you are thoroughly tested thru an IQ test and taken if...

----edit
ouch, how can i make the code box bigger?!
----edit 2
* Every driver that uses this function i.e. in response to IOControls with string data or such might be used to access R0, of course.
* Every poor driver developer that output a string by this way is exposed to WTF! crashes...
* etc. etc.

**Maximus** · February 18th, 2008, 08:37

!!
thanks, but this leaves me with a big problem now... what's happened to the win2k.sys of THIS machine!? The code I see is different, and WinUpdate is ON (even if in manual mode).
mmh...
edit------------
mmh... only some minor, optional update is missing... oook. I'll check on other windows machines...

**Maximus** · February 22nd, 2008, 16:22

vsprintf_s

Which is the "safe" version, and the length is set to 256.

out of curiosity, i checked today other windows versions. I do not see it nor in others XP (updated&original), not in 2k3server.
the call is made by 3 parameters, not 4 as vsprintf_s requires. Also, i do not see the '256' anywhere.

What strange version of Windows XP are you using? Is there a version of WinXP which uses vsprintf_s and my xppro uses it not?

aaah i see now what you are looking. Well, please ask to your MS friends if they can fix this in other OSes too -especially XP

I dont like much Vista...

**aionescu** · March 16th, 2008, 17:09

Can you confirm that on SRV03SP1 this function still uses strcpy with no extra validation? That's pretty disgusting. The bug isn't there on Vista.

**habituallurker** · March 18th, 2008, 12:45

XP SP2 5.1.2600.3099: The bug exists, but is mitigated by GS cookies:

Code:

.text:BF9332A4 ; int __stdcall EngDebugPrint(PCH Format,int,int)
.text:BF9332A4   public _EngDebugPrint@12
.text:BF9332A4 _EngDebugPrint@12 proc near
.text:BF9332A4
.text:BF9332A4 var_104= byte ptr -104h
.text:BF9332A4 var_4= dword ptr -4
.text:BF9332A4 Format= dword ptr  8
.text:BF9332A4 arg_4= dword ptr  0Ch
.text:BF9332A4 arg_8= dword ptr  10h
.text:BF9332A4
.text:BF9332A4   mov   edi, edi
.text:BF9332A6   push  ebp
.text:BF9332A7   mov   ebp, esp
.text:BF9332A9   sub   esp, 104h
.text:BF9332AF   mov   eax, gscookie
.text:BF9332B4   push  esi
.text:BF9332B5   mov   esi, [ebp+arg_4]
.text:BF9332B8   mov   [ebp+var_4], eax
.text:BF9332BB   mov   eax, [ebp+Format]
.text:BF9332BE   push  edi
.text:BF9332BF   mov   edi, [ebp+arg_8]
.text:BF9332C2   push  eax                             ; Format
.text:BF9332C3   call  _DbgPrint
.text:BF9332C8   push  edi                             ; va_list
.text:BF9332C9   lea   eax, [ebp+var_104]
.text:BF9332CF   push  esi                             ; char *
.text:BF9332D0   push  eax                             ; char *
.text:BF9332D1   call  _vsprintf
.text:BF9332D6   lea   eax, [ebp+var_104]
.text:BF9332DC   push  eax                             ; Format
.text:BF9332DD   call  _DbgPrint
.text:BF9332E2   mov   ecx, [ebp+var_4]
.text:BF9332E5   add   esp, 14h
.text:BF9332E8   pop   edi
.text:BF9332E9   pop   esi
.text:BF9332EA   call  @__security_check_cookie@4      ; __security_check_cookie(x)
.text:BF9332EF   leave
.text:BF9332F0   retn  0Ch
.text:BF9332F0 _EngDebugPrint@12 endp

**Maximus** · March 18th, 2008, 14:31

Actually, all the functions i did check when roamed w2k have the error not fixed in XP, but in vista (i.e. the debug function).

By the way... why the hell the Win2k of Vista is compiled with a LOCAL rtl included in it, instead of accessing the ntos one!?!?!?!? It's just a waste of PC memory with no real advantages (no higher speed etc.).
Mah, i start to understand why Vista is SO demanding in resources... if all files are compiled this way....

mmh... I'd like give another look at win2k for curiosity [damn, i found there of good only one XP/Vista string overflow from userland, nice but not yet what I wanted], but work is calling in this period

tx for having such bugs fixed in XPsp3 if possible

...I dream to be able to migrate to linux and not vista, in future ...but i dont bet much for it

**aionescu** · May 10th, 2008, 18:53

Looks like the bug probably got fixed in Windows Server 2003 SP1 and later, but not downstream.

Exploiting this bug would also require you to bypass the stack cookie, which may not be trivial in this context. Also, pretty much the only way you can attack the system is to have a video driver that calls EngDbgPrint (pretty unlikely) with a string that you can control (very unlikely) and that can include any possible character (even more unlikely).

Finally, the rtl you're thinking isn't the same RTL as in ntos/ntdll. Win32k has always had its own "rtl" library to deal with things such as LARGE_UNICODE_STRING and other Win32k-internal types.

Originally Posted by Maximus

Actually, all the functions i did check when roamed w2k have the error not fixed in XP, but in vista (i.e. the debug function).

By the way... why the hell the Win2k of Vista is compiled with a LOCAL rtl included in it, instead of accessing the ntos one!?!?!?!? It's just a waste of PC memory with no real advantages (no higher speed etc.).
Mah, i start to understand why Vista is SO demanding in resources... if all files are compiled this way....

mmh... I'd like give another look at win2k for curiosity [damn, i found there of good only one XP/Vista string overflow from userland, nice but not yet what I wanted], but work is calling in this period

tx for having such bugs fixed in XPsp3 if possible

...I dream to be able to migrate to linux and not vista, in future ...but i dont bet much for it

Collaborative RCE Tool Library (CRCETL)	Collaborative RCE Knowledge Library (CRCEKL)
CrackZ	Fravia's Searchlores	Yates
ARTeam	Reverse Engineering Reddit	Reverse Engineering Team
KernelMode.info	OpenRCE	Tuts 4 You
NTCore	My Infected Computer	Evilcry's Dark Cave
j00ru//vx tech blog	cr4zyserb - deroko of ARTeam	UIC R.E. Academy
		The TiGa Video Tutorial Site
Fravia's Original Reversing Site	The Original RCE-CD	Krobars Collection of tutorials
OllyDbg Extensions: Version 1.x Version 2.x

Thread: Mysteries of win32k & GDI

Thread Tools

Search Thread

Display

Similar Threads

A story of win32k!cCapString, or unicode strings gone bad.

patching win32k.sys

Analyzing local privilege escalations in win32k

Null pointer dereference in win32k

Mysteries of win32k & GDI - Win32Thread

Bookmarks

Bookmarks

Posting Permissions