MSIA685 Week 8
Created on February 5, 2024
More creations to inspire you
What is a security-focused software packing tool that uses self-modifying code?
What is a software packing tool that uses single-step exceptions in order to break into the debugger?
What is a complicated packer that is very secure, but difficult to unpack and analyze?
What is a commercial packer designed for speed and performance?
What is the most common packer used for malware?
What is a graphical user interface (GUI) front-end packer designed for optimal compression, but not for security?
WinUpack ExamplesExample. Tail jump for a program packed with UPack 010103A6 POP ECX 010103A7 OR ECX,ECX 010103A9 MOV DWORD PTR SS:[EBP+3A8],EAX 010103AF POPAD 010103B0 JNZ SHORT Sample_upac.010103BA 010103B2 MOV EAX,1 010103B7 RETN 0C 010103BA ❷PUSH Sample_upac.01005F85 010103BF ❶RETN 010103C0 MOV EAX,DWORD PTR SS:[EBP+426] 010103C6 LEA ECX,DWORD PTR SS:[EBP+43B] 010103CC PUSH ECX 010103CD PUSH EAX 010103CE CALL DWORD PTR SS:[EBP+F49] 010103D4 MOV DWORD PTR SS:[EBP+555],EAX 010103DA LEA EAX,DWORD PTR SS:[EBP+447] 010103E0 PUSH EAX 010103E1 CALL DWORD PTR SS:[EBP+F51] 010103E7 MOV DWORD PTR SS:[EBP+42A],EAX
In this listing, the tail jump at ❶ is in the middle of the unpacking stub, so it is difficult to spot. A push instruction at ❷ followed by a return instruction is extremely common for a tail jump. The code jumps all around before arriving at the tail jump in order to make it harder to spot. To further obscure the tail jump, the push that precedes the retn instruction is modified by the packer shortly before it is called. The jump is also not very far, so you can’t identify it by searching for long jumps. Because the OEP is in the same section as the unpacking stub, OllyDump cannot automatically identify the tail jump via its section-hopping method.The best strategy for finding the OEP for a program packed with UPack is to set a breakpoint on GetProcAddress, and then single-step carefully over instructions looking for the loops that set the import resolution. If you set the breakpoints at every jmp or call instruction, you will be single-stepping forever, but if you set the breakpoints too sparsely, the program will probably miss your breakpoints and run until completion.
- The best strategy for finding the OEP for a program packed with UPack is to set a breakpoint on GetProcAddress, and then single-step carefully over instructions looking for the loops that set the import resolution. If you set the breakpoints at every jmp or call instruction, you will be single-stepping forever, but if you set the breakpoints too sparsely, the program will probably miss your breakpoints and run until completion.
- Do not be discouraged if the program runs to completion without hitting your breakpoints. Simply restart the application in the debugger and try again. Making mistakes is a part of the process. Eventually, you will single-step onto a ret instruction that is the tail jump.
- Sometimes, recognizing the tail jump can be tricky. In this case, it jumps about 0x4000 bytes away. Most unpacking stubs are much smaller than 0x4000, and a jump of that size usually is a jump to the OEP. A good way to double-check is to examine the code around the OEP, which should look more like ordinary code compared to the unpacking stub. The unpacking stub often has many conditional jumps and returns in the middle of a function, but the code around the OEP should not have these unusual elements.
- Another strategy that works on UPack is to set a breakpoint on GetModuleHandleA for GUI programs or GetCommandLineA for command-line programs. In Windows, these functions are called shortly after the OEP. Once the breakpoint is triggered, search backward through the code to find the OEP.
- Sometimes WinUpack crashes OllyDbg by using a PE header that OllyDbg parses incorrectly. In Chapter 16, we showed that OllyDbg isn’t perfect and has issues parsing binaries that run just fine on Windows outside the debugger. If you encounter this problem, always try to use WinDbg before attempting to decipher PE header errors.
Themida incorporates robust features that hinder analysis through tools like VMware, debuggers, and Process Monitor (procmon), with an added challenge posed by its kernel component, which operates with fewer restrictions than user space. Despite offering enhanced security, the resulting packed executable is unusually large, and unlike typical packers, Themida's code runs continuously alongside the original program. Automated unpacking tools exist but their success varies based on Themida's version and the packing settings. Due to Themida's diverse features and settings, finding a universal unpacking strategy is impossible. Alternatively, when automated tools fail, a practical approach involves using Microsoft's ProcDump to dump process memory without debugging, enabling analysis and string extraction even in the presence of advanced anti-debugging measures. While this process doesn't fully restore the original executable, it facilitates analysis of the code while the program is running.
UPX (Ultimate Packer for eXecutables) is open source, free, and easy to use, and it supports a wide variety of platforms. UPX compresses the executable, and is designed for performance rather than security. UPX is popular because of its high decompression speed, and the small size and low memory requirements of its decompression routine.Because it’s fairly easy to overcome, UPX is a good packer for learning how to manually unpack malware. However, many stealthy malicious programs are designed to appear to be packed with UPX, when they are really packed with another packer or a modified version of UPX. When this is the case, the UPX program will not be able to unpack the executable.You can find the OEP for UPX by using many of the strategies outlined in your textbook. You can also use the Find OEP by Section Hop feature in OllyDump, or simply page down through the unpacking stub until you see the tail jump. Dumping the file and reconstructing the import table with OllyDump will be successful.
WinUpack: although security isn’t its focus, WinUpack does include security measures that make it difficult to find the OEP, and render techniques such as searching for the tail jump or using OllyDump useless. This example shows the tail jump for this executable.
Petite is a software packing tool akin to ASPack, employing anti-debugging mechanisms, utilizing single-step exceptions, and recommending the use of hardware breakpoints on the stack to find the Original Entry Point (OEP). It features a complex code structure, making the OEP discernible once in close proximity, and retains at least one import from each library in the original import table, facilitating identification of utilized DLLs without the need for unpacking.
ASPack: Although you may successfully unpack an ASPack packed file using automated techniques, most likely you’ll need to unpack files manually. Begin by opening the code for the unpacking stub. Early in the code, you will see a PUSHAD instruction. Determine which stack addresses are used to store the registers, and set a hardware breakpoint on one of those addresses. Ensure that it is set to break on a read instruction. When the corresponding POPAD instruction is called, the breakpoint will be triggered and you will be just a few instructions away from the tail jump that leads to the OEP.
PECompact: Programs packed with this packer can be difficult to unpack, because it includes anti-debugging exceptions and obfuscated code. Unpacking PECompact manually is largely the same as unpacking UPX. The program generates some exceptions, so you will need to have OllyDbg set to pass exceptions to the program. You can find the OEP by looking for the tail jump. Step over a few functions, and you will see a tail jump consisting of a jmp eax followed by many 0x00 bytes.