GDATA Security_Blog: Unpacking 101: Writing a static Unpacker for Ldpinch

[harlan4096]

What is Ldpinch?

Ldpinch is an old info-stealer malware, which tries to steal credentials for different applications from a victim's PC. The malware runs on Windows Systems with 32bit support and is a regular Portable Executable (PE).

Why unpacking?

Like most malware, Ldpinch is packed to make reverse-engineering and manual analysis more difficult. In a "packed" file, the assembly instructions which describe the behavior of the program are not directly available in the binary on disk. Instead, when the malware is loaded into memory, an unpacker decrypts the encrypted instructions to enable the CPU to execute them. If a malware analyst wants to reverse-engineer the malware, they first have to unpack it. Otherwise any disassembler will only display meaningless gibberish.

How to unpack Ldpinch

In this section we will see how Ldpinch can be statically unpacked in such a way that all assembly instructions become visible in a disassembler.
The SHA256 of the malware sample used is: cc65200e7c748e095f65a8d22ecf8618257cc1b2163e1f9df407a0a47ae17b79
We will use Cutter to reverse-engineer the malware samples. Cutter is a free and open-source disassembler and reverse-engineering tool, based on the radare2 reverse-engineering suite.

First impression

After opening the sample in Cutter, two things immediately stand out:

First, usually a PE file has the entry point somewhere in the NTDLL, which runs some initialization code. After that, it is handed over to the entry point of the application itself. In the case of Ldpinch, the entry point is a custom entry point appended right after the CODE section of the PE file. Cutter calls this entry0 at the adress 0x100026e4.

The second unusual property of the binary is that the CODE section has the write attribute. This means that it is possible to overwrite code, while the sample is executed. For security reasons, the CODE section is usually read and execute only.

These two properties are a strong indicator for a packed malware sample. The malware needs to overwrite the packed code with unpacked code, which is the reason for the writable CODE section. The unpacker itself needs to be somewhere, so the malware authors just appended it to the CODE section.

To verify our assumption, we take a jump to the CODE section by double clicking on it in the comments window. You should now see a few jumps which we can ignore. Right after the jumps, the code for the application should start, but instead there are a lot of assembly instructions which make no sense in this order and even a few invalid instructions. This is typical for packed code. The disassembler tries its best to disassemble the machine code to human readable assembly instructions, but in this case the output is either invalid or simply wrong. This confirms our suspicion that the CODE section is packed.

Full Reading