CN115795486A

CN115795486A - Fault injection protection method based on binary system rewriting

Info

Publication number: CN115795486A
Application number: CN202310069973.XA
Authority: CN
Inventors: 胡鹏飞; 赵斌; 郝立鹏; 潘润宇; 钟方天; 底晓强
Original assignee: Shandong University
Current assignee: Shandong University
Priority date: 2023-02-07
Filing date: 2023-02-07
Publication date: 2023-03-14
Anticipated expiration: 2043-02-07
Also published as: CN115795486B

Abstract

The invention belongs to the technical field of code conversion, and particularly relates to a fault injection protection method based on binary system rewriting. The fault injection protection method based on binary system rewriting comprises the following steps: step 1, simulating the fault of a target binary file under a fault model in a fault injection mode, and generating a list which is vulnerable to attack; step 2, repairing the vulnerable instruction in the fault list by using a local protection strategy to obtain a repaired binary file; and 3, repeating the operations of the step 1 and the step 2 on the repaired binary file until no new fault occurs. According to the fault injection protection method based on binary rewriting, a strategy is injected at an assembly code level in a disassembling mode through reassembly; and an iteration and simulation driven framework is provided, which only inserts countermeasures for the vulnerable part of the program, so that the binary file can be repaired in a targeted manner.

Description

Fault injection protection method based on binary system rewriting

Technical Field

The invention belongs to the technical field of code conversion, and particularly relates to a fault injection protection method based on binary rewriting.

Background

Fault injection attacks, also called fault attacks, are becoming more and more common, and a successful fault attack may result in information leakage or authority promotion, and even cause a crash of the whole system. For example, the secure boot of ARM may be affected by voltage faults, enabling an attacker to load controlled values in a Program Counter (PC); the safe boot loader on the Android smartphone can be bypassed by using laser injection faults. For such attacks, firstly, protection is performed from a hardware level, and secondly, at a software level, most of the protection countermeasures for the software level at present need to access the source code of the program, which is impractical in some cases.

Binary re-writing has many important applications in software security and systems, such as program hardening, auto-repair, instrumentation, optimization, bounds checking, and so on. The advantages of binary rewriting are: it can be applied even in the case where the source code of the software is not available, thereby achieving the purpose of protecting the software. The goal of binary rewriting is to add, delete, and replace instructions in the binary code. There are currently two main types of binary rewrite techniques: static and dynamic. In static binary overwriting, a binary file is overwritten on a disk prior to program execution. There are three main types of static binary rewrite schemes, the first being an assembly-level based bypass policy (throttling), which works through hook out underlying instructions, but this approach results in high performance degradation and additional code overhead. The second is a reconfigurable disassembling mode (readable disassembly system), the method uses a rule that the disassembling code can be relocated to disassemble an executable file, and the generated code can be assembled back to a working binary file without manual operation, which is a disassembling-reassembling process overall. The third is a full translation scheme that uses a compiler-based front-end to translate low-level machine code into a high-level Intermediate Representation (IR) for architecture-independent binary rewriting.

Disclosure of Invention

Aiming at the defects and shortcomings of protection measures of fault injection in the prior art, such as unknown source codes, high operation cost, high performance loss and the like, the invention provides a fault injection protection method based on binary rewriting.

The technical scheme adopted by the invention for solving the technical problems is as follows: the fault injection protection method based on binary rewriting comprises the following steps:

step 1, simulating the fault of a target binary file under a fault model in a fault injection mode, and generating a list which is vulnerable to attack;

step 2, repairing the vulnerable instruction in the fault list by using a local protection strategy to obtain a repaired binary file;

and 3, repeating the operations of the step 1 and the step 2 on the repaired binary file until no new fault occurs.

Further, the step 2 is realized by the following steps: pointer analysis is performed on the target binary file by adopting a Ddisasm tool, an intermediate representation is generated in the form of intermediate representation (GTIRB) of the GrammaTech binary file, and then the intermediate representation is operated through a Python GTIRB library and is recompiled into an executable binary file.

Further, the local protection policy is to locally insert protected instruction code, and includes: a protect mov instruction or a protect cmp instruction.

Further, the protection mov instruction is specifically: after the execution of the mov operation, the results of the two memory locations are compared and in case the two memory locations do not coincide, a fault handler is invoked.

Further, the protection cmp instruction is specifically: and executing two comparisons, comparing whether the results of the two comparisons are equal, and if not, calling a fault processing program.

Compared with the prior art, the invention has the following advantages and beneficial effects:

1. a static binary rewriting scheme is adopted to inject protection countermeasures, and the protection mode does not need to know the source code of a program, so that the method is suitable for most commercial software;

2. protection strategies are injected at the assembly code level by reassembling the disassembled form, so that the binary file can be repaired in a targeted manner;

3. the running overhead is small, copying each instruction means an overhead of at least 300% in code size for classical copy schemes, since for each instruction it will add another copy of the instruction and a comparison process between their results. The method proposed by the invention only aims at vulnerable points, so that the method can be better executed than a simple replication scheme.

Drawings

FIG. 1 is an overall flowchart of the binary-rewrite-based fault injection protection method of the present invention;

FIG. 2 is a flow diagram of a local protection mode of mov operation;

FIG. 3 is a flow diagram of a local protection mode of cmp operation.

Detailed Description

The technical solutions in the embodiments of the present invention will be described clearly and completely in the following description with reference to the embodiments of the present invention and the accompanying drawings. The following description of at least one exemplary embodiment is merely illustrative in nature and is in no way intended to limit the invention, its application, or uses. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

Embodiment 1 provides a fault injection protection method based on binary rewriting, which reduces fault injection vulnerabilities in a binary file by using an iteration method driven by fault simulation, and repairs the binary file by continuously iterating until no fault injection vulnerabilities occur.

The method in this embodiment is mainly implemented by using a system as shown in fig. 1, and the system is composed of two main components: one fault and one patch. The fault engine simulates the fault in a certain fault model in the target binary file and generates a list of vulnerabilities, which means that the fault is triggered in the target binary file. The stitcher uses the list generated by the faulting program to patch the binary. The patcher will patch each bug as locally as possible without affecting the code around it. The patched binary file is then run through the bug and patcher again, repeating the iteration process until no more bugs occur or can be repaired. The method specifically comprises the following steps:

1. fault simulation

First, an error model, such as a single-bit flip error model, a byte error model, etc., is selected that is intended to protect the target binary file from damage. The fault machine accepts a target binary and two inputs: one "good" input and one "bad" input. For example, a "good" entry is the correct password, while a "bad" entry is any value other than the correct password. First, the inputs of "good" and "bad" are performed to see the difference in execution trajectory between them. When the target binary file is run with "bad" input, the trace of all executed instructions can be effectively recorded. Then, for each offset in the trace, taking the single-bit flip error model as an example, the binary is run until that offset in the trace, one bit in the instruction is flipped at the offset, and then execution continues, with the target binary either crashing, or executing as an incorrect input, or behaving differently (as a correct input). If it appears as a correct input, this is a successful failure, the track offset and the error that caused it are recorded, in which case the bit offset in the command at the track offset is recorded, resulting in a failure list in which all successful failures are recorded.

2. Fault (leak) repair

The "successful failure list" from the failed machine is addressed locally in the patcher. The patcher replaces the vulnerable instructions with a known reinforcement pattern. For example, consider the operation of a fault under an "instruction skip" fault model, which identifies a fault in which the skipping of the mov instruction is successful at timestamp 40. The local countermeasures are to execute the mov twice or to add a compare instruction to verify that the mov has been executed before. Note that these countermeasures can lead to repeated reads, but redundancy is key to reducing fault injection attacks.

The invention realizes a concept verification patching program based on a GrammaTech Ddisasm tool and a Python binary operation library, and the method specifically comprises the following steps: the Ddisasm tool executes pointer analysis on the target binary file, generates an Intermediate Representation (IR) in the form of a GrammaTech binary file intermediate representation (GTIRB), then can operate the intermediate representation through a Python GTIRB library, and recompiles the intermediate representation into an executable file, wherein the recompiled executable file is the repaired binary file, namely the patched binary file.

In the method for repairing the fault, the invention adopts a local protection strategy and inserts protected codes in a local part. The following are two local protection strategies:

(1) Protecting mov instructions

To protect the mov operation from fault attacks, after the execution of the mov operation, the results of the two memory locations are compared and in case of inconsistency, a fault handler is invoked: the running of the software is stopped, or the program is crashed firstly, so that the target file is prevented from being attacked, and the protection effect is achieved. The specific flow is shown in fig. 2.

(2) Protection cmp instructions

The cmp instructions are protected from error attacks by performing two comparisons and comparing their result flags, and when the two comparisons are not equal, a fault handler is invoked, and the specific flow is shown in fig. 3. To this end, the present invention uses the pushfq instruction in the x86-64 ISA, which requires a valid stack pointer (rsp).

3. Iteration

After a fault simulation (fault) and a patch (patcher) are run, a patched binary is obtained. Running a bug on a patched binary may discover that a new bug has been added due to the addition of patch code and changing the distance between instructions. These new bugs can then be resolved by iteratively running the entire program until a fixed point is reached and no new failures occur.

The fault injection protection method based on binary rewriting provided by the invention can keep the structure of the original binary file by decomposing the binary file and inserting a strategy. And an iteration and simulation driven framework is provided, and the framework only inserts countermeasures for the vulnerable part of the program, so that the binary file can be repaired in a targeted mode.

Claims

1. The fault injection protection method based on binary rewriting is characterized by comprising the following steps:

step 1, simulating the fault of a target binary file under the fault model in a fault injection mode, and generating a vulnerable list;

2. The binary overwrite based fault injection protection method of claim 1, wherein the step 2 is implemented by: and performing pointer analysis on the target binary file by adopting a Ddisasm tool, generating an intermediate representation in the form of an intermediate representation of the GrammaTech binary file, operating the intermediate representation through a Python GTIRB library, and recompiling the intermediate representation into an executable binary file.

3. The binary overwrite based fault injection protection method of claim 1 or 2, wherein: the local protection strategy is to insert protected instruction codes locally, and comprises the following steps: a protect mov instruction or a protect cmp instruction.

4. The binary-rewrite-based fault injection protection method according to claim 3, wherein the protection mov instruction is specifically: after the execution of the mov operation, the results of the two memory locations are compared and in case the two memory locations do not coincide, a fault handler is invoked.

5. The binary rewrite-based fault injection protection method of claim 3, wherein the protection cmp instruction is specifically: and executing two comparisons, comparing whether the results of the two comparisons are equal, and calling a fault processing program if the results are not equal.