QQ: 1151639935
Today, when I was studying the process of virus infection with PE executable files, I occasionally found that programs compiled by the VB6.0 compiler have a feature, that is, it can prevent the infection of some viruses (note that it can only prevent the infection of some viruses ). So what exactly is this? See the following analysis:
After learning the principles of virus infection PE files, I tried to manually infect another PE program to verify the accuracy of my knowledge. The target program is a small program (test.exe) compiled by vb6.0 ). We know that viruses usually infect PE executable programs in the following ways:
1. Insert a new Section (Section) in the target program, write the virus body to this Section, jump to the original program entry point with a jmp command at the end, and hand over the control to the target program. This type of virus will undoubtedly increase the volume of the original target program, which is not easy for virus stealth. However, this method is simple and common in implementation.
2. find gaps in each Section of the Target Program and copy the virus body to these gaps (connect the virus code of each Section with the jmp command). Also, use a jmp command to give control to the target program. This method does not increase the size of the original target program, but there is a limitation that the virus body code is small enough, and the gap between the target program Section must be able to accommodate the virus. In addition, this method is more complex than the previous method.
In the above two methods, the implementation of the 2nd method of virus body insertion depends on the total size of the Section gap of the Target Program. The attack is random and complicated to implement. So I will first test the first method:
Step 1. Insert a new Section in the target program.
Step 2. In the newly inserted Section, directly use a simple jmp command to give control to the original target program, do nothing. Let's take a look at Step 1:
It is the status of the target program when it is not inserted into the new node. The circle is the original three sections of the original program (. text. data. rsrc). Now let's look at the status after the new node is inserted:
For example, the new section I inserted is named ". test ". Now, write the new code first, and save the file test1.exe for a try. Fuck, the following error message is displayed:
As a matter of fact, I just inserted a new section without any code. It should be okay if the program runs normally. Now let's analyze the possible causes of errors:
After a new section is inserted, a new section header is added to the section table.
Suppose 1: The problem occurs in the new section header. Let's take a look at the section header and compare the differences between the section header before and after the section is inserted:
Is the header of the newly inserted section. test, and the header of the last section. rsrc before the new section is not inserted.
Here we can see a strange phenomenon. In the figure before the new section is not inserted, there seems to be some data behind the last section. It is reasonable to say that the last section should be 0. So I guess it may be that the newly inserted section header overwrites the original data. to verify my conjecture, I will insert the last section without inserting the new section. set the data after rsrc to 0, and then run the program. This step is the last section of the test. does the data after the rsrc header affect the program.
Is the status after the. rsrc node header is set to 0:
Then run test1.exe with the saved file fuck. The message box shown in is displayed:
Now, I am sure that the data after the last section. rsrc cannot be overwritten at will. No wonder the program runs abnormally after I insert a new section. However, the data after the last section of the program compiled by the VB6 compiler cannot be overwritten, so you cannot Insert a new section to infect the vbprogram? The answer is "OK ". The solution is always developed by people. Let's analyze it now: After data is overwritten, the program cannot run, specifically, the program is not loaded as an attack at all (the error message box above shows that the program encountered an error during initialization and dll loading). How can this problem be solved? Then let's analyze again. Where is the command at low level abnormally used the data after the node header? We are now looking for a possible location for the RVA address in the data area after the application section header. It can be seen that the last section header. rsrc is split to 00000228 H, so let's look at it in the data directory of the PE file header. Coincidentally, an application with the address 00000228H was found in the IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT directory, such as in the red circle.
It seems that the input directory bound to IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT uses the last header. the data after rsrc is abnormal. Generally, all the data is stored in the data section. data, and I have never seen data in the header of the node.
We know that the bound input directory is used to locate the dll function address when determining the Dll loading location, when the dll cannot be loaded to a predetermined memory address, it is necessary to re-enter the IAT table by the connector, and then bind the input directory becomes useless. In this case, the BIND input directory does not actually exist. Well, now we will set the BIND input directory IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT to 0, indicating that we do not need to bind the input, and then Add a new section to run it.
In this example, my program test1.exe finally runs into an attack after a new section is inserted.
Now I add a jmp command in the newly inserted section that directly returns the entry point of the original program:
Modify the program entry point to start RVA for the new section, and insert the jmp command in the new section to jump to the original entry, as shown in. Save the file
Test1.exe then runs, and the program runs normally. However, I have changed the program entry process.
Now, let's sum up: I found that the program compiled by the VB6 compiler puts IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT to bind the input directory data to the last node header of the PE file. In this way, whether Microsoft is interested or not, some vbprograms infected with virus infected by new sections cannot run normally. Of course, viruses can bind the input directory item to 0 for attack loading. In fact, other compilers generally do not place the data part bound to the input directory after the header. In this way, the vbprogram has a certain degree of anti-virus capability compared with other programs. Although this anti-virus capability is not strong, can we extend this feature of VB in the future to enable PE executable programs to have self-virus capabilities in some way? This value is further studied.