Unable to see API calls for a given sample

[spookleys]

Hello,

I am have tried using this tool but I have run in to an issue. I am trying to trace the API calls used by a packed sample during its unpacking process.

The sample I am using at the moment is a basic Hancitor - 8ff43b6ddf6243bd5ee073f9987920fa223809f589d151d7e438fd8cc08ce292 (NOTE to readers - this is malware - available on malshare!)

If I run the DLL through x32dbg (just DLL_MAIN, no args) I will hit breakpoints on API calls such as VirtualAlloc and VirtualProtect after 10-20 seconds. However, I am not seeing these same API calls in the tiny_tracer output.

Is anyone able to test (in an isolated VM) and verify the same please? Should I be able to see these calls?

Many thanks @hasherezade

[hasherezade]

hi @ogbillg ! Thank you for reporting, I will check it soon.

[spookleys]

Thanks for the quick response! I am a noob so please assume I am doing something incorrectly :) I'd love to see your results.

[hasherezade]

I checked your sample briefly, and from what I am seeing, the authors used a common, and yet very effective anti-emulation trick. Introduced a significant slowdown in execution, by various loops, redundant calculations, etc. When it runs freely on a machine, the slowdowns that you can observe are like 10-20 seconds. Unfortunately PIN, just like other dynamic binary instrumentation or emulation platforms, makes execution of each instruction much slower than normal. So the slowdown got multiplied, and grown from few seconds into much longer time. In theory, it usually is possible to just wait through it, and let it run for long enough time, but it may be very frustrating. What I usually do in such cases, is I clean the code before running it: manually or by scripts. Sometimes it is just a matter of removing some loops here and there. Unfortunately here we are dealing with a well prepared obfuscator, so it is not as trivial as just removing one or two loop. The code used for the slowdown is mixed with the vital code, so it requires analyzing it first, and then writing a dedicated script that it will clean it. Currently I am busy with some other tasks, so I cannot help you, sorry.

However: what you provided seems to be a loader of the next stage, not the final payload. I was able to unpack your sample, using HollowsHunter. This is what I've got: f0d1a38c7f30b7730d6bad270cf8a09d1efed013836cee5aac78a30c67a77e0b
From what I see, this part contains no such obfuscation, and you can trace it freely. This is the log that I obtained:
https://gist.github.com/hasherezade/e703a6a157683e8fab26d36b2f4a079a (I was tracing it without the Internet connection, so if you connect, you will get more). So I hope you can proceed further from this point. BTW, in this case you need to trace not only DllMain, but also the first export. This is how you can enable it: https://github.com/hasherezade/tiny_tracer/wiki/Tracing-DLLs#calling-specific-exports . I hope it helps!

[spookleys]

Thank-you for taking the time to create that reply - I really appreciate the information you provided!

I was looking to use Tiny_Tracer to learn more about the unpacking process of samples I am reviewing. I have tried another sample and it worked perfectly so I will add it to my toolkit and play it by ear.

I will definitely give HollowsHunter a shot. Thank-you for the links you provided and the Malshare link.

Many thanks and really appreciate your time and everything you do for the community!