lib0023.html

Memory Management—Algorithms and implementation in C/C++ Introduction Chapter 1 - Memory Manag

</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">KGDT_RO_CODE</p>
</td><td class="td" align="left">
<p class="table-para">Selector to kernel code segment descriptor</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">KGDT_RO_DATA</p>
</td><td class="td" align="left">
<p class="table-para">Selector to kernel stack segment descriptor</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">n0 KGDT_R3_CODE</p>
</td><td class="td" align="left">
<p class="table-para">Selector to user code segment descriptor</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">KGDT_R3_DATA</p>
</td><td class="td" align="left">
<p class="table-para">Selector to user stack/data segment descriptor</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">KGDT_TSS</p>
</td><td class="td" align="left">
<p class="table-para">Selector to segment descriptor storing the TSS (multitasking)</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">KGDT_R0_PCR</p>
</td><td class="td" align="left">
<p class="table-para">Selector to segment containing the Process Control Region</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">KGDT_R3_TEB</p>
</td><td class="td" align="left">
<p class="table-para">Selector to segment containing the Thread Environment Block</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">KGDT_VDM_TILE</p>
</td><td class="td" align="left">
<p class="table-para">Selector to segment containing the DOS virtual machine</p>
</td>
</tr>
<tr valign="top">
<td class="td" align="left">
<p class="table-para">KGDT_LDT</p>
</td><td class="td" align="left">
<p class="table-para">Selector to segment containing the LDT</p>
</td>
</tr>
</tbody>
</table>
<p class="para">As you can see, the number of selectors is pretty scarce. This implies that the number of descriptors is also small. However, I don't have enough evidence to support this assumption, so I am going to have to take drastic measures. I am going to have to use a kernel debugger (gasp, ... no, not that, ... not the kernel debugger!).</p>
<div class="section">
<h4 class="sect4-title">Special Weapons and Tactics</h4>
<p class="first-para">A <i class="emphasis">kernel debugger</i> is a special application that can debug the Windows operating system. You can get your hands dirty with a kernel debugger by downloading the Windows <i class="emphasis">Customer Support Diagnostics</i> tool set. It is free and available at Microsoft's web site. There are three debuggers that are included:</p>
<ul class="itemizedlist">
<li class="first-listitem">
<p class="first-para">NTSD (and CDB)</p>
</li>
<li class="listitem">
<p class="first-para">KD</p>
</li>
<li class="listitem">
<p class="first-para">WinDbg</p>
</li>
</ul>
<p class="para">NTSD is the <i class="emphasis">NT Symbolic Debugger</i>. CDB is a special version of NTSD that is intended to debug console applications (i.e., <i class="emphasis">Console Debugger</i>). NTSD and CDB are both geared toward looking at user mode applications, so we're not really interested in them. WinDbg is <a name="241"></a><a name="IDX-100"></a>a Win32 GUI program that can be used to look at both kernel mode and user mode code. KD, <i class="emphasis">Kernel Debugger</i>, is the console equivalent of WinDbg. KD comes in three flavors: <span class="fixed">I386KD.EXE</span>, <span class="fixed">ALPHAKD.EXE</span>, and <span class="fixed">IA64KD.EXE</span>. I am assuming that you are on a Pentium machine, so the one you would need to use is <span class="fixed">I386KD.EXE</span>.</p>
<p class="para">Debugging a live kernel typically requires a special setup. A <i class="emphasis">target machine</i>, which is running the kernel under scrutiny, is connected by a NULL modem to a <i class="emphasis">host machine</i>. The kernel debugger lives on the host machine so that it can watch the kernel without becoming part of the action if the target machine becomes unstable. A NULL modem is just a special kind of serial cable. This target-host machine installation is illustrated in <a class="internaljump" href="#ch02fig20">Figure 2.20</a>.</p>
<div class="figure">
<a name="242"></a><a name="ch02fig20"></a><span class="figuremediaobject"><a href="images/fig128%5F01%5F0%2Ejpg" NAME="IMG_42" target="_parent"><img src="images/fig128_01.jpg" height="195" width="238" alt="Click To expand" border="0"></a></span>
<br style="line-height: 1">
<span class="figure-title"><span class="figure-titlelabel">Figure 2.20</span></span>
</div>
<table border="0" cellspacing="0" cellpadding="0" class="note">
<tr>
<td valign="top" class="admon-check"></td><td valign="top" class="admon-title">Note&nbsp;</td><td valign="top" class="admon-body">
<p class="first-para">In discussions of kernel debugging, you may hear the term <i class="emphasis">checked build</i> mentioned. A checked build is just a specially compiled version of the Windows kernel that has been built with the DEBUG compile-time flag activated. Checked builds are only shipped with high-end MSDN subscriptions. This DEBUG setting results in a whole load of extra error-checking code being placed into the kernel binaries (i.e., <span class="fixed">ASSERT()</span>). Normally when an error occurs in the retail version of the kernel, the system will become unstable and crash. The checked build is intended to catch errors that would normally cause a crash so that the operating system can be debugged. The cost of this extra supervision is memory and execution time, but this usually isn't a major issue for someone trying to see why their kernel mode driver is bringing Windows down.</p>
</td>
</tr>
</table>
<a name="243"></a><a name="IDX-101"></a>
<p class="para">If you don't have access to a second machine, you can still use a kernel debugger to look under the hood. However, in this case, the kernel will be dead. Specifically, you will need to crash your Windows computer so that it dumps an image of memory to disk. This is exactly what happens when the infamous "Blue Screen of Death" (BSOD) appears. There are several types of memory dumps that can be performed:</p>
<ul class="itemizedlist">
<li class="first-listitem">
<p class="first-para">Complete memory dump</p>
</li>
<li class="listitem">
<p class="first-para">Kernel memory dump</p>
</li>
<li class="listitem">
<p class="first-para">Small memory dump</p>
</li>
</ul>
<p class="para">A <i class="emphasis">memory dump</i> is the snapshot of a system when it died. A complete memory dump makes sure that everything but the kitchen sink ends up in the dump file. A kernel memory dump limits its contents to the kernel code and data. The small memory dump is a 64KB file containing a minimal amount of system status information.</p>
<table border="0" cellspacing="0" cellpadding="0" class="note">
<tr>
<td valign="top" class="admon-check"></td><td valign="top" class="admon-title">Note&nbsp;</td><td valign="top" class="admon-body">
<p class="first-para">Regardless of the type of memory dump that occurs, the dump file will be placed in <span class="fixed">%SystemRoot%\memory.dmp</span>.</p>
</td>
</tr>
</table>
<p class="para">To specify the type of memory dump that you want the kernel to write to disk during a crash, open the Windows Control Panel and double-click on the System icon. Select the Advanced tab and click on the Startup and Recovery button. The dialog box that should appear is displayed in <a class="internaljump" href="#ch02fig21">Figure 2.21</a>.</p>
<div class="figure">
<a name="244"></a><a name="ch02fig21"></a><span class="figuremediaobject"><a href="images/fig129%5F01%5F0%2Ejpg" NAME="IMG_43" target="_parent"><img src="images/fig129_01.jpg" height="239" width="211" alt="Click To expand" border="0"></a></span>
<br style="line-height: 1">
<span class="figure-title"><span class="figure-titlelabel">Figure 2.21</span></span>
</div>
<a name="245"></a><a name="IDX-102"></a>
<a></a>
</div>
<div class="section">
<h4 class="sect4-title">Crashing Windows with a Keystroke</h4>
<p class="first-para">Creating a memory dump is easier than you think. My favorite technique requires you to open up the registry to the following key:</p>
<div class="informalexample">
<pre class="literallayout">
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\
i8042prt\Parameters
</pre>
</div>
<p class="para">Once you are there, add the string value <span class="fixed">CrashOnCtrlScroll</span>, and set it to the value <span class="fixed">0x1</span>. You have just added a <i class="emphasis">big red switch</i> to your keyboard. Back in the 1980s, the IBM PC shipped with a big red switch that turned the machine on and off. If DOS got corrupted, you could always hit the big red switch. To activate this switch (and I know you can't help yourself), press the <i class="emphasis">rightmost</i> Ctrl key and hold it down while pressing the Scroll/Lock key twice. This will crash your computer, and your screen will salute you with a BSOD. Let the screen countdown continue until your computer reboots.</p>
<p class="para">When you log back into Windows, a <span class="fixed">Memory.dmp</span> file should be waiting for you.</p>
<table border="0" cellspacing="0" cellpadding="0" class="note">
<tr>
<td valign="top" class="admon-check"></td><td valign="top" class="admon-title">Note&nbsp;</td><td valign="top" class="admon-body">
<p class="first-para">The author and publisher of this book take no responsibility for any damage produced by the information and source code in this text. If crashing your machine to produce a memory dump seems too precarious, please read the online help that accompanies the Customer Support Diagnostics tool kit.</p>
</td>
</tr>
</table>
<a></a>
</div>
<div class="section">
<h4 class="sect4-title">Reverse Engineering the GDT</h4>
<p class="first-para">As I mentioned before, a memory dump is a snapshot of the machine's state when it crashed. The kernel debugger will allow you to sift through this information like Agent Scully performing an autopsy. I started in my quest for GDT information by loading the memory dump into memory with the kernel debugger.</p>
<div class="informalexample">
<pre class="literallayout">
E:\Program Files\Debuggers\bin&gt;I386kd -z e:\winnt\memory.dmp

Microsoft(R) Windows 2000 Kernel Debugger
Version 5.00.2184.1
Copyright (C) Microsoft Corp. 1981-1999

Symbol search path is: E:\WINNT\Symbols

Loading Dump File [e:\winnt\memory.dmp]
Kernel Dump File Only kernel address space is available

Kernel Version 2195: Service Pack 2  UP Free
Kernel base = 0x80400000 PsLoadedModuleList = 0x8046ccf0
Loaded kdextx86 extension DLL
Loaded userkdx extension DLL<a name="246"></a><a name="IDX-103"></a>
Loaded dbghelp extension DLL
f70c20bd 5e               pop     esi
kd&gt;
</pre>
</div>
<table border="0" cellspacing="0" cellpadding="0" class="note">
<tr>
<td valign="top" class="admon-check"></td><td valign="top" class="admon-title">Note&nbsp;</td><td valign="top" class="admon-body">
<p class="first-para">You will need to make sure that you have the latest kernel symbols installed on your computer. These allow the debugger to map kernel symbols to addresses. It is important to make sure that you have the correct version of symbols too. If your kernel is <span class="fixed">build 2195 SP 2</span> (Service Pack 2), you will need symbols for build <span class="fixed">2195 SP 2</span>.</p>