Hello 0x00sec fellas!
I want to start by saying that I love what you’re doing here. I’d like to thank all of you who contribute to this community even if a bit. Thank you all 
Anyway enough with the emotions 
Today I’m here with a compiled list of packer/crypter indicators that I can think of. Using these you may be able to detect if a packer/crypter is applied to your subject of analysis. Please feel free to make additions!
Lets Start.
1. Packer Signatures
Well obviously first thing to look for is the presence of any signatures related to already known packers or crypters (I’ll only use the term “packer” from now on). You could use PEiD, yarascan or any other tool really. Here is an example;
You see that PEiD found a signature match of UPX packer. The thing with signatures is that there can be false positives. Maybe author has made a loose definition while creating the signature, or maybe malware developer simply false flagged the binary. Long story short, don’t rely on them. Actually don’t rely on any single or combination of indicators. They are what they sound like, indicators not facts.
2. Abnormal Entry Point / Section Names
Some packers create new sections to store the packed executable or stub code then arbitrarily name those sections. Regular section names for PE files go like; text, bss, data, rsrc, rodata. Sometimes compilers create some additional sections in order to store things like debug symbols etc. Whatever I see other then these names instantly raise my suspicion.
3. Section or Memory Regions with RWE Permissions
This is another obvious one. Sometimes a packer allocates a section/memory region in order to store the unpacked code. So this region would need to have both writable and executable permissions; which is weird because compilers don’t do that by default cuz of security reasons. This is an anomaly. It may occur in runtime so you may wish to trace API calls related to memory permissions.
4. Abnormal Difference Between Section Vsize and Psize
Physical size is the space occupied by a section on the disk while it’s not running. And virtual size is the size on memory while it’s running. Abnormal differences between these two values may indicate the presence of a packer. Because while not running the code will be compressed, hence small in size. When it begins to run though malware will try to decompress the code so its size will increase abnormally.
Example;
You can also see that this example possess other features we have mentioned earlier as well.
5. Data Sections Are Too Large
We generally divide sections into one of two types; code section or data section. As the name suggests code sections are the ones which contains code, and data sections are the ones which contains drumroll data! For example when you define a variable in a program it gets stored in one of the data sections depending on how you define it (bss, data, rodata, rsrc…). Naturally we expect a program to contain more code than it contains data. Unless it’s designed to print out a play of Shakespeare for some reason. Whenever I see a data section that is too large I suspect that it might contain an executable file inside it.
6. Too Few Imported Functions
When a file is packed normally you would only see the functions used by its unpacker stub code. Most probably there will be stuff related to memory allocation, mem permissions, module load, resources operations… So if it seems like the program imports abnormally few functions you could suspect of a packer.
7. Section with High Entropy
Shannon’s entropy is an algorithm to calculate frequency of recurrences in a given data. It calculates a score over eight. Lesser the recurrences, higher the entropy (score). So if you see a section or file which’s entropy score is close to or above 7.0 you could suspect that the data inside it is encrypted, hence might be packed. Because increasing entropy is what any decent encryption algorithm is supposed to do.
That’s all from me for now. Please feel free to add 
