>> Typically, I have a slide for notes for the paranoid.
Well, there are more advanced Packers out there.
I've seen some that have multiple layers,
where it will unfold
one layer and then that layer will just in
turn unfold another layer and then
that will in turn unfold another layer.
Maybe in somewhere,
there's some built-in defenses,
like anti-analysis code or anti-debugging code,
to make sure a debugger isn't
being used to take it apart.
Between here and there and between the layers,
there's lots and lots of junk code.
Just meaningless instructions or
meaningless function calls,
stuff to distract you, annoy you.
If you look at a Packer for a while,
you typically are able
to eye the junk code. You can figure it out.
That might sound strange,
but honestly the person who wrote
the Packer isn't going to go to
a huge amount of effort to deter you
because a week for
them might be an hour for you to overcome.
I remember one Packer,
it did a weird jump call move combination,
where it would move a value from
EAX to ECS and then a few instructions later,
move ECS back into EAX.
It was pretty easy to pick out where it was
saving these registers and where it was restoring them.
It was pretty easy to see that the function calls
another Packer was using
didn't even check the return values
of those function calls.
It was easy to see which function calls
it actually was paying attention
to and the other ones that were just throw away values.
A lot of Packers have custom encryption.
When you get into more reverse engineering,
you'll see that there are
crypto APIs in the operating system
that some Packers will call,
some Packers will implement its own crypto,
we go for open source and AES,
Advanced Encryption Standard,
or open source RC4, or whatever else.
They copy paste because it's easy,
it's fast. It works.
Maybe they might tweak it a little so you can't
just use a tool out there
or use code that
you found out there that they were using.
There might be custom encryption,
but it's nothing you can't
overcome because with a debugger,
we can easily step through
every step of every part of it.
As you saw in the demo, we could easily just step
over stuff or just run straight through things.
Some of the most advanced Packers out
there will actually convert
>> all of the original code that
>> it was told to pack and it will convert it into
another language pretty much
and then execute that language
in its own virtual machine.
You might think about that and be like, what?
Well, if you think about Java,
you can take a dot Java file,
which is English readable strings and it compiles it
into a byte code
so that the Java virtual machine can then execute it.
Java is a well-understood virtual machine.
It's not that big of
a deal to make a disassembler for it.
But Packers that create
their own virtual machines each time,
it's very difficult to
disassemble that code because even then it might be
obfuscated or your disassembler
might not be able to handle some of the tricks
it has built-in and
it could create a rather complicated virtual machine.
At that point, it's not worth your time usually to
reverse engineer what it's
doing instruction by instruction.
Usually, you just want
to get whatever data you're targeting out of it,
like an IP address,
or a domain name,
or a particular configuration.
I wouldn't worry about those much.
If you ever come across a very advanced Packer,
then spend some time on it,
get to know what it's doing.
But definitely don't waste your time.
Learning is good.
I highly suggest that maybe you
just take a solid week and go through
a more difficult Packer or a tutorial online
about how to pack something like AS unpack or AS pack.
But definitely don't spin your wheels
on something that's not worth your time.
Because as a reverse engineer,
you're generally paid a lot and you know a lot
and you have a very detail-oriented view of something.
Packers are meant to distract
you and some of them are really good,
but they are usually very expensive,
so they're not that common.
Just a recap of what we
covered and a list of good resources.
We talked about what packers are,
some of the more common ones and then we
took the most common UPX.
Then we saw how to pack something,
how to unpack something.
We saw what exactly it's doing to the
executable and how it actually
unfolds it in memory or decrypts it in memory.
This does require a bit of assembly knowledge and
in particular the PUSHAD and POPAD instructions
because those are not usually,
as I said, admitted by compilers.
It's not usually generated code.
If we see that, we usually think,
something a little funky is going on here.
Those are excellent instructions to look out for.
I suggest the Practical and also
Cookbook because as we saw their scripts,
even though they're a bit old,
can be very enlightening
to see exactly what's going on in
a PE file and can
give us some good indicators
of whether a file is packed,
like what the entropy or the virtual sizes versus
the raw sizes of
what's on disk versus what's going to go in memory.
Practical Malware Analysis has
a decent section on Packers.
I'll suggest that you check those out.
There are plenty of Packers out
there freely available for download.
If you want to build
a simple Hello World program and then pack it with
a dozen different packers and
then see how each one is doing its thing,
that is a great way to learn.
You're going to learn 90 percent
of this with doing it yourself.
Again, my name is Sean Peters.
I hope you enjoy this video and we'll see you soon.