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 ...

From Windows Vista onwards, Microsoft has placed a substantially greater focus on the security of the operating system, which is one of the areas most users will neglect and then later come to complain about. In this article I'm going to talk about Windows Integrity Levels, and how we can view this information in WinDbg and through some SysInternals Tools. In another article, I will going into more depth about access tokens and how they are used to increase system security. These security measures were introduced since it was relatively easy to modify memory and remove any security identification, thus leads to code modification and injection being used to allow illegitimate access to important system data structures etc. User-Mode processes often require the use of system services and system resources which reside within the Kernel-Mode. To stop any illegitimate access or any poor programming from creating havoc in Kernel-Mode, some security validation procedures have been introd...

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 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...

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...