Chapter 17 Notes

to accompany Sikorski and Honig, Practical Malware Analysis, no starch press

Anti-debugging

Used by malware authors to interfere with malware analysts. Lots of techniques exist, and new ones seem to come along all the time.

Windows Debugger Detection

• The Windows API provides several functions to determine if a debugger is being used
• Set breakpoints at calls to IsDebuggerPresent, and step around setting results as desired
• How does IsDebuggerPresent work? Search the Process Environment Block (PEB) for the field isDebugged
• What other goodies are in the PEB? And what sets the isDebugged field to TRUE?
• CheckRemoteDebugger takes a process handle as a parameter, else similar to IsDebuggerPresent
• NtQueryInformationProcess with ProcessDebugPort as a parameter
• OutputDebugString sends a string to a debugger for display. Why would such a function exist? For debugging!

Manually Checking Structures

• Malware might do what these functions do, that is, look at system data structures such as the PEB
  • where can we find such information? from Microsoft!
  • note that location fs:[30h] points to a process's PEB
• Several ways to check the status of the BeingDebugged status byte
• OllyDbg has plug-ins for this purpose, e.g. hidedebug. Also windbg -hd whatever.exe
• Check the (undocumented?) ProcessHeap Flag
• Check the (undocumented?) NTGlobalFlag
• Check for System Residue, such as Registry keys, e.g.
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\NT\CurrentVersion\AeDebug
• Default is Dr. Watson? What?
• Use FindWindow to find windows named OLLYDBG

Identifying Debugger Behavior

• INT 3 is the software interrupt used to set breakpoints. The opcode is 0xCC, and it is seen in malware.
• (I once saw malware that had a ton of these, maybe an attempt to crash the debugger?)
• Furthermore, malware can look for this opcode in its own code, and knows it's being debugged
• Code checksums, another way to find modified instructions, such as 0xCC where some other opcode was there before
• Code that does this kind of check can be found and modifed, with the debugger of course

Timing Checks

• Malware can record a timestamp, and check again later. If a lot of time has passed, there's a user in the loop!
• Take a timestamp before and after raising an exception. If a lot of time has passed, there's a user in the loop!
• The rdtsc instruction returns the number of ticks since last reboot
  • do you suppose every disassembler knows about that one?
• QueryPerformanceCounter and GetTickCount functions keep track of time in a similar fashion
• Two successive calls to such functions are evidence of an attempt at debugger detection
  • and hence a weak malware indicator
• Find the comparison, and the jump, and force the desired path of execution - using the debugger

Interfering with the Debugger

• TLS is a Windows storage class that allows for thread-specific initialization
• A TLS Callback implements such thread-specific variables
• Can execute before the program's entry point , and therefore before any breakpoints might be encountered- sneaky!
• The TLS section in the PE header is used, and Windows executes these functions before branching to the OEP
• PEview can see TLS sections, which are otherwise uncommon
• IDA Pro CTRL-E command displays all entry points, including TLS callbacks
• OllyDbg can be configured to break before running TLS callback routines - which sounds like a good default!

Using Exceptions

• Structured Exception Handling is covered in Chapter 16
• An SEH can be used to do unconventional jumps
• But a process can throw an exception, and set itself up to handle it
• If the debugger catches the exception, the malware "knows" a debugger is present
• Inserting INT 3 instructions can cause spurious "breaks", as can INT 0x2D
• The undocumented icebp instruction (0xF1) messes with single-stepping
  • How many other undocumented opcodes are there? How can we find out?

Debugger Vulnerabilities

• Mess with the PE Header: Olly follows the PE spec too closely, so a program may load and run, but will crash Olly!
• OllyDbg 2.0 is not subject to this, supposedly
• I don't know if win64dbg, or Immunity, are subject to this
• Are there utilities to mess with PE headers in such a way? Quite likely
• Setting size of RawData to a large value will crash older versions of Olly
• PE Explorer can help with this

Conclusions

• several popular anti-debug techniques exist
• none seem too formidable, but take notes (and snapshots) since it's a hassle to start over
• malware authors are always coming up with new tricks!