Original: http://www.allife.org/index.php? Job = art & articleid = a_20060529_121555
Navigating the kenel debugger
Introduction
In this tutorial, we will be covering a few of the basic features of the kernel debugger, and get used to using it. I obviously can not cover everything, so only select topics will be covered to just get used to the debugger. Hopefully YOU WILL FIND this article.
Setup
To setup the Kernel Debugger, you will need to modify your BOOT.INI file as mentioned in "Debug Tutorial Part 1". / DEBUG / DEBUGPORT = COM1 / BAUDRATE = 115200 should be entered as options. If you do not specify the speed, The default I believe IS 19200. I Would Create a Separate Entry in the boot.ini so you can choose Between Debugging and not debugging. You can do this by just copying what is already there and modify it.
[boot loader] Timeout = 30DEFAULT = MULTI (0) Disk (0) rdisk (0) Partition (1) Windows [Operating Systems] Multi (0) Disk (0) RDisk (0) Partition (1) Windows = "Microsoft Windows XP Professional "/ fastdetectmulti (0) disk (0) rdisk (0) partition (1) WINDOWS =" Microsoft windows XP Professional "/ fastdetect / debug / debugport = com1 / baudrate = 115200 (Shown on seperate line to prevent long lines in This Article. Should Be on The Same Line in Boot.ini.
You can Also Use Firewire if you have.com The specified com port of the machine you want to debug, to the com port of the machine you want to use to debug.
There are also other kernel debuggers out there that run on the same machine, like Softice. There's even a "LiveKD" that can be used. This tutorial will only refer to the free tools that can be downloaded from Microsoft for windows NT. There are other versions of the tools for windows 9x.To connect to the machine, simply open WINDBG and select "Kernel Debug" from the File menu. Select "COM" tab, or other tab if you used Firewire, and then enter the options. The COM port you specify is where you connect the cable to the local machine, not the one you specified in the remote machine's BOOT.INI. If you're using VMWare, when you setup the COM port, you can select it to output to a Pipe. This Url shows the setup for vmware.
You May NEED TO PRESS "Control C" if The Machine Has Already Booted in Order for You to Enter the Debugger.
Some Other Tips; if you are having trouble connecting, you may want to try some of the folowing:
Control Break or "Break" in Debug menu Resynchronize (Debug -> Kernel Connection). Cycle Baud Rates (Debug -> Kernel Connection)... Try a different COM Port, ensure the cable is on correct ports Close the debugger and try Again by Opening Another Debugger. EnSure Boot.ini is Correct .hen booting, Should See "debugger enabled" by the name.
Ready to Go!
Now that we are connected, we are ready to go. First, ensure you are pointing to the Microsoft Symbol server using! Symfix or any method specified in "Debug Tutorial Part 1". Set your symbol path using the environment variable, for example, And adding any other symbol paths you may need ask as for your owne.
First, let's get started with something simple. Let's find all processes on the system. This is done by breaking into the kernel debugger and using the "! Process 0 0". Remember, if you get an error, make sure you are pointing to Microsoft's Symbol Server. The Debugger Needs To Locate Certain Variables in Memory To Perform Different Actions.you May See Something Like this for Each Process:
Process FCDBE2C0 sessionid: 0 CID: 00A4 PEB: 7FFDF000 Parentcid: 008c DIRBASE: 0401D000 ObjectTable: FCDC39C8 TABLESIZE: 354. Image: Winlogon.exe
SO, What Does it all mean?
PROCESS
The first is the address of the EPROCESS structure. This is a kernel data structure that describes that process. The address for this process is "fcdbe2c0". If you have symbols, you can use the "dt" command which was mentioned in an earlier Tutorial, To View this Structure.
DT _EPROCESS FCDBE2C0
oral
DT NT! _EPROCESS FCDBE2C0
If this does not work and you are debugging a windows 2000 machine, you may want to use "! Processfields" instead. It will show you the offsets into fcdbe2c0, and then you can dump the address manually to see the data you want.
Session ID
The next is the "Session ID". In a multi-user environment (Terminal Services), different users who log into a machine get their own "session". Normally, Session 0 is the console, although this is a bit different in windows XP with the fast user switching feature. For kicks, log into windows XP with a few users (unless you have 2000 or 2003 server edition, you can try the same thing) and type "qwinsta". It should give you output of the user And their session ID.
CID
The "CID" is the process identifier. If You Look in Task Manager and SELECT "PID" to Display In The Column, this is all it is. It's the pid of this process.peb
PEB is the Process Environment Block. This is a user mode data structure, and what does that mean? Generally, every process you will see the same address for this location. I hope that anyone wanting to use the kernel debugger understands Virtual Addresses. In the kernel, the system address space is mapped for all processes (without going into the details of "session space"), but the user mode addresses are mapped for that process. So, obviously, the same address in one process is not the same physical address as another. So, if all the addresses are the same, how would we view the PEB for a particular process? We need to change our "context" to that process. that way, the correct page directory tables are loaded, and Well Learn How To Set The Context Learn How To Set The Context Laarn How To Set The Context Laarn How To Set The Context Lear, Just As in The Local Debugger, You Can View The PEB in The Kernel Debugger.
Dt _peb 7ffdf000
oral
! PEB.
Parent CID
.
Dirbase
The "DirBase" is the directory base. This is the value of CR3 when this process is running. This is the address that starts the translation of Virtual Addresses to Physical Addresses. In fact, there is a command that can do this for you. ! Ptov. So, The Directory Base IS 0401D000, You Must Take Off The Last 3 Digits (Which Should Always BE 0).
PTOV 0401D
kd>! ptov 0401d4195000 1000040d6000 200003a5d000 6d00040f9000 6e0004117000 6f000405a000 70000409b000 71000409c000 72000412f000 73000413a000 7400042d1000 76000426f000 770004416000 780004458000 7a000439d000 7b00043b6000 7c0004880000 7d0004831000 7e0004ac3000 7f0004b66000 800004a67000 810004f42000 8400050a7000 890004f81000 8d000523f000 940005240000 a8000524f000 ac0005226000 b300052c4000 bc0004fda000 d600052af000 dc0005403000 e200051cc000 e5000509f000 ec0005325000 ee00052aa000 f0000512c000 f2000522e000 f300052f1000 f40005174000 f60005249000 f7000575e000 f800056df000 f90005721000 fb00058e3000 fd000576c000 fe00057ad000 ff0005833000 105000583c000 10e000 ... The address on the left is the Physical address. The address on the right is the Virtual address used by the application. to view a physical address, you do not need to switch contexts. you use the "! DC ","! db ", etc. Commands INSTEAD of the" DC "," DB "Commands Which Work ON Virtual Address. You Can Also Change The Data Stored At A Physical A Ddress by using the "! EB", etc. Commands to write data.
kd>! dc 5833000 # 5833000 72656d6d 6c616963 666f5320 72617774 mmercial Softwar # 5833010 75502065 73696c62 73726568 30414320 e Publishers CA0 # 5833020 0d309f81 862a0906 0df78648 05010101 ..0 ... *. H ....... # 5833030 8d810300 89813000 00818102 6569d3c3 ..... 0 ........ IE # 5833040 54940152 62C628AB 5554B318 458744C5 r..T. (. B..tu.de # 5833050 7ec23b4a c8d7d3d8 d88d8680 9c16f10c j;. ~ ...... ... # 5833060 29A96BCC 73768FB2 62C5C892 1EED3CA6 .K.) .. vs ... b. <.. # 5833070 13f07505 4d146c00 079098d4 817369be .u ... lm .....
Object Table
This is the table of the handle mappings for that process. This is a data structure that contains the size and a pointer to the object to handle list. This is how the kernel converts a usermode handle into its matching kernel object. We will look at Handles Again Later.Tablesize
This is the size of the table in base 10. Yes, this is a bit Non-Standard Now Since We Have Some Numbers in Hex Like The Pid, But The Size of The Table Is in Decimal. This show hows IN ITS Handle Table. If You Open Task Manager And View "Handle Count", IT Should Match This Number. This Is How Many Handle Entries Are Being Used In this process.
Image
This Is A Simple One. The Image of this Process, in This Case It's Winlogon.exe.
Changing contexts
There Are Different Ways to Change Contexts. You can do .context
First, Let's Dump Winlogon's Threads.
! Process FCDBE2C0 FF
The EPRocess Structure Must Be Supplied to the Kernel Debugger Along With Flags. Now, ff is to show everything.
kd> process fcdbe2c0 ffPROCESS fcdbe2c0 SessionId:! 0 Cid: 00a4 Peb: 7ffdf000 ParentCid: 008c DirBase: 0401d000 ObjectTable: fcdc39c8 TableSize: 354. Image: winlogon.exe VadRoot fcda2ce8 Clone 0 Private 798. Modified 1085. Locked 0. DeviceMap fcebfa48 Token e1b762d0 ElapsedTime 21: 07: 55.0882 UserTime 0: 00: 01.0241 KernelTime 0: 00: 03.0805 QuotaPoolUsage [PagedPool] 36408 QuotaPoolUsage [NonPagedPool] 62184 Working Set Sizes (now, min, max) (652, 50, 345) (2608KB, 200KB , 1380KB) PeakWorkingSetSize 2034 VirtualSize 34 Mb PeakVirtualSize 36 Mb PageFaultCount 4919 MemoryPriority BACKGROUND BasePriority 13 CommitCharge 1357 THREAD fcdbd020 Cid a4.84 Teb: 7ffde000 Win32Thread: e1b7b8 e8 WAIT: (WrUserRequest) UserMode Non-Alertable fcdb9820 SynchronizationEvent Not impersonating Owning Process fcdbe2c0 Wait Start TickCount 49551906 Elapsed Ticks: 13726 Context Switch Count 3360 LargeStack UserTime 0: 00: 00.0290 KernelTime 0: 00: 01.0041 Start Address 0x01001674 Stack Init f7660000 Current f765fcc8 Base f7660000 Limit f765d000 Call 0 Priority 15 BasePriority 15 PriorityDecrement 0 DecrementCount 0Kernel stack not resident. ChildEBP RetAddr Args to Child f765fce0 8042d61c 00000000 e1b7b8e8 00000001 nt! KiSwapThread
0xc5 f765fd08 a00159cb fcdb9820 0000000d 00000001 nt! KeWaitForSingleObject 0x1a1 f765fd44 a0014f6c 000020ff 00000000 00000001 win32k! XxxSleepThread 0x183 f765fd54 a0014f53 0006fde8 80461691 00000000 win32k! XxxWaitMessage 0xe f765fd5c 80461691 00000000 00000000 00000018 win32k! NtUserWaitMessage 0xb f765fd5c 77e14b53 00000000 00000000 00000018 nt! KiSystemService 0xc4 0006fe14 77e23570 00070022 00000000 00000010 0x77e14b53 0006fe38 77e2381e 01000000 01024c10 00000000 0x77e23570 0006fe58 77e3dcf8 01000000 01024c10 00000000 0x77e2381e 0006fe7c 01006052 01000000 00000578 00000000 0x77e3dcf8 0006feb8 01005fa8 000766b8 01000000 00000578 0x1006052 0006fef0 010099c7 000766b8 01000000 00000578 0x1005fa8 0006ff28 010019e4 000766b8 00000005 0007366c 0x10099c7 0006FF58 0100179E 01000000 0000000 0007366C 0x10019E4 0006FFF4 00000000 7FFDF000 00000C8 00000100
0x100179e THREAD fcdb8b80 Cid a4.c0 Teb: 7ffdd000 Win32Thread: 00000000 WAIT: (DelayExecution) UserMode Alertable fcdb8c68 NotificationTimer Not impersonating Owning Process fcdbe2c0 Wait Start TickCount 49564648 Elapsed Ticks: 984 Context Switch Count 33085 UserTime 0: 00: 00.0000 KernelTime 0:00: 00.0000 Start Address 0x77e92c50 Win32 Start Address 0x77f88164 Stack Init f78f4000 Current f78f3cc4 Base f78f4000 Limit f78f1000 Call 0 Priority 13 BasePriority 13 PriorityDecrement 0 DecrementCount 0Kernel stack not resident. ChildEBP RetAddr Args to Child f78f3cdc 8042d00e f78f3d64 003dffac 003dffac nt! KiSwapThread 0xc5 f78f3d04 804c04e6 003dfc01 00000001 F78f3d34 nt! kedelayexecutionthread 0x180 F78F3D54 80461691 000000 nt! NTDELAYEXECUTION 0X7F F78F3D54 77F90333 00000001 003DFFC 00000000 nt! KiSystemService 0xc4 003dffb4 77e92ca8 0006feb8 00000000 00000000 0x77f90333 003dffec 00000000 77f88164 0006feb8 00000000 0x77e92ca8 ... (Continues on with more information) Do not get worried by the "Kernel stack not resident". We know that memory gets swapped to disk, right? So, not all memory will always be available when using the kernel debugger. We just have to bear with this. in the above case, the stack is in memory, at least enough to get a stack trace, which isn ' T Always True. The Above Just Means That Part of The Stack isn't in Memory, in this case.
So, Let's Setur Context to The First Thread.
kd> .process fcdbe2c0Implicit process is now fcdbe2c0WARNING: .cache forcedecodeuser is not enabledkd> .cache forcedecodeuserMax cache size is: 1024000 bytes (0x3e8 KB) Total memory in cache: 0 bytes (0 KB) Number of regions cached: 00 full reads broken into 0 partial reads counts: 0 cached / 0 uncached, 0.00% cached bytes: 0 cached / 0 uncached, 0.00% cached ** Transition PTEs are implicitly decoded ** User virtual addresses are translated to physical addresses before accesskd> .thread fcdbd020 Implicit thread is now fcdbd020kd> kb *** Stack trace for last set context -!! .thread / .cxr resets itChildEBP RetAddr Args to Child f765fce0 8042d61c 00000000 e1b7b8e8 00000001 nt KiSwapThread 0xc5f765fd08 a00159cb fcdb9820 0000000d 00000001 nt KeWaitForSingleObject 0x1a1f765fd44 a0014f6c 000020ff 00000000 00000001 Win32k! xxxsleepthread 0x183f765fd54 A0014F53 0006FDE8 80461691 00000000 Win32k! xxxwaitMessage 0xef765fd5c 80461691 @Win32k! NTUSERWA itMessage 0xbf765fd5c 77e14b53 00000000 00000000 00000018 nt KiSystemService 0xc4WARNING:!. Frame IP not in any known module Following frames may be wrong.0006fe14 77e23570 00070022 00000000 00000010 0x77e14b530006fe38 77e2381e 01000000 01024c10 00000000 0x77e235700006fe58 77e3dcf8 01000000 01024c10 00000000 0x77e2381e0006fe7c 01006052 01000000 00000578 00000000 0x77e3dcf80006feb8 01005fa8 000766b8 01000000 00000578 0x10060520006fef0 010099c7 000766b8 01000000 00000578 0x1005fa80006ff28 010019e4 000766b8 00000005 0007366c 0x10099c70006ff58 0100179e 01000000 00000000 0007366c 0x10019e40006fff4 00000000 7ffdf000 000000c8 00000100 0x100179ekd>
ReloadConnected to Windows 2000 2195 x86 Compatible Target, Ptr64 Falseloading kernel symbols .................................. ........................................... loading unloaded Module Listno unloaded module list presentloading user symbol ............................................. ....... kd> kb *** Stack trace for last set context -!! .thread / .cxr resets itChildEBP RetAddr Args to Child f765fce0 8042d61c 00000000 e1b7b8e8 00000001 nt KiSwapThread 0xc5f765fd08 a00159cb fcdb9820 0000000d 00000001 nt KeWaitForSingleObject 0x1a1f765fd44 a0014f6c 000020ff 00000000 00000001 win32k! xxxSleepThread 0x183f765fd54 a0014f53 0006fde8 80461691 00000000 win32k! xxxWaitMessage 0xef765fd5c 80461691 00000000 00000000 00000018 win32k! NtUserWaitMessage 0xbf765fd5c 77e14b53 00000000 00000000 00000018 nt! KiSystemService 0xc40006fde0 77e23680 00000000 00000000 0000ffff USER32! NtUserWaitMessage 0xb0006fe14 77e23570 00070022 00000000 00000010 USER32 Dialogbox2 0x2160006fe38 77e2381 e 01000000 01024c10 00000000 USER32! InternalDialogBox 0xd10006fe58 77e3dcf8 01000000 01024c10 00000000 USER32! DialogBoxIndirectParamAorW 0x340006fe7c 01006052 01000000 00000578 00000000 USER32! DialogBoxParamW 0x3d0006feb8 01005fa8 000766b8 01000000 00000578 winlogon! TimeoutDialogBoxParam 0x270006fef0 010099c7 000766b8 01000000 00000578 winlogon! WlxDialogBoxParam 0x7b0006ff10 01004bdc 000766b8 00071fc8 000766b8 winlogon ! BlockWaitForUserAction 0x3c0006ff28 010019e4 000766b8 00000005 0007366c winlogon! MainLoop 0x1bf0006ff58 0100179e 01000000 00000000 0007366c winlogon! WinMain 0x2a50006fff4 00000000 7ffdf000 000000c8 00000100 winlogon! WinMainCRTStartup 0x156
Now, you notice once I set my context, I had to reload symbols in order to view usermode symbols? That's because we need to force the kernel debugger to read the new context and load the new symbols for this process. If you switch processes multiple times, you may have noticed the kernel debugger will tell you the symbols for the previous process. This is why you should try to reload symbols once you switch contexts.You should also note that the kernel stack is different from the usermode stack. When a Thread Calls Into The Kernel, It Switches The Stack. The Kernel Has Its Own Stack, And Usermode Has Its Own Stack. This is Just An fyi.
So, now you may be asking what do all the parameters mean in the PROCESS and THREAD listings? The top header we already covered, so let's start with the Process header. Though, most of it will usually just be useless information to you.
Vadroot Fcda2Ce8 Clone 0 private 798. Modified 1085. Locked 0.
The "VadRoot" is basically a pointer to a binary tree that contains the address of all Virtual Address in the process, including their start and end ranges. This is called a "Virtual Address Descriptor". If you walk this tree, you would end up seeing the same output you would if you did an x *! in the user mode debugger, but actually you may see more. This is because, this does not just include modules, but all mapped virtual address and their ranges. For example IF you Did Virtual Alloc for Some Large Blocks of Memory, These Would Show Up in this Tree List.
Try! VAD FCDA2CE8
(Notice That You SHOULD OBVIOSLY PUT The Address That's listed in Your kernel debugger there.)
DeviceMap fcebfa48
This is the Object Device Map for the system. While each process gets its own pointer to this object, as you can see below, it is stored globally in the kernel.kd> x nt! ObSystemDeviceMap8047f79c nt! ObSystemDeviceMap =
This Article Will Not Go Into Displaying Device Stacks or Anything Like That. This Article Is Just An Introduction To The Basics.
Token E1B762D0
THE! TOKEN E1B762D0:
Elapsedtime 21: 07: 55.0882 UserTime 0: 00: 01.0241 kerneltime 0: 00: 03.0805
The Amount of Time Spent In The Kernel and in Usermode.
QuotaPoolUsage [PagedPool] 36408 QuotaPoolUsage [NonPagedPool] 62184 Working Set Sizes (now, min, max) (652, 50, 345) (2608KB, 200KB, 1380KB) PeakWorkingSetSize 2034 VirtualSize 34 Mb PeakVirtualSize 36 Mb PageFaultCount 4919 MemoryPriority BACKGROUND BasePriority 13 CommitCharge 1357
....................
Now, Let's Take a look at the thread information. We can do this by using! Thread
kd> thread fcdbd020 THREAD fcdbd020 Cid a4.84 Teb:! 7ffde000 Win32Thread: e1b7b8e8 WAIT: (WrUserRequest) UserMode Non-Alertable fcdb9820 SynchronizationEventNot impersonatingOwning Process fcdbe2c0Wait Start TickCount 49551906 Elapsed Ticks: 14128Context Switch Count 3360 LargeStackUserTime 0: 00: 00.0290KernelTime 0: 00:!! 01.0041Start Address winlogon WinMainCRTStartup (0x01001674) Stack Init f7660000 Current f765fcc8 Base f7660000 Limit f765d000 Call 0Priority 15 BasePriority 15 PriorityDecrement 0 DecrementCount 0Kernel stack not resident.ChildEBP RetAddr Args to Childf765fce0 8042d61c 00000000 e1b7b8e8 00000001 nt KiSwapThread 0xc5f765fd08 a00159cb fcdb9820 0000000d 00000001 nt! KeWaitForSingleObject 0x1a1f765fd44 a0014f6c 000020ff 00000000 00000001 win32k! xxxSleepThread 0x183f765fd54 a0014f53 0006fde8 80461691 00000000 win32k! xxxWaitMessage 0xef765fd5c 80461691 00000000 00000000 00000018 win32k! NtUserWaitMessage 0xbf76 5fd5c 77e14b53 00000000 00000000 00000018 nt! KiSystemService 0xc40006fde0 77e23680 00000000 00000000 0000ffff USER32! NtUserWaitMessage 0xb0006fe14 77e23570 00070022 00000000 00000010 USER32! DialogBox2 0x2160006fe38 77e2381e 01000000 01024c10 00000000 USER32! InternalDialogBox 0xd10006fe58 77e3dcf8 01000000 01024c10 00000000 USER32! DialogBoxIndirectParamAorW 0x340006fe7c 01006052 01000000 00000578 00000000 USER32! DialogBoxParamW 0x3d0006feb8 01005fa8 000766b8 01000000 00000578 winlogon! TimeoutDialogBoxParam 0x270006fef0 010099c7 000766b8 01000000 00000578 winlogon! WlxDialogBoxParam 0x7b0006ff10 01004bdc 000766b8 00071fc8 000766b8 winlogon! BlockWaitForUserAction
0x3c0006ff28 010019e4 000766b8 00000005 0007366c winlogon! MainLoop 0x1bf0006ff58 0100179e 01000000 00000000 0007366c winlogon! WinMain 0x2a50006fff4 00000000 7ffdf000 000000c8 00000100 winlogon! WinMainCRTStartup 0x156Now, let's take a look at each piece of header information. We remember from before that the process address was actually An EPRocess Structure. Well, this is an ethread structure. this can be able!......................
So, Let's Break It Down.
Thread fcdbd020 CID A4.84 TEB: 7FFDE000 WIN32THREAD: E1B7B8E8 WAIT: (WRUSERREQUEST) Usermode Non-alertable fcdb9820 synchronizationEvent
The first address is the address of the ETHREAD structure as we mentioned. The second is the Process.Thread ID. The process ID is A4h, the thread ID is 84h. Thread IDs are useful when looking at deadlocks since the synchronization objects are owned by ........................... ..
The TEB. The Thread Environment Block is as mentioned in a previous tutorial. This has thread specific information as well as it points to the PEB, so threads can easily access certain information. The stack limit and end is here as well.! Teb or dt _TEB
. You obviously need be in the context of the process and thread to use! teb. If the TEB is NULL, this means it's a system thread. The thread is only executing in the kernel, it's not a user to Mode thread.The next is the "win32thread". What's this? This is a per-thread data structure what win32k.sys maintains.
The last part is the state of the thread. This thread is in a wait state. It's waiting in a non-alertable state in usermode. For more information on alertable, non-alertable, kernel verse. Usermode waits, please refer to MSDN's articles About KewaitFormultiPleObjects or Information About APC (Asynchronous Procedure Calls) .Not Impersonating
Whether this thread is impersonating or not. If you are familar with RPC, the server can impersonate the caller to perform operations on the caller's behalf or get information about the caller. If this thread was impersonating, you would see an impersonation token here which you COULD DO! TOKEN
on to get the information. Certain calls INTO The Kernel Will Look at this Impersonation Token if it is there and use it instead of the process' user token.Owning process fcdbe2c0
The own process' EPROCESS address. In this case, it's Winlogon. You may see weird things sometimes where a thread seems to have a different owner than it's being displayed in. The kernel may call KeAttachProcess () to perform actions in a different context.
Wait Start Tickcount 49551906 Elapsed Ticks: 14128Context Switch Count 3360 LargeStackUsertime 0:00:00.0290kernelTime 0: 00: 01.0041
Time this thread spent in usermode and kernel mode. If you are looking for a process hog, these are the values you look at to find the process, then the thread. "Elapsed Ticks" is how long it's been since this thread was executed. IF you're looking for a hog right after it happened, this is another field to look at, what threads have the least elapsed ticks.
Start Address Winlogon! WinMainCrtStartup (0x01001674)
This is the starting address of the thread.
Stack INIT F7660000 CURRENT F765FCC8 Base F7660000 LIMIT F765D000 Call 0
This Refers to the Kernel Stack, Not The User Mode Stack Which Can Be Found in The Teb. The Current Position of The Kernel Mode Stack and ITS Limits, And WHERE ITS.
Priority 15 basepriority 15 priorityDecremenet 0 DecrementCount 0
The priority of this three.
You may See, but this is a basic listing. If you notice, you! Lpc message
Now that we are in the context, we can do things like set break points, change memory, etc. Just remember that changing memory in a driver will change this memory for everyone. Setting breakpoints is the same way, you set the breakpoint for everyone On the system. this is a kernel debugger and the kernel mode drivers are Global to the system (or the session, for other certificate ".
What else can I do?
There're a lot of things that you can do, but like I mentioned before, we will just be covering some of the basics. It also depends on the area that you work in. For example, someone who is developing hardware drivers may never use or even look at anything in usermode or even that high up the driver stack. They may only know some of the hardware commands. Someone who only works with usermode applications or interaction may only use the kernel debugger for some extra information, or figure out Who's Calling with an AN RPC, ETC.
Page Table Entries
The only problem with using the kernel debugger or kernel dump is that some information may not be there, it may be paged out. So, how can we tell if memory is valid or paged out? In the x86 processor, there are levels of indirection when it comes to translating a virtual address to a physical address. There is a Page Directory Entry that points to a Page Table Entry. If you want to find the Page Table Entry, this is how you can do it. Remember, we already know HOW to Find Physical Addresses for Virtual Addresses Using The page directory of the process.
! PTE is the answer to find page Table Entries.
kd> pte 80461691 80461691 -! PDE at C0300804 PTE at C0201184 contains 00034163 contains 00461121 pfn 34 G-DA - KWV pfn 461 G - A - KRVkd> dc C0300804 L1c0300804 00034163kd> dc C0201184 L1c0201184 00461121
Just to show, if you dc those addresses, that's what you get. The Virtual Address is first added to the GDT / LDT and then it's translated. Part of the Virtual Address is taken as an offset to get the Page Directory Entry. Then next part of the address is taken to get the Page Entry Table. The last 3 nibbles of the virtual address are actually the last 3 nibbles of where the PTE points to. So, the PTE says 461xxx is the physical address. Let's find out and dump The Virtual and Physical Addresses:
KD>! DC 461691 # 461690 8BE58BD3 DFF1240D 3C558BFF 01289189 ..... .... u <.. (. # 4616a0 f7fa0000 00007045 06750002 016C45F6 .... EP .... U..L. # 4616b0 1d8b5874 FFDFF124 002E43C6 004A7B80 TX .. $ .... c ... {J. # 4616c0 DD8B4874 C7444389 003B5043 43C70000 TH ... cd.cp; .... C # 4616D0 00002338 3443C700 00000023 003043C7 8 # .... C4 # .... C0. # 4616e0 B9000000 00000001 059815FF FB508040 ............ at .p Dot # 4616f0 6a006a53 f132e801 FF59FFFC 40059C15 SJ.J..2 ... Y .... AT # 461700 44438b80 90abebfa 548bff8b 8b644c24 dot .CD ....... T $ Ld.kd> dc 80461691 80461691 0d8be58b ffdff124 893c558b 00012891 .... $ .... U <.. (.. 804616a1 45f7fa00 02000070 f6067500 74016c45. ..Ep .... u..l.t804616b1 241d8b58 c6ffdff1 80002e43 74004a7b x .. $ .... c ... {j.t804616c1 89dd8b48 43c74443 00003b50 3843c700 h ... cd.cp; .... C8804616D1 00000023 233443C7 C7000000 00003043 # .... c4 # .... C0..804616E1 01B90000 FF000000 40059815 53FB5080 ......... At.p Dot S804616F1 016A006A FCF132E8 15FF59FF 8040059C JJ.2 ... Y .... at .804617 01 FA44438B 8B90ABEB 24548BFF 1D8B644C Dot CD ....... t $ ld..ason you can see, it's true. The Physical ADDRESS DUMP IS A Little Different As It Dumped It at The Start of the Memory Rather Than 1 SO IT Was aligned, but you can see it it's the same information. If we had Dumped Them "DC 80461690", you would see the isy it.
You can Also Go Backwards, Take A Pte Address, And Find The Virtual Address It Belongs To.
KD>! PTE C020118480461000 - PDE AT C0201184 PTE AT C0201184 Contains 00034163 Contains 00461121 PFN 34 G-DA - KWV PFN 461 G - A - KRV
What happens on invalid addresses?
kd> pte 4000000040 -! PDE at C0300000 PTE at C0000000 contains 01800067 contains 00000000 pfn 1800 --DA -! UWV not validkd> dc C0300000 L1c0300000 01800067kd> dc C0000000 L1c0000000 00000000kd> pte 66740020 66740020 - PDE at C0300664 PTE at C0199D00 contains 00000000 unavailablekd> dc C0300664 L1c0300664 00000000kd> dc C0199D00 L1c0199d00 00a8d4c0 "Not Valid" means it's not a valid virtual address. (Some addresses may be "not valid" just because they have never been used yet, so they're not mapped I have found , at least that's my theory! For example, stack memory is mapped into your process but it's never been dirty, so why put it in the page file?) "Unavailable" means it's not available, but it is valid or it believes it to Be. OtherWise, The Address Is Valid. Sometimes, IF An Address IS "Unavailable", IT Will List A pagefile offset, and some will will not. Executables and binaries Are Done Using Memory Mapped Files. YO U can see this by doing! Memusage. That Means That, Unless, Would Not Be in the pagefile, and thus no pagefile offset.
There IS Also A! Sysptes That Can Dump All System Ptes.
Handle Information
Displaying handle information in the kernel is easy. Once you set your context to the correct process, just! Handle as you do in user mode, with an exception. You need to specify the process to dump the handles.
kd> handle 0 0 fcdbe2c0 processor number 0PROCESS fcdbe2c0 SessionId:! 0 Cid: 00a4 Peb: 7ffdf000 ParentCid: 008c DirBase: 0401d000 ObjectTable: fcdc39c8 TableSize: 354. Image: winlogon.exeHandle Table at e1b78000 with 354 Entries in use0004: Object: e1267030 GrantedAccess: 000f001f0008: Object: fcdee160 GrantedAccess: 00100003000c: Object: fcdee120 GrantedAccess: 001000030010: Object: fcdbe280 GrantedAccess: 00100003The first is the handle # used in usermode The second is the "Object" or kernel address of the object, and the last. Is The Access Granted to the Object. You May Also Specify Flags to Dump More Information As Seen Below:
kd> handle 0 ff fcdbe2c0 processor number 0PROCESS fcdbe2c0 SessionId:! 0 Cid: 00a4 Peb: 7ffdf000 ParentCid: 008c DirBase: 0401d000 ObjectTable: fcdc39c8 TableSize: 354. Image: winlogon.exeHandle Table at e1b78000 with 354 Entries in use0000: free handle0004: Object: e1267030 GrantedAccess: 000f001fObject: e1267030 Type: (fcebc580) Section ObjectHeader: e1267018 HandleCount: 1 PointerCount: 10008: Object: fcdee160 GrantedAccess: 00100003Object: fcdee160 Type: (fcebf420) Event ObjectHeader: fcdee148 HandleCount: 1 PointerCount: 1000c: Object: fcdee120 GrantedAccess: 00100003Object: fcdee120 Type: (fcebf420) Event ObjectHeader: fcdee108 HandleCount: 1 PointerCount: 10010: Object: fcdbe280 GrantedAccess: 00100003Object: fcdbe280 Type: (fcebf420) Event ObjectHeader: fcdbe268 HandleCount: 1 PointerCount: 10014: Object: fcec6c50 GrantedAccess : 00000003 Object: FCEC6C50 TYPE: (FCEE4B40) Directory ObjectHeader: FCEC6C38 HandleCount: 15 PointerCount: 44 Directory Object: fcebfab0 Name: KnownDlls HashBucket [00]: e137ca00 Section 'gdi32.dll' e134b900 Section 'imagehlp.dll' e13154a0 Section 'url.dll' HashBucket [02]: e13dee00 Section 'MPR.dll 'HashBucket [03]: e135b040 Section' ole32.dll 'e135d2a0 Section' urlmon.dll 'HashBucket [04]: e1373600 Section' lz32.dll 'e138bde0 Section' olesvr32.dll 'HashBucket [06]: e137ef40 Section' shell32.dll 'E12c7880 section' WLDAP32.DLL '
HashBucket [09]: e13126e0 Section 'user32.dll' e13118a0 Section 'version.dll' HashBucket [10]: e135af80 Section 'olecli32.dll' HashBucket [14]: e13713e0 Section 'MSASN1.DLL' HashBucket [16]: e1314c60 Section 'COMCTL32.DLL' fcde6c50 SymbolicLink 'KnownDllPath' HashBucket [17]: e13171c0 'CRYPT32.dll' HashBucket [18] Section: e1316e60 Section 'advapi32.dll' e13583a0 Section 'oleaut32.dll' HashBucket [19]: e135c980 Section 'SHLWAPI .DLL 'e12c2fc0 Section' wow32.dll 'e1316460 Section' olecnv32.dll 'HashBucket [23]: e131a520 Section' comdlg32.dll 'HashBucket [26]: e1317b80 Section' wininet.dll 'HashBucket [27]: e12d5fc0 Section' olethk32 .dll 'hashbucket [28]: E124C800 Section' msvcrt.dll 'hashbucket [31]: E134DBE0 section' rpcrt4.dll 'hashbucket [32]: E130B460 Section' kene l32.dll'0018: Object: fccc3c88 GrantedAccess: 00100020 (Inherit) Object: fccc3c88 Type: (fced7c40) File ObjectHeader: fccc3c70 HandleCount: 1 PointerCount: 1 Directory Object: 00000000 Name: / WINNT / system32 {HarddiskVolume1} 001c: Object: fcdfb730 GrantedAccess: 000f000fObject: fcdfb730 Type: (fcee4b40) Directory ObjectHeader: fcdfb718 HandleCount: 14 PointerCount: 18 Directory Object: fcebfab0 Name: windows HashBucket [04]: e1b76d40 Port 'SbApiPort' HashBucket [09]: e1b65a00 Port 'ApiPort'
HashBucket [32]: fcdc1750 Directory 'WindowStations'0020: Object: fcdb9de0 GrantedAccess: 00100003Object: fcdb9de0 Type: (fcebf420) Event ObjectHeader: fcdb9dc8 HandleCount: 1 PointerCount: 10024: Object: e1b7be30 GrantedAccess: 001f0001 (Protected) Object: e1b7be30 Type: (fceb7640) Port ObjectHeader: e1b7be18 HandleCount: 1 PointerCount: 180028: Object: fceca3c0 GrantedAccess: 00000001Object: fceca3c0 Type: (fcebda40) Mutant ObjectHeader: fceca3a8 HandleCount: 15 PointerCount: 16 Directory Object: fcebfab0 Name: NlsCacheMutant002c: Object: fcdb99a0 GrantedAccess: 00100003Object: FCDB99A0 TYPE: (FCEBF420) Event ObjectHeader: fcdb9988 handlecount: 1 Pointercount: 1you can also, instead of using 0, Specify an actual handle value to just list one handle.
kd> handle 2c ff fcdbe2c0 processor number 0PROCESS fcdbe2c0 SessionId:! 0 Cid: 00a4 Peb: 7ffdf000 ParentCid: 008c DirBase: 0401d000 ObjectTable: fcdc39c8 TableSize: 354. Image: winlogon.exeHandle Table at e1b78000 with 354 Entries in use002c: Object: fcdb99a0 GrantedAccess: 00100003Object: fcdb99a0 type: (FCEBF420) Event ObjectHeader: fcdb9988 handlecount: 1 Pointercount: 1
There are other methods to dump the object You notice there's an Object:. And an address, object can also be used on that address All the kernel debugger really does when finding handle information is look for that ObjectTable address, and find the handle!. Table, Then Just Dump The Information Since It Knows The Data Structure.
Let's attempt to interpret this table manually. First, The ObjectTable IS AT FCDC39C8.
KD> DC FCDC39C8FCDC39C8 00000000 00000162 E1B78000 FCDBE2C0 .... b ......... FCDC39D8 000000A4 0000016F 00000300 FCDBE0A8 .... o ........... FCDC39E8 fcdbe5a8 000000000000000000000000 ................ fcdc39f8 00000000 000,000 00000000 000,000 ................ fcdc3a08 00000000000000 00000000 00000000 ........ ....... FCDC3A18 00000000 FCDB079C FCDC42BC 00040000 ......... B ... FCDC3A28 00000000 FCDC3A2C FCDC3A2C 0030005C ....,: ..,: ../. 0. fcdc3a38 00300030 00000030 07018004 69436d4d 0.0.0 ....... MmCikd> 162Evaluate expression:? 354 = 00000162You notice that I dumped a variable that basically specified the number of handles in use You also notice that the next value is the address. That! Handle Said Was The Handle Table. Now, Let's Dump this.
KD> DC E1B78000 E1B78000 E1B78400 00000000 00000000 00000000 .............. E1B78010 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000 ................ E1B78030 000,000 00000000 00000000 000,000 ................ E1B78040 00000000000000 00000000 00000000 ....... ......... E1B78050 000 million 00000000 000,000 00000000 .................. E1B78060 000000 000,000 00000000 000,00000 ............... .e1b78070 @0000000000 000000000000000000 .............. KD> DC E1B78400 E1B78400 E1B78800 E1D47000 E1D47800 00000000 ..... P ... x ... E1B78410 00000000 00000000 00000000 00000000 ................ E1B78420 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000 00000000 ... .......... E1B78440 00000000 000,000 00000000 000,00000 ... ..e1b78460 00000000 00000000 000,000 00000000 ................ E1B78470 00000000 0000 0000 00000000 000,000 .............. KD> DC E1B78800 E1B78800 000000 00000001 61267018 000F001F ......... P & A .... E1B78810 7cdee148 00100003 7cdee108 00100003 h .. | ....... | .... E1B78820 7CDBE268 00100003 7CEC6C38 00000003 h .. | ....8l. | .... E1B78830 7CCC3C72 00100020 7CDFB718 000f000f r <.. ... E1B78840 7CDB9DC8 00100003 61B7BE19 001F0001 ... | ....... A .... E1B78850 7CECA3A8 00000001 7CDB9988 0010000003 ... | ....... | .... E1B78860 6125DC8 000F003F 6125DCD8 000F001F ^? a? .....% a ... e1b78870 7CDB9809 001F0003 7CDC3778 0002000F ... | .... x7. | ....
Now, I dump the address and it looks like there's another address. So, I dump that and looks like there's 3 addresses now, so I dump the first one. What did I find? Well, I found what appears to be the "table ". The second DWORD of every pair appears to match the access mask of the objects in order of the dump, if you look above. 000f001f, followed by 00100003, matches exactly. Now, how do the first numbers relate to the object? If I dump them, they are not valid addresses! There are a few ways we could approach this dilemma. The first would be to debug the kernel debugger and figure out where it's going to translate this. The second would be to make a call into the kernel with one of these objects and figure out what it's doing to translate them. The last would obviously be attempt everything we can think of to translate it back. Well, let's try something. Let's set a "ba r1" on one of those locations And Hope Winlogon Attempts to Use it. we Could Also Write Our Own Application, But I ' ma bit lazy. We need to find an object we think Winlogon will attempt to use often though.I actually think it may be easier to do this with an application like Notepad. Find handles it has open, then set break points on those, and Close It. It will new to close those handles!
We Have Already Figured Out That if this location is 0, it's a "free" handle.
NOW, I'VE SET 4 "BA R1
" in the notepad object table. We can only set a maximum of 4, so i 市, I then close notepad. I End Up in a function called ExmapHandletopointer.eax = e1dfb8f0 ebx = 00000000 ecx = e1dfb800 edx = 00000000 esi = 61caf508 edi = fb6e6bd0eip = 804b3971 esp = fb6e6af8 ebp = fb6e6b08 iopl = 0 nv up ei pl zr na po nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00000246nt ExLockHandleTableEntry 0xe: 804b3971 85f6 test esi, esikd>; p; reax = e1dfb8f0 ebx = 00000000 ecx = e1dfb800 edx = 00000000 esi = 61caf508 edi = fb6e6bd0eip = 804b3973 esp = fb6e6af8 ebp = fb6e6b08 iopl =! 0 nv up ei pl nz na pe nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs 0030 gs = 0000 efl = 00000202nt = ExLockHandleTableEntry 0x10:! 804b3973 8975f8 mov [ebp-0x8], esi ss: 0010: fb6e6b00 = e1dfb800kd>; eax = e1dfb8f0 ebx = 00000000 ecx = e1dfb800 edx = 00000000 esi = 61caf508 edi = fb6e6bd0eip = 804b3976 esp = fb6e6af8 ebp = fb6e6b08 iopl = 0 nv up ei pl nz na pe nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 GS = 0000 EFL = 00000202NT! EXLOCKHANDLETABLEENTRY 0X13: 804B3976 0F8449F0FFFF JE NT! EXLOCKHANDLETABLFF JE NT! EXLOCKHANDLETABLEENTRY 0X5C (804B29C5) [BR = 0] kd>; EA x = e1dfb8f0 ebx = 00000000 ecx = e1dfb800 edx = 00000000 esi = 61caf508 edi = fb6e6bd0eip = 804b397c esp = fb6e6af8 ebp = fb6e6b08 iopl = 0 nv up ei pl nz na pe nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs = !! 0030 gs = 0000 efl = 00000202nt ExLockHandleTableEntry 0x15: 804b397c 0f8eabdb0000 jle nt ExLockHandleTableEntry 0x31 (804c152d) [br = 0] kd>; eax = e1dfb8f0 ebx = 00000000 ecx = e1dfb800 edx = 00000000 esi =
61caf508 edi = fb6e6bd0eip = 804b3982 esp = fb6e6af8 ebp = fb6e6b08 iopl = 0 nv up ei pl nz na pe nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00000202nt ExLockHandleTableEntry 0x17:! 804b3982 8bc6 mov eax, esikd>; eax = 61caf508 ebx = 00000000 ecx = e1dfb800 edx = 00000000 esi = 61caf508 edi = fb6e6bd0eip = 804b3984 esp = fb6e6af8 ebp = fb6e6b08 iopl = 0 nv up ei pl nz na pe nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00000202nt ExLockHandleTableEntry 0x19: 804b3984 0d00000080 or eax, 0x80000000kd>; eax = e1caf508 ebx = 00000000 ecx = e1dfb800 edx = 00000000 esi = 61caf508 edi = fb6e6bd0eip = 804b3989 esp = fb6e6af8 ebp! = fb6e6b08 iopl = 0 nv up ei ng nz na pe nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00000282nt ExLockHandleTableEntry 0x1e:! 804b3989 8945fc mov [ebp-0x4], eax ss: 0010: FB6E6B04 = E1DFB800KD>; EAX = E1CAF508 EBX = 00000000 ECX = E1DFB800 EDX = 00000000 ESI = 61caf508 EDI = FB6E6BD0EIP = 804B398C esp = fb6e6af8 ebp = fb6e6b08 iopl = 0 nv up ei ng nz na pe nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00000282nt ExLockHandleTableEntry 0x21:! 804b398c 8b45f8 mov eax, [ebp- 0x8] ss: 0010: fb6e6b00 = 61caf508kd>; eax = 61caf508 ebx = 00000000 ecx = e1dfb800 edx = 00000000 esi = 61caf508 edi = fb6e6bd0eip = 804b398f esp = fb6e6af8 ebp = fb6e6b08 iopl = 0 nv up ei ng nz na pe nccs =
0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00000282nt ExLockHandleTableEntry 0x24: 804b398f 8b4d0c mov ecx, [ebp 0xc] ss: 0010: fb6e6b14 = e1dfb8f0kd>; eax = 61caf508 ebx = 00000000 ecx! = e1dfb8f0 edx = 00000000 esi = 61caf508 edi = fb6e6bd0eip = 804b3992 esp = fb6e6af8 ebp = fb6e6b08 iopl = 0 nv up ei ng nz na pe nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs 0030 gs = 0000 efl = 00000282nt = ! ExLockHandleTableEntry 0x27: 804b3992 8b55fc mov edx, [ebp-0x4] ss: 0010: fb6e6b04 = e1caf508kd>; eax = 61caf508 ebx = 00000000 ecx = e1dfb8f0 edx = e1caf508 esi = 61caf508 edi = fb6e6bd0eip = 804b3995 esp = fb6e6af8 ebp = fb6e6b08 iopl = 0 nv up ei ng nz na pe nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00000282nt ExLockHandleTableEntry 0x2a:! 804b3995 0fb111 cmpxchg [ecx], edx ds: 0023: e1dfb8f0 = 61caf508kd>; BreakPoint 1 Hiteax = 61caf508 EBX = 00000000 ECX = E1DFB8F0 EDX = E1CAF508 ESI = 61caf508 EDI = FB6E6BD0EIP = 804B3998 ESP = FB6E6AF8 EBP = FB 6e6b08 iopl = 0 nv up ei pl zr na po nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00000246nt ExLockHandleTableEntry 0x2d:! 804b3998 3bc6 cmp eax, esikd>; eax = 61caf508 ebx = 00000000 ecx = e1dfb8f0 edx = e1caf508 esi = 61caf508 edi = fb6e6bd0eip = 804b399a esp = fb6e6af8 ebp = fb6e6b08 iopl = 0 nv up ei pl zr na po nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs =
!! 0000 efl = 00000246nt ExLockHandleTableEntry 0x2f: 804b399a 0f858ddb0000 jne nt ExLockHandleTableEntry 0x31 (804c152d) [br = 0] kd>; eax = 61caf508 ebx = 00000000 ecx = e1dfb8f0 edx = e1caf508 esi = 61caf508 edi = fb6e6bd0eip = 804b39a0 esp = fb6e6af8 ebp = fb6e6b08 iopl = 0 nv up ei pl zr na po nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs 0030 gs = 0000 efl = 00000246nt = ExLockHandleTableEntry 0x60: 804b39a0 b001 mov al, 0x1kd>; eax =! 61caf501 ebx = 00000000 ecx = e1dfb8f0 edx = e1caf508 esi = 61caf508 edi = fb6e6bd0eip = 804b39a2 esp = fb6e6af8 ebp = fb6e6b08 iopl = 0 nv up ei pl zr na po nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00000246nt ExLockHandleTableEntry 0x62:! 804b39a2 5e pop esikd>; eax = 61caf501 ebx = 00000000 ecx = e1dfb8f0 edx = e1caf508 esi = e1dfb8f0 edi = fb6e6bd0eip = 804b39a3 esp = fb6e6afc ebp = fb6e6b08 iopl = 0 nv up ei pl zr Na PO nccs = 0008 ss = 0010 DS = 0023 ES = 0023 fs = 0030 GS = 0000 EFL = 00000246NT! EXLOCKHANDLET ableEntry 0x63: 804b39a3 5b pop ebxkd>; eax = 61caf501 ebx = 00000078 ecx = e1dfb8f0 edx = e1caf508 esi = e1dfb8f0 edi = fb6e6bd0eip = 804b39a4 esp = fb6e6b00 ebp = fb6e6b08 iopl = 0 nv up ei pl zr na po nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00000246nt ExLockHandleTableEntry 0x64: 804b39a4 c9 leavekd>; eax = 61caf501 ebx = 00000078 ecx = e1dfb8f0 edx = e1caf508 esi =!
e1dfb8f0 edi = fb6e6bd0eip = 804b39a5 esp = fb6e6b0c ebp = fb6e6bc4 iopl = 0 nv up ei pl zr na po nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00000246nt ExLockHandleTableEntry 0x65:! 804b39a5 c20800 ret 0x8kd>; eax = 61caf501 ebx = 00000078 ecx = e1dfb8f0 edx = e1caf508 esi = e1dfb8f0 edi = fb6e6bd0eip = 804b3a17 esp = fb6e6b18 ebp = fb6e6bc4 iopl = 0 nv up ei pl zr na po nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00000246nt ExMapHandleToPointer 0x1e: 804b3a17 f6d8 neg alkd>; eax = 61caf5ff ebx = 00000078 ecx = e1dfb8f0 edx = e1caf508 esi = e1dfb8f0 edi = fb6e6bd0eip = 804b3a19 esp = fb6e6b18 ebp = fb6e6bc4 iopl =! 0 nv up ei ng nz ac po cycs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00000297nt ExMapHandleToPointer 0x20:! 804b3a19 1bc0 sbb eax, eaxkd>; eax = ffffffff ebx = 00000078 ecx = E1DFB8F0 EDX = E1CAF508 ESI = E1DFB8F0 EDI = FB6E6BD0EIP = 804B3A1B ESP = FB6E6B18 EBP = FB6E6BC4 IOPL = 0 NV Up EI NG NZ ac po cycs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00000297nt ExMapHandleToPointer 0x22: 804b3a1b 23c6 and eax, esikd>; eax = e1dfb8f0 ebx = 00000078 ecx = e1dfb8f0 edx = e1caf508 esi =! E1DFB8F0 EDI = FB6E6BD0EIP = 804B3A1D ESP = FB6E6B18 EBP = FB6E6BC4 IOPL = 0 NV UP EI Ng NZ NA PO NCCS = 0008 SS = 0010 DS = 0023 ES = 0023 fs = 0030 GS = 0000 EFL =
! 00000286nt ExMapHandleToPointer 0x24: 804b3a1d 5e pop esikd>; eax = e1dfb8f0 ebx = 00000078 ecx = e1dfb8f0 edx = e1caf508 esi = 00000000 edi = fb6e6bd0eip = 804b3a1e esp = fb6e6b1c ebp = fb6e6bc4 iopl = 0 nv up ei ng nz na po nccs = 0008 ss = 0010 ds = 0023 es = 0023 fs = 0030 gs = 0000 efl = 00000286nt ExMapHandleToPointer 0x25: 804b3a1e c20800 ret 0x8kd>; handle 78 ff fcc654e0 processor number 0PROCESS fcc654e0 SessionId:!! 0 Cid: 03ac Peb: 7ffdf000 ParentCid: 02e0 DirBase: 03cc6000 ObjectTable: fcc59988 TableSize: 16. Image: NOTEPAD.EXEHandle Table at e1dfb000 with 16 Entries in use0078: Object: e1caf520 GrantedAccess: 000f003f (Locked) Object: e1caf520 Type: (fcebc160) Key ObjectHeader: e1caf508 HandleCount: 1 PointerCount : 1 Directory Object: 00000000 Name: / REGISTRY / USERSo, what have we accomplished We notice that we index into the handle table and find that weird number that weird number is then replaced by the object hea.. DER "E1CAF508". The Actual Object IS At ObjectHeader 18H, SO E1CAF508 18 = E1CAF520.
KD>! Object E1CAF520 Object: E1CAF520 TYPE: (FCEBC160) Key ObjectHeader: E1CAF508 Handlecount: 1 Pointercount: 1 Directory Object: 00000000 Name: / Registry / User
Now, What Was? SO Simple, "OR EAX, 0x80000000". Let's Give It A Try Now ON Some of Those Other Objects. WE HAD 7CDEE148, AND We get fcdee148. Add 18h, And We Should Be Able to! Object.
KD>! Object fcdee160 Object: fcdee160 Type: (fcebf420) Event ObjectHeader: fcdee148 handlecount: 1 Pointercount: 1
So, That's How Simple It Is.Heap Information
The heap for a particular process can be displayed from kernel mode. Set your context to that process and dump the PEB. The PEB will point to the number of heaps and a heap list which can be used. Each heap then has a VirtualAlloc list that can be used as a linked list. This can all be done in usermode as well, nothing special here. The only difference is that you may not be able to display all of the information if it's paged out. Anyway, luckily you do not Even Have to Go Through all this. You can simply! Heap in the kernel! Just set your context and just use! heap as normal. You May Refer Back to Debug Tutorial Part 3 To Learn More About Heaps.
Pools
Kernel drivers generally use memory from the Paged and Non-Paged pool. You can take an address and do! Pool to determine its size, tag information, etc. If you develop drivers, you know that when you allocate memory in the kernel, it comes from a global pool, not per-process. So if you corrupt memory, you can end up corrupting other drivers in the system. When a driver allocates memory, they generally specify a "pool tag" which is then associated with the memory. This Is How We can Tell What Driver Allocated What Memory. There IS Also! Poolfind * To Find Pool Based on a pool tag. You can look online or other place to find information About a pool tag and what it is it.
For example, let's do! Pool on the objects wee wele handling before.
KD>
!
pool e1caf520 e1caf000 size: 60 previous size: 0 (Allocated) NtFd e1caf060 size: 20 previous size: 60 (Free) .... e1caf080 size: 40 previous size: 20 (Allocated) NtFs e1caf0c0 size: 20 previous size: 40 ( Free) Key e1caf0e0 size: 20 previous size: 20 (Allocated) CMVI e1caf100 size: 40 previous size: 20 (Allocated) CMVa e1caf140 size: 20 previous size: 40 (Free) CMVa e1caf160 size: 40 previous size: 20 (Lookaside) Key (Protected) e1caf1a0 size: 20 previous size: 40 (Allocated) Ntf0 e1caf1c0 size: 40 previous size: 20 (Allocated) IoNm e1caf200 size: 20 previous size: 40 (Free) Gla8 e1caf220 size: 40 previous size: 20 (Allocated ) CMVa e1caf260 size: 40 previous size: 40 (Allocated) CMVa e1caf2a0 size: 20 previous size: 40 (Free) Key e1caf2c0 size: 60 previous size: 20 (Allocated) Ntfo e1caf320 size: 40 previous size: 60 (Allocated) CMNb (Protected) E1CAF360 SIZE: 40 previous size: 40 (Allocated) CMIn (Protected) e1caf3a0 size: a0 previous size: 40 (Allocated) SeSd e1caf440 size: 20 previous size: a0 (Free) Usqm e1caf460 size: 40 previous size: 20 (Allocated) CMVa e1caf4a0 size : 40 previous size: 40 (Allocated) CMVa e1caf4e0 size: 20 previous size: 40 (Allocated) Ntf0 * e1caf500 size: 40 previous size: 20 (Allocated) * Key (Protected) e1caf540 size: 20 previous size: 40 (Free) Gla8 e1caf560 size: 40 previous size: 20 (Allocated) CMVa e1caf5a0 size: 20 previous size: 40 (Free) SYSA e1caf5c0 size: 20 previous size: 20 (Allocated) CMNb (Protected) e1caf5e0 size: 40 previous size:
20 (Allocated) CMNb (Protected) e1caf620 size: 40 previous size: 40 (Allocated) CMNb (Protected) e1caf660 size: a0 previous size: 40 (Allocated) CMDa e1caf700 size: 40 previous size: a0 (Allocated) NtFL e1caf740 size: 40 previous size: 40 (Allocated) CMNb (Protected) e1caf780 size: a0 previous size: 40 (Allocated) MmSt e1caf820 size: 40 previous size: a0 (Allocated) CMNb (Protected) e1caf860 size: 20 previous size: 40 (Allocated) ObDi e1caf880 size: 20 previous size: 20 (Free) CMDa e1caf8a0 size: 20 previous size: 20 (Allocated) CMVI e1caf8c0 size: 40 previous size: 20 (Allocated) IoNm e1caf900 size: 80 previous size: 40 (Allocated) FSim e1caf980 size: 20 previous size: 80 (Free) MmSt e1caf9a0 size: 60 previous size: 20 (Allocated) CMDa e1cafa00 size: 3e0 previous size: 60 (Allocated) NtfF e1cafde0 size: 60 previous size: 3e0 (Allocated) CMDa e1cafe40 size: 40 Previous Size: 60 (All ocated) CMVa e1cafe80 size: 40 previous size: 40 (Allocated) CMVa e1cafec0 size: 80 previous size: 40 (Allocated) FSim e1caff40 size: 40 previous size: 80 (Allocated) Key (Protected) e1caff80 size: 80 previous size: 40 (Allocated) GLA AT
The Kernel Debugger will display the allocation with an "*" dot All the kernel debugger does is it takes the address, and takes off the last 3 numbers and replace them with 0. In this case, e1caf520, became e1caf000. It then simply walks the pool from there. It's a linked list, just like the user mode heap, except it does not go by pointer links but rather by size links. The sizes point forward and backward. In the above case, the sizes are shifted by 5 , and the sizes are represented bytes. Take Take.kd> DB E1CAFF80 E1CAFF80 02 81 02 04 47 6C 61 40-59 01 10 08 00 00 00 .... GLA AT Y DOT .... ..e1caff90 00 00 00 80 00 00 00 00-07 00 00 00 00 00 00 00 ................ e1caffa0 00 00 00 00 14 00 00 80-8b 00 00 00 f0 00 75 00 .............. u.e1caffb0 00 00 00 00 d4 d0 c8 00-00 00 00 00 00 00 00 00 ............ .... e1caffc0 01 00 00 00 00 00 00 ................ E1CAFFD0 08 00 00 C8 D0 D4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 D4 D0 C8 00 ........ ........ E1caffe0 01 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 74-01 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000 = 000040kd>? 04 << 5EVALUATE Expression: 128 = 00000080
The flags in the middle specify a SHORT that tells whether the allocation is free or used, for example. The tag is the next 4 bytes, and then is the allocated memory. 8 byte header, just like in user mode. (Of course, there is a large header in usermode for large allocations in the "VirtualAlloc" list of the heap.) of course, the kernel can allocate large blocks of memory as well in the pool, how does that work? You just get a few pages of memory not allocated from a pool, you get your own address that looks like "e1caf000", and unlike doing this in usermode that has a 32 byte header information with size, there is no header information.Ready Threads
Ready Threads Are Threads That Are Ready to Be Executed, in a ready state..
KD>! Ready 0Ready Threads At Priority 0 Thread Fcebf020 CID 8.4 TEB: 00000000 Win32thread: 00000000 Ready
Just! Ready will display the entire thread information. In windows XP / 2003, there is also a! Running which will show the currently running threads on multiprocessor systems. Also, ~
CPU ID
There Are Other Things you can do like! Cpuid.
KD>! CPUIDCP F / M / S Manufacturer MHz 0 5, 8, 12 Authenticamd 350
Virtual memory usage
To Display Memory Usage, You CAN Use! VM.
KD>
!
VM *** Virtual Memory Usage *** Physical Memory: 31613 (126452 KB) Page File: / ??
/C:/pagefile.sys Current: 184320Kb Free Space: 180464Kb Minimum: 184320Kb Maximum: 368640Kb Available Pages: 17617 (70468 Kb) ResAvail Pages: 26203 (104812 Kb) Modified Pages: 543 (2172 Kb) NonPagedPool Usage: 677 (2708 kb) NonPagedPool Max: 12528 (50112 kb) PagedPool 0 Usage: 2993 (11972 kb) PagedPool 1 Usage: 439 (1756 kb) PagedPool 2 Usage: 451 (1804 kb) PagedPool Usage: 3883 (15532 kb) PagedPool Maximum: 25600 ( 102400 KB) Shared Commit: 324 (1296 KB) Special Pool: 0 (0 KB) Free System Ptes: 14442 (57768 KB) Shared Process: 1125 (4500 kB) PagedPool Commit: 3883 (15532 KB) Driver Commit: 912 (3648 KB) Committed Pages: 11945 (47780 KB) Commit limit: 73862 (295448 KB) Total Private: 5662 (22648 kB) 00A4 Winlogon.exe 1358 (5432 KB) 00D8 Services.exe 587 (2348 KB) 02E4 Explorer.exe 557 (2228 KB) 01B4 Spoolsv.exe 503 (2012 KB) 00E4 LSASS.EXE 446 (1784 KB) 01E8 SVCHOST.EXE 412 (1648 KB) 00A8 CSRS.EXE 329 (1316 KB) 0374 MspAint.exe 303 (1212 KB) 008C SMSS.EXE 273 (1092 KB) 018C SVCHOST.EXE 227 (908 KB) 0290 Winvnc.exe 164 (656 kB) 0264 WinMgmt.exe 154 (616 kB) 02E0 cmd.exe 143 (572 kB) 0228 MStask.exe 141 (564 kB) 0210 Regsvc.exe 59 (236 KB) 0008 System 6 (24 kB)
If you're looking for "is the system out of memory", you basically want to look at the "committed pages" versus the "commit limit". The committed pages are how much memory is currently being used and the commit limit is how Much Total Memory Can Be Used.The Next Tool That Can Be Used Is! Memusage Which Builds A Map of All Memory Mapped Files on The System.
KD>
!
MEMUSAGE Loading PFN DatabaseLoading: 3163 (12652 KB) Free: 20 (80 kB) Standby: 14434 (57736 KB) Modified: 543 (2172 KB) ModifiedNowrite: 0 (0 kB) Active / Valid: 13567 ( 54268 KB) Transition: 0 (0 KB) UNKNOWN: 0 (0 KB) Total: 31727 (126908 KB) Building Kernel Map Finished Building Kernel Map Usage Summary (in KB):
Control Valid Standby Dirty Shared Locked PageTables namefce7a3c8 468 16776 0 0 0 0 No Name for Filefccf6148 0 2876 0 0 0 0 mapped_file (CIM.REP) fcd43388 0 96 0 0 0 0 mapped_file (chord.wav) fcc40568 0 48 0 0 0 0 Mapped_file (index.dat) FCC64308 0 2420 0 0 0 mapped_file (mshtml.dll) FCCE8B28 0 188 0 0 0 0 Mapped_file (rasppp.dll) FCC76728 0 208 0 0 0 0 Mapped_file (h323.tsp) FCCEC3C8 220 92 0 0 0 0 mapped_file (Netcfgx.dll) FCE48E88 1152 180 0 0 0 mapped_file (win32k.sys) fcde4f28 16 460 0 0 0 mapped_file (wininet.dll) FCC7F808 0 32 0 0 0 Mapped_file (Wbemcomn.dll) FCC4D7A8 0 388 0 0 0 0 mapped_file (ntvdm.exe) FCCEB128 80 200 0 0 000 mapped_file (rasdlg.dll) FCDE5A08 200 896 0 120 0 0 mapped_file (shell32.dll) fceca188 3196 1280 0 0 0 0 no name for filefcd88 108 36 0 0 0 0 mapped_file (Tapsrv.dll) FCDA5A28 8 204 0 0 0 0 Mapped_file (msgina.dll) FCC83348 0 300 0 0 0 0 mapped_file (wbemess.dll) fcce9248 40 756 0 0 0 0 mapped_file (shdocvw.dll) fcd10a68 0 32 0 0 0 0 mapped_file (notepad.exe) fcd7dd08 0 504 0 0 0 0 mapped_file (jscript.dll) fcc7cc48 0 32 0 0 0 0 Mapped_file (mswsock.dll) FCC4A4A8 0 116 0 0 0 Mapped_file (DXTMSFT.
DLL) FCCE95E8 32 40 0 0 000 mapped_file (ntmarta.dll) FCCE89A8 0 12 0 0 000 mapped_file (ntlsapi.dll) FCC821A8 0 68 0 0 0 Mapped_file (modemui.dll) FCC7A4E8 16 196 0 0 0 mapped_file msi.dll) FCCEC688 112 32 0 0 0 Mapped_file (rasmans.dll) FCC4EA68 240 64 0 0 0 0 mapped_file (mspaint.exe) FCD64BA8 0 32 0 0 0 Mapped_file (Tapsrv.dll) FCDE4AA8 0 36 0 0 0 0 0 0 Mapped_file (mpr.dll) FCDC33A8 164 64 0 0 0 mapped_file (winsrv.dll) FCCEEB08 0 32 0 0 000 mapped_file (wkssvc.dll) FCCF3ee8 0 32 0 0 000 mapped_file (Winlogon.exe) FCC54A28 112 36 0 0 0 0 mapped_file (cmd.exe) FCC60408 0 148 0 0 000 mapped_file (DXTRANS.DLL) FCCEE4A8 0 32 0 0 0 0 Mapped_file ( Cryptsvc.dll) FCC7FE08 0 32 0 0 0 Mapped_file (spoolsv.exe) FCD7E788 80 512 0 0 0 0 Mapped_file (browseui.dll) FCC7ED28 0 0 4 0 0 Mapped_file (Software.log) FCC7F128 40 264 0 8 0 0 Mapped_file (netshell.dll) FCC51AC8 0 32 0 0 0 mapped_file (jscript.dll) ...-------- 12 0 0 ----- ----- 8 PageFile Section (78a7) - ------- 456 0 0 ----- ----- 72 Process (mstask.exe) -------- 452 536 116 --------- 92 Process (lsass.exe) -------- 140 0 0 ----- ----- 28 Process (smss.exe) -------- 88 452 0 ----- ---- 52 Process (Winmgmt.
EXE) -------- 236 0 0 ----- ----- 36 Process (regsvc.exe) -------- 520 0 0 ----- ---- - 72 Process (Winvnc.exe) -------- 12 0 0 ----- ----- 8 Pagefile Section (6933) -------- 1320 100 0 ---- - 0 ----- Driver (ntoskrnl.exe) -------- 60 16 0 ----- 0 ----- Driver (HAL.DLL) ... as you can see, all files that are loaded in the system are loaded as memory mapped files. This means the Operating System uses the copy on disk to continuously load it into memory. It does not copy it into memory and then put it in the page file. to get Information ON One of these Mapped Files, Such As How Many References Are Currently Being Mapped, ETC., USE! CA.
KD>
!
ca fcdee008 ControlArea at fcdee008 Segment: e1b764c8 Flink 0 Blink: 0 Section Ref 1 Pfn Ref 1e Mapped Views: 1 User Ref 2 Subsections 4 Flush Count: 0 File Object fcdbe728 ModWriteCount 0 System Views: 0 WaitForDel 0 Paged Usage 100 NonPaged Usage c0 Flags (90000a0) Image File HadUserReference Accessed File: /WINNT/system32/winlogon.exeSegment at e1b764c8: ControlArea fcdee008 Total Ptes 0 NonExtendPtes: 2d WriteUserRef 2d Extend Info 0 SizeOfSegment: 2d000 Image Base 0 Committed e1b765b8 Based Addr 2d36f438PTE Template: 3 Image commit 1000000 Image info: 0 Protoptes E1B76500Subsection 1 Dot At fcdee040 Controlarea: fcdee008 Starting Sector 0 Number of Sectors 2 Base PTE E1B76500 Ptes In Subsect 1 Unused Ptes 0 Flags 15 Sector Offset 0 Protection 1 ReadOnly SubsectionStatic Subsection 2 dot at fcdee060 ControlArea: fcdee008 Starting Sector 2 Number Of Sectors ff Base Pte e1b76504 Ptes In subsect 20 Unused Ptes 0 Flags 35 Sector Offset 0 Protection 3 ReadOnly SubsectionStatic Subsection 3 dot at fcdee080 ControlArea: fcdee008 STARTING SECTOR 101 NUMBER OF SECTORS 11 BASE PTE E1B76584 Ptes in Subsect 3 Unused Ptes 0 Flags 55 Sector Offset 0 Protection 5 Readonly SubsectionStatic Subsection 4 Dot At fcdee0A0 Controlarea:
fcdee008 Starting Sector 112 Number Of Sectors 48 Base Pte e1b76590 Ptes In subsect 9 Unused Ptes 0 Flags 15 Sector Offset 0 Protection 1 ReadOnly SubsectionStaticYou will notice there is only one mapped view for Winlogon on this machine dot Do not worry if it says 0 views And The Process Is Running; Look on The List, There May Being Used.
Conclusion
This is a simple introduction to the kernel debugger and a few things that you can do While I have not covered everything, I hope that you now know at least the basics and can navigate it There's always the help and http:.. // ! www.google.com/ You learn something new everyday; one person can not know everything, but they can try I tried to make sure the information presented is as accurate as possible, but things can get through, so let me know! I missed Something or Misreprepreprepresented Something. I May Add More Kernel Debugging Tutorials in The Future, WITH OTHER TOPICS. We Didn't Even Cover IRPS!
