flynn017

The SwishDbgExt library contains a number of interesting extensions which are imperative for deep debugging results. The SwishDbgExt library was written by Matt Suiche . Note: If you wish to use the ProcDumpExt DLL for WinDbg, and also view the help information for the extensions provided in SwishDbgExt, then you'll need to unload ProcDumpExt first since ProcDumpExt will overload the !help extension with it's own version. You can simply load ProcDumpExt again afterwards. Alternatively, if you do not wish to unload the ProcDumpExt DLL, then simply use the longhand method of !SwishDbgExt.help <SwishDbgExt Extension> . You must also omit the exclamation mark (!) from the extension name, otherwise the !help extension will not work. Note: You can use the .chain command to check if you have the ProcDumpExt DLL loaded or not. The .chain command will dump all loaded DLLs for the dump file. The available extensions from the DLL can be found by using the !SwishDbgExt.help ex...

Windows needs to ensure that untrusted code and untrusted users aren't accessing important areas of the operating system, and creating problems which would ultimately lead to a vast number of BSODs. Windows manages this through Access Tokens which are used to identify the security context of a process/thread and a user. Access Tokens take two main forms: a Primary access token and a Impersonation access token. The Access Token additionally has two important features which are integral to security validation: SIDs (Security Identifiers) and a Privilege Array which contains the privileges allowed for that object. The token type can be found within a enumeration called TOKEN_TYPE.   The data structure can be found under the TokenType field within the _TOKEN structure. The Primary type determines the security context of the process for the currently logged on user, and the Impersonation type allows a thread to temporarily use a different security context. The Token type can also ...

The !podev , !poreqlist and !poaction aren't documented within WinDbg for some reason, but there is a person which has written about them thankfully. These extensions are a must for Stop 0x0A and debugging any issues related to power like Stop 0x9F. !popolicy  The !popolicy displays information related to the current power policy of the current user.  !pocaps The !pocaps extensions displays information in relation to the power capabilities of the system, this is ideal for checking if drivers are attempting to use a unsupported sleep state. !poreqlist The !poreqlist extension will list all outstanding power IRPs from any driver which has called the PoRequestPowerIrp function. The function will create a Power IRP and then send it to the top of the device stack for a given device object.  The list of power IRPs will be shown under the FieldOffset field. The extension will provide the device object, driver object and the nature of the power IRP. !poaction  The !p...

When I was writing up my WinDbg cheat sheet, I managed to stumble upon the !tz and !tzinfo extensions in the WinDbg Help documentation. The extensions seem to be solemnly documented directly by Microsoft, but using the ACPI documentation is easily to understand what most of the fields mean. The !tz and !tzinfo gather information from the ACPI subsystem about the currently allocated thermal zones and the cooling policies being implemented. On Windows, you can manipulate the cooling policies slightly by changing your Power Settings. Power Settings - Windows 7   By changing the power consumption, the Active and Passive Cooling policies will be changed. I will explain the difference between Active and Passive cooling later. The Thermal Management mostly uses a component called the OSPM (Operating System Directed Configuration and Power Management) to manage different cooling policies and check the thermal zones. The OSPM is used to remove any device management responsibilities from...

The _KUSER_SHARED_DATA structure contains some interesting information related to the currently logged on user, we can obtain the address of this data structure by using the !kuser extension in WinDbg. Most of the fields aren't officially documented from what I can find, but you should be easily be able to work out what they mean from their names. Using the address with the _KUSER_SHARED_DATA will provide the following (omitted structure): There is some debugging bit fields within this structure, so you can check what debugging features have been enabled for that user. It also contains some basic system information. Additional Reading: The System Call Dispatcher on x86 struct KUSER_SHARED_DATA

I've created a comprehensive and complete WinDbg cheat sheet of the most general and useful extensions/commands which you'll be using regularly. I've added a few data structures to the list too. The list is organised by category, according to the different areas of debugging such as Memory or I/O. Download Link (OneDrive) - https://onedrive.live.com/?cid=7101A9E8FE03DB78&id=7101A9E8FE03DB78!105    If there are any suggestions or corrections to be made, then please leave a comment in the comments section. Additionally, I've been attempting to convert my blog posts into a .DOC format which can be printed, unfortunately I haven't added any images to conserve space and ink. However, I have tried to construct the blog posts so you know which row or column to check; dd commands with the IAT/EAT post for example.

I may have created a small list of tools before, however, I would like to expand this list and provide some better descriptions for each of the tools listed. These tools are either completely free or have a limited free version which provides enough functionality for those like myself, who aren't professional security researchers, escalation engineers or get paid for doing reverse engineering/debugging. These tools can and are used by professionals and enthusiasts alike. If you have any recommendations then please add a link to the comments section. WinDbg - Reverse Engineering/Debugging This tool is my most favorite, it provides complete functionality for enthusiasts and is for free. There is a wide range of extension and commands for viewing data structures, memory addresses and call stacks. It can be used for both reverse engineering and debugging BSODs (Blue Screens of Death). There is good documentation for WinDbg for finding hidden rootkits, examining data structures and loo...

This is a very simple error, and be can useful in providing a hint at which point the crash may have occurred. This has been explained by Scott Noone on this blog, but I wanted to write my own blog post about it and provide the data structure which he didn't mention. The error was found by Patrick in a Stop 0x101 bugcheck, and perfectly matches the context of the crash. Looking at Parameter 4, we can see the Processor Index Number which has become hung. This is where the error message is located too.  The highlighted address is the physical address stored within the CR3 Register.  Using the !process extension on the same Processor Number Index, we can check the DirBase field to find the mismatch within the two address indicated in the error message. The DirBase is a physical address of the Process Directory Table Base. The DirBase field is the field within structure formatted with !process , which contains the address of the Process Directory Table Base for the current proc...

Malicious Software is able to detect if it's running within a debugging environment or a debugger has been attached to the process, and thus will not generate of it's malicious behaviors in order to avoid detection from the security analyst or whoever is attempting to debug the process. In this article, I'm going to describe some of the common anti-debugging techniques which are used to detect the presence of a debugger.   NtGlobalFlag: The NtGlobalFlag is located within the Process Environment Block (PEB) at offset 0x68 on x86 Windows, and at offset 0xBC on x64 Windows. Windows 7 SP1 x86 The default value is always 0, and doesn't change when a debugger is attached to the process. There are several methods in which the NtGlobalFlag can be changed to detect the presence of a debugger. The NtGlobalFlag contains many flags which affect the running of a process. The most common flags which are set with NtGlobalFlag when a debugger creates a process, is the heap checking fl...

LPCs or Local Inter-Process Communication calls are used to communicate between two User-Mode NT components, or between a User-Mode component and a Kernel-Mode Component. I believe there may be some bugchecks related to LPCs or at least problems you may potentially run into when working with LPCs if your a software engineer. The User-Mode to Kernel-Mode communication tends to be related to security, and the User-Mode components tends to be related to creating logon sessions for the user. The terms Client and Server are used here, and this tends to refer to a different thread or different process. It depends on who created the port and who is receiving the messages. LPCs build upon the concept of IPC (Inter-Process Communication): Methods of IPC:   The methods are usually some form of synchronization like a Semaphore, or a shared object such as a File object or Memory-Mapped File. A comprehensive list can be found on Wikipedia . Port Creation and Port API: With Windows Vista onwards...