decaf-project / DECAF

DECAF (short for Dynamic Executable Code Analysis Framework) is a binary analysis platform based on QEMU. This is also the home of the DroidScope dynamic Android malware analysis platform. DroidScope is now an extension to DECAF.
GNU General Public License v3.0
803 stars 168 forks source link

Unloading modules and emptying cache without having to unload plugin #61

Open dkfulp opened 5 years ago

dkfulp commented 5 years ago

Hello,

I am trying to write a plugin that will involve running a process in the guest multiple times. The issue I am facing is that between guest runs the modules in decaf are not cleared. I have found the issue to be within the lm variable that is a _LoadModule_Params struct. Do you know of a way to clear out past lm modules so that decaf sees the program as new each time it runs?

Currently to do this we need to unload the plugin and then reload it.

hengyin commented 5 years ago

Hi Zhenxiao,

Can you look into this?

Heng

On Tue, Feb 26, 2019 at 7:57 AM Dakota Fulp notifications@github.com wrote:

Hello,

I am trying to write a plugin that will involve running a process in the guest multiple times. The issue I am facing is that between guest runs the modules in decaf are not cleared. I have found the issue to be within the lm variable that is a _LoadModule_Params struct. Do you know of a way to clear out past lm modules so that decaf sees the program as new each time it runs?

Currently to do this we need to unload the plugin and then reload it.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sycurelab/DECAF/issues/61, or mute the thread https://github.com/notifications/unsubscribe-auth/ACydRnoJqkRh7nJogcwVSwgX3zFwRSPJks5vRVlegaJpZM4bSghf .

enlighten5 commented 5 years ago

Hi, The problem is, there is a global list module_name containing the module info and a local list module_list for each process, both store the pointers to the module info. In normal cases, we get the module info indexed by the process ID. So in some sense, when a process is dead, we only need to remove the process from the process_map, which is what DECAF does for now. however, sometimes the global list is also used to traverse the module info, which results in some issues. One possible solution is that in the VMI_remove_process function, where we delete the dead process info, try delete *mod_pointer and mod_pointer=NULL as well.

enlighten5 commented 5 years ago

Hi, Could you give more details about how do you find that the modules in decaf are not cleared? As far as I'm concerned, the module info belonging to the process is indexed by the process PID, the previous process's module should not mess up with that of the running process.

dkfulp commented 5 years ago

Currently, when a module is loaded, we use the lm.name, lm.base, and lm.size. The issue we are having is that I will call a program say foo in the guest and decaf sees this as a new module that has not been seen before, but if I run foo again, it uses some kind of cached memory of sorts. If I wanted decaf to look at programs as brand new during each run, how would we go about that.

Would it be possible to clear all information that is related to the lm.cr3 of the program that we are running?

enlighten5 commented 5 years ago

It's normal that the module info has been seen before since the same module is loaded from the global module list and is reusable. If you run a program for multiple times, the cr3 and some other process info would be different and DECAF still recognizes the program as brand new during each run.