Closed v-p-b closed 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_ .
Multiple processes. File name length can be a factor.
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).
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
That's odd but who knows, the name of the process in memory might be based on the info the PE header?
Here's my test case (Win7 32-bit):
Looks like another Windows weirdness...
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?
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.
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..
I've tried this with both
drakvuf_get_current_process_name
anddrakvuf_get_process_name
. I'm downloading an .exe, and place it to the Desktop from my Downloads folder: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.