Introduzione all'unpacking dei malware

Malware authors often use packers to hide their malicious code. Think of a packer like a protective shell around the original program.

This shell compresses or encrypts the malware's core logic. The goal is to make it harder for security analysts to understand and detect the threat.

Packers serve several key purposes for malware:

• Evade Detection: Signature-based antivirus tools struggle to identify packed malware. The packed form looks different from the original, known malicious signature.
• Obfuscate Code: It hides the true functionality, making static analysis (looking at the code without running it) much harder.
• Reduce Size: Sometimes, though less common for malware, packing can reduce the file size, similar to a ZIP file.

When a program is packed, its original code is transformed (compressed/encrypted) and embedded within a new small piece of code called the "stub".

When the packed program runs, the stub executes first. Its job is to:

• Allocate memory.
• Decrypt or decompress the original program code into that memory.
• Transfer control (jump) to the original program's entry point.

How can you tell if a file is packed? Here are some common indicators:

• High Entropy: Random-looking data (like encrypted data) has high entropy. Tools can measure this.
• Unusual Sections: Packed files often have custom or renamed sections (e.g., .UPX0, .RLC) with unusual permissions.
• Lack of Imports: The file's import table (list of external functions it calls) might be very small, as the stub does the loading.

Tools like PEiD or Detect It Easy (DIE) can often identify common packers.

Unpacking is the process of reversing the packing operation. Our goal is to retrieve the original, un-obfuscated code from memory and save it to a new file.

Once unpacked, the malware becomes much easier to analyze using static analysis tools (disassemblers) and debuggers, revealing its true intentions.

The most critical step in manual unpacking is finding the Original Entry Point (OEP). This is the memory address where the original, unpacked program code begins execution.

The packer's stub will eventually jump to the OEP after it has finished decrypting/decompressing the original program. Your task is to find this jump.

In a debugger (like OllyDbg or x64dbg), you can find the OEP by:

• Tracing: Step through the packer's stub until you see a long jump (JMP) or return (RET) instruction that leads to another memory region.
• Hardware Breakpoints: Set a hardware breakpoint on the code section of the packed file. When it's written to (unpacked), the debugger will pause, often near the OEP.
• API Breakpoints: Set breakpoints on common API functions like LoadLibraryA/W or GetProcAddress, which the original program might call soon after unpacking.

Once the program has executed its unpacking stub and landed at the OEP, the original code is now available in the process's memory space.

You can use your debugger's functionality to "dump" this memory region to a new file on disk. This new file will contain the unpacked executable image.

Tools like ScyllaHide or built-in debugger features can assist with this.

The dumped executable often has a broken or incomplete Import Address Table (IAT). The IAT tells the program which external functions (from DLLs) it needs to call.

Tools like Import REConstructor (ImpREC) or Scylla can analyze the dumped file and the running process to rebuild the IAT, making the unpacked executable runnable and analyzable.

In this lesson, we explored the world of malware packers, understanding why they're used and how they work. We learned to identify packed files and outlined the key steps for manual unpacking: finding the OEP, dumping memory, and fixing the import table.

Mastering these basic unpacking techniques is crucial for advanced malware analysis, allowing you to reveal the true malicious code for deeper investigation.