Unless it’s designed to print out a play of Shakespeare for some reason. Naturally we expect a program to contain more code than it contains data. 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…). We generally divide sections into one of two types code section or data section. You can also see that this example possess other features we have mentioned earlier as well. When it begins to run though malware will try to decompress the code so its size will increase abnormally. Because while not running the code will be compressed, hence small in size. Abnormal differences between these two values may indicate the presence of a packer. And virtual size is the size on memory while it’s running. Physical size is the space occupied by a section on the disk while it’s not running. Abnormal Difference Between Section Vsize and Psize It may occur in runtime so you may wish to trace API calls related to memory permissions.Ĥ. 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. Sometimes a packer allocates a section/memory region in order to store the unpacked code. Section or Memory Regions with RWE Permissions Whatever I see other then these names instantly raise my suspicion.ģ. Sometimes compilers create some additional sections in order to store things like debug symbols etc. Regular section names for PE files go like text, bss, data, rsrc, rodata. Some packers create new sections to store the packed executable or stub code then arbitrarily name those sections. They are what they sound like, indicators not facts. Actually don’t rely on any single or combination of indicators. Maybe author has made a loose definition while creating the signature, or maybe malware developer simply false flagged the binary. The thing with signatures is that there can be false positives. You see that PEiD found a signature match of UPX packer.
You could use PEiD, yarascan or any other tool really.
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). Using these you may be able to detect if a packer/crypter is applied to your subject of analysis. Thank you allĪnyway enough with the emotions Today I’m here with a compiled list of packer/crypter indicators that I can think of. I’d like to thank all of you who contribute to this community even if a bit. I want to start by saying that I love what you’re doing here.
0 kommentar(er)
