Anti-Analysis Part 2

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

3 hours 41 minutes
Video Transcription
Hello and welcome to anti analysis Part two.
In this session, we're going to learn about some anti reverse engineering techniques.
This is gonna be a brief overview. As a lot of these techniques are quite advanced, it will be covered in their own separate. Siri's
probably one of the most basic anti analysis techniques that mount where authors employ is looking for if they're matter where is being debugged.
Now we're uses a variety of techniques to see f a D buggers attached, and these include using the windows A P I s such as the function you see here is the bugger present.
This is one of the simplest AP functions that and malware author could implement to check for the bugger
other a P s include check remote debunker, present anti query information process and output debug strength.
Some of these AP eyes were designed for to bugger detection, and some were designed for other purposes. However, the easiest way to overcome anti debugging AP I functions is to modify the malware not to call these functions.
Speaking of the day, bugger, Remember that buggers use break points to step through a process. However, also remember that When you're stepping through your code, the debunker modifies the code. In the process.
There's several anti debugging techniques to detect this type of debugging behavior
into scanning and timing checks.
What is an in three, though
this is a software interrupt use by the buggers to create a break point. When the do Bugger sets a break point, it modifies the code by inserting a CC instruction.
A common anti debugging technique is for the Mauer to scan this process for this instruction,
timing checks or another popular way from our to detect the buggers.
This works by seeing how much time has elapsed while it processes running. As you single step through a program, the execution will be much slower. Not only can malware a scan if it's being debugged, but it can also interfere with the bugger functionality
Techniques such as thread, local storage callbacks and interrupt insertion try to disrupt the program's execution if it's being rung in a do bugger.
When you load a program into do bugger, we've seen that it pauses at the first instruction, which is typically the entry point. However, this could be modified to execute code before this point. This is a thread local storage call back. It's used to execute code before the entry point.
Interrupt insertion is a form of anti debugging, similar to inserting our CC instruction.
Depending on the the bugger settings, thes insertions could cause the bugger to stop.
To prevent malware from being analyzed by us, the analyst malware authors try to confuse us by adding code or data into a program that will make disassembly fail. Now there's a few ways that these air implemented. But in most cases, the malware author creates a code sequence or an algorithm
that tricks the dis assembler into showing a different list of instructions
than the ones that are supposed to be executed. This works by taking advantage of a linear dis assembler.
For instance, the dis assembler. Can Onley represent each bite of a program as one instruction at a time when the dis assembler is tricked at the wrong, offset instructions can be hidden from view.
In this code segment, we can see that we've got a call instruction, but the target of the call instruction doesn't make any sense
because the first instruction is a jump whose target fails because it's in the middle of the next instruction. You could see this by the indication of a plus one. Here,
you can somewhat pick these out sometimes. Typically the coat around. The instructions will be highlighted in red, indicating that the disassembly has failed in some way
underneath where you've got the same code segment. But instead we used a flow oriented dis assembler rather than a linear, dis assembler,
flow oriented disassemble to make choices and assumptions. Now you would think that choices and assumptions might seem unnecessary, but simple code instructions are complicated by the addition of problematic code aspects such as pointers exceptions and conditional branches. The second fragment reveals a different sequence of assembly instructions, and it appears to be correct.
Here we can see the call to the A P I function. Sleep.
The target of the first jump instruction is now properly formatted,
and we can see that it jumps to a push instruction, followed by the call to sleep. The bite on the third line of the example
zero X e eight. This is not executed by program because the jump instruction skipped over it.
Now there's many ways to implement anti disassembly techniques, and the primary way is to basically force this assembler to provide you inaccurate results by taking advantage of the choices it makes
thes air implemented by forcing this assembler down a specific disassembly path that will never be executed when the process is run.
Popular techniques that use these types of implementations are jumps with the same target address
jumping to an instruction that always has the same condition, for example, using a Jay Z instruction when we always know the condition will be zero. And other techniques that will explore in the later Siri's include misusing structured exception handlers and abusing how the dis assembler uses the call stack.
Okay, so let's wrap up the Malware Challenges module with a brief summary.
Up Next