## 3 Proposed Method and Implementation
### Static Analysis Process  
The static analysis consists of software for malicious code analysis without execution in order to determine the pattern attack of the malicious program and its capabilities to harm the system. This process helps us to identify the byte-sequence n-grams, a syntactic library call, control flow graph, and all types of non-executable and executable files. However, the static analysis has limitations due to packed or obfuscated malware. Similar methods have been proposed such as Dynamically Generated and Obfuscated Malicious Code (DOME) which is a host-based technique for detecting several general classes of malicious code in software executables [35]; however, it was unable to handle packed malware.  
In this research, to overcome the challenge of packed malware, we have used the dissembler tools such as IDA Pro (IDA is the Interactive **D**is**As**sembler: the world's smartest and most feature-full disassembler, which many software security specialists are familiar with) [36] and PeStudio [37]. Figure 2 shows the distribution of the packers names from our dataset.  
The experiment has been conducted over 61,354 malware files, and we used the IDA Pro to translate a program into its equivalent high-level-language program given the content of the binary and PEid [38], a specialized software to unpack the malware. As given in Figure 2, the result is that 43% of these malware programs are unpacked identified as \"nothing\", with the other identifiers accounting for approximately 57%of the total percent. From the result, we can understand that the malicious code has the ability to evade the detection system by changing their byte sequence with the aid of obfuscation techniques. The SQLite (SQLite is a C-language library that implements a small, fast, self-contained, high-reliability, full-featured, SQL database engine) [39] has been used to construct our API call lists after dissembling the malware. It is a library used by IDA Pro to allow security analysts to create plug-ins to be performed by IDA Pro.  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Type** & **Source** & **Quantity** & **Percentage** \\ \hline
**Malware** & VirusShare & 61,354 & 78\% \\
**Benign** & Various locations and made from our lab & 17,214 & 12\% \\ \hline \hline \end{tabular}
\end{table}
Table 1: Summary of dataset created as per VirusTotal.  
In addition, it implements an independent transactional SQL DB engine in order to generate the database (.db). During this process, by using the SQLite plugin (SQLite is a C-language library that implements a small, fast, self-contained, high-reliability, full-featured, SQL database engine) we have generated 16 tables; however, we list only eight tables as follows: Expression, modules, instructions, metainformation, callgraph, function, segments, and basic blocks. Different information from the tables regarding the binary content has been observed. The Stacks table contains the function address, the stack name, and the start and end addresses. The Function table contains all the recognizable API system calls, non-recognizable function names, and the length (start and the end location of each function). The Segments table contains information that describes each segment in an executable file, segment name (Code, Data, BSS, idata, tls, rdata, reloc, andrsrc), and the segment length. The operation code (OP) and their addresses and block addresses are contained in the instructions table. The API calls have been extracted using the function table. To operate a match and identify the windows API, we have used the reference from the Microsoft Developer Network (MSDN) which is a comprehensive API reference for working with Microsoft tools, services, and technologies. Figure 3 is a snapshot of IDA Pro in action.