Bypassing Anti Analysis Techniques

Questions
,
1

I’m currently trying to reverse windows x86 malware to identify small sections of code of the malware that make it malicious. I’m using immunity debugger and running into issues.

As i’m stepping through the code I can see certain win32 api calls in the code, while there is a string like c73rfg.exe in a register. Which makes me think i’m about to see something happen, however I then run into what seems like an infinite loop and never reaching those win32 calls. I set breakpoints just before the win32 calls, however when running it instead exits execution. I’m quite confused and have a few questions

  1. How does malware actually run differently under analysis? I.e. does the binary actually change or does it just take a different branch of execution when running?

  2. What can I do to make it behave normally under analysis?

  3. Do Malware authors write these anti analysis techniques into the malware themself or is there a tool to optimize the code?

thank you

2

Interesting question, I’d like to know as well.

3

What’s the difference between normal Execution and a binary “under analysis” ?

One has a debugger attached to it, the other doesnt :slight_smile:

One (Windows-)function being isDebuggerPresent.

 if(IsDebuggerPresent())
 {
   TerminateProcess(GetCurrentProcess(), 1);
 }

IsDebuggerPresent reads the BeingDebugged byte from the PEB, so that could be another check.

These are just 2 possible checks that happen on Windows, there’s a lot more, and you can find some pretty good resources here too.

Like this one for example.

Well, it “knows” you attached a debugger, so you’re gonna have to tell it there’s no debugger there!
Lucky for you, a lot of debuggers have scripts to auto-hide your debugger against a lot of different features.

One such plugin, is ScyllaHide.

Well, I suppose a lot of people just copy pasta SO code, also, implementing something like “IsdebuggerPresent” is not that hard as you can see above.

Of course, the amount of effort you put into obfuscation and anti-debugging / anti-vm / … will result in higher effort on the other side (to reverse it back).

I’m not aware of any tools that automatically implement advanced anti-debugging, but this is of course without consideration of packers and crypters.

2 Likes
4

Jarvis gave a very detailed answer.

I would like to add that in most cases you will never directly encounter calls to APIs in obfuscated malware samples, and even if you would it’s not worth the time too look for them.

I would suggest to set direct breakpoints on these APIs and to view the call stack to see what exactly is going on and where are these calls being made from(In x64dbg its done by executing bp/h <API_FULL_NAME> in the command prompt under the debugging view).

Setting memory breakpoints on all the APIs you see as not always a good idea, you should be very goal oriented when performing unpacking otherwise you’ll just get lost.

If you have no experience with malware unpacking I suggest you do two things:

  1. Subscribe to OALabs on YouTube, most of the knowledge I gained in anti analysis was from that channel.

  2. Get yourself a copy of Practical Malware Analysis and read chapters 15-18.

Hope I helped, feel free to DM me or find me on Discord :nerd_face:

2 Likes
5

Thanks this helped a lot! :grinning:

2 Likes
6

hi,
if you’d like to learn more about anti reverse-engineering techniques, there are several good resources under the AntiRE topic.
I first learned about these in “Anti Reverse Engineering for Linux” Free eBook - though it is written for linux, many techniques can be adopted under windows.
Additional there is the AntiRE binary collection that might help understand different techniques under lab conditions.

I hope these might help you :slight_smile:

1 Like
7

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.