ErcinDedeoglu / WubbabooMark

Debugger Anti-Detection Benchmark

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

WubbabooMark

Debugger Anti-Detection Benchmark

Build status

WubbabooMark aimed to detect traces of usage of software debuggers or special software designed to hide debuggers presence from debugee by tampering various aspects of program environment.

Typical set of debuggers nowadays is actually limited to a few most popular solutions like Ghidra/IDA/OllyDbg/x32+x64dbg/WinDbg and so on. There is a special class of software designed to "hide" debugger from being detected by debugee. Debugger detection usually used by another software class - software protectors (e.g. Themida/VMProtect/Obsidium/WinLicense). Sometimes software that counteracts these detections referred as "anti-anti-debug" or whatsoever. Personally I found all of this "anti-anti" kind of annoying because we can continue and it will be "anti-anti-anti-..." with all sense lost somewhere in the middle.

What this "anti-anti" class of software actually does is creating a landscape of additional detection vectors, while some of most notorious pieces compromise operation system components integrity and security in the sake of being able to work. And all of them, absolutely all of them brings multiple bugs due to inability correctly replicate original behavior of hooked/emulated functions. Sounds scary? Not much that scary as most of this software users (they call themselves "reversers/crackers") know what they're doing and doing that on purpose... right? Carelessly implemented targeted antidetection methods against known and well reverse-engineered commercial protectors creating a bunch of new artifacts. WubbabooMark using publicly known, actualized and enchanced methods to list those artifacts.

The continuous VMProtect drama generates a lot of fun so I just can't stay away of it. Since VMProtect recently goes "open-source" under DGAF license I had an opportunity to look closer on its "anti-" stuff. What VMProtect has under the hood clearly demonstrates authors following mainstream "scene" with little own creativity in some aspects due to limits as commercial product and software support requirements. Direct syscalls, heavens gate? What year is it now? However, reinventing this stuff even in 2018 seems have doomed to dead some of this so called "anti-anti" software.

Anyway, we have some debuggers, some "tampering tools/plugins" etc, lets see how good they are!

System Requirements

x64 Windows 10/11 and above.

Anything below Windows 10 is unsupported. Well, because those OSes discontinued by Microsoft and mainstream industry. What a surprise! What a surprise! Forget stone age systems and move on.

Windows 11 preview/developer builds WARNING: since this program rely on completely undocumented stuff there can be problems with most recent versions that program doesn't know about resulting in false-positive detection or program crashes. Use on your own risk.

Implemented tests

(a short list, almost each actually does more but for readme technical details are too much)

  • Common set of tests
    • Presence of Windows policy allowing custom kernel signers
    • Detection of Windows kernel debugger by NtSystemDebugControl behavior.
    • Check for unnecessary process privileges enablement
  • Process Environment Block (PEB) Loader entries verification
    • Must be all authenticode signed, have valid names
  • Loaded Kernel Modules verification
    • Must be all authenticode signed, doesn't include anything from built-in blacklist
    • Detect lazy data tampering
  • Blacklisted Driver Device Objects
    • Lookup devices object names in Object Manager namespace and compare them with blacklist
  • Windows Version Information
    • Detect l33t and other BS changes
    • Cross-compare version information from several system modules that are in KnownDlls
    • Cross-compare version information from PEB with data obtained through WMI
    • Validate system call (syscall) layout for PEB version
    • Validate system build number acceptable range
  • Running Processes
    • Check if process name is in blacklist
    • Cross-compare Native API query result with WMI data to detect hidden from client processes
    • Detect lazy Native API data tampering
    • Check client against console host information
    • Application Compatibility (AppCompat) parent information
  • Client Threads
    • Verify that client threads instruction pointers belong to visible modules
  • NTDLL mapping validation
    • Map NTDLL using several methods and cross-compare results
  • Examine program stack
    • Find a code that doesn't belong to any loaded module
  • Validate Working Set (WS) information
    • Query WS and walk each page looking for suspicious flags
    • Use WS watch and look for page fault data
  • Perform Handle Tracing
    • Enable handle tracing for client, perform bait call and examine results
    • Check NtClose misbehavior
  • Validate NTDLL syscalls
    • Obtain system call data by various methods, use it and cross-compare results
  • Validate WIN32U syscalls
    • Obtain system call data and compare results
  • Detect Debugger presence
    • Process Debug Port with indirect syscall
    • Process Debug Handle with indirect syscall
    • Process Debug Flags with indirect syscall
    • DR registers
    • User Shared Data information
  • Examine system handle dump
    • Find debug objects and debug handles
    • Detect lazy Native API data tampering
    • Detect client handles with suspicious rights
  • Enumerate NtUser objects
    • Walk UserHandleTable to find objects which owners are invisible to client API calls
  • Enumerate NtGdi objects
    • Walk GdiSharedHandleTable to find objects which owners are invisible to client API calls
  • Enumerate Boot Configuration Data (That one requires client elevation)
    • Search for option enablements: TestMode, WinPEMode, DisableIntegrityChecks, KernelDebugger
  • Scan process memory regions
    • Search for regions with memory executable flags that doesn't belong to any loaded module

Program can be configured which tests you want to try. Go to menu "Probes -> Settings", apply changes and start scan. Note settings are saved to registry and read uppon program load.

Output Examples

  • Clean scan

  • Wubbaboos found scan

How To Run Test And Don't Ask Questions Next

  1. Download or Compile from source "Skilla.exe"
    • If you want to compile yourself: Use Microsoft Visual Studio 2019 and above with recent Windows SDK installed. Compile configuration is "Release", not "Debug".
    • If you want to download precompiled binary it is in Bin folder of this repository.
  2. Load your debugger, setup your tampering plugins, load "Skilla.exe".
  3. Run the program in debugger and watch output. If something crashed including your debugger - it is your own fault (maybe~).
  4. Look for results. Normally there should be nothing detected, literally ZERO wubbaboos in list.
  5. If you want to repeat test - there is no need to restart "Skilla.exe" or repeat (2)(3) - go to menu and use "File -> Scan".

Do you found something that looks like a false-positive or a bug? Feel free to report in issues section! You can save generated report using "Probes -> Save As ..." menu. File will be saved in comma separated values (CSV) format.

False positives

Antimalware/anticheat software may cause false positives due to the way these software class works. Make sure you understand what you do. This is not AV/EDR benchmark nor testing tool.

Driver Bugs

While encountering random BSODs from the best and funniest "super hide" software I was about to make a fuzzer test just because every driver I compiled contained improper handling of syscalls it intercepts. However since authors of these software doesn't care and usage of all these drivers limited to small group of masochists this idea was dropped at early stage. Well what can I say - never use anything from that super hiding stuff on a live machine or you risk to lose your data due to sudden bugcheck.

Virtual Machine Detection

Not an aim of this tool and will never be added. This tool will work fine with VM.

Links

Here I would like to put some useful links, enjoy.

Debuggers first!

Debugger Anti-Detection

Debugger Detection

Here I should put some links to what is now reinvented wheels about debuggers detection that you can easily find in the world wide web. It is mostly time-machine to where Windows XP was all new and shine.

Project Name

Wubbaboo is a mischievous spirit from Cognosphere videogame Honkai Star Rail. It likes to hide in unexpected places and does a lot of pranks just like the software class we are testing.

No wubbaboos were harmed during tests!

Authors

  • (c) 2023 WubbabooMark Project

License

MIT

About

Debugger Anti-Detection Benchmark

License:MIT License


Languages

Language:C 64.1%Language:C++ 35.7%Language:Assembly 0.1%