Indicators of Packers

#1

Hello 0x00sec fellas!
I want to start by saying that I love what you’re doing here. I’d like to thank all of you who contribute to this community even if a bit. Thank you all :two_hearts:

Anyway enough with the emotions :smiley: Today I’m here with a compiled list of packer/crypter indicators that I can think of. Using these you may be able to detect if a packer/crypter is applied to your subject of analysis. Please feel free to make additions!

Lets Start.

1. Packer Signatures
Well obviously first thing to look for is the presence of any signatures related to already known packers or crypters (I’ll only use the term “packer” from now on). You could use PEiD, yarascan or any other tool really. Here is an example;
resim

You see that PEiD found a signature match of UPX packer. The thing with signatures is that there can be false positives. Maybe author has made a loose definition while creating the signature, or maybe malware developer simply false flagged the binary. Long story short, don’t rely on them. Actually don’t rely on any single or combination of indicators. They are what they sound like, indicators not facts.

2. Abnormal Entry Point / Section Names
Some packers create new sections to store the packed executable or stub code then arbitrarily name those sections. Regular section names for PE files go like; text, bss, data, rsrc, rodata. Sometimes compilers create some additional sections in order to store things like debug symbols etc. Whatever I see other then these names instantly raise my suspicion.
resim

3. Section or Memory Regions with RWE Permissions
This is another obvious one. Sometimes a packer allocates a section/memory region in order to store the unpacked code. So this region would need to have both writable and executable permissions; which is weird because compilers don’t do that by default cuz of security reasons. This is an anomaly. It may occur in runtime so you may wish to trace API calls related to memory permissions.

4. Abnormal Difference Between Section Vsize and Psize
Physical size is the space occupied by a section on the disk while it’s not running. And virtual size is the size on memory while it’s running. Abnormal differences between these two values may indicate the presence of a packer. Because while not running the code will be compressed, hence small in size. When it begins to run though malware will try to decompress the code so its size will increase abnormally.
Example;

You can also see that this example possess other features we have mentioned earlier as well.

5. Data Sections Are Too Large
We generally divide sections into one of two types; code section or data section. As the name suggests code sections are the ones which contains code, and data sections are the ones which contains drumroll data! For example when you define a variable in a program it gets stored in one of the data sections depending on how you define it (bss, data, rodata, rsrc…). Naturally we expect a program to contain more code than it contains data. Unless it’s designed to print out a play of Shakespeare for some reason. Whenever I see a data section that is too large I suspect that it might contain an executable file inside it.

6. Too Few Imported Functions
When a file is packed normally you would only see the functions used by its unpacker stub code. Most probably there will be stuff related to memory allocation, mem permissions, module load, resources operations… So if it seems like the program imports abnormally few functions you could suspect of a packer.

7. Section with High Entropy
Shannon’s entropy is an algorithm to calculate frequency of recurrences in a given data. It calculates a score over eight. Lesser the recurrences, higher the entropy (score). So if you see a section or file which’s entropy score is close to or above 7.0 you could suspect that the data inside it is encrypted, hence might be packed. Because increasing entropy is what any decent encryption algorithm is supposed to do.

That’s all from me for now. Please feel free to add :slight_smile:

19 Likes

#2

pestudio

Thank me later. :wink:

5 Likes

#3

i am well aware of the tool :slight_smile: it helps to know what to look for and where to find it from an investigator perspective

0 Likes

(exploit) #4

This post was flagged by the community and is temporarily hidden.

1 Like

#5

I heard of these types of programs before but I never knew they were called packers, that will aid my future research into these topics :slight_smile:

Since I’m a complete n00b at packers I hope you don’t mind if I ask a few questions.

  • How easy is it to unpack a packed binary?
  • How long does it take for a packer to get reverse engineer’d to allow to unpack packed binaries?
  • Is VMProtect a packer? Can you unpack binaries protected with VMProtect?

Also what are your opinions on packers? I’d love to know more about this topic :slight_smile:

0 Likes

#6

I’m glad that you enjoyed my topic. I will try to answer your questions as long as my knowledge let me so. Please free feel to add/correct any missing or false information.

it depends. is the packer a known and widely used one? for example it’s fairly simple to unpack an upx packed executable. if a custom packer has been applied, sometimes simple unpacking tricks work; like running the exe a little bit and looking for RWE memory regions, PE signature etc. then dumping the region. other times you may need to reverse engineer the whole thing.

depends on the encryption/packing algorithm used, anti analysis measures if there are any and your reverse engineering skills obviously.

it is a “protector”. meaning it’s a crypting + anti analysis + anti forensics + maybe virtualizing code etc. whatever needs to protect the code from piracy (remember, purpose of a packer is shrinking the file not protecting it). as to my information there are some unpackers for some versions of vmprotect. newest versions employ code virtualization and a bunch of anti forensics/analysis methods as well. it is not impossible ofc but it would be fairly time consuming i believe.

1 Like

#7

Hey thanks for your reply! I’m still not 100% sure on how packers work but from what I understand packers are simply programs that have their instructions encoded in some way. (Encrypted file / zipped file / anti RE crap / …). Correct?

And packed files need to unpack their code at some point, does this mean they just save it to memory or do they unpack instructions as they go (and what performance impact would that have)?
If they unpack all their instructions right to memory wouldn’t you just be able to take a copy of the memory and inspect it that way?

0 Likes

#8

the name “packer” is used too broadly nowadays. when they were first introduced their only purpose was to shrink an executable file by using data compression algorithms (like the ones used in winrar, 7zip etc). in those times most antivirus software deployed only static signature based detecion methods. these “packers” come to corrupt the “signatures” on an executable while compressing it and hence a packed executable could evade AV detection more easily. little after that this behavior was noticed and these “application packers” got widely adopted by malware developers. this is how this innocent tool of binary shrinking got weaponized. then some malware developers rolled out their own packers and also introduced encryption features into these “packers”, in order to better evade detection. then the term “packer” evolved into a different and broader meaning than it was before; covering both encryption and compression employment with the purpose of AV evasion. Now they may also contain anti forensics and analysis methods as well. But this is where the term originated.

1 Like

#9

There are many different types of packers out there. The ones that are concerned with malware and are probably the most common ones come with both encryption and compression. These are labelled “run-time” (as opposed to “scan-time”) packers meaning that they will deobfuscate the original code in memory and execute it without touching disk. The reason this is important is because if the deobfuscated malware is dropped to the disk (“scan-time”), it may trigger an anti-virus to scan its exposed code.

In order to unpack in-memory, the obfuscated malware code is contained within what’s known as the “stub” which is responsible for the recovery and initialisation of the original malware. Essentially, the stub is its own functional code - either shellcode or full PE file - basically a manual executable linker.

Using UPX as an example, UPX compresses the original binary and generates a new PE file. This PE file has at least two main sections, .upx0 and .upx1. upx0 is actually empty in terms of raw “disk” size but its virtual size (in memory) is as big as the original binary’s size. upx1 contains both the compressed binary as well as the assembly “stub”. What the stub does is it will locate the compressed code and decompress it back into the upx0 in memory (remember the virtual size is big enough to contain the original binary). It will then initialise the original binary by applying relocations(?), rebuilding the import table functions, and then call the .tls functions if they exist. When this is done, it will jump execution to the original binary’s entry point from where it will continue normal execution like nothing happened.

Most of the times with the average packer, you can do this. If we are speaking about protectors, it’s a different story. Parts of the original bytes may be intentionally misplaced or replaced with equivalent code and spread across memory which will provide the same functionality, but results in the original code being fragmented. Some examples of this include API redirection or byte stealing. Protectors like VMProtect may virtualise the code which means that the original code is unrecoverable.

So if you want to get into building these packers, you may need to understand the executable file formats, how they interact with memory, and the Windows operating system.

5 Likes

#10

Thanks for both your well written replies, I was able to learn a lot from them!

0 Likes

#11

For some AV vendors UPX is an indicator of malware(increase the detection ratio). I don’t fully understand why malware developers keep using it. Any idea?

0 Likes

#12

IMHO AV vendors should not be increasing the detection score if an application is packed using classic UPX because it can be trivially unpacked. About malware developers using UPX, I don’t really see any reason for it besides compression. I’ve only ever seen or heard of this in skiddy skid malware builders such as those public .NET RATs, etc. If I were developing (new) malware, I should not need to use a packer however, if I reuse something that is already known and has signatures, I would develop my own packer rather than use something like UPX.

1 Like

#13

Pretty easy unpack UPX and simple packers. There are tools that do this. VMProtect is paid for crypter and no easy to reeverse. AV will flag packers so not good for red team

0 Likes

(system) closed #14

This topic was automatically closed after 30 days. New replies are no longer allowed.

0 Likes