tklengyel / drakvuf

DRAKVUF Black-box Binary Analysis
https://drakvuf.com
Other
1.07k stars 255 forks source link

APIs for process name retrieval return incorrect results #168

Closed v-p-b closed 8 years ago

v-p-b commented 8 years ago

I've tried this with both drakvuf_get_current_process_name and drakvuf_get_process_name. I'm downloading an .exe, and place it to the Desktop from my Downloads folder:

[SYSCALL] vCPU:0 CR3:0xb9ee9480,CrashMe.exexe ntoskrnl.exe!NtClose

It looks like a NULL byte is missing somewhere, or there's some misalignment (the original name is CrashMe.exe).

The issue can be worked around by renaming the file to "C.exe" for example. As far as I can remember this feature worked as expected before.

tklengyel commented 8 years ago

Hm that's odd, does it happen with other processes too or only that one? On Jun 11, 2016 02:26, "buherator" notifications@github.com wrote:

I've tried this with both drakvuf_get_current_process_name and drakvuf_get_process_name. I'm downloading an .exe, and place it to the Desktop from my Downloads folder:

[SYSCALL] vCPU:0 CR3:0xb9ee9480,CrashMe.exexe ntoskrnl.exe!NtClose

It looks like a NULL byte is missing somewhere, or there's some misalignment (the original name is CrashMe.exe).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tklengyel/drakvuf/issues/168, or mute the thread https://github.com/notifications/unsubscribe/ADBp3UHg9coMh2QMOnt0HMrLs16xGBRHks5qKnFDgaJpZM4IzgJ_ .

v-p-b commented 8 years ago

Multiple processes. File name length can be a factor.

tklengyel commented 8 years ago

You might want to verify manually what the string in memory is. The function responsible for reading this is vmi_read_str in LibVMI, so if there is a bug it's actually in LibVMI. Get the physical address for the string and then use volshell to read that memory area (or xxd).

v-p-b commented 8 years ago

I did a 64 byte hexdump with vmi_read() and it seems that the string in memory is in fact the one printed by the API:

43726173684d652e6578657865002689c084689c0840000b01f7386b01f738600008095ae851000f0f02ee90800000000f0fd7f
[SYSCALL] vCPU:0 CR3:0xb9ee9580,CrashMe.exexe ntoskrnl.exe!NtCallbackReturn
tklengyel commented 8 years ago

That's odd but who knows, the name of the process in memory might be based on the info the PE header?

v-p-b commented 8 years ago

Here's my test case (Win7 32-bit):

Looks like another Windows weirdness...

tklengyel commented 8 years ago

Hm, I've been placing things on the Desktop without this issue so I guess the key here is moving the file with ctrl-X, ctrl-V that mucks something up? What happens if you run process-list? And what does task manager show in the VM?

v-p-b commented 8 years ago

Retested with c:\Users\user\Downloads> move CrashMe.exe ..\Desktop\, same result. Also tried moving the file back and forth, explicitly stating the destination file name, still the same.

tklengyel commented 8 years ago

Yea, I can verify this happens on my Win7 x64 VM as well (fully updated). What's interesting is if I shorten the name of the file I get:

[ 2620] test.exe.exe (struct addr:fffffa80020b3060)

then

[ 2876] t.exeexe.exe (struct addr:fffffa8001b7ab10)

However, Volatility reports the same thing:

0xfffffa8001b7ab10 test.exe.exe 2068 1184 8 306 1 1 2016-06-15 01:17:57 UTC+0000

And Rekall too:

0xfa8001b7ab10 test.exe.exe 2068 1184 6 300 1 True 2016-06-15 01:17:57+0000 -

So I'll just scrub this up to Windows being weird..