how can sure truly the exe file packed or not?

[rever_ser]

i have the malware that unclear for me that is packed or not?

the program like PEid shows that code writen with c++ but in addition sandbox shows that's packed with Armadilo and in string of malware there is Aspack. so how can i recognize the malware is packed or not?

note:epilog of file is push ebp - mov ebp،esp - push -1 but it hasn't getversion phrase.i think that it is a fake epilog.

 

[SmilingWolf]

You can understand in multiple ways:

1. Experience

2. Entropy (the higher this one is, the higher the chance the file is packed)

3. Position of EP (not a panacea of course, but if the EP is in one of the last sections it usually means there is a stub taking control before the real application)

4. Sections' names (again, not the best method, but for example Arma had an option to randomize section names and a lot of packers add a section with a name that recalls the name of the product used)

(Note that the last two can easily be faked, so you're back to option #1 anyway)

5. PEiD is too outdated nowadays, some people suggest using RDG Packer Detector, while I usually go for ProtectionID.

Edited November 30, 2014 by SmilingWolf

[evlncrn8]

6. add up the physical sizes of the sections and compare that against the virtual ones, compare against image size.. obviously take into account uninitialised data like .bss and such

7. exports that are not forwarded but their va when converted isnt in file

8. multiple sections that are marked as executable

but generally experience is the key here

[Conquest]

1.packed - imports being fully or partially destroyed , codesection being compressed (how to check if codesection is compressed or not, load in any disassembler and check codesection if its garbage or clean)

2. obfuscated/protected - unable to load in debugger (debugger being detected). Sometime application may incorporate separate protection mechanism and in that case if you can deadlist the code section , its not packed . if codesection is still unreadable , its protected.

3. Vmed - only functions can be vmed , not whole program. (to be exact they apply vm to any function, means they can protect 1st then apply vm to protection functions, compress it and again vm the compression function which will be retarded). It usually takes experienced eyes to find out the details about vm .Exe can deploy any or all of the things i mentioned. At very basic level, grab some clean files and check the oep of them to match . if none of them matches you can be sure something fishy is there (protected/packed or coder manually changed oep).

[rever_ser]

i have the malware that unclear for me that is packed or not?

the program like PEid shows that code writen with c++ but in addition sandbox shows that's packed with Armadilo and in string of malware there is Aspack. so how can i recognize the malware is packed or not?

note:epilog of file is push ebp - mov ebp،esp - push -1 but it hasn't getversion phrase.i think that it is a fake epilog.

 

 

can any one help me plz?

[evlncrn8]

something wrong with the other thread?

https://forum.tuts4you.com/topic/36484-how-can-sure-truly-the-exe-file-packed-or-not/#entry169638

[evlncrn8]

oh

9. entrypoint not in first section is usually another good indicator

[c0d3inj3cT]

Adding some more points here:

 

1. Some packers also add junk instructions. If you identify several sections of code with a lot of junk instructions, then it is an indicator of a packer as well. Junk instructions can at times be easy to identify and sometimes not so easy. In most cases, the final result of a sequence of junk instruction would be similar to a NOP.

 

example:

inc eax

dec eax

push esp

pop esp

mov ebx, dword ptr [eax]

mov dword ptr [eax], ebx

2. Most custom packers will decompress the code at runtime. You could use dynamic binary instrumentation (using pintools) to get an API trace. Usually, they would allocate memory (RWX), write packed code to it and then execute it.

 

This is also the method used by some automated unpackers. They monitor memory regions to which data was written and then executed.

 

3. Some custom packers might also use sequences of self modifying code in it. An easy way to identify that would be usage of GetPC (call/pop) sequence of instructions.

 

A call/pop sequence of instruction allows you to get the EIP. Then using EIP you could locate the encrypted code and decrypt it. This technique is common in encoded shellcodes.