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.
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 ...
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 ...
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:
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+...
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 ...
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 ...
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 ...
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 ...
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.
if (len(sys.argv) < 1):
print 'usage: check_config.py config_file'
cf = open(sys.argv[...
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 ...
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):
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 ...
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 ...
If you are just starting out learn Assembly and Study C, and don't try to learn how to "unpack" commercial protectors (They are commercial for a reason), even if you want to insist on the error easily you will find scripts to do all the work for you, but I ask you, will you learn something new or just say that you know how to unpack with someone ...
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 ...
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 ...
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)
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.
This isn't a language specific concept. The values you'll need to modify as they are (or are meant to be) referenced:
(optional depending on which sections you're modifying. Relevant for .text, .data, and .idata but afaik are unused)
- SizeOfCode, ...
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 ...
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'...
You really cannot. You can only slow a reverser down
The goal of the packer, crypter or anti debug methods, ect. is simply to slow the reverser . Eventually (if there is desire ) your code will be cracked
There are packers like ASProtect and others which will simply just encrypt or compress certian portions and create a loader for it to be unpacked at run ...
protectionid supports x64 files no problem... and if you can think of anything i could add to it, just let me know and i'll see what i can do (new build is planned for halloween and it'll be a spooky 'theme').. just dont tell anyone, its a secret
Malware can be removing/manipulating its own PE Header.
DWORD OldProtect = 0;
char *pBaseAddr = (char*)GetModuleHandle(NULL);
Executable compression (AKA executable packing) is the idea that an PE, ELF and MACHO file formats were not fully designed to be compact for obvious reasons.
In the past, when memory was scarce, making executable files smaller in size was often a goal either mandatory of preferable.
For that reason, tools were created to keep an executable functional while ...
Here is my solution to unpack the files in C#.
I could not figure out how the 64 byte alignment works so I hard coded an offset of 0xD60 for the words that did not lie on the alignment boundary. I believe this is the offset of the next free page.
If anyone else wants to use this solution they will either need to find the page offset manually using IDA etc ...