uninitialized class member in decaf/shared/vmi.h make hook unstable
zdzhjx opened this issue · 4 comments
in head file, decaf/shared/vmi.h
31 class module{
32 public:
33 char name[VMI_MAX_MODULE_PROCESS_NAME_LEN];
34 char fullname[VMI_MAX_MODULE_FULL_NAME_LEN];
35 uint32_t size;
36 uint32_t codesize; // use these to identify dll
37 uint32_t checksum;
38 uint16_t major;
39 uint16_t minor;
40 bool symbols_extracted;
41 unordered_map < uint32_t, string> function_map_offset;
42 unordered_map < string, uint32_t> function_map_name;
43 unsigned int inode_number;
44
45 module()
46 {
47 this->inode_number = 0;
48 }
49 };
symbols_extracted is uninitialized, which will make class member symbols_extracted' default value be true or false. plugin hookapitests may works well in some times , but always failed in my testing.
path is:
module()
{
this->inode_number = 0;
this->symbols_extracted=false;
}
pls submit the code, thanks.
We had other issues which popped up when we had this variable initialized in the constructor. Our workaround for this was to initialize the variable instead in the only points where instances are actually created. For example, in the linux vmi, (refer line 174 in https://github.com/sycurelab/DECAF/blob/master/decaf/shared/linux_vmi_new.cpp ) this is already taken care of, but for windows this is not handled. Please change the windows vmi accordingly if you are having problems with windows.
I see.
but we can fix it in shared/windows_vmi.cpp after line 289
288 if (!curr_entry) {
289 curr_entry = new module();
** curr_entry->symbols_extracted=false;
290 DECAF_read_mem(env,
291 curr_mod + handle_funds[GuestOS_index].offset->SIZE_OFFSET,
292 4, &curr_entry->size); // dllsize SIZE_OFFSET
by the way, would you please tell me about your version 2 at https://github.com/TheLoneRanger14/Decaf.v2, can it run faster?
Yes absolutely. That would work perfectly for windows.
Regarding DECAF.v2, it was an attempt to port DECAF to the newest version of QEMU. Due to other project commitments I have not been able to finish it. I'm not sure how significant a boost in runtime speed you might get with that even if complete.
Sorry, I just saw this. I'm not sure what "other issues which popped up" refer to. But I guess the unintialized variables left risks to the program...