View Full Version : Ways to detect the difference between a packed and unpacked exe in memory
onebitshort
February 24th, 2007, 03:22
Run say, notepad.exe ... dump its memory image to disk. Apart from being restructured for use in memory, reallocations, RVAs etc, it's pretty much an identical copy of the on-disk version of the executable.
Then run an exe crypter (we'll use a crypter over a packer because there shouldnt be any change in size - lets just assume it XORs each byte) ...
Programatically speaking (not manual user checks), what checks could be made by a program to determine if the in-memory version seems to be a decrypted/decompressed version?
Nico
February 27th, 2007, 10:31
You could use cheap heuristics, some compiler signatures (FLIRT might provide some ideas), or even entropy.
Extremist
February 27th, 2007, 19:32
Check out van Someren and Shamir work.
onebitshort
February 27th, 2007, 20:40
Quote:
Check out van Someren and Shamir work. |
Do you have any URLs? I googled for them but found nothing but cryptography-related works, and nothing in regards to executable packers ... ?
Extremist
February 28th, 2007, 05:51
Look for their paper on "playing hide and seek" with RSA keys. They search binaries for random-looking fragments, which might store such keys. If a binary is packed, it should appear more or less random throughout, assuming the encryption is halfway decent. One of the simplest tests is to make a histogram of random pieces of the binary. If the distribution seems uniform across all 256 bytes, chances are it's packed.
Maximus
February 28th, 2007, 16:01
No need for complex stuff.
A compressed executable is a 'random' number, which means it's information not much compressible anymore.
Take you zip streamer and try to compress a good chunk (for avoiding the stub loader, it's compressible) of the packed file (or its text section, or part of it). If you compress it over 20-25% -that's surely unpacked. Else, it is packed -absolutely no way.
Same test for memory image, if you wish.
however I'm interested in that work -nice idea! By sampling randominess of an executable area, you can quickly locate 'tough' values as RSA keys.
onebitshort
February 28th, 2007, 21:28
But COMPRESSION is only one side of it - ENCRYPTION is the other

And not just strong encryption ... weak ciphers must be accounted for as well. Afterall, XOR is weak but isn't uncommon, and in its case it
would compress down even after XOR'ing.
Maximus
March 2nd, 2007, 05:36
count the number of calls in IAT, count the number of references to IAT (jmp) and references to such jumps.
Packed apps uses little IAT and solved all at runtime.
Ciphered applications will have such calls 'xored'.
Always looks to the bottlenecks...
LLXX
March 3rd, 2007, 01:14
entropy.
Powered by vBulletin® Version 4.2.2 Copyright © 2018 vBulletin Solutions, Inc. All rights reserved.