Background: I’m currently working on a packer. I’m well familiar with programming in C & assembly. I’ve also invested a lot of time in understanding AV and detection mechanisms.
During my tests on AV detections, I’ve been hung up on detections due to a large .data section.
These are my test results with a non-malicious executable that just displays a “Hello World” dialog. I’m using AntiScan[.]me to scan:
Compiled with MSVC:
- Just “Hello World” => 2/30
- Adding 100KB repeating bytes into the data section => 3/30
The results tell me, that a big .data section does not necessarily trigger AV detection.
Compiled with FASM:
- A simple “Hello World” => 2/30
- 2 KB repeating bytes in .data section => 4/30
- 10 KB repeating bytes in .data section => 5/30
- 100 KB => 13/30 (mostly Gen:[email protected])
My assumption is: FASM is used more often than C++ for malware. Therefore, static signature detection (AI) is trained to detect combined traits of a FASM compiled executable that also has a big .data section
My attempts to figure out where static detection kicks in:
- Make sure, that the checksum is valid (it was)
- Change a lot of the IMAGE_OPTIONAL_HEADER properties to match those of the C++ executable
- Copy contents of the .text .data and .rdata section of the C++ executable over to the FASM code
So, from what I can observe is that this is a static detection that is caused by a big .data section, but it is prelevant in FASM executables, but not in MSVC executables.
My question would be: Is there any preferred methodology to isolate detection indicators - and what causes the mass amount of false positives in FASM executables?