mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-26 14:40:37 +00:00
22 lines
3 KiB
Markdown
22 lines
3 KiB
Markdown
# Unpacking binaries
|
|
|
|
## Identifying packed binaries
|
|
|
|
* **lack of strings**: It's common to find that packed binaries doesn't have almost any string
|
|
* A lot of **unused strings**: Also, when a malware is using some kind of commercial packer it's common to find a lot of strings without cross-references. Even if these strings exist that doesn't mean that the binary isn't packed.
|
|
* You can also use some tools to try to find which packer was used to pack a binary:
|
|
* [PEiD](http://www.softpedia.com/get/Programming/Packers-Crypters-Protectors/PEiD-updated.shtml)
|
|
* [Exeinfo PE](http://www.softpedia.com/get/Programming/Packers-Crypters-Protectors/ExEinfo-PE.shtml)
|
|
* [Language 2000](http://farrokhi.net/language/)
|
|
|
|
## Basic Recommendations
|
|
|
|
* **Start** analysing the packed binary **from the bottom in IDA and move up**. Unpackers exit once the unpacked code exit so it's unlikely that the unpacker passes execution to the unpacked code at the start.
|
|
* Search for **JMP's** or **CALLs** to **registers** or **regions** of **memory**. Also search for **functions pushing arguments and an address direction and then calling `retn`**, because the return of the function in that case may call the address just pushed to the stack before calling it.
|
|
* Put a **breakpoint** on `VirtualAlloc` as this allocates space in memory where the program can write unpacked code. The "run to user code" or use F8 to **get to value inside EAX** after executing the function and "**follow that address in dump**". You never know if that is the region where the unpacked code is going to be saved.
|
|
* **`VirtualAlloc`** with the value "**40**" as an argument means Read+Write+Execute \(some code that needs execution is going to be copied here\).
|
|
* **While unpacking** code it's normal to find **several calls** to **arithmetic operations** and functions like **`memcopy`** or **`Virtual`**`Alloc`. If you find yourself in a function that apparently only perform arithmetic operations and maybe some `memcopy` , the recommendation is to try to **find the end of the function** \(maybe a JMP or call to some register\) **or** at least the **call to the last function** and run to then as the code isn't interesting.
|
|
* While unpacking code **note** whenever you **change memory region** as a memory region change may indicate the **starting of the unpacking code**. You can easily dump a memory region using Process Hacker \(process --> properties --> memory\).
|
|
* While trying to unpack code a good way to **know if you are already working with the unpacked code** \(so you can just dump it\) is to **check the strings of the binary**. If at some point you perform a jump \(maybe changing the memory region\) and you notice that **a lot more strings where added**, then you can know **you are working with the unpacked code**. However, if the packer already contains a lot of strings you can see how many strings contains the word "http" and see if this number increases.
|
|
* When you dump an executable from a region of memory you can fix some headers using [PE-bear](https://github.com/hasherezade/pe-bear-releases/releases).
|
|
|