>> Now, we saw like it's being debugged and we saw
a find window Anti-Debugging trick and
OutputDebugString trick and there are many more.
There are lots of things like if you see in the bottom
right end 0xCC scanning,
that scan for the three soft breakpoint instruction.
Remember how I said that with a debugger,
if we hit "F2", it will replace that instruction
>> with the CC byte,
>> which is the N3 instruction that when the process is
executing and it hits
that instruction and hands over
control to the anti-debugger,
which is in another process.
Now some malware will look for that byte,
the 0xCC byte and its own code.
It's just looking for debuggers and the way around
that would be to use a hardware breakpoint,
instead of a software breakpoint like 0xCC or N3.
There's lots of API function calls,
both documented and undocumented
that malware authors will use.
They'll look at various data structures in memory.
They'll look at whether certain memory flags are set.
They'll look at many, many things.
The time, as I mentioned
before but this is not an exhaustive list.
In fact, there are many more techniques and
tricks that come out not all the time,
but it's not uncommon for a new technique to come out.
The thing about these tricks and techniques is
>> they only slow down malware analysts.
>> They don't stop us and it's
a losing battle in terms of time.
If a malware author spends three or four days figuring
out a new anti debugging technique
it'll take us 10 or 15 minutes.
If we're decent reverse engineer,
it will take us 10 or 15 minutes to bypass that,
either patch it or whatever.
There was a trend awhile ago about
more anti-virtual machine techniques
and there are lots of cool things you can do with this.
But that's faded away because a lot of
infrastructure nowadays and small companies
or medium-sized companies is all virtual.
If you hardcode stuff into your rat
>> or Trojan or malware,
>> that just kills itself
when it's detected in a virtual machine.
You can't infect like 90 percent
>> of the infrastructure of your
>> target company because they virtualize
>> your Active Directory service or server,
>> they virtualize file server,
they virtualize their ORTP server,
they virtualize their whatever else.
A lot of malware will say,
"okay, I'll infect it, I'll even run,
I'll even do a normal thing,
but I am going to report back as
soon as possible that I am running in a VM."
But it's more common to say,
I'm anti-cuckoo sandbox or
I'm anti Geo Sandbox or I'm anti firearm,
anti whatever else, threat creditor,
glue court or whatever.
I mentioned anti disassembly earlier and
here's a pretty basic example of that.
We saw before with like illusion bot where
>> IDA Pro didn't pick up the fact
>> that it was just going to another section of memory.
It figured out that that was code,
but didn't figure out how it was
being called but IDA Pro has
a very advanced disassembly algorithm.
However, not all disassemblers are,
only debugging has a pretty good one.
But there are some disassemblers
that will just look at one instruction,
say, "okay, this instruction is four bytes in length.
What's the next one? This one is
two bytes in length, what's the next one?
It's three bytes in length. What's the next one?"
That's called a linear disassembler.
On the left we can see
some basic assembly that you can put into
your C code or
Visual Studio project and the first instruction is XOR,
EAX, EDX, that's just zeros out EAX as we've seen.
We can say jump zero,
it will jump somewhere else and then right after that,
we can put a byte like 0xEA,
where that doesn't actually disassembled to anything.
Or if the disassembly gets confused and says,
"okay, it's part of a larger byte, 0xEA, AB,
Ff or whatever," is still
going to break all of the code beneath it,
because it's trying to say, okay,
this instructions is this, how many
bytes onto the next one.
This instructions one byte,
this instruction is two bytes,
whatever and your program could have jumped to where
the real good code is and
the disassembler will just
break because it's not following that jump.
However, IDA Pro
has a pretty good disassembly algorithm and
will follow the jumps if it can
and some malware authors as
a way to fool IDA Pro will do this,
say XO EAX EX jump,
you know, EDX plus EAX.
IDA Pro doesn't know that the final jump destination is
a constant value but IDA Pro
is pretty good at
this stuff and IDA Pros been around for a while,
it's the best in the industry, I think.
They've developed a lot of
algorithms to get around that type of stuff.
Over on the right,
we can see another kind of trick and
that's dynamic co-generation colic packers.
Where one instruction like move
EAX is moving in there a pointer,
a label called changeMe,
EAX is right there,
has the address of changeMe and then
the next instruction is move 0x90,
which is a NOP, no operation code,
and moves it into the location of EAX,
NOP is one byte.
Let's say the first byte of what
changeMe is pointing at could make no sense whatsoever.
It could be just jump code
until that first byte is knocked out and then
>> the rest of the code will just makes sense because
>> the processor doesn't actually check to
>> make sure that what it's doing makes sense.
>> The processor just executes code,
it just executes the bytes, whatever it gets.
If it gets an invalid instruction,
it throws an exception otherwise
it'll just keep chugging through.
You can actually jump
into another instruction and that is
a technique that some packers or malware authors will
use where they say,
okay, here's a bunch of move instructions.
Now here's a jump instruction that jumps into one
of the previous move instructions and this
breaks all disassemblers currently
because they only look at something as,
okay, this has been assembled
despite it has been accounted for.
This has been assembled, these three bytes have been
accounted for and can't really
comprehend the idea that this byte could be
this instruction and can also be part of
this instruction and some other ways.
Some newer ways that malware is one family that I know
of is breaking disassemblers is it's
like switching between 32-bit and 64-bit code,
which is really tricky,
hard to do and it's currently breaking all disassemblers.
Back to debugging real quick.
If we're running Ali debug and we
saw that that call is being debugged and we thought,
what is it actually doing and
>> jumped into that function.
>> We would see there's only three instructions
or four instructions
where it's only checking a little bit.
Like literally it's checking a bit in memory to see if
it's one or a zero and then returns that bit,
wouldn't it be cool if we just patched that bit to be
zero and there are plugins for Ali, like LTE-Advanced.
>> I think all the AD or
>> all the anti-debugger or whatever,
>> where it basically goes through a bunch
of these anti-debug checks and neutralism.
This is an anti-anti-debugging technique,
where the code has some anti or the malware has
some anti-debugging technique and we
are taking care of that.
We are either hooking that function,
or we're modifying the result of that function,
or we're modifying the memory address
which is that function checks,
or whatever we're doing.
We can lie to the application.
I've used this all the advanced plug-in before.
It's for only 1.1,
I believe, or one.xx.
We'll work on one dot,
whatever versions of volley.
I haven't really played with all the 2.0,
all that much and I haven't really played for,
played with their debugging capabilities
or anti-anti-debugging capabilities.
Mainly because I'd like
to know actually what my tools are doing,
and if I don't know what a plugin is doing,
I can't really account for it.
I use the light, usually I like to run
without any plugins unless I absolutely have to.
What we did was patch the program.
We can also patch the memory and we can
also use a plugin like this.
However, what we did when we
patched the executable was we
changed machine code and that can be accounted for.
The malware could have
some integrity checking algorithms,
it could have anti-dumping code.
It could have a few different things that could happen.
What I mean by that is,
there's a simple CRC check.
I think it's correction
or code or cyclic redundancy check what CRC stands for.
I've seen some malware where it'll
run some code and then do it,
check where it says,
for the last 100 bytes or something,
hash that in to tool like an output of
a four byte hash and then check it against this value.
It's this value, then great, keep going.
If it's not, the mouth or nose has been tampered
with and can terminate or do whatever,.
Not only more now we'll do this,
but commercial software do this to.
The worst I've seen is Skype.
Skype has a ton of anti-reversing,
anti-debugging, and anti-patching,
things built into it.
I think I've seen a malware where it'll check
its own code two or three times and Skype,
I think I've seen it, do it 33 different times.
Skype can be pretty tricky about what it does because
is very protected software.
More than anything else I've ever seen,
>> more than games,
>> which is the biggest user of anti-debugging stuff
or anti-reversing or anti-pattern
or ant-modification, whatever.
Of course, the other technique we can use
besides anti-anti-debugging techniques is
we can just not use a debugger.
There are programs out there that
will just inject a DLL into a process,
and this monitor everything it does.
There are things that try to instrument hook
all the functions that might be
called and they just monitor through those.
There are software out there
that just all run them our and then dump
the memory and pause it if it's a virtual machine or
just stop it when it
gets to a certain code page
by throwing an exception or something like that.
Just a quick recap and a little brush up.
Usually malware has a goal of
stopping automated analysis,
so they have anti-sandbox and anti-VM stuff,
and to slow down our analysts,
so they'll have anti-debugging or
anti-virtual machine stuff or anti-disassembly stuff.
With anti-debugging, we've seen
some API calls is being debugged, being called.
We've seen some process and thread stuff.
Whether you I knew it or not,
when I said that is being
debugged is only three or four instructions,
and it checks a certain part of the memory.
It was checking a
>> certain data structure called the PEB,
>> the process environmental block,
and it was just
checking for that one little bit in there.
It was just in the user land,
and the malware didn't even need to call that function.
It could have just executed
those four instructions by itself.
Which is not something a lot of malware authors do.
But as an analyst,
you should be familiar with those instructions,
particularly the FS register,
because it checks the PEB,
the process environmental block,
and there are a lot of flags,
there's a lot of bits and bytes in there that will
indicate whether a process is being debugged.
Anti-debugging, hardware and register
based ways of getting rid of debugger.
Like I was mentioning earlier, hardware breakpoints,
certain registers that debuggers use.
If you want to know more,
I will give you more resources here in the next slide.
There's exception base. We didn't really cover that.
But because debuggers want to instrument a program,
they will get what's called a first chance exception,
so if your program does a divide by 0,
it will throw an exception.
The process here will throw an exception,
and if you have a try catch block in your code,
your C code or C# code or
for C# uses SEH, structured exception handling.
Other programming languages have other things built-in,
but they're mainly based
around exceptions, structured exceptions,
and when an exception happens within a process,
the first chance exception goes to the debugger
before the malware will
take care of a problem like divide-by-zero.
The debugger will take over first,
and then it'll give you the ability to look at memory,
look at values and variables that we'll look at
the call stack will look at all this other stuff
because there's debugger is meant to get rid of bugs.
It's meant to help you. If you just say, continue,
if you change something remembering say,
there's a bug and it's malware
which happens all the time.
I was dealing with it today actually.
Then continue, it won't call
the exception handler or
the exception code in the malware.
The malware could have a flag in there.
It says, if this flag didn't get checked,
we know that a debugger is
attached and intercepting those exceptions.
There's a few different methods built around that idea.
>> We talked about the modified code based anti debugging,
where it checks its own code either for the CC byte
or Syriac CC byte or the N3 instruction.
Or it'll just do a hash check or CRC check of
the code that it's about to execute or that it has
executed and checks it against usually
>> a four byte hash.
>> If it's different than what it's expecting,
then it knows it's been modified and
will take whatever actions at once.
We also talked about timing based,
where I mentioned that
some malware we'll just call asleep function.
We'll see if it actually slept that long or if
it's being short circuited
or knocked or hooked or whatever.
But an older technique is actually where
the malware will execute a number of
instructions and then see how
fast it took to execute those instructions.
There are instructions in X86 that says, oh,
give me the real time clock rate,
or give me whatever.
You can actually determine how much time has
passed between executing different instructions.
It used to be based off the idea
that virtual machines are
usually jam packed onto
very high and powerful computers,
but there's several virtual machines going at once,
the processes switching between them.
Virtual machines actually take much longer to execute
instructions, than physical ones.
The timing based attack was,
or detection was meant to determine if
you're in a virtual machine
via how fast you are executing code.
There is lots of anti virtual machine things
that we talked about,
not just API calls, or not just
>> programmed process names or memory constants,
>> or things in the API,
or instructions that you can or
can't execute within a VM.
But there are things like
certain API calls or
ports that are open to virtual machines only.
VM ware, what we've been running,
or what I've been running, opens
up a special input and output port.
That's how copy and paste works and that's
how drag and drop works,
is it communicates information through
this port that doesn't exist in normal machines.
A popular anti, or
a popular virtual machine detection trick
is to see if that port is available.
As I mentioned earlier,
a lot of malware doesn't
seem to concern the disinfection in a virtual machine
anymore because targets are
usually on virtual machines as well.
We went over some anti disassembly
techniques ware like dynamic code generation,
or assembly meant to
specifically break algorithms of disassemblers.
If you want to know more,
I would suggest going online to
symantec's anti debug reference
where they've collected from over the years,
malware doing various things for
anti debugging or anti reversing,
anti analysis, whatever.
The open RCE forum, open RCE.org.
They have a pretty impressive library
and source code available for
anti reversing or anti debugging examples.
If you're interested in
>> anti virtual machine techniques,
>> Pafish or paranoid fish made
by Alberto Ortega is pretty good.
The code project.com,
that article shows a lot of source code,
sea level, assembly level source code
of how to implement reverse engineering techniques.
It's not aimed at malware authors,
it's more aimed at people who want to protect
their game from being pirated or
protect their intellectual property.
The two papers at the bottom I highly suggest
reading and there are talks that go along with them.
Source code, anti debugging and developers
>> view is really good as scientific but not academic.
>> Academic overview of malware anti debugging,
anti disassembly anti,
VM ware technologies, that's really good.
The scientific, the last one I just
mentioned is Rodrigo Branco,
Gabriel Barbarossa, and Pedro Nieto.
Tyler Shields is the one who
did the developer's viewpoint.
Practical malware analysis has
some good chapters devoted to it.
Two years ago about I did a talk at NoVA hackers,
a Chaconne epilogue, where I had collected
>> all of the techniques that I had ever observed.
>> I put them in one giant project and I
had taken all this code
and I developed a game around it,
where you can execute this piece of malware and it will
choose a random anti debugging trick,
random anti VM trick,
random technique of communication via
IRC or HTTP or random install persistence mechanism,
via registry run,
via service or whatever else.
Then it would hide on the system and then
the malware analyst would have to go and look for it
and then bypass those anti debugging or anti VM tricks,
to get at an encrypted string.
Then the encryption was random as well,
or you can specify all of them.
If you're interested in these techniques,
this technology as I am,
I would suggest implementing
a lot of these things yourself.
Don't go just writing malware and releasing it,
but it's good to be familiar
with how these things work at a pragmatic level,
so you can not only develop it
yourself and reverse engineer it yourself,
but understand where the pivot points are.
Like say, oh,
I made some anti VM code based on paranoid fish,
but it doesn't actually work under this circumstance.
One technique doesn't work if you're
running multiple cores in
your VM. It's good stuff to know.
It's good to be aware of this stuff.
Again, my name is Sean Pierce,
I've been the resident expert
for malware reverse engineering.
If you have any questions,
my Twitter is here
and I've mentioned my email
before, Cybrary@SecureSean.com.
I hope you enjoyed this video series.
I wish you good luck.