 Welcome to Mavic Analysis for Hedgehogs. Today's topic is Peckers from the perspective of a Mavic Analyst. So I already made a few videos about this topic right when I started my YouTube channel. But those videos are low quality, which is natural when you just started creating videos for the first time. So also in the meantime, I have trained some Mavic Analysts at work. And by now I know more precisely what are common misconceptions about Peckers. So what is actually preventing you from understanding them correctly. And I would like to pinpoint those misconceptions and make clear what is true and what is not working. So today's topic is, I explained to you how Peckers work in general, how they are used to defeat antivirus products, and why we even care about Peckers. Yeah, why do we care? Because most malware that is mass targeted, that's not APT malware, is pecked. So it's a very useful skill for a malware analyst to recognize that a file is pecked and also in the long run to know how to unpack it. But that's not the topic today. So yeah. What is the purpose of pecking? I am using a Pecker taxonomy from an academic paper here. Originally Peckers were used to compress executable files. That means shrinking their size to save space on disk. UPX is probably the most famous example. This type of Peckers also called a compressor. Peckers that encrypt files are called cryptos because they do not compress but encrypt the target file. These are for instance used by threat actors to evade antivirus detection. But they might also be used to prevent reverse engineering. In academic papers, protectors have been defined as Peckers that do both compression and encryption. The paper reference is in the video description below. But how does pecking actually work? Firstly, we have a program called the Pecker. That is for instance, UPX. The Pecker takes a file as input as well as a stub. Some Peckers take the stub as separate input as shown here, but the stub might also be part of the Pecker or generated by the Pecker. So this is just one example of several possibilities. The output of the Pecker is the pecked file. The process of producing a pecked file is called pecking. The pecked file is the stub with the target file inside which is now compressed or encrypted. The stub is also called software envelope because if you look at the file contents, you first see only the stub. The strings and headers of the target file inside are not visible without further steps because it's encrypted. By the way, those terms Pecker and pecked file are often confused. The Pecker is always the program that does the actual pecking. Think of UPX and generally, it's not the program that we see when analyzing malware. We mostly just see the pecked file. Another common misconception probably appeared because it makes sense for people who know how old viruses work. It is the idea that during pecking, the stub is injected into the target file and that only parts of the target file are encrypted. While this is possible to do, it is overly complicated for the purposes of Peckers. Injection into certain file formats like PE files isn't as easy as just compressing or encrypting the whole file because it requires detailed knowledge of the internal structures and corner cases involved in changing a compiled binary like that. Furthermore, threat actors want to make their malware undetected by antivirus products and leaving parts of the target file in plain like the headers means that the antivirus products have more opportunity to detect the file. So while it would be possible to pull this off, I have never seen any sample pecked like this except when dealing with viruses which inject themselves into a host file and may modify parts of the host file. For the goals of pecking, it also seems to have no advantages really. Let's make sure that this is a misconception by using thick lines here. Now we know how pecking works but how does the pecked file work? How does the encrypted part get executed? The stub is also called decompression or decryption stub because its purpose is to decompress or decrypt the encrypted part in the pecked file and then execute it in memory. There are two main ways used by pecked malware files to run the target file in memory. It can be done in the current process of the pecked file or it creates a child process of itself and injects the decrypt portion into it using a process injection technique. Process injection is very unusual for clean files. Using the own process to execute is usually done by reserving a section that has enough empty space in memory to put the decrypted or decompressed data inside. Such sections have a small or zero raw size but a big virtual size. So that's why this is a common sign of pecked files. UPX falls into this category as well as many other legit packers. Are there legit and malicious packers? In a sense, yes, when I say legit packers, I mean those that are used by clean programs and sometimes also by malware. Such packers are often easy to identify because their steps often contain the packer's name and tools like Detected Easy will tell you the packer's name. Maliciously used packers are those that are only used to pack malware and whose main purpose is antivirus evasion. Such packers mostly do not identify themselves. If they do, we malware analysts have an easy way to detect all the malware samples packed with them. So in such cases, packers make our lives for finding new malware and detecting it easier. Let's talk about another misconception that may arise if you are familiar with marketing campaigns of malware packers. The people who sell their packing services or packers want them to sound pretty cool. So they invented something called ScanTimeCryptor. And opposing to the RuntimeCryptor, according to the marketing campaign, the ScanTimeCryptor uses a decryption step that writes the target file to disk. For instance, into the temp folder and then it executes the target file. So there is no direct execution in memory when it comes to ScanTimeCryptors. But from the viewpoint of the malware analysts, ScanTimeCryptors are not packers. They are builders for malware droppers. A file that is built in such a way is called a dropper and it's not a packed file. So with that misconception out of the way, let's continue. I would like to add some more useful details about packed files here. How does a stub know where the encrypted content is located? A very common thing that you may encounter is the use of start and end markers. Such markers can be very useful for detection patterns. Because the encrypted part must be decrypted, you will also find the decryption keys somewhere inside the binary or key generation function. Both might be useful for writing static unpackers. But not all packed files work like that. Oftentimes the encrypted part is placed in well-known structures of the file. For instance, it could be placed at a fixed offset or directly at the end of the file. Another common location is the last section of the file. Why the last? Because the size of it can be easily expanded without affecting other sections that follow after it. The PE resources are also a common location as well as the .NET resources. What I also see often is a huge base 64 string that contains the encrypted data. An important term in connection with packers and packing is binary padding. Binary padding means that the packet changes a small portion of the file randomly. For instance, it might add random data to the packed file. This method changes the hash value of every packed file, even if the step in the input file are the same. This method is also able to circumvent block listing by antivirus products. But it does not evade any other detection mechanisms. However, this is not the same as polymorphism. If you have seen my video about polymorphic and metamorphic viruses, you will already know why this is false advertising. Actually, I find it even difficult to apply the term polymorphism to packers in the first place. But it has been established by now. So let's talk about what polymorphism means when it is used to describe packers. In packers, it refers to the ability to create unique decryption steps. Another term for that is unique step generation or short USG. That means the packer has a raw step or step pieces that it modifies into millions of possible variants to create a unique step for every packed file. Such modification can, for instance, be achieved by carrying the raw step source shuffling instructions where the order does not matter, including junk instructions and random places and compiling the step. The main difference to binary padding is that USG evades antivirus pattern detection. What is also no polymorphism is carrying like 20, 100, or even 1000 steps to choose from and picking one randomly. That would be called oligomorphism. 1000 is a small number when it comes to that. When malware reports say that a malware server delivers a new malware variant every minute, what they actually refer to is files packed by a polymorphic crypto at the malware server. If such a crypto had only 1000 steps, it would not even last one day before they are used repeatedly. The difference between polymorphic and oligomorphic cryptos is that polymorphic cryptos have so many possible step variants that in practical application, they will not create the same step twice. So what is the purpose of polymorphic packing? It is the evasion of antivirus pattern detection. Patterns are sequences of bytes that the antivirus scanner is looking for in a malware. Antivirus signatures may contain patterns among others to determine maliciousness. If that byte sequence is found and all other requirements of the signature are met, then the antivirus program detects a file as malicious. To detect malware packed by malware cryptos, the most obvious choice is a pattern over the decryption or execution code in the stub. A pattern in an encrypted portion of the file and the target file does not make sense because a small change in the target file or in the encryption key will already change entirely how the encrypted part looks like. So the stub is here, the part that will usually be detected by the antivirus program. Non-unique stubs make our lives as malware analysis easier that say someone creates a malware that is not yet detected by antivirus programs but packs it with a malware cryptor just to be sure. If that cryptor now applies the same stub that was used for other malware before, the resulting packed file will be detected as malicious although the original malware was not detected. A unique stub, however, has never been seen before. So the antivirus scanner will not be able to detect the malware by using a pattern signature on the stub. While automatic signature creation may still create a pattern for the unique stub, it will not work on the next one that was generated by the packer. Now compare this to binary padding and you will realize why it is fake advertising from both sides, the antivirus media and the marketing of cryptos. I will not go into metamorphism here because that's not a term I would apply to packers at all. If you are interested in metamorphism, watch my video about viruses. In the next video, I will cover the question how to actually know if a file is packed. So thanks for watching. Please ask remaining questions below and see you in the next video.