Some immature research to solve the problem that easy language programs are falsely reported by anti-virus software

 

Author: Zhuang Xiaoli (liigo), 2010/7/5

This article first address: http://blog.csdn.net/liigo/archive/2010/07/04/5712547.aspx

Reprinted please indicate the source: http://blog.csdn.net/liigo

 

 

Since the release of the easy language 5.0 static compilation version, there are still some anti-virus software false positives. programs compiled in easy language are viruses or Trojans. During the past two weekends, I (liigo) made some immature research based on a simple and naive idea. This idea is: first use myccl to locate the signature, and then check the location where the () signature is located in the EXE/PE file, if it is located in the code segment (. in text), you can further find the function in the compilation unit from which the command comes from, and then perform corresponding technical processing based on the situation, until the purpose of fundamentally removing false positives is achieved. Even if the ultimate goal is not achieved, it would be a great achievement to summarize the reasons for false positives of easy language programs in anti-virus software.

 

Due to lack of understanding and maturity, the study requires the following prerequisites:

1. most well-known anti-virus software uses the pattern as the main method of scanning and killing. modifying a certain segment of data at a specific file offset can relieve false positives.

2. executable code in the EXE/DLL file generated by the linker, all from external compilation units (. OBJ,. Lib ).

 

Analyze the static compilation link process in easy language. All the compilation units used by the linker are divided into the following three parts: 1. OBJ files generated by the easy language compiler (this is the main code of the easy language program) and res files; 2. Easy language support for library static libraries (LIB files); 3. Other static libraries (LIB files) provided by the linker ), for example, the C/C ++ base library, the MFC base library, and the import and export of the operating system core DLL (kernel32.lib, user32.lib. The first two parts are provided in easy language, and the others are provided by the linker manufacturer (such as Microsoft or Microsoft of Visual Studio.

 

Based on the above 2nd assumptions and the analysis of the compilation link process, the following inferences are drawn:An EXE/DLL file generated by static compilation in easy language. Any part of the executable code (x86 Instruction Set) must be one of the three parts of the compilation unit used by the aforementioned linker.. As long as this inference is true, the source of the signature can be tracked (see below). The source is the compiler, and the source is the support library, other static libraries provided by the linker are processed by other unconventional means. Note that I used the word "inevitable" with quotation marks in the inference, and used the word "inevitable" because "it is supposed to be so deduced based on theory". The quotation marks indicate suspicion and negation, because, I (liigo) cannot prove this inference for the time being. What's more, the subsequent process in this article even denies this inference to a certain extent, so that I cannot start to study it further.

 

In the following sequence, let's talk about the entire (probably half) research process. The target program is a blank window Program (exe) statically compiled using the official version of easy language 5.11 without any code. Anti-virus software has successively used  and Jiang min (upgraded to the latest version and Latest Virus database ), A false positive is reported to the target program.

 

FirstUse myccl software to locate the patternThere are many tutorials on the Internet, so I will not elaborate on them ,:

 

After finding the signature,See where it is in the PE file (EXE/DLL).

I first found a signature for the anti-virus software, located at 2 bytes at the file offset 0x01fc (value: 0 x, 0x10), and found that it was located in the PE standard code segment (. text), and then the exact point is part of the image_section_header.pointertorawdata (DWORD) data, day, this can also be done as a pattern (code segment data header file offset is 0x1000 is very common), No matter first, if you change the value randomly, the system passes the  anti-virus software test and no false positives are reported. However, this pattern is not executable code in the code segment and cannot be traced to its source. For another Jiangmin anti-virus software, one of the signatures locates the 24 bytes at the file offset 0x052dee (any byte value starting with manual modification can be removed from the false alarm), as shown in 010 Editor:

The disassembly commands shown in ollydbg are as follows:

 

BelowTrace pattern SourceThis is the highlight of this study.

According to the inferences above, the code snippet signature should come from a. OBJ or. Lib file used by the linker. Which files are used? We have already divided them into three major parts. I wrote a pattern scanning program in easy language, scanning the pattern one by one in all these lib and OBJ files. If found, the LIB/obj file and the file offset are recorded, to further track the source (locate its function ). Because the executable code in the signature may have addresses or relative addresses to be relocated (for example, the four E8 bytes after the file offset 0x052dfe in the previous signature ), not necessarily the same as the code in lib/obj. The scan program has already filtered the code to ensure precise tracking and locating. Ah, find one in the Lib file Glaux. Lib:

Later, it was confirmed that Glaux. Lib was not involved in the link, because the link can be successfully deleted or renamed. In addition, my scanner did not find the "confirmed in EXE code segment" in all other possible lib/OBJ files! The results are regrettable. I am still wondering where the code comes from? Is it a self-generated by the linker (optimizing the integrated code )? Some lib/OBJ files were missing during the scan. (The Lib files of the supported libraries outside the core library are not included because they are confirmed to be unused. The linker calls the external program (cvtres. EXE) The OBJ file generated from the res file is not included because there is no executable code )? Scan the program's own bug? Although this possibility cannot be ruled out, it should be very unlikely because of careful tests. This signature contains a function call that scans the header code segment of the function body and does not track its source lib/obj. Strange. How can this happen? Why is this result? Why ?......

 

 

 

2010/7/8:

Mistakes, mistakes, and the last mistake. The static library of MFC was missing during the search! Haha, after this makeupFinally found the "culprit", nafxcw. Lib(At the same time, lib that also contains the same signature is also found to be mfcs42.lib and uafxcw. Lib. It has been confirmed that the link is not involved ):

 

I (liigo) will continue this work. As planned, the next step will find the feature code from which function in nafxcw. Lib comes. Coming soon.

 

2010/7/11:

The following is the core source code for searching and locating signatures, which is written in easy language:

Traverse all lib files (mainly the lib directory of the linker and the static_lib directory of the language), read the file content, and call the above functions cyclically. This is very simple and the code will not be pasted.

 

2010/7/12:

The full text is complete. For more information, see the next article: Search for the function of locating the virus pattern in the static library lib/obj file, and find the C/C ++ source code.