Detection Example: DSE vs Debuggers
Description: In their conventional form, debuggers are programs that software engineers use to analyse and modify programs at a very low level. Debuggers have essentially complete control over the target process that they're debugging (the debuggee). However, debuggers can actually be very simple programs - a process can start debugging another process simply by calling a single function such as DebugActiveProcess (from kernel32.dll), making it very easy for a virus or other form of malware to gain debug-level control other processes.
Detection: For our main demonstration we've used the publically-available freeware debugger 'OllyDbg', written by Oleh Yuschuk.
Here we can see the OllyDbg debugger with CALC.EXE loaded as its target. OllyDbg now has full control over the calc.exe process. In addition to that we'll also set a hardware breakpoint at its entrypoint (address 0x01012475):
Here we can see how easily DSE detects the debugger, and fast too - almost instantly.
Under the Hardware Breakpoints subsection we can clearly see the breakpoint we set, including which module it's in (calc.exe), what address the breakpoint was set at (0x01012475), as well as additional information such as the breakpoint event type, its size, and so on.
The Debuggers - Active subsection shows all live debuggers (ollydbg.exe), including their targets (calc.exe).
The Debuggers - Just-In-Time subsection shows all debuggers that have registered themselves with the operating system so that whenever a program or a script breaks from a bug the appropriate debugger can be activated.
Breakpoints - Int3 wasn't used in this demonstration, but essentially it is a variation of the powerful Code Modifications feature. These breakpoints differ from hardware breakpoints in that they actually modify the software's code by replacing an existing instruction with an Int3 (breakpoint) instruction, so instead of looking for all Code Modifications this feature simply looks for bytes that have been replaced with Int3 breakpoints.
DEBUG CHAINS
In a proof-of-concept test here at the DiamondCS lab we created a circular chain of 3 processes debugging one another, with Process A debugging Process B, Process B debugging Process C, and Process C debugging Process A. The end result is 3 live processes (they are all running, not in a frozen state) that can't be attached to by any other debuggers:
You can see this chain in DSE, with all 3 processes being both a Debugger and a Debuggee (target) at the same time, and with each being linked to each other in a chain as can be seen by their Process IDs:
Copyright © 2008, Diamond Computer Systems Pty. Ltd. All rights reserved.