filedelete - missing traps?

[zashraf1337]

What are there known issues / reasons for the following:

//drakvuf_add_trap(drakvuf, &traps[1]);
//drakvuf_add_trap(drakvuf, &traps[2]);
//drakvuf_add_trap(drakvuf, &traps[3]);

What's the reason for not enabling the traps for the following.

ZwSetInformationFile
NtDeleteFile
ZwDeleteFile

[tklengyel]

Nt/ZwDeleteFile have different input then Nt/ZwSetInformationFile so they just have not been implemented to be handled yet. ZwSetInformationFile could be enabled.

[v-p-b]

Does this mean that not receiving filedelete messages (my current problem) is a known issue? I remember this plugin working like charm.

[tklengyel]

It's working as far as I know, it just means that there may be other syscalls that can be issued to delete files. The one currently being caught is just the most common one (ie. right-click->delete)

[v-p-b]

Can you please check if it works for you? I tried both right click, del from command line and os.unlink() from Python, neither seems to work for me.

Debug output:

Starting plugin filedelete
        ntoskrnl.exe @ 0x8264a000
Reservation increased? 0 with new gfn: 0x35c282
Copied trapped page to new location
Activating remapped gfns in the altp2m views!
                Trap added @ PA 0x28a275c RPA 0x35c28275c Page 10402 for NtSetInformationFile. 
Starting plugin filedelete finished
[...]
Started DRAKVUF loop
INT3 event vCPU 0 altp2m:1 CR3: 0xb9ee91a0 PA=0x28a275c RIP=0x828a2701. Insn_length: 1
Switching altp2m and to singlestep on vcpu 0
reset trap on vCPU 0, switching altp2m 0->1
INT3 event vCPU 0 altp2m:1 CR3: 0xb9ee9400 PA=0x28a275c RIP=0x828a2701. Insn_length: 1
Handle table @ 0x9db9d000. Handle count 21. Looking for handle: 0x7f4e00000054
        Handle table array size: 512 at 0x9db9d000. Table entry size is 8. Handle count remaining: 21
                Handle #: 21. Addr: 0x8b6ead58. Value: 0x4
                Handle #: 20. Addr: 0x84d462f0. Value: 0x8
                Handle #: 19. Addr: 0x84dfedd8. Value: 0xc
                Handle #: 18. Addr: 0x8c264cb0. Value: 0x10
                Handle #: 17. Addr: 0x84fc0150. Value: 0x14
                Handle #: 16. Addr: 0x8652d7e8. Value: 0x18
                Handle #: 15. Addr: 0xa3fa5f30. Value: 0x1c
                Handle #: 14. Addr: 0x84e76a88. Value: 0x20
                Handle #: 13. Addr: 0x84d44a50. Value: 0x24
                Handle #: 12. Addr: 0x862ebbc0. Value: 0x28
                Handle #: 11. Addr: 0x862f3030. Value: 0x2c
                Handle #: 10. Addr: 0x862ebbc0. Value: 0x30
                Handle #: 9. Addr: 0x85069430. Value: 0x34
                Handle #: 8. Addr: 0xa3fc08f8. Value: 0x38
                Handle #: 7. Addr: 0x85095018. Value: 0x3c
                Handle #: 6. Addr: 0xa3f8ff58. Value: 0x40
                Handle #: 5. Addr: 0xa3f65218. Value: 0x44
                Handle #: 4. Addr: 0x9d3461c0. Value: 0x48
                Handle #: 3. Addr: 0xa3fc0f30. Value: 0x4c
                Handle #: 2. Addr: 0x86566f68. Value: 0x50
                Handle #: 1. Addr: 0x850ca9e0. Value: 0x54
Switching altp2m and to singlestep on vcpu 0
reset trap on vCPU 0, switching altp2m 0->1

[tklengyel]

INT3 event vCPU 0 altp2m:1 CR3: 0x135fd000 PA=0x295ecb0 RIP=0xfffff8000295ec01. Insn_length: 1
Handle table @ 0xfffff8a001477000. Handle count 758. Looking for handle: 0x4d0
	Handle table array size: 512 at 0xfffff8a001477000. Table entry size is 8. Handle count remaining: 758
	Handle table array size: 256 at 0xfffff8a0017ed000. Table entry size is 16. Handle count remaining: 758
		Handle #: 758. Addr: 0xfffff8a0017f0190. Value: 0x4
		Handle #: 757. Addr: 0xfffff8a00304b420. Value: 0x8
...
		Handle #: 453. Addr: 0xfffffa8001af4040. Value: 0x4d0
[FILEDELETE] VCPU:0 CR3:0x135fd000,explorer.exe SessionID:-1 "\Users\MrX\Desktop\asdsadasd.txt"

[tklengyel]

Your handle value looks pretty odd, 0x7f4e00000054 to me looks more like a virtual address.

[tklengyel]

Ah I see the problem. The handle variable isn't being initialized to 0 in the filedelete plugin, so when

if ( VMI_FAILURE == vmi_read_32(vmi, &ctx, (uint32_t*) &handle) )
            goto done;

reads the handle, only the lover 32-bits are being initialized, the upper 32-bits are random data.

[tklengyel]

PR #235 should fix that problem!