>> Hello and welcome to Cybrary.
My name is Sean Pierce, I'm
a subject matter expert for
Introduction to malware or analysis.
Today we will be covering Packers,
so, what are packers?
One-sentence, they are self decrypting executables.
A long time ago, developers noticed that if you
crack open EXE file in a hex editor,
a lot of the file is empty space full of zeros,
and as we mentioned before,
a lot of X86 code is repeated,
90 percent of all the code that's out
there consists of just 14 X86 instructions.
There's definitely room for improvement,
but PE files weren't made to
be efficient in terms of size.
Early developers made Packers,
so they are programs that would either make an
executable that's much smaller in
size than the original and when you execute it,
it would unfold or decompress,
or decrypt the original code into memory.
This is annoying for us as
malware analysts because this will hide
anything that's in the native binary
that we might like to look for,
like strings, and we will see
an example in a few minutes but we saw
that with our illusion bought example we can
just look at the strings and
the executable and we can see IP addresses,
URLs, commands, and that was really useful.
But if something is compressed,
we wouldn't see that information right off the bat.
Packers are really useful to our authors because
it hinders just the easy process
so just looking for strings and the executable,
and it also will change the hash value of
the original executable because it's
a completely different executable.
When you look at malware,
if you just download some of
the Internet or get it from malware,
exchange websites, a lot of them will be packed.
Not quite sure if I'd say majority
>> of malware is packed,
>> but a lot of it is out there.
It's hard to categorize
how much power is out there, how many variants,
versions and other things
because with the packer, you can say,
I have this malware and I'm going to pack
it and it produces new hash,
same behavior, new hash,
and then you say,
I'm going to use another Packer on
the same original file and you can produce a new file,
a new hash, but same behavior.
This is producing multiple files
that are in fact the same piece of malware,
but with different hashes.
It's hard to say, I know this is
a variant and this file is just the exact same thing,
it just had a packer on it because even if we unpack
it and somehow get the original code out,
it may not have
the same hash value because the packer may
have done something to tinker with it.
When we're looking at malware samples and
we want to see if it's packed or not,
we can look for some strings,
there won't be many, but if there are,
there are sometimes, actually,
I would say usually strings that advertise the packer.
One might be UPX and
so you might see the string UPX everywhere.
You might see another one that's
like the mystic compressor,
or [inaudible], or
something like that and if
you just Google that and can be like,
so, thermite or Packer.
Also, packers tend to
dynamically resolve all of
the functions that the original program needed,
so that means it has very few imports.
You will note, remember from
our last example with the illusion bot,
it would dynamically resolve
all of its functions that it needed.
But when we looked at the functions in IDA,
when we looked at the imports in IDA,
it only listed four or five and that was all
it needed to resolve the other functions.
Packers tend to have the same type
>> profile where it only
>> has one or two or three imports
>> in it's import section in
>> the PE header and it uses
those to resolve what
the original program had originally.
Also in packers encrypt
something or compressed something,
the result is high entropy,
as there's a lot of difference in the bytes.
Normal code doesn't have very high entropy
and doesn't have a whole lot of
randomness from byte to byte, to byte.
Most bytes are very similar
and with just compressed data,
most bytes are very different.
We'll take a look at an example
>> of that here in a minute.
>> Another indicator that a file is
packed would be that there are
large virtual sections with
very small ROD disk size and we'll see
an example here in a bit but don't let that scare you,
it's basically just virtual sections
are what the program with a PE file says,
I need this much memory when this code begins executing
and the raw disk size is
>> how much code is actually there.
>> If you have a few bytes of
code and it says it needs a whole ton of memory,
that's a little suspicious because that
means it's doing something big,
it's unfolding, it's doing something with that memory.
Of course, a program can always
ask for more memory than it
needs but most don't.
Packers are usually very specialized in their purpose,
so they're pretty much
the only software that I know it does that,
but then again, I'm not expert
in very unique development of very unique software,
I generally look at very general software,
video games and basic executables,
and packers, and crack [inaudible] and stuff like that.
When a mal author uses a packer,
generally they're trying to do three things.
One is hide strings and
other binary signatures and changing,
they try to change the hash,
so this gets in our way,
and we're going to walk
through how we can take care of this problem.
You might think, now,
why doesn't antivirus or
other security products look
for signatures of packed software?
Like I mentioned earlier,
that one of the characteristics
of a packer is that it
advertises that it is the thermite of packers,
the UPX packer, is the mystic Packer.
Well, it's because there are legitimate
>> uses for packers.
>> As I mentioned before, code compression
was the reason why they were made to begin with,
but also intellectual property protection,
so large companies might use a packer
to protect their Qi Jin algorithms,
so Photoshop, and other Adobe products tend to have
very specialized code when
they check to see if your key is valid.
Because that's their intellectual property,
if they lose that ability to sell their software,
then their business model is short.
>> This is a anti reverse engineering technique.
Not only is it done for
key generators or key checking algorithms,
but it is also done for video games to
protect the video game software from being altered so
that people can't just access
all the resources that a video game process would have.
A normal software can do this too.
If you make a small app,
and I've seen many,
and you want to protect it from
reverse engineers figuring out
exactly how you do something,
you could use a packer.
With video games, it's important because if
you play an online video game
and you have a bunch
of walls and it's a first-person shooter,
and you can shoot through the walls,
but you can't see through them.
How does the game know if
you've actually shot someone through the wall?
Well, the game server will send you
all the locations of all the players at all times.
When you shoot, the software on your end,
tells the server I shot a bullet,
and it's going this direction, this velocity, whatever,
and your software does the
>> calculation of whether or not
>> it hits the other player
and then reports to the game server,
okay, this player died because this bullet got it.
The game server might do
some checking to verify that or might not,
or maybe the players that it is describing
to your version of
the software are invisible, you can't see them.
But if you have altered your game and
you've hacked the software
to tell you exactly where people are,
even if they are invisible,
then you have a big advantage,
and people wouldn't want to play this game
where someone has a huge advantage.
This has happened before in the past.
Another related topic is digital rights management.
There's a lot of licensing built-in
to some of the more legitimate packing products,
and they say, okay,
so you license this packer,
and this packer will protect your licensing,
so no one can even execute this thing.
It won't even unfold,
it won't even decrypt unless they have
a proper key and it checks online with our key server,
and in this way,
you can protect your game from being pirated,
and so on and so forth.
Whether you believe in
intellectual property or digital rights management or
also it's stuff that's beside the points and
some reverse engineers do not believe in
that type of stuff and they go out of their way to
break these packers or licensing things,
just to say, "Hey,
I can do this, stop
trying to restrict my rights or whatever."
But the Digital Millennium Copyright Act
actually prevents people from
even researching this topic.
It's a legal gray area
where technically you are
not allowed to reverse engineer.
Some of the intellectual property protection mechanisms
built into things, for instance, DVDs.
The video isn't just
encoded on the disk, it's actually encrypted,
it's scrambled, and you need
a decryption key to access it.
There's major zones where
the DVD uses
that zone's encryption key to properly decrypt.
That's why you can't just buy a copy of a video or
a movie from China
and then put it in your DVD player and it work,
because China has its own zone,
its own keys for its own DVDs,
and North America has it's own.
Reverse engineers, for a while it was illegal for
them to even look
into those algorithms or how any of that stuff worked.
But there is an exception
in the law for security researchers.
If you are doing security auditing on a piece of
software to make sure that it is
secure and you find a vulnerability,
then you can publish your results.
You can say exactly how you did something
and you would be free from prosecution.
But if you cracked open Adobe Photoshop
and then you're reverse engineering it and you said,
"Oh, this is how those key engine
works," you publish code data around it,
>> that is illegal.
>> There is debates about this.
If you want to learn more, you can
look at the Free Software Foundation.
They are very much
against even
saying intellectual property law, will irritate them.
But keep in mind,
when you are reverse engineering,
especially defenses of software,
you may be violating law.
I'm pretty sure you can do
it with your own resources and equipment,
but if you publish it,
then that's definitely something
they will try to come after you for.
As I mentioned before, there
are legitimate uses for packers,
but I think by far,
Malware uses them the most.
The most common ones I have
seen in my line work has been UPX.
For sure, it's one of the
oldest, longest running packers,
and it is mainly geared toward compression.
Armadillo is definitely geared
towards protecting a software,
and I believe the source code got leaked awhile
ago and so on the underground
it's fairly common and you'll see a lot
of packer signature detectors
like Fire off it, Armadillo like 1.71.
I think those were originally got leaked or
maybe it was just a really flimsy signature.
ASPack is another one I've seen,
VMProtect, that's more legitimate,
it also does licensing and I
think it's tends to be very expensive.
Themida is very difficult to crack.
Really as for me I'm not an expert on packer,
but I know my way around things.
But typically reverse engineers will specialize
in unpacking or are like,
"Oh, ASPack,
I have a unpacker
for that I've written a program or whatever."
Typically reverse engineers just
do the job they need to do.
If that's finding an IP address
for the command and control servers, they'll find it.
They don't need to unpack the program or
understand every detail of how something works.
They just go for the gold and say,
okay, run this program, see what it calls out to,
and they need to say,
oh, it has these strings,
they'll just dump the memory,
and we'll go over how to do that in just a minute.
I found this image a while ago and I think it's
probably the best collection of Packers I've seen.
I wish I knew who made it, but packer or landscape.
More over on the right side,
you'll see more commercial,
more legitimately used packers,
and over on the left, the free ones tend to be
abused a bit more by Malware authors.
They are easier to unpack,
and you usually can cut through them pretty fast.
What exactly happens when an executable is packed?
Well, as you can see from these images
that I just completely ripped off the Internet.
Normally, there's several sections
>> as we've seen before,
>> an executable usually follow the convention
>> of dot text,
>> our data, dot data whatever BSS.
The entry point for the code,
usually called the OEP,
the original entry point
is usually somewhere in the dot text section.
That's where the executable code
is usually stored by the compiler.
The packer will take this whole file,
the P header, all the sections,
and it will compress all of that and then
stick it in a file that it will make,
and it'll have a little stub,
that's what they call it, and the stub will
typically unpack it in
memory when it runs and then
execute the OEP, the original entry point.
We can see two pretty simplistic images here.