Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-25 22:20:43 +00:00
Code Issues Projects Releases Packages Wiki Activity

GitBook: [master] 411 pages modified

Browse source
This commit is contained in:
CPol 2020-12-09 00:31:50 +00:00 committed by gitbook-bot
parent 70f526e104
commit e36a12f477
No known key found for this signature in database
GPG key ID: 07D2180C7B12D0FF
2 changed files with 31 additions and 23 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
reversing/common-api-used-in-malware.md
View file

@ -49,24 +49,24 @@
| Name | |
| :--- | :--- |
| VirtualAlloc\(\) | Alloc memory \(packers\) |
| VirtualProtect\(\) | Change memory permission \(packer giving execution permission to a section\) |
| ReadProcessMemory\(\) | Injection into external processes |
| WriteProcessMemory\(\) | Injection into external processes |
| VirtualAlloc | Alloc memory \(packers\) |
| VirtualProtect | Change memory permission \(packer giving execution permission to a section\) |
| ReadProcessMemory | Injection into external processes |
| WriteProcessMemoryA/W | Injection into external processes |
| NtWriteVirtualMemory | |
| CreateRemoteThread\(\) | DLL/Process injection... |
| NtUnmapViewOfSection\(\) | |
| QueueUserAPC\(\) | |
| CreateProcessInternalW\(\) | |
| CreateRemoteThread | DLL/Process injection... |
| NtUnmapViewOfSection | |
| QueueUserAPC | |
| CreateProcessInternalA/W | |
## Execution
| Function Name |
| :--- |
| CreateProcess\(\) |
| ShellExecute\(\) |
| WinExec\(\) |
| ResumeThread\(\) |
| CreateProcessA/W |
| ShellExecute |
| WinExec |
| ResumeThread |
| NtResumeThread |
## Miscellaneous

30
reversing/cryptographic-algorithms/unpacking-binaries.md
View file

@ -1,14 +1,22 @@
# Unpacking binaries
* lack of strings
* search for JMP's or CALLs to registers or regions of memory. Also search for functions pushing arguments and an address direction and the 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.
* Start analysing the packer from the bottom in IDA before moving up. Unpackers exit once the unpacked code exit so it's unlikely that the unpacker passes execution to the unpacked code at the start.
* If the unpacked code gets executed use a tool such as PE-Sieve to dump the unpacked process once it has executed and unpacked itself
* 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 `VirtualAlloc`. If you find yourself in a function that apparently only has those functions 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 navigate to therein order to bypass that unpacking code.
* 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.
* Custom packers normally won't have much strings and functions, commercial packers are stealthier and they will have them
* While trying to unpack code a good way to know if you are already working with the unpacked code \(you 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.
* To jump from a call to an API function \(like VirtualProtect\) to user code you can press the "run to user code" button
## 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).