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.
When attempting to run decaf from a ubuntu 20.04 host, with VMI enabled with a windows XP sp3 guest, the code in VMI_remove_process() sometimes (perhaps one in every 4 closed processes) causes a double free error when it deletes the process object. This occurs with or without loading any plugins.
We have done some initial investigations, and it seems that the process_pid_map.erase(iter); in /shared/vmi.cpp on line 372, sometimes corrupts iter with pointers to a seemingly irrelevant data structure. Then on line 373 delete iter->second; attempts to free this data structure (a tcache used by malloc) instead of the process pointer it is supposed to.
The crash can be worked around by creating a copy of iter->second, i.e. process * proc = iter->second. Then using that pointer for deletion at the end of the function. However, without knowing exactly what is causing the underlying issue, we do not know what the bug might end up doing to the system over time.
Decaf was compiled from source using the instructions provide in the wiki, with only the default VMI enabled. Please let me know if any other information would help.
@ddemicc, thanks for raising this issue. I wonder if there are multiple VCPUs created for the virtual machine, so there might be a race condition caused by multiple kernel threads running in the guest kernel.
When attempting to run decaf from a ubuntu 20.04 host, with VMI enabled with a windows XP sp3 guest, the code in VMI_remove_process() sometimes (perhaps one in every 4 closed processes) causes a double free error when it deletes the process object. This occurs with or without loading any plugins.
We have done some initial investigations, and it seems that the
process_pid_map.erase(iter);
in /shared/vmi.cpp on line 372, sometimes corrupts iter with pointers to a seemingly irrelevant data structure. Then on line 373delete iter->second;
attempts to free this data structure (a tcache used by malloc) instead of the process pointer it is supposed to.The crash can be worked around by creating a copy of iter->second, i.e.
process * proc = iter->second
. Then using that pointer for deletion at the end of the function. However, without knowing exactly what is causing the underlying issue, we do not know what the bug might end up doing to the system over time.Decaf was compiled from source using the instructions provide in the wiki, with only the default VMI enabled. Please let me know if any other information would help.