x64dbg/gleebug

Debugging Framework for Windows.

GleeBug

GleeBug is a Debugging Framework for Windows aimed at making debugging enjoyable. It should be complete and easy to use. Feel free to clone and send a pull request or report a bug!

Notice that the project is currently very volatile so for this reason pull requests with new features might be rejected if I feel like they don't fit the current codebase. If you plan on adding major features, please consider consulting me (mrexodia) so there isn't any time wasted.

gleebug's Issues

cross references

find references in code

store functions

have an interface to store function boundaries

dll debugging

write a loader to support DLL debugging directly

design a higher level interface for cross-platform compatibility

A minimal high level interface should be defined so GleeBug can be used in a cross-platform setting.

remote debugging

GleeBug should have support for remote usage.

write coding guidelines and enforce them with tools where possible

coding guidelines are very important for contributers. also document in the code why certain decisions were made so it makes the project more accessible to new collaborators

software breakpoints

functions for label names

functionality for pretty-printing an address

file mapping class for easy usage

CreateFileMapping and MapViewOfFile

branch tracing

x64dbg/x64dbg#227

conditional breakpoints

string detection functionality

there should be functionality for extracting strings from raw data, easing analysis

store labels

have an interface for storing label addresses

record a history of what actions were taken in the framework

this could be useful if people want to generate scripts, possibly also provide a functionality to repeat recorded actions

hwbp to step/trace code

x64dbg/x64dbg#161

abstract debug symbol support

there should be an abstract layer around dbghelp so it is possible to add DWARF support later. and caching, lots of caching (up to the point where the PDB files are not loaded in memory at all)

allow halting the debuggee to switch to another debugger easily

can probably be done by injecting some code in the process and updating the CONTEXT in a way that other debuggers can JIT and resume execution on detach.

write automated testing

probably quite hard to come up for automated tests with debugging, but I think it's possible

Application Freezes After Period of Time

• Debugger: Oct 2 2020 (GleeBug)
• OS: Windows 10 Pro 1903 18362.329

The debugger application locks up after a period of time. This does not appear to be dependent on the executable used. It happens consistently after a period of time using the debugger. The environment is VirtualBox 6.1.14 on macOS 10.15.7.

This behavior does not exist using VMWare Fusion. Is it reproducible on a different set of hardware running the same version of macOS. The operating system does not lock up. Keyboard works and ctrl-alt-delete works. Mouse is able to move, but nothing is clickable and focus does not follow the mouse. Using the keyboard to navigate to Task Manager and then ending debugger task, the mouse is still not usable. However, running the debugger again fresh gets everything working again and after that point the mouse is usable as normal.

static execution

maybe something like unicorn can be used for this.

memory map

work correctly with debug privileges

there should be an option that automatically acquires debug privileges

floating pointer register support

FPU, MMX, SSE, AVX registers with FPU flags and everything.

logging breakpoints

hardware breakpoints

have good extensibility and modularity

it should be easy to add and modify modules to have a different behavior.

pop ss

http://www.ragestorm.net/blogs/?p=45

single stepping

good debug event callback system

this is a really hard problem, but the basic idea @Nukem9 came up with was to have some sort of queue that processes registered callbacks sequentially, similar to the Intel PIN tool. Details should be discussed or mentioned here.

make a nice class diagram

might be useful in the future.

call stack

loaded libraries

store loaded libraries and their imports/exports also deserialize them using the class from #4 and optionally recursively deserialize their dependencies

detect and mitigate avoidable anti-anti debug tricks

stuff like single step detection should be mitigated as well as specific anti-debug tricks (will comment here later)

class that can serialize/deserialize a PE file

should have the ability to modify the file layout, delete/reorder/modify sections, abstract access to data directories, work with overlays, serialize/deserialize a PE file

GleeBug hardware breakpoint issue

Hello!

I started to use new version with GleeBug engine. Version is "Oct 2 2020"
To reproduce the bug:

• set any hardware break point on a memory
• delete this breakpoint
• set another hardware breakpoint on the same address

patches

have support for storing memory modifications so they can be reverted later

StaticEngine doesn't work

When I try to load an exe, it says that file not found.
When I try to load a dll, it crashes.
Let me know if that's just me, I'll try to provide more details.

attach support

Cannot modify code on entry point when break point is triggered

Here's a gif demonstrating the bug. Another limitation is that a new breakpoint can't be set at that location until you step out of it.

tracing support

there should be tracing support (with single step/hardware breakpoint/memory breakpoint/software breakpoint) that builds up a buffer with all the useful information (modified registers, complete context, modified memory and some surrounding data)

Win10 Improvement: Use WaitForDebugEventEx instead of WaitForDebugEvent

Taken from x64dbg/x64dbg#388

---

WaitForDebugEventEx

https://msdn.microsoft.com/en-us/library/windows/desktop/mt171594(v=vs.85).aspx

thread safe functions

There should be a container line threadsafe_map and threadsafe_vector that uses SRW locks (or critical sections for XP support).

Source code of interest: https://github.com/x64dbg/x64dbg/blob/development/src/dbg/threading.h

analyze code

fix the reading/writing of context data with multiple threads

• thread-safety
• mIsDebugging determines if the context is read directly or lazily

store bookmarks

have an interface for storing bookmarks on specific addresses

Can not use target<> to check if two std::function are equal

GleeBug/GleeBug/Debugger.Thread.cpp

Lines 42 to 56 in cd01d22

	void Thread::StepInto(const StepCallback & cbStep)
	{
	StepInto();
	auto target = cbStep.target<void()>();
	for (const auto & cb : stepCallbacks)
	{
	if (target == cb.target<void()>())
	{
	puts("duplicate StepInto callback detected!");
	return;
	}
	}
	stepCallbacks.push_back(cbStep);
	}

I run a test with following code, taget<void()> always return nullptr. So I can't use this to check if two std::function are equal.

#include <vector>
#include <functional>

typedef std::function<void()> StepCallback;

std::vector<StepCallback> stepCallbacks;

void StepInto(const StepCallback& cbStep)
{
	auto target = cbStep.target<void()>();
	for (const auto& cb : stepCallbacks)
	{
                // always get null
		if (target == cb.target<void()>())
		{
			puts("duplicate StepInto callback detected!");
			return;
		}
	}
	stepCallbacks.push_back(cbStep);
}

void fun1() {}

void fun2() {}

int main()
{
	StepInto(fun1);
	StepInto(fun1);
	StepInto(fun2);
	StepInto([]() {});
	StepInto(std::bind([]() {}));
	return 0;
}

output:

duplicate StepInto callback detected!
duplicate StepInto callback detected!
duplicate StepInto callback detected!
duplicate StepInto callback detected!

According to cppreference, the template type of target<> seems very strict. Or there is something wrong with my test?

memory breakpoints

memory breakpoints with a variable size window allowing for accesses in the page to be narrowed down to specific addresses (as an alternative for hardware breakpoints)

decent code documentation

documentation should highlight limitations or warnings for various functions.

Crash while stepping over - thread is a NULL pointer

Hi Duncan :)

So I updated x64dbg and accepted the offer to try out the new engine, GleeBug. I've used it for several hours with no apparent issues, until, at some moment, it crashed. I wasn't prepared for troubleshooting so I didn't have symbols and such, but from the location of the crash and the source code it looks like it crashed here on line 26:

GleeBug/GleeBug/Debugger.Process.cpp

Lines 24 to 26 in 9fd62da

	void Process::StepOver(const StepCallback & cbStep)
	{
	auto gip = Registers(thread->hThread, CONTEXT_CONTROL).Gip();

with thread holding a NULL pointer.

All I did was smashing F8 to step over.

That's not much, but here's a screenshot of handling the exception as a JIT debugger:

disassembler interface

preferably with capstone