Hot answers tagged


First, let's see UPX structure. UPX Structure Prologue CMP / JNZ for DLLs parameter checks Pushad, set registers optional NOP alignment Decompression algorithm whether it's NRV or LZMA Call/Jumps restoring UPX transform relative calls and jumps into absolute ones, to improve compression. Imports load libraries, resolve APIs Reset section flags ...


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 will ignore that there's multiple compression algorithms in UPX and that there's been multiple versions of UPX. Generally when people ask if it's plain or vanilla UPX it's because malware and other software likes to take UPX and modify it slightly so that it can't be unpacked with the standard UPX executable and so that anti viruses will have a harder ...


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 ...


Okay, assuming vanilla UPX you should be fine by detecting the strings UPX! or UPX0. As far as I remember this would also work on Windows. So it's a shell one-liner such as: grep UPX\! <filename> or grep UPX0 <filename> ... assuming the GNU version of grep here. Another method, but using the same principle: $ hexdump -C <filename> |...


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 ...


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 ...


Here you can find bunch of tools for unpacking upx. One of them(Upx Unpacker 0.2) solved my issue. Every unpacker should be used in specific case and this list may be incomplete.


I do not recommend you to rely on the strings or section names you may find. Normally, it will indicate that the file is packed with UPX but, specially if you're analyzing malware, it may be done in order to fool you. My recommendation is to look to the entry point and find a pattern similar to this one: 0x00023b60 ; FUNCTION start 0x00023b60 (01) 60 ...


I'm not sure if this is what you're asking, but UPX has multiple ways of compressing a given format. For example, an ELF - can be decompressed directly into memory - can be decompressed into /tmp and executed from there By default the first option is preferred, but I don't think it's mandatory. See the UPX Manual for details.


Unless the binary has been modified to prevent it, UPX itself should be able to unpack it: upx -d packed.bin


You said that the base address changes so I assume your system and target executable have ASLR enabled. This sometimes causes problems when unpacking due to relocations not being fixed. Easiest solution is to disable ASLR and then unpack. If you want to disable ASLR on the packed executable, edit the IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE flag of the DLL ...


get UPX make your own UPX-packed ELFs, with different options (LZMA, NRV,...) As UPX is easy to modify, and very often modified, patched or even faked, comparing the code starts will make it easy to check if your target is indeed UPX-packed, and if this is truely the original UPX version or if it's modified in any way.


In Linux/Unix variants, strings command has helped me identify some of the packers such as UPX, Aspack, NSPack, NTKrnl, PeCompact, Themida, etc., All these packers tend to leave embedded strings in the packed executable which helps identify the type of packer. Granted, the author of the elf file could introduce the very same strings intentionally to throw ...


Any dynamically-linked executable will need to import functionality from dynamically-loaded libraries. The executable you have needs some functions from comctl32.dll to accomplish whatever it does. A packer like UPX is basically creating a completely new executable and compressing the original one into a "payload". The reason your packed executable now has ...


You should try to unpack it manually and reconstruct the IAT. With UPX, it should be pretty straightforward. Here is a tutorial in case you don't know how to start :


Is Olly 2.01 actually "smarter", recognizing the packer and stopping at the unpacked OEP? Yes! You can disable it in OllyDbg's options though by going to Debugging → SFX and unchecking Unpack SFX modules automatically:


Just set a breakpoint in 0x00ef674c. Press F9. When it hit the breakpoint, press F7 to go the original Entrypoint of the unpacked file. Just make sure that the EIP is the OEP.


Please check example usage in It looks like load method is not implemented. Based on example usage it's required to load PE file manually.


The product overview of PE Explorer states in several places that it will load PE files that are compressed with UPX. Open UPX-, Upack- and NsPack-compressed files seamlessly in PE Explorer, without long workarounds


Hard to tell what the reason for the differences might be without actually seeing the differences, but one guess is that you're doing ReadProcessMemory(hProcess, header32.ImageBase, buffer, header32.SizeOfImage, bytes_read), while the other tool may be doing foreach(section) {ReadProcessMemory(hProcess, header32.ImageBase + section.RVA, buffer, section....


UPX is already managing ELF (see: UPX supported executable formats). Or, did I miss the point of your question ? But, note that UPX is not designed for obfuscation purpose, it mainly aims at compressing the executable.

Only top voted, non community-wiki answers of a minimum length are eligible