Research on Modularization-based Code Reuse Technology in Software System Development

By monitoring an executing process, all instruction sequences executed by the process can be obtained, and these instruction sequences can be transformed into a program execution flow graph by graph extraction [28].

EFG is a subgraph of CFG, but it is more representative of the real execution flow of the program. Figure 2 shows the comparison of EFG during the ROP variant attack, and it can be clearly seen that EFG can well represent the characteristics of the attack.

Figure 2.

EFG execution flow comparison

The overall flow of ROPGMN is shown in Fig. 3 and is divided into two phases: 1)

Preparation phase, where benign inputs are constructed before the detection starts, and the acquisition program executes the flow to extract the benign AEFG by feature extraction on the EFG. The benign AEFG was stored in memory as a control.

Figure 3.

Overall ROPGMN process

The preparation and detection phases are two separate detection executions, and the biggest difference between the two executions is in the acquisition of the execution stream. The execution stream is the complete sequence of instructions for program execution, and the binary interpolation tool PIN can be used to efficiently acquire every instruction of program execution in real time.

The execution flow will be efficiently transformed into an easy-to-handle EFG graph structure, which, if the graph structure is too large, will result in low training efficiency and accuracy of the graph neural network [29]. Therefore, in this paper, only code segments containing dangerous function calls are transformed into graph structures, which greatly reduces the number of EFG nodes and edges and improves the efficiency of graph neural networks. Dangerous function calls refer to function calls with buffer overflow vulnerabilities.

Each node of the EFG is a kind of base block with a sequence of instructions within the base block, and these sequences of instructions cannot be used as inputs to the neural network, so feature extraction is needed to transform the sequence of instructions in a node into a vector v representation of the execution flowchart obtained in the previous section.

Through graph similarity computation, the similarity score between two graphs can be obtained, based on the similarity score to determine whether the current AEFG is a normal execution flow. Nowadays, the rapid progress of GPU promotes the development of artificial intelligence, and graph neural network comes into being by borrowing the ideas of recurrent network and convolutional network. Therefore, in the calculation of graph similarity, in addition to using the traditional graph theory algorithm, a variety of graph neural networks can be used in order to obtain the similarity score. 1)

Model Selection

For the case of this paper, two AEFG graphs G1 = (V1, E1) and G2 = (V2, E2) containing node feature X_i and edge feature X_i→j, a pair of AEFGs are used as inputs using the graph matching model, and the attention mechanism is utilized for joint inference, and finally the similarity score of the graph pairs is generated S(G1, G2), which determines whether or not the current execution flow is being attacked by a ROP.

Propagation Layer: through neural networks, the node features are propagated through multiple rounds of information to update the nodes. For each round, any edge will unite its connected two nodes to generate a new message_j→i through a neural network, and any node will unite its connected edges carrying message_j→i mapped as a new node through a neural network, and the formula for updating from node h^t to h^t+1 is as follows: (3)mj→i=fmessage(hi(t),hj(t),eij),∀(i,j)∈E1∪E2 (4)μj→i=fmatch(hi(t),hj(t)),∀i∈V1,j∈V2,ori∈V2,j∈V1 (5)hi(t+1)=fnode(hi(t),∑jmj→i,∑j′μj′→i)

The f_match for obtaining graph cross-information uses an attention-based propagation module with the following formula: (6)aj→i=exp(sh(hi(t),hj(t)))∑j′exp(sh(hi(t),hj′(t))) (7)μj→i=aj→i(hi(t)−hj(t)) (8)∑jμj→i=∑jaj→i(hi(t)−hj(t))=hi(t)−∑jaj→ihj(t)

Aggregation layer: after a certain number of T rounds of propagation, a tight fit layer is needed to aggregate all nodes to form a vector representation of the entire graph. The aggregation layer performs a vector-weighted sum with gate for each node using the approach provided by Li et al. It can help filter out irrelevant signals: (9)hG=MLPG(∑i∈Vσ(MLPgate(hi(t)))⊙MLP(hi(t)))

After obtaining h_G1 and h_G2 of a pair of graphs, similarity distance similarity algorithms can be utilized to compute the similarity, such as Euclidean similarity, cosine similarity, or Hamming similarity: (10)s=fs(hG1,hG2)

The advent of the PREADY signal allows the APB3 bus to support slower slave devices, while the advent of the PSLVERR signal allows for more reliable transmission on the APB3 bus.

There are several versions of APB bus, APB2, APB3, APB4 and so on. In order for the code generator designed in this paper to support more APB interfaces, this paper needs to make a comparison between them. The differences between these three versions are listed below. 1)

Catalog structure design

Although APB2, APB3, APB4 are all APB buses, however, they are still different after all. In order not to confuse cross use. In this paper, we designed a directory structure with a strict hierarchical relationship, and then put the corresponding template files at the bottom of the directory structure.

The template files were designed with full consideration of later reuse of the code. The widely promoted coding techniques or UVM built-in mechanisms are utilized in an all-round and comprehensive way. It is mainly reflected in the following points: 1)

Use of parameters, such as address bitwidth, data bitwidth, etc., to adapt to different systems. And put the parameters common to many related components in the same package for easy management.

The user interface of the code generator determines how the code generator is used. Through the previous analysis, it can be known that the original easer_uvm_code_generator is complicated to operate and requires more things to be configured when generating an authentication platform for the IP of the AHMA interface. This is more difficult for novices to get started. For this reason, this paper needs to improve it. Before improvement, this paper needs to clarify the goal of improvement.

Wrapping the original perl code generator. For example, comment.tpl can be processed in a scripting language to automatically generate some of the files that the original code generator needs to use.

This section begins the process of how this paper redefines the user interface. Figure 4 shows the generation process of the new code generator validation platform. As can be seen from the figure, there are two main processes: first, the processing of common.tpl. Second, the template file for the AMBA interface is read and processed.

Figure 4.

Flowchart of the verification generated by the generated code generator

1)

Processing of the common.tpl file

First of all, in order to ensure compatibility with the original code generator, some of the original configuration options can still be used in the new common.tpl.

In order to generate the verification environment for the AMBA interface IP, this paper defines some configuration information that the bash language needs to handle. These configurations start with AMBA_begin and are on a separate line. This is immediately followed by the if=<interface> field to indicate the interface type, type=<M_or_S> to indicate whether to use a master or slave device, and id=<number>, which is an optional field to indicate the device ID number. Finally, name=<name> is used to indicate the name of the object when the agent is being instantiated, and is terminated by AMBA_end.

1)

Effectiveness of testing in real applications

In this section, four commonly used applications are utilized to evaluate the effectiveness of this mechanism to test real applications. First, CFG construction and data collection are performed on four different programs, namely, Adobe Flash Player, nginx, proftpd and firefox, respectively. The gadget chains are constructed, the data is encoded to generate a training dataset, and labels are added to the benign and malicious samples. The number of gadget chains generated by each application is shown in Table 1.

First, the mechanism is evaluated using Adobe Flash Player. For the collected dataset, 80% is randomly selected as the training set, 10% is used for validation, and 10% is used for testing. The 80% dataset contains 80% of the benign gadget chains and 80% of the malicious gadget chains in the entire dataset. Therefore, the training and validation sets contain a total of 180,987 benign gadget chains and 150,822 malicious gadget chains, and the test set contains 20,109 benign gadget chains and 16,758 malicious gadget chains. The test results are shown in Table 2.

The accuracy rate is 97.1%, false positive rate is 0.42% and false negative rate is 0.54%. It can be seen that the neural network trained with real applications as samples can get high detection rate, low false positive rate and false negative rate. The experimental results show that the deep neural network can learn the attack features better. This is because deep neural networks are able to discover complex features in larger datasets rather than overfitting small training data and losing key features. The detection effect of the present mechanism on three other real applications is further evaluated to demonstrate the broad applicability of the mechanism.

For the other three programs, again 80% of the dataset is selected as training data, 10% for validation and 10% for testing to achieve the best performance. From the results, it can be seen that the defense mechanism proposed in this paper can show high accuracy rate and low false positive rate on all the different programs, which indicates its wide applicability. The average accuracy rate obtained from the evaluation is 98.0%, the average false positive rate is 0.14% and the average false negative rate is 0.54%.

2)

Detection Effectiveness of Real CRA Attacks

In this subsection, the defense mechanism is tested by real exploits. Four samples of real exploits are identified in Exploit-DB. To further create test samples, ROPGadget and Ropper are used to generate the exploits that execute mprotec or execve. At the same time, exploits were manually modified to swap the order of multiple gadgets without changing the attack behavior, or to replace some of the gadgets with new gadgets that have the same effect, resulting in 64 real payloads. Their detection using a classifier revealed that the neural network model correctly classified them as genuine CRA payloads, suggesting that the defense mechanism is capable of detecting real-world CRA exploits. It also demonstrates the feasibility of the CFG splitting based scheme in detecting code reuse attacks.

In this subsection, traditional machine learning methods are compared with the deep neural network used in this defense mechanism. Traditional machine learning methods, such as SVM, have been used for ROP detection. Here, the neural network model is compared with SVM and LR for detection. Specifically, SVM and LR with radial basis function kernel are used as classifiers and trained with 80% of Firefox’s dataset. The results are shown in Table 3. LR detects 82.1% accuracy, 8.3% false positives and 20.3% false negatives. SVM detects 74.6% accuracy, 7.7% false positives and 25.1% false negatives.

Comparative results show that the defense mechanism proposed in this paper significantly outperforms SVM and LR in terms of accuracy, false-positive and false-negative rates. The results confirm that the designed algorithms have significant advantages in learning complex datasets. It also verifies that the neural network architecture is able to capture these spatial features better. On the contrary, as mentioned earlier, SVM and LR are not able to acquire this information, thus producing a rather high false positive rate.

All 12 SEPC CPU2006 benchmark programs written in C were run on GCC 4.7 using the -O2 optimization level to measure the runtime performance of this defense mechanism. The experimental results are shown in Table 4. All benchmark programs have 0% overhead. The reason for this is that the mechanism is a non-interruptive detection mechanism that does not require interrupting the application at runtime. Therefore, there is no impact on the protected application.

The mechanism is compared with several other CFI mechanisms. The evaluation metrics are categorized into five classes and they are security level, compiler modifications, instruction set extensions, runtime overhead, and non-intrusive detection. The reference HCIC categorizes the security level into four classes:

Level I: Defense against ROP only.

Level II: Defense against ROP and JOP.

Level III: Defense against ROP, JOP and some advanced CRAs.

Level IV: Defense against all possible CRAs.

Table 5 shows the comparison between different CFI mechanisms taught. From Table 5, it can be seen that the present for proposed does not need to modify the compiler, does not need to extend the instruction set architecture, and has no runtime overhead. It is worth noting that the present mechanism is able to achieve level III security, which is attributed to the fact that the intention of CRAs is all about changing the control flow of the program. In addition, traditional CFIs usually require the insertion of detection instructions or the addition of runtime detection modules, both of which add extra overhead to the original program. This mechanism is a non-intrusive defense mechanism that does not require staking out files or any other kind of modification. The mechanism is divided into two phases. In the training phase, branching information is collected to construct CFGs, and then the CFGs are encoded into DNN training data and DNN models are trained. In the detection phase, branching information is dynamically collected at runtime using IPT and stored in a specific memory in the form of packets. Each time a branch instruction is executed, a packet is generated in real time and the packet contains information such as the destination address of the branch instruction. By retrieving the packet stored in memory in real time to determine whether a CRA has occurred. The entire process does not interfere with the protected application program. As a result, the performance overhead of the program is 0%.

Figure 5 shows the comparison of the running time of each test case of SPECjvm98 in this paper’s algorithm, Swift benchmark case and JIT-C execution mode. The results show that compared with the Swift benchmark data, this paper’s algorithm improves the program performance by about 11.7% on average, of which compress improves as much as 34.5%, db by about 20%, and jack and javac effects reach 2.5% and 3.6%, respectively.

Figure 5.

Performance comparison of SPECjvm98

JIT-C is inefficient mainly because: 1)

Generating THUMB-2 instructions on ARMv6 can only be executed with THUMB instruction compatibility and requires switching back and forth with the ARM instructions used by the interpreter. Compatible execution is inefficient and the instruction set switching overhead is high.

Table 6 shows the cumulative total length and average growth of executable code for each use case of SPECjvm98. From the table, it can be seen that the storage space allocated by the code manager for the PIC code (PIC Code column) is about 3.72M, which is an increase of about 214K compared to the baseline data (Swift Code column), where the growth values of jess, ja-vac, and jack are between 40K and 55K, and the growth of the rest of the use cases is about 25K. the average increase in the length of the instructions per method for each use case ( Average Inc) of each method is only about 35~75 bytes, and the overall average increase of all the use cases is less than 50 bytes, which shows that the length of PICs generated by this paper’s algorithm is not over-inflated compared to Swift. It is worth noting that the total code length data of the algorithm in this paper is the cumulative growth value, which does not require such a large space in actual operation. Thus, compared with the fixed code space allocation of JIT-C (512K for ARMv6), the algorithm code in this paper actually uses less space.

The cache file contains two parts, corresponding to Dalvik Java class library methods and SPECjvm98 Java methods. The statistics show that SPECjvm98 accounts for 82.2% of the total size of the cache space, and the class library methods account for 14.6%, and the sum of the two is only about 1.8 M. In addition to the statistics of the actual size of the cache file, the test also records the cumulative size of the cache for the class library methods of all the use cases at runtime. The results show that the cumulative cache file size of class library methods is about 1.38M, while the actual class library cache file size is only about 260K, which indicates that most of the class library methods used by each test case are the same, and thus, their caches can be shared. The high sharing rate of cache files indicates that if sharing of location-independent code in memory can be realized, then it will save the memory resources of the system.