 Hey, have you ever heard someone say that packer identifiers can tell you if a file is packed? This is not true. Let's talk about that. By the way, if you haven't seen my video about packer misconceptions yet, please watch it before that one. So what is the difference between detection and identification? Detection answers the question of whether a file is packed or not. Detection on the other hand answers the question what packer was used to create the packed file. Tools like PEID or detected easy are so-called packer identifiers. These tools can sometimes tell you the names of legitimate packers, installers, compilers or wrappers that created the file. Legitimate packers are those that are used to pack both clean and malicious files. Because they are legitimate, they have visible patterns in the decryption step, sometimes even their name in the section names. For instance, Vibu code meters section names are __vibu00 and so on. They do not have a reason to hide that. You can look up these patterns in the signature databases of PEID if you are curious. For detected easy you just have to press on the little s button to be directed to the signature. In contrast malware packers are only used to pack malware. Their main purpose is antivirus evasion. For that reason antivirus products will detect their stub over time. As we have seen and understood from the last video, old un-maintained malware packers create files which are detected by antivirus scanners, even if you pack calc.exe with them. These malware packers, if they are reasonably made, do their best to not have any obvious names or patterns in the decryption step that the antivirus can pick up easily. For that reason they are not detected by identifiers like PEID or detected easy. Why is it useful to identify the packer? Because you can find unpacking tools for them and simply google information about them that help you unpack the file. What about packer detectors? Is there something like that? There are some tools that can determine heuristically if a file is packed, but they do not perfectly detect a packed file. They just assume it based on common characteristics of packed files. You do not need these automatic tools as an analyst though. For you, the actual characteristics are interesting to know how to proceed with analysis or unpacking. But let's first talk about how dynamic unpacking usually works. I told you that packer identifiers do not tell you if a file is packed. Beginners who assume that they do often fall into a particular trap. They unpack a file based on a tutorial, drag and drop the unpacked file into PEID and it still shows the file is being packed by upx. So they assume they failed and did not really unpack anything when actually they did everything right. Why does this happen? A packed file on disk usually looks like that. It has the decryption stub and somewhere the encrypted target file. The header of the file tells Windows the entry point where to start execution. The entry point points to the stub because that is the part responsible for decrypting the target file. That obviously needs to happen before it can be executed. Members that unpacked the file in their own process often define a zero-sized section on disk that will have a bigger size in memory. This section is meant to hold the decrypted data of the target file and because it is not needed on disk its raw size is zero. In memory the zero-sized section has now grown and is empty at first. The stub first decrypts the encrypted data, then writes it into our zero-filled section. After that it passes execution to the decrypted target file. Now what happens if you want to unpack the file? You stop execution at this point at the so-called original entry point or OEP. That is the address of the first instruction in the target file. So you stop execution here and in the header you change the entry point to the original entry point. So that target is executed directly. You do not need the stub anymore once the file is unpacked. Now look at your dump. You may already see the answer to your question. Unless you deliberately removed the stub from the dump, the stub code is still in there. If we now put our unpacked file into PEID it will still detect a pattern in the dump. Some patterns of PEID are dependent on the entry point and would not match anymore but others will still identify the packer that the stub belongs to. Time is true for detect it easy or any other tool that searches for patterns in the stub or in the headers. And that is why packer identifiers do not tell you if a file is packed. So now the question becomes how do I know if a file is packed? There are some signs for that. For instance, often times there is high entropy where the encrypted target file is placed. You may remember the common target file locations from the last video. Those are something to look out for. The entropy of the whole file is not that relevant but local entropies can tell you where the target file might be. Strings are often almost non-existent in the packed files. But then there are of course some packer authors who got the idea to use word lists and fill the decryption stubs with random English words to make it seem more legitimate. The same happens with imports. Packed files do not have many of them but sometimes they include garbage inputs on purpose. Or you deal with, for instance, .NET assemblies which often have only one PE import regardless if they are packed. So there are exceptions to every rule. Depending on how the packed file is structured, the decryption stub may also inject the target file into a child process. The presence of import combinations, which are typical for injection, may indicate that. Load library and get proc address are a common pair of APIs imported to resolve imports dynamically. The import reserving is something that decryption stubs commonly do to provide the proper imports for the target file. The presence of the child process, which is attached to the same executable is also an indicator of packed files. Taking triage, this is something you will commonly see in a sandbox report and can already tip you off that this might be a packed file using self-injection. We also saw in our dynamic unpacking example that a small or zero raw size section that is bigger in memory can be an indicator for a packed file. Large base 64 strings are also typical. Among checking the strings of a file I recommend to use byteplot visualizations and to look out for areas with ASCII color pixels. For instance in Portex Analyzer these are blue areas. Base 64 strings, which are large enough to hold, a PM image are often also big enough to show up there. But you can also see big areas filled with seemingly arbitrary numbers or images filled with noise that are encrypted target files. There are more possibilities but these are the most common ones. You might notice that a lot of these are also true for droppers. Droppers are not packed files in contrast, to packed files they drop the payload on disk and execute it. But since they have to carry an often encrypted payload and also work in some ways similar to packer steps, some of these signs are present in them as well. How do you know if it is a packed file or a dropper? Thankfully that is easy to answer, you run the dropper either in a sandbox or use a tool like process monitor. If these tools show that the dropper writes a file and executes it, check if that file is a copy of the original or if it's a different file. If it's a different file then it's a dropper. If it's the same file it is just a way for the malware to put itself into the right place for instance as a preparation for persistence. What you should notice by looking at this list is that you cannot tell if a file is packed based on these horistics alone. To be sure of that you will actually have to disassemble or decompile the file, read the code and try to unpack the target. I can tell you this was something that made me very a lot as a beginner. I thought if I don't get this question right at first try I'm failing as an analyst. The truth is, malware analysis involves a lot of guessing. After guessing you collect proof by following the lead of your guess. If that turns out to be wrong and you disprove your guess, you take some steps back, make another guess, then rinse and repeat until you get proof for every guess that's relevant for your analysis report. What I'm saying is don't worry. Take a good guess and if that turns out to be wrong, that's fine. That is the usual workflow of malware analysis and not a sign that you failed. Experienced analysts are as clueless as you are when try aging a file. They just know how to find and follow the leads faster.