Virus Trojan killing No. 012: The reverse analysis of QQ stealing Trojan horse

First, preface

In this series of articles, for each virus analysis of the last part, without special circumstances, I will use the reverse analysis means to thoroughly analyze the target virus for the reader. But before the "Panda incense" virus, I used three articles (about 2500 words per article) also only analyzed the virus one-third, and has not been analyzed to the core of the virus. Mainly because that is my series for everyone to analyze the first virus, in order to make some of the original rational things clear, so the article is slightly lengthy, but also mainly to take care of the beginner's friends, abandon those tall things, will my actual analysis process completely presented. I believe that after reading the three articles, we can master the basic analysis methods, then I will only discuss some of the more important parts of the virus in future articles, will be jumping-type to explain, omit the irrelevant content. Of course, I will still be with detailed pictures and text to explain, so that everyone just read these articles, just like hands-on.

In general, virus analysis does not involve algorithmic problems, if it is to analyze the algorithm (such as my previous analysis of the CM4 registration mechanism), then we need to pay more attention to the process and logic of the program, generally do not delve into the specific content of call. Viral analysis often requires a clear understanding of the different call meanings to be able to understand the behavior of the virus. So the first part of this article focuses on the analysis of these call. The second part briefly discusses the implementation of process daemon technology.

Second, reverse analysis

Here we skip the initialization part of the program and come to the location of the first API function:

Figure 1

The first API function that we can see directly is GetModuleFileName, which is used to get the full path to the file of the module that the current process has loaded, and that module must be loaded by the current process. The return value of the function is the length of the file path, which is visible, and the return value is stored in eax, which is 2B, which means that the path length is 2B characters. You can see what path is returned. The path is saved in the "Pathbuffer" in Figure 1, tracking the address for viewing:

Figure 2

The visible program has correctly obtained the address of the current file. Then continue to analyze the next API function:

Figure 3

The function of ShellExecute is to run an external program (either open a registered file, open a directory, print a file, etc.) and have some control over the external program. Specific to this program, ShellExecute will run the Explorer.exe program to open "D:\", in fact, using the program Manager to open the D-packing directory. However, executing this API function is conditional, it needs to be judged according to the result of the second line of call statement in Figure 3, so it is necessary to enter this call to see what conditions need to be fulfilled to execute shellexecute.

Enter oso.00403c48 This function, you can see the following code:

Figure 4

The program will compare the content in EAX and edx, where the eax saved string is the path to the current file we obtained using GetModuleFileName, but is converted to uppercase characters. EdX holds the OSO.EXE file path in the D-packing directory. The two are obviously different here. Therefore, the yellow highlighted conditional jump statements in Figure 4 are not valid, the program will continue to execute sequentially:

Figure 5

It is necessary to note that, since the virus was written by Delphi, the first address of the string minus 4, the 4 bytes taken out is the length of this string. So the first two lines of code in Figure 5 mean to get the number of characters in two paths, and then compare them by subtracting them. It is clear here that the number of characters in the current path is large, so the yellow highlighted condition jumps to the oso.00403c6b position:

Figure 6

Here is still the comparison of characters, because the two are not equal, so the condition of the last sentence jump set, came to OSO.00403CD1 position:

Figure 7

Here the comparison is the disk character, is not equal, so the conditional jump is established, this function is executed. To synthesize the above analysis, this function is to determine whether the currently executing file is located at the root of the D drive, and if so, execute the ShellExecute function in Figure 3, or skip the function execution. Since our program is located on the desktop, we do not execute the ShellExecute function.

Next the program will continue to determine whether the current program is located in the E, F, G, H, I packing directory, if not, then do not execute the corresponding ShellExecute function.

The program then calls the function named OSO.004050F0 and enters its internal analysis:

Figure 8

It is visible that the virus program called the GetSystemDirectory function to get the system directory. In general, the intent of the malicious program to use this function is to copy itself into the system directory in order to confuse users (see "Anti-Virus Research NO. 001: Self-replication and self-deletion"). The virus program then combines the character "Severe.exe" with the system directory string obtained above, and the new path is where the virus program needs to be hidden:

Figure 9

You can then see the CreateFile function:

Figure 10

However, the execution of this CreateFile function is conditional, depending on the return value of call in the first line of code. Entering this call for analysis, you can find:

Figure 11

The program calls the FindFirstFile function to find out if there is no severe.exe in the system directory, and if not (the return value is-1) does not perform the CreateFile function in Figure 10. Thus, the function of the CreateFile is not to create a file, but to open the file. Next is the file copy operation:

Figure 12

Then again a series of file copies, the virus will rename itself to Tfidma.exe, and copied to the system directory. It also renames itself to Conime.exe, which is copied to the Drivers folder in the system directory. Similar operations are not mentioned. The program then calls the ShellExecute function again to execute the programs that were created. As a result, processes such as Severe.exe, Conime.exe, and Tfidma.exe appear in the explorer. It can be said that at this time, our computer is already in the virus. Next we will encounter the thread creation function:

Figure 13

CreateThread functions are often used in conjunction with sleep or WaitForSingleObject functions. Because each thread has its own CPU time slice, its CPU time slice is sometimes not finished when the main thread creates a new one, and it can continue to execute. Sometimes if the main thread has very little code, then the main thread in the CPU-specific CPU time slice is executed and then exited. The end of the main thread means that the program is finished, so in this case, the thread we created ourselves is not executed at all. So we need to use the sleep or WaitForSingleObject function to get the main thread to wait for the threads we created. This procedure uses the Sleep function (wait 1.3 seconds).

Back to Figure 13, according to OD's parsing of the CreateThread function, it is known that the thread is invoking the oso.00404958 function. Analyze this function to know that it mainly creates a batch file named "Hx1.bat" and executes it, and the content of the batch is:

@echo Offset date=2004-1-22ping * * localhost > nuldate%date%del%0

Its main function is to modify the system time, test the local network system and delete itself. This is part of the routine analysis of viruses.

third, the process of guarding the principle of technology

The daemon technology of the process was originally originated from the "Chinese Hacker virus (worm.runouce)", which pioneered the use of the "three-thread" structure. The third thread is created to better protect the program itself from being shut down and deleted. We can put the code we want to execute in the main thread, and then generate two worker threads, their function is to implement the protection of the program, to prevent the program from being closed or deleted by the user. Here, the process that calls our executables is the main process. Two worker threads monitor each other in real time and re-create the thread or process if the monitored object is closed. For example, virus programs can choose Explorer.exe and Taskmgr.exe as remote process resident. If the user knows that the remote thread's resident is a resource manager, the Task manager is opened to end the explorer, and then we put the remote thread into the task Manager. That is, it is impossible to end the main process as long as an explorer or taskmgr exists. If there are other tools to end the process, you can shut it down, and if neither the Resource manager nor the Task manager exist, there is no resident to maintain the remote process. However, if the remote process we choose is random, or is a virus-created, this is not easy to find.

        The program framework of this three-thread structure is roughly as follows (the code comes from the "analysis of three-wire procedure development ideas and implementation"):

1. Main thread: main//Get the Operating system directory GetSystemDirectory (Syspath,max_path);     Query the system directory to see if the virus exists FindFirstFile (virusname,&fdata);     If not in the system directory, copy the running program to the system directory CopyFile (Curname,tname,true);     After the query is complete, close the related handle FindClose (Ffhandle);     Open the system directory under File CreateFile (kname,generic_write,file_share_write,null,open_existing,file_attribute_normal,null);     Modification Time Setfiletime (fchandle,&ftime,null,&ftime); Set Property SetFileAttributes (kname,file_attribute_readonly| file_attribute_hidden|     File_attribute_system);     Create a secondary monitoring thread that resides within the main process CreateThread (Null,0,watch, (LPVOID) rthread,0,null); 2. Local secondary Monitoring thread: Watch//Open the registry as a query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run RegOpenKeyEx (HK     Ey_local_machine,rgspath,0,key_query_value,&hkey);     Query for the existence of Virusname key value RegQueryValueEx (hkey,_t ("Virusname"), Null,null, (LPBYTE) lpdata,&dwbuflen); If there is no relative key value, the registry RegOpenKeyEx (Hkey_local_machine,rgspath,0,key_write,&hkey) is opened again in the write mode;     Write what we want, the system will run our executable every time it is started; RegSetValueEx (hkey,_t ("Virusname"), Null,type, (const BYTE *) Wtname,dwbuflen);          Get the remote thread running, see if it is still_active, and if not, create a remote thread getexitcodethread (Wethread,&exitcode);     3. Remote thread: Remotely//Open the main process in all possible ways to monitor the running status of the main process topenprocess (PROCESS_ALL_ACCESS,FALSE,ERP->RPMOUSEPID);     Wait until the main process is over Twaitforsingleobject (erp->rpprocesshandle,infinite);     Restart our executable file twinexec (erp->rpwinexecname, 0);     4. Get the process Id:processtopid//Enumerate all the Processes enumprocesses (lpidprocesses,sizeof (lpidprocesses), &cbneeded); Open process openprocess with query information and read (Process_query_information |     Process_vm_read,false,lpidprocesses[i]);     Get the handle of the process module EnumProcessModules (hprocess,&hmodule,sizeof (hmodule), &cbneeded);     Obtain the name of a specific module for comparison getmodulebasename (hprocess,hmodule,normalname,sizeof (normalname)); 5. Create a remote thread: createremote//Process_create_thread for CreateRemoteThread//process_vm_operation for VirtualalLocex//Process_vm_write for writeprocessmemory openprocess (process_create_thread| process_vm_operation|     PROCESS_VM_WRITE,FALSE,REMOTEPID);     Allocates space in the remote process in case the thread code is placed in it VirtualAllocEx (Rphandle,null,cb,mem_commit,page_execute_readwrite);     Writes the remote thread's code to the remote process's address space writeprocessmemory (RPHANDLE,REMOTETHR, (LPVOID) remote,cb,null);     The parameters required by the remote thread are also written to the address space of the remote process writeprocessmemory (Rphandle,remotepar, (LPVOID) &rp,cb,null); Create a remote monitoring thread CreateRemoteThread (rphandle,null,0, (Lpthread_start_routine) Remotethr, (LPVOID) remotepar,0,null);

After all, this series is not to teach you to write a virus, but to analyze the general idea of the virus, so the above procedure everyone has a general impression, so in the future of the actual analysis, you can have a rough idea of coping.

Iv. SummaryAt this point, QQ theft Trojan (oso.exe) virus program analysis is here. In fact, this article also mainly discusses the process of daemon technology implementation and kill. In future articles, I will only discuss some of the virus in some of the characteristics of the parts, but also with the times, to study some of the current popular virus, I hope you like.

Virus Trojan killing No. 012: The reverse analysis of QQ stealing Trojan horse