By Holger Unterbrink.
Cisco Talos is releasing a new beta version of Dynamic Data Resolver (DDR) today. This release comes with a new architecture for samples using multi-threading. The process and thread tracing has been completely reimplemented.
We also fixed a few bugs and memory leaks. Another new feature is that the DDR backend now comes in two flavors: a release version and a debugging version. The latter will improve code quality and bug hunting. It helps to detect memory leaks and minor issues which are silently handled by the underlying DynamoRIO framework in the release version. We also improved the installer and the IDA plugin is now installed to the user plugin directory instead to the IDA installation directory under Program Files. The IDA plugin and all its dependencies are also now automatically installed by a script.
You can download DDR, version 1.0.1 beta here
FANTASTIC NEWS! DDR HAS WON THE HEXRAYS IDA PLUGIN CONTEST 2020
We would like to thank HexRays for recognizing this plugin and awarding it with the first prize in their IDA plugin contest. We hope HexRays keeps up the fantastic work they are doing with IDA. It makes our reverse-engineering lives a bit easier every day.
You still install DDR by executing the DDR_INSTALLER.py on the DDR server side like we have described it in our former DDR blog. The latest version of IDA now supports Python 3.8 so you can go with 3.8 on both sides — the DDR client and the server side. In this version, we have improved the installer, you don’t have to install the IDA plugin side manually anymore. The installation provides a Python script for the IDA plugin side, which is installing the plugin to the user plugin directory and also fixes all dependencies. Administrator rights aren’t necessary anymore for installing the plugin.
This is by far the biggest change in this version of DDR. We moved from the file-based approach to a shared memory object approach. If a sample is launching multiple threads and processes, tracing gets complex. The underlying DynamoRio framework supports multiple threads and processes. Threads are relatively easy to handle via the DynamoRio thread initialization and exit call back functions. Processes are a bit more difficult. Obviously, a separate instance of the DynamoRio client library (DDR32/64.dll) is running in every new process, which the initial sample starts at runtime. This means we can’t easily share data structures like global variables between these processes. We need an inter-process data sharing mechanism to synchronize the different tracing features, for example, which instruction data is written to which trace file. In the former version, we used files to track the processes and threads. Unfortunately, this is very time consuming and has certain other architecture disadvantages. For example, we need to know at certain points in the code, if the thread exit function is the one of the first process — in other words, the sample we are code tracing, or if it is an exit function of a sub process. There are also future features we are working on which will need this architecture change.
We heavily improved the debugging capabilities of DDR. There are now two versions: one speed optimised release version and one debugging version of the ddr32.dll and ddr64.dll. The debugging versions can be found in the installer directory ‘ddr_installer\install_data\ddr32/64dbg.dll’. These debugging versions are not recommended for daily use — they are only there for troubleshooting in case DDR is crashing or not behaving as expected.
They come with a huge overhead on additional output information that’s extremely useful for the developers to track down crashes and bugs in DDR. The debugging versions can also be used to debug the client library (ddr32/64.dll) in WinDbg. If you want to debug an issue you need to set up Windbg as described here.
Despite what the document says, we are using WinDbg, version 10.0.19041.1 on Windows 10, which works fine for the cases we handled so far. You can debug the DynamoRio client library (ddr32/64.dll aka DDR) without using a DynamoRIO debugging version. This means you can attach the debugger to the client the way we are describing it below, no matter if the DynamoRio framework is a debugging version or a release version. You only have to use the debugging version of the client (ddr32/64dbg.dll). For most issues, it is usually enough to check the command line output of the DDR debugging versions, but if you need more details, the following section describes how to debug DDR with WinDbg. You can find sample debugging sessions in the Appendix.
You can control the verbose level of the output in the debugging version of ddr32/64.dll via the -d switch. At the moment only -d 5 is supported and is adding additional output. It will print additional information for every trace instruction, so use it with care. For most cases, run it without the -d parameter.
How to debug the DDR backend with WinDbg:
Read more here: blog.talosintelligence.com
