 there are a lot of resources on unpacking samples out there. And still, when I started out as a weather analyst, I did not find them sufficient. I got lost in them. It was, I just didn't understand when to use which unpacking method. And there's almost no guide or tutorial out there that tells you when to use which and how to know what to do if you don't find a specific packer for the sample. So I'm gonna attempt to do that today and give you at least something you can start out with. So one generic unpacking approach that I found relatively efficient. And an overview to the methods, to the unpacking methods you can use. Let's try. Let's start with unpacking methods. What different ways do you have to unpack samples? These methods might not be comprehensive, but these categories are enough to summarize all of the things I have used so far. So first, there is run and dump. Run and dump is very easy and fast. You simply execute the file and use a tool to dump the payload. Examples are Hashirizad's mel unpack tool or just something like system informer, which you can use to dump the memory. This has the advantage and also the disadvantage that you don't need to know how the unpacking stub works. Why is it a disadvantage? Because in some cases, you want to know how it works. Maybe you need to write detection signatures on the stub behavior or describe it in a report or find out why it does not run in a specific sandbox system. Secondly, there is static unpacking. That includes using or writing static unpacking tools, recipes for Cybershift or binary refinery command lines. Static unpacking needs to know exactly how the unpacking stub works. It is easy for mev unpacking stubs to break these tools, but it is ideal for simple encryption algorithms and a good approach for writing extractors that can be run safely without risk of executing mev code. Thirdly, the self-extracting patch. This method is applicable if you can easily modify the sample. You change the sample so that instead of executing the payload, it will save the unpack payload to a file or print it to the command line. Four is emulation. Whether this is applicable depends on the sample. Emulation is vulnerable to anti-emulation mechanisms. Many samples in the wild have these anti-emulation tricks. Sometimes it is easier to do than static unpacking and can be applied more generically. The last method is debugger and breakpoints. It is probably the method that is taught the most when it comes to unpacking. It is a manual and dynamic unpacking method. Usually it requires less effort than static unpacking and you do not need to know every detail of the unpacking step, just its basic approach. For instance, you do not need to know the exact decryption algorithm for the target code. You just let the sample do the decryption. Let's now give you a framework for a generic unpacking approach. That means I'm gonna give you an overview on when you can apply which of these methods. If you have been doing malware unpacking for a while, you will have your own approach. This is not the only working approach that I'm giving you. It is just one you can start with and modify as you see fit. But especially as a beginner, it helps to have such framework. The first step is identification. If you haven't already, please watch this video about packer identification. Identification means you try to identify the exact packer that was used to pack the file. So you put the sample into a tool like Detected Easy and you see if it can identify the packer. But this only works for legitimate packers that do not try to hide from antivirus scanners. Malware creptors which only pack malware usually cannot be identified this way. If you had no success, you need to continue with the next step. If you had success, please search for the packer name on Google, check the packer's website, look for something that tells you if it is using virtualization as an obfuscation technique. For instance, VM Protect and Tamida fall into that category. If the sample is not virtualized, Google Unpacking and the packer's name, you will find either a tool or a guide on how to deal with this packed file. For instance, the compressor UPX has also an option to unpack files. If your file uses virtualization-based obfuscation, as a beginner, you should stop right here. This is not a sample that is suitable for beginners. If that is a topic that highly interests you, check out Tim's workshop on virtualization-based obfuscation to get a feeling about the effort to break these kind of packers and the concepts you need to know about them. I will put the workshop in a link into the video description below. But in most cases, you should concentrate on other goals at first and be able to unpack the other kinds of packed files before you attempt to unpack virtualization-based obfuscation. If you haven't been successful with unpacking, skim the file for obvious encryption. What do I mean by that? For instance, you should always check the strings of the sample with sysinternet strings exe. There you may find a large base 64 string in the file. If you do, simply try to decode the string and see what you get. Other very obvious encryptions are large integer arrays, especially in script-based malware or big exord areas. Integer arrays can be easily decoded with binary, refinery, or cyberchef. Simple exor encryption with one byte keys or small key length is something you will also be able to see with the naked eye, especially in areas of the target payload that contain zeros. In that case, the key itself will be visible. If you suspect exor encryption, you can use an exor brute forcing tool like exor tool or the exor brute force command that you can specify with binary refinery. One video where we took this approach is unpacking all the stuff with large obfuscated script. Check this one out. For these simple encryption cases, it is ideal to use static unpacking as a method. Cyberchef, binary, refinery, or your own small Python script will do. Now, where do you look for obvious encryption? If the file is small, skim through it with a hex editor. If it is bigger, check some key areas. These key areas include the overlay, the end of the file, the resources, both PE resources, which you can see with resource hacker, and dotnet resources, which you can see with the Nspy. The last section, and of course the strings listing. The third step is run and done. Because this method is easy to do, we try this before we consider any more complicated methods. One easy way to do it is to download Mail Unpack and execute the following command line. Instead of this, you can also use automatic unpacking services like UnpackMe, create process dumps with system informer or download dumps from sandbox systems, like any run or VMray. If that is not helping, then you continue with debugger and breakpoints. This method has three steps. API logging, breakpoint key functions, and dump and fix. First, you need to get an idea how the unpacking stuff works. Many people do this by checking automatic sandbox reports, but anything that gives you some API logging will surface. Some other examples are API monitoring tools like API monitor, API tracing with the debugger using emulators that print API logs, like speak easy, and anything you can think of. What you look out for is APIs that you can break on in the next step, breakpoint key functions. What kind of APIs are these? Firstly, any APIs that perform memory allocation like virtualElloc are used by almost all unpacking steps because they have to put the unpack code into some allocated memory. So often people may just try and break on virtualElloc, follow the allocated memory in the debugger hex view and see what is written into the location. VirtualProtect, if it adds execution rights to a memory area can be interesting too. Here's an overview of memory allocation functions and which functions are called by which functions. Key functions are also functions that transport target data like write process memory, functions that execute the target's code, that create a process, especially if that is in a suspended state, or functions that decrypt, decompress or decode the target data like RTL decompress buffer. An overview that can help to identify such key functions is this here, which applies specifically to packed files which perform process injection. It is not complete, it certainly needs some updates by now as new injection techniques are invented all the time, but it is a good start. If you want to see a video on this topic where I approach unpacking file with API logging and debugging and breakpoints, check out the Agneane Stealer native step to the net unpacking video. The last step is dump and fix. When your debugger breaks at a point in time where the target data is in a decrypted state, you dump it to a file. Afterwards, you may still have to perform some fix ups before you can continue. For instance, the file might be memory mapped. So you have to unmap the file first. Watch this video about memory mapping to understand this better. Oftentimes you need to change the entry point of the executable to the original entry point called OEP. Or you may have to rebuild the import table. In more rare cases, you may have to fix an erased header. Now, this unpacking approach that you can use as a framework did not include two methods that I mentioned at the beginning, namely emulation and the set extracting patch. So when would you use these? Emulation is something that you can do in this approach chain instead of the debugger and breakpoints step. So if that is something that interests you, you can put it there. Check out Dumpulator or SpeakEasy for emulation scripting with Python. I will add video references for each method in the description below, so check it out, especially OA Labs has quite some videos on Dumpulator. The self-extracting patch is very interesting for packed scripts because scripts can be changed easily. If a script contains, for instance, an evaluation or execute function, replace this function with a command that writes the unpack code either to a file or to the command line. Again, I will put a reference for this in the video description. One final note on this generic unpacking approach. If you train the debugger and breakpoints method for the first time, do not follow this approach. Use the debugger and breakpoints directly. Otherwise, you only get the difficult samples for step four as they are successfully unpacked by run and dump, for instance. And if you start out, you want to train the easy stuff first and then go forward with the more difficult stuff. If you want to learn method analysis from the ground up, then check the link in the description below. There's a link to my Udemy course for beginners. It contains 11 hours of video content and the link is the coupon link that's a little bit cheaper for you than buying it from Udemy itself. So check it out and maybe I see you there.