Unpacking a generic wrapping packer or cryptor usually involves the following steps:
1. Trace the code, possibly evading or bypassing anti-debugging checks.
This is not difficult with simple packers but might be tricky with the more advanced ones. They may employ timing checks (rdtsc), exception-based control transfer, using debug registers for ...
[Complete ReEdit3] further progress & shortening the text to fit the 30KB limit
First some input how I got here (for future readers trying to do the same for different format).
Image Data size
Comparing provided background image to its raw image size xs*ys reveal direct dependence Which implies no compression or one that has always the same pixel to ...
In a typical, non-packed Windows PE executable, the header contains metadata that describes to the operating system which symbols from other libraries that the executable depends upon. The operating system's loader is responsible for loading those libraries into memory (if they are not already loaded), and for placing the addresses of those imported symbols ...
virtualizers usage in the wild
They are rarely used, and even worse (or better), rarely used in a useful way.
how they're used
Typically, it was the use of a virtualizer of over only the main function, or another binary packer, and both cases don't prevent analysis: if you bypass the virtualized packer code, then you get the original unpacked code anyway.
I kind of like your answer about changing the subsystem, especially if you're not a fan of kernel debugging. I'm a big fan of Windbg, though. The way I do this is:
Hook up my kernel debugger to a VM
Change the first byte of the driver's entry point to be an INT3 (0xCC).
Fix-up the PE checksum (I'm a fan of letting pefile do this work for me).
Load the ...
Igor's answer is very good. However, the outlined techniques rely on the assumption that at some point the executable is unpacked in memory. This is not always true. Virtualization obfusactors compile the original binary into a custom instruction set when is executed by an simulator at runtime. If you encounter a binary obfuscated in this way you have no ...
Unpacking Themida, especially the newer versions, is not a small task by any means. It is literally worlds different from unpacking UPX and if you are new to unpacking, you have absolutely no business trying to unpack Themida. Here's why:
Themida uses an extremely complex virtual machine environment combined with every anti-debug and anti-analysis trick in ...
change the driver subsystem to GUI (turning it into a user-mode binary)
clear the imports' RVA, or use a set of fake kernel DLLs (only in 32 bits) to enable imports loading
launch in your debugger and proceed as if it was user-mode - you'll probably need to simulate some API calls before reaching the original EntryPoint.
TL;DR: What we have here is probably not an encryption algorithm, it is more likely a decompression loop, by the look of it. It simply does not do anything that could be considered even remotely similar to encryption.
Encryption algorithms are divided into two classes. First is a stream cipher. From wikipedia:
A stream cipher is a symmetric key cipher ...
I see filenames. That is an extremely important starting point - if I did not, I'd have to assume the file is encrypted, compressed, or does not use filenames at all, which are all harder to unpack.
For the moment, skip the header "BigFile" and the immedtaly following data and concentrate on these filenames alone.
If the filenames have different lengths, ...
The difference between a debug apk and a release apk is that a debug apk is signed by a particular key which is provided with the SDK, whereas a release apk is signed by some other key. There's nothing to reverse engineer: all you have to do to make a release apk and sign it.
Nobody but you can create an apk signed by you. But anyone can make their own ...
According to the developer of Resource Hacker, this product is discontinued (and hasn't been updated since Sep 2011):
I have been overwhelmed by the interest in Resource HackerTM, the
emails of thanks, encouragement and suggestions. It's been downloaded
many millions of times. However, I've moved on to other things and
have no plans to continue its ...
An alternative to patching the DriverInit function with an INT3 is to put a breakpoint in the IopLoadDriver function which is responsible for calling DriverInit. On Windows XP SP3, the breakpoint should be added at IopLoadDriver+0x66a which is call dword ptr [edi+2Ch] (0x2C is _DRIVER_OBJECT.DriverInit).
Find IopLoadDriver with x nt!IopLoadDriver
Add a ...
As you saw by yourself, RE is not a easy skill to accomplish. One must find as much patience (at least) as he could to acquire it, some intelligence and knowledge will also help. If you think that just following the tutorial you will understand all of it from the first read, then you are wrong.
My advice to you is :
read the tutorial several times and try ...
Your program is not packed, but rather compiled as Visual Basic P-code or Visual Basic native code.
If it's VB native code, you can use your favorite debugger (OllyDbg, IDA, etc.) to debug it, and IDA to disassemble it.
If it's VB P-code, you can use VB Decompiler Pro to disassemble/decompile it:
... and WKTVBDE to debug it:
Note that VB Decompiler Pro ...
If you compare the hash values of original/unpacked files, then they are different since upx -d does not restore bit-by-bit of the original file. Indeed, UPX parses the original file and keeps only information so that the packed data, after being unpacked, can be executed exactly the same as the original one, i.e. the original/unpacked files are semantically ...
Over the 30+ embedded device firmwares I've seen in the past I have rarely seen them using anything proprietary. Often it's just gzip/LZMA or a similar compression they're using (albeit sometimes with modified or stripped headers).
Thus as a first step I would try something like binwalk to search for known compression algorithms. If that doesn't help try ...
The output from the file utility, as you've probably guessed, is a false positive. The beginning of the firmware.bin file contains what looks to be a basic header (note the "SIG" string near the beginning of the file), and a bunch of MIPS executable code, which is likely the bootloader:
DECIMAL HEX DESCRIPTION
The CramFS image is a false positive; I doubt there would be over 1 billion files in a 5MB firmware image.
It looks like your binwalk signatures are a bit old; here is the output from mine (running the latest from the trunk):
DECIMAL HEX DESCRIPTION
After you have finished unpacking the program and get to the OEP
File --> Plugins --> Universal Unpacker Manual Reconstruct
Fill in the info if its not correct :)
Ok, edit for free version:
Heres what I have done to get the program re-analyzed:
UPX packed notepad.exe (easy to unpack)
loaded packed file into freshly installed IDA Pro Free 5.0
I wouldn't say that obfuscation detection is strictly related to entropy.
When I detected obfuscated code areas I did it by simple statistical comparison of probabilities of appearances of specific assembly commands.
For example number of jump related commands will be significantly larger in a binary with control flow obfuscation.
Number of arithmetic ...
Here's an explanation for what I think the individual symbols mean. I'm basing this around the presumption that a little selector is going through the cells, one by one.
\xFF = Null cell
\x05 = A string is following, with \xNumber coming after the string to define how far to displace the string from the selector's current position, if at all.
I can support the presented view of the other responders. You will rarely encounter code virtualization when looking at in the wild samples.
Just to add, here is a recent case-study by Tora looking at the custom virtualization used in FinFisher (sorry, direct link to PDF, have no other source).
The VM used here has only 11 opcodes, thus this example can be ...
nt!IopLoadDriver indirect call is used only for SERVICE_DEMAND start driver entry
for boot loading drivers you would need to break on nt!IopInitializeBuiltInDriver indirect call as well
you can see a short example on message #17 & #18 in this link
this is a dormant script (slightly edited to use gc ...
Your mistake is that you put the breakpoint while being on the PUSHAD instruction (meaning it wasn't executed yet).
I just unpacked the file, and this is how you do it:
1. Drop the file in Olly and find the PUSHAD instruction
Simply do what you did before, and end up here:
2. Step once to skip the PUSHAD
Now, you got everything pushed, and the ...
There is not a single paper or book that explains the art of unpacking. This is mainly due to all the different packers that require different techniques to unpack them. There are of course generic approaches that work on some packers but knowing when to use them is gained from experience. IMHO the best approach to learn unpacking is to follow along with ...