\n\nThis page has been machine-translated from the original page.
\n
In this appendix, I introduce several debugger techniques that could not be included in the main text.
\n\nYou can configure the WinDbg Command window to write execution results to any file.
\nThis is useful when you want to save a history of your analysis with WinDbg, or when you want to analyze the results of commands that produce a huge amount of output using methods other than WinDbg.
\nIf you want to save WinDbg command output to a specified file, run the .logopen <full path to the destination file> command in the Command window.
After running this command, the results of subsequent commands will be written to the specified path as ASCII text.
\nTo stop writing and close the file, run the .logclose command.
By running the commands above, the output is saved to a log as shown in the image below.
\nNote that if you specify a log destination with .logopen and a file already exists at that path, the existing file data will be deleted and replaced with the new command output.
If you want to save command output by appending to an existing file, use the .logappend <full path to the destination file> command instead of .logopen.
Also, if you want to avoid accidentally overwriting a file that contains past analysis results, you can use the /t option with the .logopen command.
When you use the /t option, timestamp information for the date and time when logging started is automatically added to the specified file path, as in the example below, which prevents existing files from being overwritten.
0:000> .logopen /t C:\\Users\\Public\\windbg.log\nClosing open log file C:\\Users\\Public\\windbg.log\nOpened log file 'C:\\Users\\Public\\windbg_1058_2023-09-24_08-36-13-088.log'Whichever command you use, run .logclose to stop writing and close the file.
For more detailed information about saving WinDbg output, please refer to the official documentation below.
\nKeeping a Log File in WinDbg:
\nhttps://learn.microsoft.com/ja-jp/windows-hardware/drivers/debugger/keeping-a-log-file-in-windbg
\nWinDbg can execute complex scripted processing.
\nIn this book, when using commands for dump file analysis, I entered either a single command or multiple commands separated by semicolons (;) in the WinDbg Command window.
However, to analyze more efficiently, there are cases where you may want to execute complex commands all at once or control which commands run by using conditional branches.
\nFor example, the following script enumerates EPROCESS structures in kernel memory and uses an If statement to print only the address when the D4C.exe process is found.
\n$$ Get process list LIST_ENTRY in $t0.\nr $t0 = nt!PsActiveProcessHead\n\n$$ Iterate over all processes in list.\n.for (r $t1 = poi(@$t0);\n (@$t1 != 0) & (@$t1 != @$t0);\n r $t1 = poi(@$t1))\n{\n r? $t2 = #CONTAINING_RECORD(@$t1, nt!_EPROCESS, ActiveProcessLinks);\n as /x Procc @$t2\n\n $$ Get image name into $ImageName.\n as /ma $ImageName @@c++(&@$t2->ImageFileName[0])\n\n .block\n {\n .if ($scmp(\"D4C.exe\",\"${$ImageName}\")) { } .else {.echo ${$ImageName} at ${Procc}}\n }\n\n ad $ImageName\n ad Procc\n}You can save this script as C:\\Users\\Win10\\Downloads\\windbg_script.txt and execute it by invoking it in WinDbg as follows.
6: kd> $$>a<C:\\Users\\Win10\\Downloads\\windbg_script.txt\nD4C.exe at 0xffffc18f45284080This book does not explain in detail the script invocation commands1, the syntax for the conditional branches2 and loops3 used in this script, or how to use aliases4 and pseudo-registers5.
\nPlease refer to the public documentation for details on each command.
\nThe MEX extension is an extension for WinDbg officially provided by Microsoft.
\nSome commands in the MEX extension were used in Chapter 7.
\nFor the level of analysis covered in this book, you do not need to use the MEX extension, but I think it is convenient to know about it.
\nTo use the MEX extension, first run Mex.exe, which can be downloaded from the URL below, on a Windows system.
\nDownload MEX Debugging Extension from Official Microsoft Download Center:
\nhttps://www.microsoft.com/en-us/download/details.aspx?id=53304
\nNext, in the window that appears after you agree to the license terms, specify any folder path where the MEX extension modules will be placed.
\nIf you open the path you specified above in Explorer, you can confirm that a file named Mex.zip has been placed there, so extract this ZIP file.
By loading the mex.dll file contained in the extracted folder into WinDbg with the .load <full path to mex.dll> command, you will be able to use the MEX extension.
This book does not explain the MEX extension in detail, but you can output help for each available feature by running the !mex.help -all command.
In this section, I introduce a technique for retrieving file data from memory data collected in a full memory dump.
\nOn Windows systems, a mechanism called the cache manager caches file contents and file system metadata.6
\nThis cache manager tracks which parts of which files exist in the cache by using a mechanism called Virtual Block Caching.
\nIn this book, I attempt to extract file contents from the system by identifying the address of the structure called the virtual address control block (VACB), which is managed by the cache manager, from a memory-mapped file object.
\nNote that this method assumes cached data exists in pages included in the full memory dump, so it is important to keep in mind that you cannot necessarily retrieve file contents from every full memory dump you collect.
\nTo extract file contents from a full memory dump, first load the collected full memory dump into WinDbg and run the !memusage command.
Because the output of !memusage is enormous, I recommend enabling output to a file in advance with the .logopen command.
As a result of running !memusage and analyzing the PFN database information, I confirmed the presence of no-cached-file.txt and Microsoft-Windows-Windows Defender%4Operational.evtx (the Microsoft Defender Antivirus event log file) as mapped files.
0: kd> !memusage\nloading PFN database\n{{ omitted }}\nUsage Summary (in Kb):\nControl Valid Standby Dirty Shared Locked PageTables name\n\nffffc40861b53750 0 4 0 0 0 0 mapped_file( no-cached-file.txt )\n\nffffc40861b5c350 68 0 0 0 68 0 mapped_file( Microsoft-Windows-Windows Defender%4Operational.evtx )To inspect the Control information identified here, use the !ca extension.7
When I ran the !ca ffffc40861b53750 command using 0xffffc40861b53750, which is the address of the control area corresponding to mapped_file( no-cached-file.txt ), I obtained the following result.
Although the detailed specification of the Windows Event Log (EVTX) format is not public, you can get information about the file header and chunk header from the public information in the libyal/libevtx repository on GitHub.
\nTo further check whether event log file data is written to the memory region beginning at this BaseAddress, dump an arbitrary 10000 bytes into windefend-event.txt with the .writemem C:\\windefend-event.txt ffff9688ea940000 L10000 command.
Because the text inside the event log file is written as a wide string, when I extracted text from the file with a command such as strings -e l windefend-event.txt, I found that I could obtain data written in the event log file as shown below.
$ strings -e l windefend-event.txt\n\nMicrosoft Defender Antivirus\n4.18.23080.2006\n1.397.865.0\n1.1.23080.2005\nSecurity intelligence update\nC:\\ProgramData\\Microsoft\\Windows Defender\\Scans\\RtSigs\\data\\884898236a1fb17353dac39aea1e06cfeadc24e4\n0.0.0.0\n10/20/2023 11:36:23 AM\nDuration\n2592000000\nMicrosoft-Windows-Windows Defender\nMicrosoft-Windows-Windows Defender/OperationalBy the way, this time I followed the structure information step by step from the file object address to reach the VACB address, but if you use the !finddata extension9, you can identify the address where the contents are cached much more easily.
When I ran the !finddata command using the addresses of the file objects for no-cached-file.txt and the event log file that I investigated above, I obtained the following results.
# Inspect the file object for no-cached-file.txt\n0: kd> !finddata ffffc40861f5f720\n\nFindData for FileObject ffffc40861f5f720 Section Object Pointers: ffffc40861f22a98\nShared Cache Map: 00000000Unable to read nt!_SHARED_CACHE_MAP at 0000000000000000\n\n\n# Inspect the file object for the event log file\n0: kd> !finddata ffffc40861920440\n\nFindData for FileObject ffffc40861920440 Section Object Pointers: ffffc40861981b38\nShared Cache Map: ffffc40861582a20 File Offset: 0 in VACB number 0\nVacb: ffffc4085abd5ea0\nYour data is at: ffff9688ea940000In the case of no-cached-file.txt, which had no cache present in memory, text was output indicating that the address of the nt!_SHARED_CACHE_MAP structure could not be referenced.
On the other hand, for the event log file, Your data is at: ffff9688ea940000 was output, which is the cached address of the contents identified from the VACB structure information.
With that, I was able to extract data for files cached in the system from the full memory dump.
\nThis method makes it difficult to retrieve a specifically targeted file or the original complete file, but I think it is an interesting technique to know when analyzing full memory dumps.
\nYou are unlikely to need this in actual troubleshooting, but for example, when analyzing a dump file from a malware-infected system, there are cases where you may want to retrieve the original executable from the memory dump.
\nIn such cases, you can obtain an executable (a PE file) by extracting the data expanded in a process’s memory with WinDbg and exporting it as a file.
\nHowever, note that an executable extracted from process memory with this method is not completely identical to the original executable.10
\nThere are several reasons for this, but one is that some sections of the PE file are not expanded into process memory.
\nAlso, if values such as global variables or executable code expanded in memory have been modified by the program, it is no longer possible to extract the original executable file.
\nThere are other reasons why it is difficult to extract a file from process memory that is completely identical to the original executable, but this book omits a detailed explanation.
\nFor executable extraction from process memory, the reference listed in this book, The Art of Memory Forensics, explains the topic in detail.
\nIn this book, I will recover the D4C.exe executable from a full process memory dump using WinDbg.
\nBasically, recovery is possible by performing the reverse of the PE file loader: extracting the PE headers and each section’s information as expanded in process memory and merging them into a single file.
\nAs introduced in Chapters 5 and 6, it is technically possible to recover the executable by using the !dh -f and !dh -s commands to obtain information about the IAT and section headers, then using the .writemem command to write each memory region to a file.
This time, however, I will extract the executable by using an open-source extension published on GitHub (HongThatCong/dumpext).
\nThis book only introduces the fact that executables can be extracted from process dumps, so it does not explain the details of the extension.
\nTo extract the executable, I use the D4C.exe process dump obtained in Chapter 6.
\nAfter loading the D4C.exe process dump into WinDbg, load the extension downloaded from the HongThatCong/dumpext repository with the .load C:\\Users\\Public\\Downloads\\dumpext.dll command.
After loading the extension, run the !dumpext.dump_pe !D4C command to dump the executable from the process.