search

DynamoRIO / dynamorio

Dynamic Instrumentation Tool Platform
Other
2.57k stars 550 forks source link

drltrace for malware behavior analysis #2156

Open mxmssh opened 7 years ago

mxmssh commented 7 years ago

I found that drltrace is a very useful tool for malware analysis. A trace of library calls is very important and may save a lot of time for malware analyst especially in cases of highly obfuscated malicious executables. However there are a lot of capabilities that would be great to add in drltrace, such as:

  1. Printing symbolic values of input arguments and return values (in the same way like we did it in DrMemory's drstrace).
  2. Printing id of current thread and return address in malware's memory.
  3. Printing when malware performs execution of instructions stored in a dynamically allocated memory block.
  4. It would be great to support tracing of injected code in a remote process's memory.

Right now, we have support of symbolic values printing using debug information in DrMemory's drstrace. However, only system calls tracing is not enough to break semantic gap and I'm planning to integrate drstrace functionality into drltrace (or vice versa?).

The question is what is a right way in terms of DynamoRIO/DrMemory architecture to do that ? Moreover, there is a note in drltrace about printing symbolic values "XXX i#1349: features to add:" which is not in our list of issues on github.

derekbruening commented 7 years ago

drltrace was originally filed in the DrMem tracker and the issue there lists several desired features: https://github.com/DynamoRIO/drmemory/issues/1349

derekbruening commented 7 years ago

The main thing being shared would be the lists of named constants that are currently in drstrace?

Just talking out loud here: if drstrace were made into a library to share these, and drltrace in DR uses drstracelib, it would have to be optional and build without it to support plain DR builds. Testing then becomes an issue: we could add tests in the DrMem repo I suppose. It might be better to move drltrace to the DrM repo in that case (remaining BSD I suppose). Are there other suggestions?

mxmssh commented 7 years ago

The question is: do we want drltrace to be a standalone application like drstrace ? If yes, do we want to share drstrace_frontend for drltrace or just keep everything related to drltrace in a separate dir? What about our version of DR's drltrace for Linux in this case ? I already implemented drltrace as a standalone application for Windows, just for experiment. It works fine, symbols fetching (that we will need in future) works fine as well. In general, I think drltrace will use drstrace's named_consts and all printing routines may be shared as well. Next, some of syscalls (that we already have) are possible to use for library calls arguments printing. However, we still need a table for a rest of Windows API (I don't know how to do it automatically).

derekbruening commented 7 years ago

The question is: do we want drltrace to be a standalone application like drstrace ? If yes, do we want to share drstrace_frontend for drltrace or just keep everything related to drltrace in a separate dir?

If drltrace needs to fetch symbols, it would probably have to be standalone.

drfrontendlib is supposed to make creating new frontends easy so we wouldn't need to share drstrace_frontend. IIRC even some of the symbol fetching stuff is in drfrontendlib.

mxmssh commented 7 years ago

Ok. What about DR's version of drltrace ? We can leave it at least while we don't have better version in DrMemory repo or leave only Linux version...

derekbruening commented 7 years ago

I would think it would be moved as-is rather than starting from scratch?