If I used PE Studio and go to the sections tab it's showing IMAGE_SECTION_HEADER details
2 fields of interest are the
- virtual-size
- raw-size
Virtual size is how much is allocated when loaded.
Raw size is how big the section is on disk.
In normal programs these 2 sizes are relatively similar (they won't be exact, but they should be similar) because when a program's section is loaded to memory it should take approximately the same space that it was on disk.
The .data section is a caveat, as it's normal for the .data section in windows programs to have much more virtual / allocated space than the raw disk.
Large differences or anomalies can indicate a malicious nature, such as a packed program where for example either
a.) space is allocated for a section, but the disk has nothing in that section ... which means some other section may write to here once executed
b.) space allocated for a section is dramatically larger that what's on disk meaning it may be unpacking or writing something once executed
Looking at some real examples
--------
legitimate nbstat.exe
--------
.text (virtual=10036, raw=10240) <== similar sizes
.data (virtual=44608, raw=512) <== normal to be different
.rsrc (virtual=2104, raw=2560) <== similar sizes
.reloc (virtual=802, raw=1024) <== similar sizes
--------
legitimate notepad.exe
--------
.text (virtual=42748, raw=43008) <== similar sizes
.data (virtual=8458, raw=4096) <== normal to be different
.rsrc (virtual=127336, raw=127488) <== similar sizes
.reloc (virtual=3640, raw=4096) <== similar sizes
since all sizes are similar, this does not appear to be packed
-----------
legitimate FireEye floss32.exe
-----------
.text (virtual=40100, raw=40448) <== similar sizes
.data (virtual=42, raw=512) <== normal to be different
.rdata (virtual=20232, raw=20480) <== similar sizes
.bss (virtual=50696, raw=0) <== i think bss is always initialized to 0, so it probably has no disk
.idata (virtual=3036, raw=3072) <== similar sizes
.CRT (virtual=52, raw=512) <== section auto-created by Microsoft C++ compiler
.tls (virtual=32, raw=512) <== section auto-created by Microsoft TlsAlloc thread allocation manager
.rsrc (virtual=95464, raw=95744) <== similar sizes
since all sizes are similar, this does not appear to be packed
------------
legitimate Move.Mouse.exe freeware
------------
.text (virtual=683100, raw=683520) <== similar sizes
.rsrc (virtual=87160, raw=87552) <== similar sizes
.reloc (virtual=12, raw=512) <== used to resolve addresses, seems too small to matter
since all sizes are similar, this does not appear to be packed
------------
PrivaZer.exe
md5 D1560DBFC8FB5B0F78FEEF20D8410885
https://app.any.run/tasks/30aeeda0-fae8-4369-9411-c5dedc3be3e3
-------------
CODE (virtual=6078616, raw=6078976) <== similar sizes
DATA (virtual=96272, raw=96768) <== similar sizes
BSS (virtual=59021, raw=0) <== i think it's normal for BSS to be empty
.idata (virtual=19586, raw=19968) <== similar sizes
.edata (virtual=79, raw=512) <== too small to be concerned
.tls (virtual=560, raw=0) <== too small to be concerned
.rdata (virtual=24, raw=512) <== too small to be concerned
.reloc (virtual=318176, raw=318464) <== similar sizes
.rscr (virtual=10750710, raw=10750976) <== similar sizes
since all sizes are similar, this does not appear to be packed
--------------
Documentacao - Importante .exe
md5 913812CB2959F5611A8CD699932FE043
https://app.any.run/tasks/ca9fe312-bf54-42a4-a103-a47e603665e3
--------------
.text (virtual=386572, raw=387072) <== similar sizes
.rdata (virtual=70440, raw=70656) <== similar sizes
.data (virtual=37224, raw=7680) <== normal to be different
.rsrc (virtual=10104, raw=10240) <== similar sizes
since all sizes are similar, this does not appear to be packed
--------------
data.exe
md5 FC1F15917F36BB6C1D18466AB39BF1A0
https://app.any.run/tasks/8bc211e2-ee2b-4806-9887-482fa2a8cb9e
--------------
.text (virtual=225492, raw=225792) <== similar sizes
.rsrc (virtual=1344, raw=1536) <== similar sizes
.reloc (virtual=12, raw=512) <== too small to be concerned
since all sizes are similar, this does not appear to be packed
-----------
keygen.exe
md5 E0B94BD0A0451BCC539D4D5DC76DD27A
https://app.any.run/tasks/39ac85c7-6ae4-4b31-9518-6678c688cbc0
------------
UPX0 (virtual=40960, raw=0) <== notice the huge virtual size and 0 bytes on disk, that means something it going to get written here after loading, probably the malicious code
UPX1 (virtual=28672, raw=26624) <== entry point to program, similar sizes, but UPX1 name should be a dead giveaway that it's packed with UPX
.rsrc (virtual=20480, raw=16896) <== there is a difference here, more allocated than actually existing, so it's possibly something could get written here after loading also
since it has the dramatic differences in sizes, this is packed
------------
https://www.virustotal.com/#/file/a4ea9b8116ca39cd538250ece162aea9ced57723f9520bca1e19ac7c948d6e03/detection
------------
.text (virtual=115391, raw=115712) <== similar sizes
.rdata (virtual=57896, raw=58368) <== similar sizes
.data (virtual=44868, raw=4608) <== normal to be different
.gfids (virtual=4644, raw=1536) <== quite a different, more allocated than on disk, perhaps could be used to unpack or write something, also had a random section name
.rsrc (virtual=139260, raw=139264) <== similar sizes
.reloc (virtual=7908, raw=8192) <== similar sizes
given 1 section has the big difference in sizes and it's named randomly, this could be packed
-------------
md5 68b28f07c4d49f94341e739c36b17843
https://www.virustotal.com/#/file/8a94a86a695bb46d01cbfe84e2ceb3b159aa2c46069044ec7bc87d4d4830af65/detection
--------------
no name (virtual=517792, raw=168960) <== large difference, definitely could unpack and write stuff to this section, also interesting that the section has no defined name, and it's the entry point
no name (virtual=8192, raw=2048) <== big difference, definitely could unpack and write stuff to this section
no name (virtual=4096, raw=0) <== only allocated, nothing on disk, suspicious
no name (virtual=12288, raw=9728) <== big difference, definitely could unpack and write stuff to this section
no name (virtual=4096, raw=0) <== only allocated, nothing on disk, suspicious
no name (virtual=4096, raw=512) <== big difference, definitely could unpack and write stuff to this section
no name (virtual=32768, raw=0) <== only allocated, nothing on disk, very suspicious, large space
.rsrc (virtual=454656, raw=157696) <== big difference, definitely could unpack and write stuff to this section
.data (virtual=532480, raw=529920) <== similar sizes
.adata (virtual=4096, raw=0) <== only allocated, nothing on disk, suspicious
lots of dramatic size difference, sections without names, this looks packed
-----------------
md5 8e2e9241cbe301c777b7719570ad5b1d
https://www.virustotal.com/#/file/f4e0872a3839b6b2236c9b2cf9bf1d868e813ab95e69d360a11772c64afd56fe/details
-----------------
.textbss (virtual=106496, raw=0) <== normal to be empty
.text (virtual=8192, raw=0) <== big difference, odd that the code section is empty, probably gets unpacked to here
.data (virtual=131072, raw=0) <== big difference, odd that the data section is empty, probably gets unpacked to here
.idata (virtual=4096, raw=0) <== big difference, odd that the data section is empty, probably gets unpacked to here
.rsrc (virtual=4096, raw=0) <== big difference, odd that the resource section is empty, probably gets unpacked to here
.sedata (virtual=1228800, raw=0) <== big difference, odd that the data section is empty, probably gets unpacked to here
.vmp0 (virtual=4096, raw=0) <== big difference, strange name, reminds me of UPX0 and UPX1 packing naming convention, so i'm guessing code gets unpacked here when loaded
.vmp1 (virtual=1286956, raw=0) <== big difference, strange name, reminds me of UPX0 and UPX1 packing naming convention, so i'm guessing code gets unpacked here when loaded
.vmp2 (virtual=2139888, raw=2140160) <== similar sizes, this is also the entry point, reminds me of the UPX naming convention, I'm guessing this is the unpacking stub code that will unpack to vmp0 & vmp1 sections
.rsrc (virtual=2396, raw=2560) <== similar sizes
with the dramatic size differences and interesting naming conventions, this appears packed. I think vmp stands for VMProtect ( Software Protection vmpsoft.com/ )
No comments:
Post a Comment