16 Oct 2016, by mrexodia
It has been two months already since the first weekly digest! This is number eight and it will highlight the things that happened around x64dbg this week.
GUID Reference Searching
Just after I wrote the digest last week, torusrxxx implemented GUID reference searching. It shows various things that might be interesting if you are looking into COM.
The graph view didn’t show much information before. It will now show the same comments as in the disassembly view so you can easily spot string references and such.
Graph overview
In addition to traced blocks, the graph overview will now show the blocks that end in a ret instruction in a different color. This allows you to spot potential function exit points more easily.
Added some expression functions
You can now use the dis.next and dis.prev expression functions to get the address of the next/previous instruction. For example you can use the following command to trace until the next instruction is a ret.
TraceIntoConditional dis.isret(dis.next(cip))
Cross references dialog
By running the analx command x64dbg will do cross reference analysis. Cross references can be viewed by pressing ‘X’ on the instruction that is referenced. The dialog showing the referencing instructions is now non-modal you can browse around the current reference to see whats there without confirming you want to go there.
Graph debugging
It is now possible to synchronise the current instruction of the graph with ‘Origin’ (EIP/RIP). This allows you to do some basic debugging in the graph view!
Freeze stack has been fixed
Thanks to shamanas in pull request #1158 the freeze stack option now works correctly again!
I would also like to thank fearless again for contributing lots of these great icons!
Fixed complex memory assignments
The expression 1:[x64dbg:EntryPoint]=90 now works like it’s supposed to. If you want to find out what it does, check out the manual. Specifically the sections on input and expressions.
Execute multiple commands
Someone on the mailing list (yes that’s right) noticed that you cannot execute multiple commands at a time. You can now do that, separating them with a semicolon. Beware: commands that interact with the debugger (step, run and rtr for instance) will not be executed like scripts! Doing eax=0;step;eax++ does not guarantee that eax++ is executed after the step finished.
x64dbgbinja
After the x64dbgida plugin, there is now the x64dbgbinja plugin that allows you to import/export x64dbg databases with Binary Ninja. Also thanks to the team there for providing me with a license so I could actually test the plugin!
Refactor
There has been quite some refactoring going on. Most notably the command callbacks no longer require CMDRESULT as return type (making it even easier to write commands) and the CPUStack has been refactored to use the MenuBuilder to save lots of development time in the long run.
Tracing plugins
Tracing has been a much requested feature for x64dbg. The x64_tracer plugin by KurapicaBS implemented a trace plugin, but you can now register the CB_TRACEEXECUTE callback to receive callback on every step of a trace. An example plugin that stops every tracer after 20 000 steps is available here.
Usual things
That has been about it for this week again. If you have any questions, contact us on Telegram, Gitter or IRC. If you want to see the changes in more detail, check the commit log.
You can always get the latest release of x64dbg here. If you are interested in contributing, check out this page.
Finally, if someone is interested in hiring me to work on x64dbg more, please contact me!
Comments
09 Oct 2016, by mrexodia
This is the seventh of (hopefully) many weekly digests. Basically it will highlight the things that happened to x64dbg and related projects during the week before.
Plugin page
There is now a wiki page available dedicated to x64dbg plugins. It contains various templates and also a list of plugins. If you wrote a plugin yourself, feel free to add it to the list!
Variable list will now be shown in the reference view
The command varlist will now show the available variables in the reference view instead of in the log.
Fixed a crash in the pluginload command
Previously the pluginload commands would not check the number of arguments and it would read in bad memory. See issue #1141 for more details.
Added undo in registers view
Atvaark added an ‘Undo’ option to revert register changes in pull request #1142.
Think there are too many entries in the disassembly context menu? You can now move menu entries you don’t use to the ‘More commands’ section to make your life less complicated. This also works for some other menus but some more work is required to make it possible everywhere.
Better character recognition in the info box
The info box will now recognize escaped characters in addition to printable characters.
Pull request #1145 added character recognition requested in issue #1128.
Goto origin in memory map
Atvaark has added the Goto -> Origin option in the memory map in pull request #1146. This will show you the memory page that EIP/RIP is currently in.
The branch lines in the sidebar are now highlighted when selecting the branch destination. This is in addition to the xref feature that was implemented some time ago. If you want xref analysis use the command analx, analyze a single function with the ‘A’ button or use the analr command. For more analysis commands, see the analysis section of the documentation.
Various updates to the mnemonic database
If you are looking for a quick description of every instruction you can use the ‘Show mnemonic brief’ (Ctrl+Alt+F1) option to get a brief description of every opcode. The mnemonic database used for this has been slightly updated and should give better results in some cases.
Open file/directory options for the source view
You can now open the file/directory of the source file you are currently debugging in to view the file in your favorite editor.
Next/Previous/Hide tab
The third and fourth(!!!) pull request by Atvaark this week (#1152 and #1153) added more flexibility with tabs. You can now easily hide tabs and switch between them.
Import/export database
It is now possible to use the dbload and dbsave commands to import/export databases to an arbitrary location. Once you have an exported the database you can import it in IDA with the x64dbgida plugin. This also works the other way around!
Better IsJumpGoingToExecute
The function that analyzes the flags to see if a jump is going to execute has been re-implemented and should now be faster. In addition to that the loop instruction is correctly analyzed now.
Usual stuff
That has been about it for this week again. If you have any questions, contact us on Telegram, Gitter or IRC. If you want to see the changes in more detail, check the commit log.
You can always get the latest release of x64dbg here. If you are interested in contributing, check out this page.
Finally, if someone is interested in hiring me to work on x64dbg more, please contact me!
Comments
04 Oct 2016, by torusrxxx
x64dbg has a complex architecture. There are three basic parts, namely DBG, BRIDGE and GUI, but in fact there is a fourth part, EXE. This is the main executable, it compiles into x64dbg.exe.
Bootstrapping
When the user starts x64dbg, it will follow this initialization path to get x64dbg running:
- WinMain
- BridgeInit
- LoadLibrary(“x64gui.dll”)
- Initialize global variables in the GUI
- LoadLibrary(“x64dbg.dll”)
- Initialize global variables in the DBG
- Load function pointers
- BridgeStart
Debugging
To start debugging, the GUI sends an init command to the DBG. Then the following things start:
Message passing from GUI to DBG
There are four methods to call DBG from GUI. They are commands, directly exported functions, bridge exported functions (messages) and DbgFunctions(). Currently the directly exported functions are frozen and no new ones should be added. The message flows for each way will be described below.
Commands dispatch
DbgCmdExec is relayed by the bridge to the DBG and eventually received by the cmdloop running in the command thread. This is done asynchronously (meaning DbgCmdExec will not wait until the command is completed).
DbgCmdExecDirect is relayed by the bridge to DBG and then directly in cmddirectexec. This will only return after the command is completed.
In both cases the command is parsed and dispatched to various registered command callbacks. A command callback is similar to main() functions. It can receive number of arguments (plus one), and pointer to every argument string.
Commands are registered in the registercommands function. If you want to get a total list of supported commands, or add your own, just go to that file. Make sure to put your command in the correct category and also make sure to add it to the documentation.
Directly exported functions
There are some legacy functions still unconverted to another method, these can be found in exports.h.
Export functions dispatch
Many Dbg*** functions are exported by the bridge. It then calls _dbg_sendmessage exported by DBG to pass information. Some Dbg*** functions have exports directly in DBG.
DbgFunctions
_dbgfunctions.cpp has a function table that is accessible by anyone. The GUI can call functions in DBG through this table directly.
Message flow from DBG to GUI
There are various Gui*** functions exported by the bridge. The control flow is described below:
- Gui*** export
- Bridge calls _gui_sendmessage
- Bridge calls Bridge::processMessage
- A long list of switch statements in
processMessage, basically to emit the corresponding signal. If you want to receive a system event, connect to one of the signals in Bridge::getBridge()
Important subsystems in GUI
Tables in GUI
There is three-level class architecture to support various tables. The first-level class is AbstractTableView, which only includes some basic functions. The second-level classes are Disassembly, HexDump and StdTable. They all inherit from AbstractTableView. Many basic and common functions are defined here, such as table painting, selection, content presentation and column reordering. The third-level classes inherit from the second-level classes. There are many third-level classes. The most common parent for these tables is StdTable.
There are two styles of context menu management. The traditional one builds actions in setupContextMenu and adds them into a menu object in contextMenuEvent. CPUStack uses this style currently. A newer way to manage context menu is to use MenuBuilder. You can see CPUDisassembly or this blog post for more details. It is the preferred way to manage context menu in newer tables, but it does not support non-table widgets out of the box. We want to convert traditional context menu systems into MenuBuilder to speed up development.
Configuration management
Configurations are stored in the Config() object which uses Utf8Ini in the bridge as its backend. When you want to add a new configuration, you have to modify the following files: Configuration.cpp and the SettingsDialog. If you are adding a color then you have to modify the AppearanceDialog as well. Config() can emit settings change signals.
Important subsystems in DBG
There are many subsystems in DBG. The following subsystems are important if you want to contribute:
threading.h
It includes various locks to prevent race condition. Without it, x64dbg will crash much more often. Don’t forget to acquire the lock when you are accessing a subsystem.
x64dbg.cpp
It registers all commands in x64dbg. The details of command processing is described above.
memory.h , module.h and thread.h, label.h and breakpoint.h, etc
They manages corresponding information of the debuggee.
scriptapi
It is intended to be used by plugins. It provides easy scripting experience for developers. x64dbg does not call any of these functions.
Comments