In this article, we will try to explain the terms packer, crypter, and protector in the context of how they are used in malware. Bear in mind that no definitions for these categories are set in stone and that they all have overlap and that there are exceptions to the rules. But this is the classification that makes sense to me.

What they all have in common is their goal

The payload, which is the actual malware that the threat actor wants to run on the victims’ computers, is protected against reverse engineering and detection (by security software). This is done by adding code that is not strictly malicious, but only intended to hide the malicious code. So the goal is to hide the payload from the victim and from researchers that get their hands on the file.


This usually is short for “runtime packers” which are also known as “self-extracting archives”. Software that unpacks itself in memory when the “packed file” is executed. Sometimes this technique is also called “executable compression”. This type of compression was invented to make files smaller. So users wouldn’t have to unpack them manually before they could be executed. But given the current size of portable media and internet speeds, the need for smaller files is not that urgent anymore. So when you see some packers being used nowadays, it is almost always for malicious purposes. In essence to make reverse engineering more difficult, with the added benefit of a smaller footprint on the infected machine.


The crudest technique for crypters is usually called obfuscation. A more elaborate blog post on that is Obfuscation: Malware’s best friend. Obfuscation is also used often in scripts, like javascripts and vbscripts. But most of the time these are not very hard to bypass or de-obfuscate. More complex methods use actual encryption. Most crypters do not only encrypt the file, but the crypter software offers the user many other options to make the hidden executable as hard to detect by security vendors as possible The same is true for some packers. An in-depth analysis of one crypter (as an example) can be found in our blog post Malware Crypters – the Deceptive First Layer. Another thing you will find in that post is the expression FUD (Fully Undetectable) which is the ultimate goal for malware authors. Being able to go undetected by any security vendor is the holy grail for malware authors. But if they can go undetected for a while and then easily change their files again once they are detected, they will settle for that.


A protector in this context is software that is intended to prevent tampering and reverse engineering of programs. The methods used can, and usually will, include both packing and encrypting. That combination plus some added features makes what is usually referred to as a protector. So a researcher will be faced with protective layers around the payload, making reverse engineering difficult.

A completely different approach, which also falls under the umbrella of protectors, is code virtualization, which uses a customized and different virtual instruction set every time you use it to protect your application. Of these protectors there are professional versions that are used in the gaming industry against piracy. But the technique itself has also made its way into malware, more specifically ransomware. Which enables ransomware that doesn’t need a C&C server to communicate the encryption key. The protection is so efficient that the encryption key can be hardcoded into the ransomware. An example is Locky Bart that uses WProtect, an open-source code-virtualization project.


We discussed several techniques to protect malware against analysis, hoping to make sense of the different names that are in use for this class of programs.