# A Cloud-Based Real-Time Mechanism to Protect End Hosts against Malware
## 3 System Design  
The overall system architecture of Skywalker is shown in Figure 3. Letters (a)-(j) beside the arrows in the figure represent the execution order of related operation. Skywalker consists of three major components, _SSDT Hooker, Image Controller, and Image Handler_. Moreover, Skywalker consists of two phases. Phase 1 is SSDT hooking, implemented by SSDT Hooker and Image Handler. Phase 2 is image scanning, implemented by Image Controller and Image Handler. \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Setting** \\ \hline
**Privileges** & public key \\
**Request rate** & 4 requests/minute \\
**Daily quota** & 5760 requests/day \\
**Monthly quota** & 178,560 requests/month \\
**Status** & Key enabled \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Limitations of VirusTotal public Application Programming Interface (API). Component SSDT Hooker activates in phase 1. It is responsible for hooking Image Controller into SSDT. Skywalker uses a Windows driver to implement SDDT Hooker. SSDT Hooker clears the WP flag of cr0 register first. Then, SSDT Hooker receives the system call number and the address of stub function ZwCreateUserProcess from Image Handler. The system call number is an SSDT index from which we can obtain the location that stores the address of the hooked function ntlNCreateUserProcess. Thus, the address of native API ntlNCreateUserProcess in SSDT is replaced by our component, Image Controller. After the hooking, once a user clicks an executable image, the execution control flow of kernel is transferred to Image Controller before the executable is executed. Image Controller gets the full path name of the executable and sends the name to Image Handler, which in turn gets the image of the executable and sends it to VirusTotal for scanning. Finally, after getting the result from VirusTotal, if the executable is not malware, Image Handler notifies Image Controller to give the control to the ntlNCreateUserProcess to create a process and execute the executable. Otherwise, Image Handler notifies Image Controller to block the execution of the executable and send the user a warning message. Component Image Controller activates in phase 2. It is in charge of both the retrieval of the path name of an executable that is going to be executed and execution of the executable. When a user double clicks an executable file, Windows system calls stub function ZwCreateUserProcess first. Then, the system executes the hooked Image Controller. Image Controller uses a named pipe to communicate with Image Handler. A named pipe connection is created by API PipeConnection. After creating and setting a named Pipe, Image Controller can use SendImagePathFromPipe to send the path name of a target executable to Image Handler. Finally, ReceiveOrderFromPipe is invoked to wait for the response result from the Image Handler. If the result is 1, Image Handler passes all parameters that it receives from the stub function to native API NtCreateUserProcess and transfers the control flow to it. NtCreateUserProcess creates a new process to execute the executable. However, if the result is 0, it means the executable is malware. Hence, Image Controller blocks the execution of the executable and returns execution flow to the stub function. Image Controller also sends a warning message to the user. Component Image Handler resides in user address space of a Skywalker process and takes different roles in phase 1 and phase 2. The main task in phase 1 is to pass the memory address of stub function ZwCreateUserProcess into SSDT Hooker. Image Handler loads ntlll.dll into the memory. The stub function ZwCreateUserProcess is exported from ntlll.dll, thus we can use GetProcAddress to obtain the memory address of it. Image Handler then uses DeviceIOControl to communicate with SSDT Hooker. The memory address is transmitted to SSDT Hooker in the kernel address space. Image Handler then enters into phase 2.