x64dbg / gleebug Goto Github PK

Debugging Framework for Windows.

License: MIT License

C++ 2.73% C 97.27% Batchfile 0.01%

gleebug's Introduction

x64dbg

An open-source binary debugger for Windows, aimed at malware analysis and reverse engineering of executables you do not have the source code for. There are many features available and a comprehensive plugin system to add your own. You can find more information on the blog!

Screenshots

Installation & Usage

Download a snapshot from GitHub, SourceForge or OSDN and extract it in a location your user has write access to.
Optionally use x96dbg.exe to register a shell extension and add shortcuts to your desktop.
You can now run x32\x32dbg.exe if you want to debug a 32-bit executable or x64\x64dbg.exe to debug a 64-bit executable! If you are unsure you can always run x96dbg.exe and choose your architecture there.

You can also compile x64dbg yourself with a few easy steps!

Contributing

This is a community effort and we accept pull requests! See the CONTRIBUTING document for more information. If you have any questions you can always contact us or open an issue. You can take a look at the good first issues to get started.

Credits

Debugger core by TitanEngine Community Edition
Disassembly powered by Zydis
Assembly powered by XEDParse and asmjit
Import reconstruction powered by Scylla
JSON powered by Jansson
Database compression powered by lz4
Bug icon by VisualPharm
Interface icons by Fugue
Website by tr4ceflow

Developers

Code contributions

You can find an exhaustive list of GitHub contributors here.

Special Thanks

Sigma for developing the initial GUI
All the donators!
Everybody adding issues!
People I forgot to add to this list
Writers of the blog!
EXETools community
Tuts4You community
ReSharper
Coverity
acidflash
cyberbob
cypher
Teddy Rogers
TEAM DVT
DMichael
Artic
ahmadmansoor
_pusher_
firelegend
kao
sstrato
kobalicek
athre0z
ZehMatt
mrfearless
JustMagic

Without the help of many people and other open-source projects, it would not have been possible to make x64dbg what it is today, thank you!

gleebug's People

Contributors

Stargazers

Watchers

gleebug's Issues

patches

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

string detection functionality

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

attach support

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

write automated testing

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

memory map

remote debugging

GleeBug should have support for remote usage.

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.

call stack

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)

cross references

find references in code

analyze code

conditional breakpoints

dll debugging

write a loader to support DLL debugging directly

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?

file mapping class for easy usage

CreateFileMapping and MapViewOfFile

logging breakpoints

static execution

maybe something like unicorn can be used for this.

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

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

software breakpoints

functions for label names

functionality for pretty-printing an address

fix the reading/writing of context data with multiple threads

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

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.

disassembler interface

preferably with capstone

loaded libraries

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

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.

pop ss

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

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)

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.

store bookmarks

have an interface for storing bookmarks on specific addresses

decent code documentation

documentation should highlight limitations or warnings for various functions.

have good extensibility and modularity

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

branch tracing

x64dbg/x64dbg#227

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.

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

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:

	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);
	}

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