17
Generic definition
Binary packers alter the original binary data, and restore it (more or less) before execution.
Their different names depend more on their characteristic: it's difficult to clearly distinguish, as just putting an anti-debug and a Xor loop would make a packer also a protector and a cryptor.
types
extension
extra packer code is executed
...
14
UPX doesn't check the unpacking stub's integrity, and just blindly restores the data from the stored information, not from the actual execution.
Since UPX is open-source and documented (commented IDB), it's easy to modify its and actually do something extra (anti-debug, patch, decryption, jump to real entrypoint...) that will be lost when 'upx -d' is used.
...
14
I'm not sure if it's still around, but Themida used to have a kernel-mode driver component that facilitated some of the protection features. It could well be installed on your system and catching the debugger out.
My first suggestion would be to try Immunity Debugger. It's an Olly fork that is designed for offensive debugging and exploit development, but it ...
11
Fooling upx -d can be as simple as one byte patch here is a small sample.
Pack the MS-Windows standard calc.exe, hexedit one byte and result is an undepackable executable with upx -d (this is not corrupting the exe, the exe will run and can be unpacked manually). Only unpacking with the -d switch wont work.
create a new folder foolupx:
foolupx:\>md ...
11
SimplePack is simple and open-source (albeit in ASM, not in C)
SimplePack is not trivial, yet simple enough so that I typically use it myself as a first 'hands-on' for binary packer training.
also, my minimalists packers (source/binaries) in python (EP-patcher, compresser, cryptor, dropper, protecter, virtualizer, mutater). No real use, but made as ...
10
The unpacker will request a page of memory from the OS that is marked write and unpack the code into there. Once the unpacking is done it will use VirtualProtect on windows or mprotect on posix compliant systems to change the protection bits to read-only and execute (or allocate the page as read-write+execute in the first place and skip making it read+...
9
Definition
We'll define a packer as an executable compressor.
Packers reduce the physical size of an executable by compressing it. A decompression stub is usually then attached, parasitically, to the executable. At runtime, the decompression stub expands the original application and transfers control to the original entry point.
Packers exist for almost ...
9
This looks like what you want: sePACK
A simple windows .exe/.dll packer. (Compresses code section and your
compiled binaries waste less space) Almost whole codes written in pure
C and very minimal also understandable (which makes modifying very
easy; like debugger traps, encryption etc.)
8
No there is not. You can make it harder to reverse engineer, but there's nothing you can realistically do to make it impossible, if there's enough incentive to reverse engineer your application. Professional malware researchers routinely reverse engineer much tougher stuff then anything you'll find publicly.
Theoretically, it may be possible using fully ...
8
Apart from the classix UPX, you should take a look at Burneye (With its crackers, UNFburninhell and Burndump) and elfuck. They are pretty old, but still interesting.
If you are interested about tricks that can be used, this is a good introduction by aczid, and I would also recommend Binary protection schemes for a more complete overview.
Someone also ...
8
It's very easy to prevent the UPX tool to unpack an UPX compressed file. If you take a look to the source code you will see that it checks for the magic string UPX_MAGIC_LE32 in p_lx_interp.cpp. So, I simply changed all matches of the string (in binary chunks) "UPX!" to "AAA!". I copied /bin/ls (ELF64) to another folder and packed with UPX. Then I edited it ...
7
This is a topic that has a ton of depth depending on how crazy you want to go but I'll try to break it down into chunks as much as possible and you can look at each one as much as you want. I'll mention the theory behind the steps and some details about how to do them mechanically as well.
Generally the packer is going to do these things:
First, you'll ...
7
VMProtect uses a few anti-debug techniques. Firstly, you aren't going to want to tackle them on your own because there is quite and exhaustive set of techniques to detect a debugger. Consider using an anti-anti-debug plugin (ScyllaHide)
One you are probably going to encounter that is difficult to work around is the rdtsc instruction.
rdtsc essentially ...
6
I recommend you to take a look to Yoda's Protector. There is a version with source code. Unfortunately, it doesn't work on Windows 7 for some reason (but does work on Win XP). Apart from this, I don't know any other open source packer or protector (except UPX, as you mentioned).
6
Depending on what you're looking to accomplish, you have a handful of options:
Use RL!dePacker 1.5, which supports unpacking Stone's PE Encryptor 2.0. The technology at the core of this unpacker, TitanEngine, has been immensely improved since its implementation back then, and is available as open source via ReversingLabs. Official video tutorial from RL can ...
5
Here are 4 open-source packers, written in Delphi (you can convert to C++ if you want):
ExeFog 1.1
Polymorphic Crypter, Morphine
AHPacker 0.1
GHF Protector 1.0
If you don't have a copy of Delphi, you can use the open-source Lazarus IDE with the Free Pascal (FPC) compiler.
Lazarus + FPC can open Delphi project files and can usually compile Delphi projects ...
5
You might be better off looking at a generic data packer first, such as LZ4. It's a very simple packer written in C. There are various unpackers in several languages, too, on the same site. Jumping right into a runtime packer means lots of file format details that, really, no-one gets quite right in all cases.
5
The second CRC is the CRC of the header started from 0x10 to 0x28. The following script checks the config file based on the dbcCfgFileDecry function, which verify and decompress the config file from offset 0x10.
import sys
import binascii
import struct
import zlib
if (len(sys.argv) < 1):
print 'usage: check_config.py config_file'
cf = open(sys.argv[...
5
First, this article from Trustwave does an excellent job covering the topic thoroughly from a beginner's perspective (note: there are formatting errors throughout the article where it mashes two words together every two lines or so, but that aside, the content is good):
https://www.trustwave.com/Resources/SpiderLabs-Blog/Basic-Packers--Easy-As-Pie/
Next, ...
4
Also, try Detect It Easy. The project is alive and updated frequently.
4
You can't. You don't know how the file is packed, the only thing you have is the unpacking code in the file. You could try running the file through an emulator like QEMU, so the unpacking takes place in the emulator, not in the "physical" computer. However, that still executes the code.
And you'll have the problem that you don't know when you reach the end ...
4
For my unpacking session I'm using x64dbg and I will unpack the executable in kkrunchy_023a2.zip.
Get to the entry point and enable trace record. Also bind the Trace into beyond trace record option to say Ctrl+/.
Next up, press G (for graph) and you should see the return blocks marked in red.
Put a breakpoint on both of them, run, step and you will notice ...
3
You might want to:
give your packer stub have the same standard ImageBase
allocates memory somewhere else
relocate the (EIP-independant, for convenience) stub code there
to rebuild the original code at the original ImageBase without any risk.
3
You could try TitanHide. It is a kernel-mode hiding driver for both x86 and x64 OSses. It has the following features:
- ProcessDebugFlags (NtQueryInformationProcess)
- ProcessDebugPort (NtQueryInformationProcess)
- ProcessDebugObjectHandle (NtQueryInformationProcess)
- DebugObject (NtQueryObject)
- SystemKernelDebuggerInformation (NtQuerySystemInformation)
-...
3
IDA don't detect type of packer. Also, signatures are not used. Instead, it analyze PE-header: .idata section, entry point and import entries.
This method is very accurate, has low false positives.
3
This isn't a language specific concept. The values you'll need to modify as they are (or are meant to be) referenced:
!IMAGE_FILE_HEADER:
- NumberOfSections
!IMAGE_OPTIONAL_HEADER:
- SizeOfImage
- SizeOfHeaders
(optional depending on which sections you're modifying. Relevant for .text, .data, and .idata but afaik are unused)
- SizeOfCode, ...
3
The file abo1.exe (MD5: 22702FBFC5B198080ACA8F0BE6F2DF0B) doesn't look packed to me. Looking at the PE structure we can see the entry point is in the .text section and the file has a few imports:
Disassembling this entry point shows some code that looks normal. The main function gets the command line arguments and passes them to another function before ...
3
I used PEiD & Stud_PE to get the packer/encrypter signature but
unfortunately they didn't detect it.
Exeinfo PE has more recent signatures (beware of gifs, though).
EDIT: As @beatcracker said in comments, using ExeinfoPe says:
Detected Themida v2.x Inside, Themida Code on Section.
Is there a native exe unpacker for Themida ?
Themida is very hard to ...
3
Thanks to the original poster who figured it out (and the other suggestion for foremost). I had to audit some of our own xamarin apps and wanted to unpack the code so I have what an attacker would be able to get to.
After decompiling the .so and checking out the headers, I'm certain it's possible to derive the magic offset from the file (with the number of ...
3
This works very well cross-platform. Make sure to install these python packages:
sudo pip install pyelftools
sudo pip install yara-python
this will export all dlls from libmonodroid_bundle_app.so:
from elftools.elf.elffile import ELFFile
from zipfile import ZipFile
from cStringIO import StringIO
import gzip, string
data = open('libmonodroid_bundle_app.so'...
Only top voted, non community-wiki answers of a minimum length are eligible
