X64dbg Plugins Download
Dicky Pyle
To make it easier to debug plugins you can use the PluginDevHelper to automatically reload the plugin when you build it in Visual Studio. The CMake PluginTemplate automatically detects PluginDevBuildTool.exe and sets this up for you, but you can also set it up manually by following the instructions in the README.
Yes, the integrated one is already provided for by x64dbg, and comes included with the latest snapshots. The second one was created by myself, converting the existing plugin SDK to an assembler friendly one for use with Masm32 (x86) or JWasm / HJWasm (x64)
The plugin files for x64dbg, are files that end with the .dp32 or .dp64 extension. These correspond to the processor architecture used in each version of x64dbg - 32bit and 64bit. In reality these plugin files (.dp32 for 32bit x32dbg and .dp64 for 64bit x64dbg) are just simple dynamic link libraries (.dll files).
Technically only DllMain and pluginit are required at a minimum, but it is considered a good practise to include plugstop to allow for cleanup of your plugins code, should it be required, and plugsetup for obtaining menu handles if your plugin will be creating its own menu items.
Understanding the plugin loading sequence will hopefully help you understand where best to place your code for your plugin and the obvious impact of having cpu intensive code in the initialization and setup functions. Other plugins will be delayed in loading and the x64dbg debugger itself will be waiting for your code to finish before it can continue on to do its main job of debugging.
DllMain is the entry point into a dynamic link library, and is optional for each dll file to have one. The plugins, being dll files, can make use of this function by storing the HINSTANCE hInst value for later use in other api calls. The code required for creating a DllMain function is relatively straightforward.
pluginit passes a pointer to a PLUG_INITSTRUCT structure as the only parameter in the function: initStruct. This structure is used to register the plugin with x64dbg and for obtaining a valid plugin handle which is used in future api calls.
The second way of using callbacks, which may be easier to implement, is to have specifically named functions exported from your plugin. x64dbg will look for these exported functions when loading your plugin and if found will automatically register these as callback events. The exported functions that will be recognised are:
When reach the VirtualAlloc callback the allocated memory address would be stored at EAX/RAX, we can use the scriptapi register function GetCAX to read this value (remember x64dbg provides special registers for architecture-independent code).
In this post I pretend to give a first look from my perspective, of the task of interacting with x64dbg debugger plugins API to extend and give some extra functionality to this awesome and modern debugger.
xAnalyzer is a x64dbg plugin written by me to extend and/or complement the core analysis functionality in this debugger. The plugin was written and intended as a feature that, in the present day of writing this article, has not been implemented yet as a builtin functionality in x64dbg, and I quote:
The plugin starts by launching some of the internal analysis algorithms of x64dbg, such as: cfanal, exanal, analx, analadv or anal. Soon after that it goes into API call analysis. The plugin gets the start and end address of the section in which the current CONTEXT is, this in order to loop and make the analysis overall these bytes. For processing each instruction the plugin uses DbgDisasmFastAt function which has the following definition:
To set the API function name comment, as well as its arguments, the plugin read over the definition files to get the correct data. Finally it also uses some of the functions in the SDK of x64dbg such as: DbgGetCommentAt, DbgSetCommentAt, DbgClearAutoCommentRange and Script::Argument::Add* to set up the visual aid for the current executable function.
Various (small) bugs in the capstone wrapper module have been fixed. NOP jumps should now be correctly detected. In addition x64dbg will show comments helping you see that certain branches are useless.
Testing all the features every time something changed is extremely time-consuming, which is why x64dbg relies on users willing to be on the bleeding edge to find issues like this. I would like to thank all of you!
The (currently undocumented) CB_ADDRINFO plugin callback allows plugins to insert dynamically generated comments. This would allow a plugin to show context-relevant information directly in the comments.
As a RE noob, I am trying to follow this blog post about reverse engineering Black Desert, but it seems like Scylla, a default plugin in x64dbg, is not working for me as it throws the error ("cannot dump image") as shown below.
x64dbg is (probably) the most user-friendly x64 debugger right now. It's pretty, it's open-source and it usually works. But I find it very hard to switch from WinDbg to x64dbg for several reasons. Some of them are purely emotional (don't worry, I'm not going to bore you to death explaining those) but most of them are technical and related to the way x64dbg is being developed.
Both DNSpy and x64dbg suffer from this disease. They love to use the "latest and greatest" of technologies, meaning Visual Studio 2017, .NET 4.6 and what not. That's perfectly fine when you're writing normal software. But debugger is not a normal software.
Technically x64dbg has never come out of alpha (and it will probably not come out of alpha for another 3 years). Some people confused 0.24ALPHA (released April 2014) with a 'stable' version to use which is why I changed to a continuous 'release' model.
That said, I see both arguments on this one. On the one hand, Olly was stable and great at what it did. On the other, there were bugs/missing features in there which plugins such as OllyAdvanced fixed on V1.10 (fpu, inability to break on tls). Olly really would have benefited from more quick releases, but relied on one (all be it, brilliant) man.
Personally, I have taken the positives and started using x64dbg more and more (I use a slightly older version which I consider stable, and update as I test and see the need). I welcome the opportunity to move the debugger functionality forward at a fast pace.
You sound butthurt on everything about x64dbg and seem to have some some beef with the developer, even though you'll never amount to anything close to what mr exodia has. See, it's just useless personal remarks. Don't even know why he wastes time explaining himself to dumb asses like you.
x64DBG is a great piece of software. I haven't had much issues with it that I've had with Olly. Windbg is good but its ui is ancient and honestly in this day and age, some eyecandy like x64DBG is a must. It has an active development community, lots of plugins, good API and it works well at what it does.
Randomly stumbled upon this. Whoever wrote this article, even at the time x64dbg was in alpha phase, has no real sense of how useful this debugger is. Why you need 3 ASM engines.. try to compile a MOV RAX,[ptr] instruction and you will see.. It matters in terms of size and ASLR.
I wrote the article and gave a very specific list of the reasons why I (personally) am not using x64dbg for my work. Your reply did not address any of them, it just stated your personal opinion without any concrete evidence.
760c119bf3