Return value and follow args

[maxspl]

Hi!

I tried to add these two options in a fork:

1. Log return value of syscall and function call

Enabled in the .ini file using LOG_RETURN_VALUE.

I'v used this logic:

• For function calls:
  • Store the return address at call time.
  • Compare it with each instruction via CheckIfFunctionReturned. If one of the instructions after the call is the return one, it indicates we're at the function return.
  • I've tried this with MonitorFunctionArgs and IPOINT_AFTER, but it doesn't work for some functions.
• For syscalls:
  • Simpler logic using SyscallCalledAfter.

Output Example

The output looks like this:
GetProcAddress:
	Arg[0] = ptr 0x00007ff8acab0000 -> {MZ\x90\x00\x03\x00\x00\x00\x04\x00\x00\x00\xff\xff\x00\x00}
	Arg[1] = ptr 0x00007ff78683400a -> "NtAllocateVirtualMemory"

GetProcAddress
	returned: ptr 0x00007ff8acb4d7e0 -> {L\x8b\xd1\xb8\x18\x00\x00\x00\xf6\x04%\x08\x03\xfe\x7f\x01}

2. Follow the args and return value

Enabled in the .ini file via FOLLOW_ARGS_RETURN

The goal is to track args and returns (if they are valid pointers) of all calls to detect any change (ex: log the first bytes of the allocated memory by VirtualAlloc when filled).

This is done like that :

• Each call is described in a struct (ID (unique per thread), name, return adress, args, return value...)
• At an arbitrarily chosen point in the code (I've chosen every time any function specified in params.txt is called, but this can be changed), the saved calls are scanned and their args (if valid pointer) and return value (if valid pointer) are checked: a comparison is made between the current pointed value and the initial value. If a change is detected, it is logged.

The output looks like this for a new value pointed to by an arg :

CreateProcessA:
	Arg[0] = ptr 0x000000ef813ff750 -> "C:\Windows\System32\cmd.exe"
	Arg[1] = 0
	Arg[2] = 0
	Arg[3] = 0
	Arg[4] = 0x0000000300000000 = 12884901888
	Arg[5] = 0
	Arg[6] = 0
	Arg[7] = 0
	Arg[8] = ptr 0x000000ef813ff790 -> L"h"
	Arg[9] = ptr 0x000000ef813ff770 -> {\x00\x00\x00\x00\x00\x00\x00\x00}

CreateProcessA
	returned: 0x0000000000000001 = 1

[...]

VirtualAlloc:
	Arg[0] = 0
	Arg[1] = 0x00000000000001b2 = 434
	Arg[2] = 0x0000000000003000 = 12288
	Arg[3] = 0x0000000000000040 = 64

CreateProcessA, Arg[0] Pointer: 0x000000ef813ff750 changed:
	Old: {ptr 0x000000ef813ff750 -> "C:\Windows\System32\cmd.exe"}
	New: {ptr 0x000000ef813ff750 -> "C:\temp.exe"}
CreateProcessA, Arg[9] Pointer: 0x000000ef813ff770 changed:
	Old: {ptr 0x000000ef813ff770 -> {\x00\x00\x00\x00\x00\x00\x00\x00}}
	New: {ptr 0x000000ef813ff770 -> {\x0c\x01\x00\x00\x00\x00\x00\x00}}

The output looks like this for a new value pointed to by a return pointer:

[...]
CreateProcessA:
	Arg[0] = ptr 0x000000ef813ff750 -> "C:\temp.exe"
	Arg[1] = 0
	Arg[2] = 0
	Arg[3] = 0
	Arg[4] = 0x0000000300000000 = 12884901888
	Arg[5] = 0
	Arg[6] = 0
	Arg[7] = 0
	Arg[8] = ptr 0x000000ef813ff790 -> L"h"
	Arg[9] = ptr 0x000000ef813ff770 -> {\x0c\x01\x00\x00\x00\x00\x00\x00}

VirtualAlloc, Return Pointer: 0x1f26bb00000 changed:
	Old: {ptr 0x000001f26bb00000 -> {\x00\x00\x00\x00\x00\x00\x00\x00}}
	New: {ptr 0x000001f26bb00000 -> {H\x83\xec(H\x83\xe4\xf0}}

CreateProcessA
	returned: 0

I plan to add another feature that will enrich the tracking of args and return values: PE and shellcode detection, memory extraction etc.

I hope all this is understandable, but before making a PR, I wanted to submit the idea here and find out if it might be possible to integrate these additions. The changes can be found on this fork (cf. the last two commits): https://github.com/maxspl/tiny_tracer.

Thanks in advance :)

[hasherezade]

Hi @maxspl ! Sorry for the delayed response. You did a good work, feel free to send me a pull request and I will merge it.

[hasherezade]

Thank you for your contribution @maxspl ! But there is one problem that I noticed.
It looks like the tracking of the arguments persists even after the function returned. Look at this fragment of the tracelog:

25b82;kernel32.HeapFree
HeapFree:
	Arg[0] = ptr 0x000001faa1130000 -> {\x00\x00\x00\x00\x00\x00\x00\x00}
	Arg[1] = 0
	Arg[2] = ptr 0x000001faa1141a30 ->  -> {C\x00\x14\xa1\xfa\x01\x00\x00}

HeapFree
	returned: 0x0000000000000001 = 1

25b82;kernel32.HeapFree
HeapFree:
	Arg[0] = ptr 0x000001faa1130000 -> {\x00\x00\x00\x00\x00\x00\x00\x00}
	Arg[1] = 0
	Arg[2] = ptr 0x000001faa1141a10 ->  -> {C\x00\x14\xa1\xfa\x01\x00\x00}

HeapFree, Arg[2] Pointer: 0x000001faa1141a30 changed:
	Old: {ptr 0x000001faa1141a30 ->  -> {C\x00\x14\xa1\xfa\x01\x00\x00}}
	New: {ptr 0x000001faa1141a30 -> {0"\x14\xa1\xfa\x01\x00\x00}}

HeapFree
	returned: 0x0000000000000001 = 1

1eac7;ntdll.RtlLeaveCriticalSection

1eac7;ntdll.RtlLeaveCriticalSection
266ba;ntdll.RtlAllocateHeap
1eac7;ntdll.RtlLeaveCriticalSection
1ea46;ntdll.RtlEnterCriticalSection
1ea9a;ntdll.RtlLeaveCriticalSection
1ea46;ntdll.RtlEnterCriticalSection
1ea9a;ntdll.RtlLeaveCriticalSection
1ea46;ntdll.RtlEnterCriticalSection
1ea9a;ntdll.RtlLeaveCriticalSection
1ea46;ntdll.RtlEnterCriticalSection
1ea9a;ntdll.RtlLeaveCriticalSection
1ea46;ntdll.RtlEnterCriticalSection
1ea9a;ntdll.RtlLeaveCriticalSection
1f990;ntdll.RtlEnterCriticalSection
1f990;ntdll.RtlEnterCriticalSection
266ba;ntdll.RtlAllocateHeap
2e680;ntdll.RtlEnterCriticalSection
2a4eb;kernel32.WriteFile
WriteFile:
	Arg[0] = 0x0000000000000068 = 104
	Arg[1] = ptr 0x000000bcb5cfe550 -> "Demo!!!
"
	Arg[2] = 0x000000000000001f = 31
	Arg[3] = ptr 0x000000bcb5cfe540 -> {\x00\x00\x00\x00\x00\x00\x00\x00}
	Arg[4] = 0

GetLastError, Arg[0] Pointer: 0x000001faa0fa0000 changed:
	Old: {ptr 0x000001faa0fa0000 -> {\x80\xe5V\x82\xf6\x7f\x00\x00}}
	New: {ptr 0x000001faa0fa0000 -> {\x18\xc2V\x82\xf6\x7f\x00\x00}}

GetLastError, Arg[0] Pointer: 0x000001faa0fa0000 changed:
	Old: {ptr 0x000001faa0fa0000 -> {\x80\xe5V\x82\xf6\x7f\x00\x00}}
	New: {ptr 0x000001faa0fa0000 -> {\x18\xc2V\x82\xf6\x7f\x00\x00}}

GetLastError, Arg[0] Pointer: 0x000001faa0fa0000 changed:
	Old: {ptr 0x000001faa0fa0000 -> {\x80\xe5V\x82\xf6\x7f\x00\x00}}
	New: {ptr 0x000001faa0fa0000 -> {\x18\xc2V\x82\xf6\x7f\x00\x00}}

HeapFree, Arg[2] Pointer: 0x000001faa1141a10 changed:
	Old: {ptr 0x000001faa1141a10 ->  -> {C\x00\x14\xa1\xfa\x01\x00\x00}}
	New: {ptr 0x000001faa1141a10 -> {0"\x14\xa1\xfa\x01\x00\x00}}

WriteFile
	returned: 0x0000000000000001 = 1

2e6a8;ntdll.RtlLeaveCriticalSection

There is HeapFree called:

25b82;kernel32.HeapFree
HeapFree:
	Arg[0] = ptr 0x000001faa1130000 -> {\x00\x00\x00\x00\x00\x00\x00\x00}
	Arg[1] = 0
	Arg[2] = ptr 0x000001faa1141a10 ->  -> {C\x00\x14\xa1\xfa\x01\x00\x00}

HeapFree, Arg[2] Pointer: 0x000001faa1141a30 changed:
	Old: {ptr 0x000001faa1141a30 ->  -> {C\x00\x14\xa1\xfa\x01\x00\x00}}
	New: {ptr 0x000001faa1141a30 -> {0"\x14\xa1\xfa\x01\x00\x00}}

HeapFree
	returned: 0x0000000000000001 = 1

The above fragment looks correct at the first glance, but when you look closer you may notice that the Arg[2] that was displayed does not belong to this call of HeapFree - it is a leftover of the call traced earlier.
Then, the arg 2 of this function reappears in the log again, after quite some time:

HeapFree, Arg[2] Pointer: 0x000001faa1141a10 changed:
	Old: {ptr 0x000001faa1141a10 ->  -> {C\x00\x14\xa1\xfa\x01\x00\x00}}
	New: {ptr 0x000001faa1141a10 -> {0"\x14\xa1\xfa\x01\x00\x00}}

This is after the function finished, so the memory at this address may be reused by anything else. We should not be tracking the changes in it at this point.

BTW, just to be clear - I refactored the code a bit, to improve maintainability, but this problem occurs in the original version as well.
This above trace was made with the commit 87fbab4461bbfc1a643fbd628e55822fd7a4399a - just after I merged your changes.

Full tracelog:
demo.exe.tag.txt

[hasherezade]

@maxspl - did you already start working on the changes? I am going to have some time for this in the upcoming weekend, so if you don't mind, I can take care of it.

[maxspl]

@hasherezade yes, I've started working on the changes we mentioned. It's not completely finished and I've still got some testing to do, but if you want an overview: maxspl@92976a4
Here's what I've changed:

• The check on args modification is only done between call entry and exit
• There's no more structure that tracks all calls, instead I've used a stack storage, I've done this to make it work even if watched calls are nested (currently I don't see if there's a configuration of the tool that would allow this but just in case, I chose this approach)
  I'll wait for your feedback before continuing, but of course if you want to make the adjustments yourself, no problem.

[hasherezade]

@maxspl - ok, that's perfectly fine. You can continue as you planned, and just send me a pull request whenever you are ready. I didn't mean to rush you, it was just a question. Just wanted to sync with you in order to prioritize what to do in my own free time.

[hasherezade]

Thank you for your cool contribution, @maxspl ! The new version, including your changes, has been released: https://github.com/hasherezade/tiny_tracer/releases/tag/3.0

[maxspl]

It was a pleasure to contribute and nice release (local functions tracing was my next feature request 😄) !