A static rewriting method and system for aarch64 disassembled binary program

Abstract

This invention relates to binary program rewriting technology, and discloses a static rewriting method and system for AArch64 desymbolized binary programs. This method uses disassembly supporting inline data pool identification, ADRP address dependency tracing across basic blocks and functions, compressed jump table reverse recovery and shadow reconstruction, and an in-place trampoline safety net to uniformly repair PC relative addressing, direct branches, indirect control flow, and relocation in cloned code. It can further implant coverage instrumentation or BTI landing points. This solution improves the correctness, robustness, and deployability of AArch64 legacy binary rewriting without source code.

Description

Technical Field

[0001] This invention belongs to the field of software security enhancement technology, specifically relating to a static rewriting method and system for AArch64 desymbolized binary programs. Background Technology

[0002] This section provides only background information relevant to this disclosure and is not necessarily prior art.

[0003] With the widespread deployment of the AArch64 architecture in cloud computing, edge computing, industrial control, and critical infrastructure, a large number of software assets exist for extended periods in closed-source, de-symbolized binary form. For such binary-only programs, maintainers typically cannot access the security capabilities provided by modern compilers and hardware platforms through recompilation, and it is also difficult to perform structural analysis and instrumentation on the program without source code, debugging symbols, and complete relocation information.

[0004] Static binary rewriting is an important method for managing source-less software. Its basic idea is to migrate code, patch addresses, and implant logic into the target binary without changing program functionality, thereby enhancing the security capabilities of legacy software. However, most existing rewriting solutions are built around the x86 platform and are difficult to directly adapt to several characteristics of the AArch64 architecture.

[0005] First, AArch64 uses a fixed 32-bit instruction encoding, and address calculations heavily rely on split PC-relative addressing chains formed by combinations of instructions such as ADRP, ADD, LDR, and LDUR. This address construction chain is often broken up by instruction scheduling in highly optimized compilation artifacts, and may even propagate across basic blocks and function boundaries, making it difficult for traditional patching methods based on local pattern matching to accurately recover address semantics.

[0006] Secondly, the AArch64 compiler often uses compressed jump tables in switch statements and computational jump scenarios, storing jump targets with 1 or 2-byte offsets. After optimizations such as tail merging and hot / cold separation, the base address definition of the jump table may be scattered across multiple paths; at the same time, once code instrumentation or migration is performed, the target address may exceed the encoding range of the original compressed table entry, causing indirect jumps to fail.

[0007] Furthermore, in location-dependent code, function pointers, callback tables, or computed jump targets are often embedded in data or code segments as absolute address constants. After de-symbolizing missing binary types and relocating metadata, static analysis struggles to reliably distinguish between real control flow pointers and ordinary scalar data. Mistakenly treating ordinary data as pointers for patching will corrupt program semantics, while omitting the patching of real hidden pointers will lead to control flow reconstruction failure.

[0008] Furthermore, when implementing fuzzy test coverage instrumentation or ARMv8.5-A BTI protection in source code-less scenarios, it is essential to reliably restore legitimate control flow targets first. Incomplete control flow reconstruction can easily lead to issues such as distorted coverage feedback, missing indirect targets, or program crashes after rewriting.

[0009] Therefore, a static rewriting scheme is needed that can reconstruct the control flow uniformly for AArch64 desymbolized binary programs, so as to balance address semantic correctness, indirect control flow reachability and engineering deployment robustness without source code. Summary of the Invention

[0010] The present invention aims to solve the problems existing in the static rewriting of AArch64 desymbolized binary programs, and provides a static rewriting method and system for AArch64 desymbolized binary programs.

[0011] In a first aspect, the present invention discloses a static rewriting method for AArch64 desymbolized binary programs, comprising the following steps:

[0012] Step 1: Read the ELF file of the target binary program, identify the code segment and related information, and perform disassembly on the code segment that supports inline data pool skipping to obtain the instruction stream and data region partitioning results. The data region partitioning results are used to distinguish between instructions and data items in subsequent processing, so that the data items maintain the original byte content in the rewritten code segment and do not participate in address patching for instructions.

[0013] Step 2: Extract the function entry set based on the instruction stream, and generate an ADRP tracing result set, a jump table object set, and an instrumentation address set;

[0014] Step 3: For the ADRP instruction in the instruction stream, establish a data flow tracing state across basic blocks and functions to identify the address construction chain formed by the combination of ADRP and subsequent instructions, and generate pointer construction records to be repaired. These pointer construction records are read during the address repair phase to construct the instruction set to be repaired. Specifically, for multiple pointer construction records associated with the same ADRP instruction, it is first determined whether their rewritten target addresses are still within the same page. If they are within the same page, the page base address of the ADRP instruction is repaired uniformly, and the page offsets of each pointer construction instruction are repaired separately. If the uniform repair condition is not met, the instruction set remains unchanged or is handled by the runtime forwarding mechanism to avoid inconsistent repairs that could disrupt address semantics.

[0015] Step 4: Perform reverse slicing and candidate base address search for indirect jump instructions to determine the jump table base address, table entry width and target address set, and reconstruct the original jump table into a shadow jump table accordingly;

[0016] Step 5: Clone the original code segment to the new executable segment, insert the target instrumentation logic into the cloned code, and establish a mapping relationship between the address of the original code segment and the address of the new executable segment;

[0017] Step 6: Based on the address mapping relationship, the pointer construction record, and the shadow jump table, repair the PC relative addressing, direct jump or call, and relocation information;

[0018] Step 7: For indirect control flows that cannot be fully determined statically, retain the in-place trampoline safety net in the original code segment so that the original entry can forward the control flow to the cloned code or the patched legitimate target to generate the rewritten target binary program.

[0019] In some embodiments, step 1 specifically includes:

[0020] Step 1-1: Read the ELF file of the target binary program, identify the code segments and related information, including but not limited to relocation information, initialization arrays, termination arrays and exception unrolling information;

[0021] Step 1-2: Based on the code segment, perform a full-coverage disassembly of the code segment by enabling the disassembler's skipdata skip data mode;

[0022] Steps 1-3: During the disassembly process, when an undecodeable instruction word is encountered, it is marked as a data item and skipped according to the width alignment of the AArch64 instruction;

[0023] Steps 1-4: Based on the instruction stream obtained from disassembly and the data items marked in Steps 1-3, establish a full-coverage byte mapping relationship for the code segment, thereby obtaining the instruction stream and data region partitioning results.

[0024] In some embodiments, the source of the extracted function entry set in step 2 includes at least one of the following:

[0025] Function symbols in a symbol table or dynamic symbol table;

[0026] The initial address corresponding to the frame description item in the exception expansion information;

[0027] The addresses of functions in the initialization and terminating arrays;

[0028] Program entry point;

[0029] For location-related code, the candidate entry points are obtained by extracting address constants in the code segment.

[0030] In some embodiments, step 3 specifically includes:

[0031] Step 3-1: Using the destination register of the ADRP instruction as the initial trace register, record its page base address value, and use this instruction address as the starting point for tracing, propagate the data flow state backward along the control flow graph; the data flow state includes the set of registers being traced, the mapping from registers to page base address values, and the mapping from stack slots to page base address values;

[0032] Step 3-2: During the propagation process, perform a status update based on the current instruction type:

[0033] When a register copy instruction is detected and its source register is in the currently tracked register set, the page base address value is synchronously propagated to the target register;

[0034] When a stack store instruction is detected and the register being written to is in the currently tracked register set, the page base address value is associated with the corresponding stack slot key;

[0035] When a stack load instruction is detected and the load source corresponds to a stack slot with a recorded page base address value, the page base address value recorded in that stack slot is restored to the load destination register.

[0036] When a function call instruction is detected, only the register and stack slot states that can continue to propagate reliably across the call are preserved, according to the AAPCS64 calling convention.

[0037] When a conditional jump instruction is detected, the data stream tracking state is simultaneously propagated along the branch target and sequential successor.

[0038] A status key is constructed based on the current instruction address, the set of traced registers, and the page base address value corresponding to each register. When subsequent propagation reaches the same instruction location again and has the same set of registers and stack slot summary, it is determined that the propagation status has been visited and repeated propagation is stopped.

[0039] Step 3-3: During the above propagation process, when an instruction that uses the traced page base address value to construct the target address is identified, a corresponding pointer construction record is generated as the pointer construction record to be repaired.

[0040] In some embodiments, step 4 specifically includes:

[0041] Step 4-1: Starting with the indirect jump instruction as the target, slice forward from its target register to determine the PC relative base address register and the table entry offset register;

[0042] Step 4-2: Position the table entry loading instruction forward, and determine the table entry width of the jump table according to the table entry loading instruction;

[0043] Step 4-3: On the control flow preceding the table entry loading instruction, search for candidate instruction pairs for defining the jump table base address, including at least one of the following forms: a table base address definition formed by a single ADR instruction, in which case the ADR instruction is recorded simultaneously as a base address loading instruction and an offset accumulation instruction; and a table base address definition formed by the combination of ADRP and ADD instructions, wherein ADRP calculates the page base address where the jump table is located, and ADD adds the page offset to obtain the complete jump table base address.

[0044] Step 4-4: For each candidate instruction pair, read a preset number of entries based on its defined candidate base address, and verify whether the target address corresponding to the entry falls within a valid code region. The valid code region must at least satisfy the following conditions: the target address is within the .text code segment of the target binary program; when .eh_frame or basic block range information exists, the target address should also fall within the range of the function to which the current indirect jump belongs, the basic block range of the same function, or the relevant code range confirmed by exception expansion information and function reference relationships. For cases where precise function boundaries cannot be obtained, the .text segment range is used as a conservative validity constraint.

[0045] Steps 4-5: When there are multiple candidate base addresses, the candidate base address that has passed the verification is selected first; if no candidate table base address has passed the verification completely, the candidate table base address with the most valid targets is selected.

[0046] Steps 4-6: Based on the verified candidate table base addresses and their corresponding entry widths and number of entries, determine the jump table base address, entry width, and target address set; establish a shadow jump table in the newly added data segment, uniformly expand the original compressed entries into entries adapted to the target address range after rewriting, each shadow entry stores the value of the difference between the target address and the address calculation base address after inverse shift transformation, and establish a mapping from the original jump table address to the offset position in the shadow jump table to obtain the shadow jump table.

[0047] In some embodiments, step 6 specifically includes:

[0048] Step 6-1: Update the address mapping relationship based on the number of new instructions added after inserting the target instrumentation logic and the inter-section offset between the original code segment and the new executable segment;

[0049] Step 6-2: Based on the updated address mapping relationship, recalculate the relative offsets for direct jump, call, and PC relative literal load instructions;

[0050] Step 6-3: After generating the clone code and before performing address patching, pre-scan for short immediate numeric segment instructions that may exceed the encoding range due to address changes after rewriting, including ADR, LDR / LDRSW in literal pool form, and TBZ / TBNZ instructions; when it is detected that they may need to be expanded into multiple instructions after patching, insert a no-operation instruction as a successor empty slot after the instruction, and record the address of the empty slot in the instrumentation address set.

[0051] Step 6-4: Based on the updated address mapping relationship and the pointer construction record, re-encode the ADRP instruction, ADR instruction and their subsequent address construction instructions, and repair multiple address construction instructions derived from the same ADRP instruction in a group manner;

[0052] Step 6-5: Based on the mapping relationship between the shadow jump table and the original jump table, modify the instructions in the instruction sequence that reference the base address and entry of the original jump table to reference the shadow jump table;

[0053] Step 6-6: When the target to be repaired exceeds the instruction encoding range, the reserved successor slot is used to extend it into a longer instruction sequence.

[0054] In some embodiments, step 7 specifically includes:

[0055] Step 7-1: Retain at least a portion of the original entry addresses unchanged in the original code segment;

[0056] Step 7-2: Insert a micro-jump instruction at the original entry address to forward the control flow to the corresponding new entry point in the cloned code;

[0057] Step 7-3: For addresses that are not accurately identified statically but may serve as indirect control flow targets at runtime, the control flow is redirected to the corresponding new code region using the micro-jump instruction;

[0058] Step 7-4: For absolute or relative relocation entries that point to the function entry point of the original code segment, update them synchronously to point to the corresponding entry point in the new code segment, thus reducing the worst-case scenario of unrecognized hidden pointers to controllable forwarding.

[0059] In some embodiments, the target instrumentation logic is fuzzy test instrumentation logic, and the method further includes:

[0060] Identify valid basic block entries in the rewritten code;

[0061] A coverage probe is inserted at the entry point of the legal basic block. The coverage probe includes a sequence of register save, coverage update, and register restore instructions.

[0062] Construct a dedicated section, which includes at least a coverage callback function, an initialization stub function, and a runtime data slot;

[0063] By replacing the constructor entry in the initialization array with the initialization stub function entry, the program will execute fork server initialization and shared memory bitmap initialization first when it starts.

[0064] Add a dynamic relocation entry to the runtime function pointer slot in the dedicated section.

[0065] In some embodiments, the target stake-insertion logic is a branch target identification and reinforcement logic, and the method further includes:

[0066] Identify the set of legal targets for indirect jumps, the set of legal targets for indirect calls, and the set of overlapping targets corresponding to the intersection of the two;

[0067] Insert a BTI J instruction at the set of legal indirect jump targets;

[0068] Insert BTI C instructions at the set of legal targets for the indirect call;

[0069] Insert a BTI JC instruction at the overlapping target set;

[0070] Modify the registers of the indirect tail call path so that the tail call jumps through the preset register.

[0071] Based on this, the method further includes:

[0072] Analyze the PLT section and the corresponding repositioning section to identify the PLT pile entry point;

[0073] For each PLT stub, a new dedicated section is constructed with a jump board that begins with BTI J, followed by a sequence of instructions to access the GOT slot and jump to the actual target.

[0074] Rewrite the first instruction of the original PLT stub as BTI C and make it jump to the corresponding jump board;

[0075] Check or add a GNU property section to declare that the output ELF file supports AArch64 BTI features.

[0076] Secondly, this invention discloses a static rewriting system for AArch64 desymbolized binary programs, comprising:

[0077] The disassembler and metadata extraction module is used to identify the code segments, function entry points, data regions, and relocation-related information of the target binary program, and to generate an ADRP tracing result set and a jump table object set.

[0078] The address dependency tracing module is used to perform cross-block and cross-function data flow tracing of ADRP instructions and generate pointer construction records and pointer patch description objects;

[0079] The jump table recovery module is used to perform reverse slicing, candidate base address verification, shadow jump table reconstruction, and jump table reference update for indirect jumps;

[0080] The code cloning and patching module is used to clone the original code segment to a new executable segment, establish a mapping from the address of the original code segment to the address of the new executable segment, and patch PC relative addressing, direct branching, literal access, relocation and jump table references.

[0081] The indirect control flow reconstruction module is used to redirect indirect control flows that cannot be statically determined completely through the stationary trampoline safety net.

[0082] The output module is used to generate the rewritten AArch64 binary program.

[0083] Thirdly, the present invention discloses an electronic device, including a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the electronic device performs the above-described method.

[0084] Fourthly, the present invention discloses a readable storage medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the above-described method.

[0085] This invention solves the following problems existing in the prior art:

[0086] The inability to accurately associate ADRP and its use points across basic blocks and functions leads to incomplete or incorrect address patching; the inability to reliably restore compressed jump tables in highly optimized scenarios, and the difficulty in overcoming the addressing range limitations of the original compressed table entries; the inability to perform fully static determination of hidden pointers in location-related code, thus affecting the correctness of the rewritten functionality; and the difficulty in simultaneously supporting instrumentation requirements in source-free scenarios and hardware control flow protection enhancement requirements within the same rewrite framework.

[0087] The present invention has the following beneficial effects:

[0088] By analyzing data flow across basic blocks and functions, we can accurately correlate the ADRP definition and usage chain under AArch64 split addressing, thereby improving the completeness and correctness of address patching.

[0089] By verifying candidate base addresses and reconstructing shadow jump tables, compressed jump tables can be stably restored in highly optimized scenarios, and the original table entry encoding range limitation can be broken.

[0090] By using a "static identification priority and runtime fallback" safety net, the worst-case scenario of unidentified hidden pointers can be downgraded from program crash to controllable forwarding, thus improving the deployability of the project.

[0091] It can support various security applications such as source code-less fuzz testing instrumentation and BTI automated implantation within a unified rewrite framework, and has good scalability;

[0092] While maintaining program functionality, it can reduce the overhead of traditional dynamic binary translation schemes and enhance the security capabilities of legacy AArch64 binaries. Attached Figure Description

[0093] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments, and the advantages of the present invention in the above and / or other aspects will become clearer.

[0094] Figure 1 This is the overall flowchart of the static rewriting method for AArch64 desymbolized binary programs described in this invention.

[0095] Figure 2 This is a schematic diagram of the control flow rewriting described in this invention, illustrating three control flow reconstruction mechanisms: direct repair, trampoline safety net, and shadow jump table. Detailed Implementation

[0096] Example 1: Overall Rewrite Process

[0097] In this embodiment, the input is a de-symbolized ELF binary program under the AArch64 architecture, and the output is a rewritten binary program that maintains the same functionality and has undergone security instrumentation or security hardening. The overall process can be divided into four stages: "metadata extraction and analysis", "code cloning and instrumentation", "global address correction", and "indirect control flow reconstruction".

[0098] like Figure 1-2 As shown, a static rewriting method for AArch64 desymbolized binary programs includes the following steps:

[0099] Step 1: Read the ELF file of the target binary program, identify the code segments and related information, and perform disassembly on the code segments that supports inline data pool skipping to obtain the instruction stream and data region partitioning results;

[0100] Step 2: Extract the function entry set based on the instruction stream, and generate an ADRP tracing result set, a jump table object set, and an instrumentation address set;

[0101] Step 3: For the ADRP instruction in the instruction stream, establish a data flow tracing state across basic blocks and functions to identify the address construction chain formed by the combination of ADRP and subsequent instructions, and generate a pointer construction record to be repaired;

[0102] Step 4: Perform reverse slicing and candidate base address search for indirect jump instructions to determine the jump table base address, table entry width and target address set, and reconstruct the original jump table into a shadow jump table accordingly;

[0103] Step 5: Clone the original code segment to the new executable segment, insert the target instrumentation logic into the cloned code, and establish a mapping relationship between the address of the original code segment and the address of the new executable segment;

[0104] Step 6: Based on the address mapping relationship, the pointer construction record, and the shadow jump table, repair the PC relative addressing, direct jump or call, and relocation information;

[0105] Step 7: For indirect control flows that cannot be fully determined statically, retain the in-place trampoline safety net in the original code segment so that the original entry can forward the control flow to the cloned code or the patched legitimate target to generate the rewritten target binary program.

[0106] Step 1, in the metadata extraction phase, first reads the target program's ELF file to obtain the .text segment, program entry point, segment table, section table, dynamic section, symbol table, dynamic symbol table, EH frame, .init_array, .fini_array, relocation table, and other section information. If the target program contains multiple PT_LOAD segments, the alignment constraints of each segment are further read to provide a basis for subsequent addition of sections and layout write-back.

[0107] Step 1 specifically includes:

[0108] Step 1-1: Read the ELF file of the target binary program, identify the code segments and related information, including but not limited to relocation information, initialization arrays, termination arrays and exception unrolling information;

[0109] Step 1-2: Based on the code segment, perform a full-coverage disassembly of the code segment by enabling the disassembler's skipdata skip data mode;

[0110] Considering that the code segment of an AArch64 program may contain constant pools, literal addresses, or other inline data, this embodiment enables skipdata mode during the disassembly stage. When the disassembler encounters an undecodeable 32-bit word, it records it as a data item and proceeds along 4-byte boundaries, thereby ensuring a continuous and complete byte-level overlay mapping for the entire code segment. In this way, not only is the executable instruction stream obtained, but also the data distribution information within the code segment is acquired, avoiding incomplete address patching caused by inline data truncation during disassembly.

[0111] Steps 1-3: During the disassembly process, when an undecodeable instruction word is encountered, it is marked as a data item and skipped according to the width alignment of the AArch64 instruction;

[0112] Steps 1-4: Based on the instruction stream obtained from disassembly and the data items marked in Steps 1-3, establish a full-coverage byte mapping relationship for the code segment, thereby obtaining the instruction stream and data region partitioning results.

[0113] The source of the function entry set described in step 2 includes at least one of the following:

[0114] Function symbols in a symbol table or dynamic symbol table;

[0115] The initial address corresponding to the frame description item in the exception expansion information;

[0116] The addresses of functions in the initialization and terminating arrays;

[0117] Program entry point;

[0118] Candidate entry points extracted from address constants in the code segment.

[0119] After obtaining the instruction stream, a set of function entry points is extracted. Function entry points can come from the symbol table, dynamic symbol table, frame descriptors in the EHframe, `.init_array`, `.fini_array`, and program entry points. In location-dependent code scenarios, candidate entry points related to computation jumps can also be extracted from code segments. This set of function entry points serves as important input for subsequent function-level redirection, indirect call target preservation, and basic block identification.

[0120] During the analysis phase, the system generates at least three types of intermediate results in parallel. The first type is the ADRP tracing result set, which records the split address construction chain; the second type is the jump table object set, which describes the location, width, and target of the compressed jump table; and the third type is the size of the code segment before instrumentation, the original function entry list, and the original address space baseline, which are used to subsequently establish the address mapping from the original .text to the new .inst.

[0121] Step 3 specifically includes:

[0122] Step 3-1: Using the destination register of the ADRP instruction as the initial trace register, record its page base address value, and use this instruction address as the starting point for tracing, propagate the data flow state backward along the control flow graph; the data flow state includes the set of registers being traced, the mapping from registers to page base address values, and the mapping from stack slots to page base address values;

[0123] The tracing state in this embodiment includes at least four parts: the currently tracing register set, the mapping from registers to page base addresses, the mapping from stack slots to page base addresses, and the set of recorded pointer construction records. For each ADRP instruction, the system adds its destination register to the tracing register set and records the page base address corresponding to the ADRP in the register mapping table. Then, starting from the instruction following the ADRP, this state is propagated sequentially along the control flow graph.

[0124] Step 3-2: During the propagation process, perform a status update based on the current instruction type:

[0125] When a register copy instruction is detected and its source register is in the currently tracked register set, the page base address value is synchronously propagated to the target register;

[0126] Regarding register propagation, if a register copy or equivalent transfer instruction is encountered, and its source register belongs to the currently traced register, the corresponding page base address value is synchronously propagated to the target register. In this way, even if the result of ADRP is transferred between registers multiple times, the system can still continuously trace its address source.

[0127] When a stack store instruction is detected and the register being written to is in the currently tracked register set, the page base address value is associated with the corresponding stack slot key;

[0128] When a stack load instruction is detected and the load source corresponds to a stack slot with a recorded page base address value, the page base address value recorded in that stack slot is restored to the load destination register.

[0129] Regarding stack slot propagation, if a stack store instruction is encountered, and the register written to the stack slot belongs to the currently traced register, the page base address value corresponding to that register is recorded under the stack slot key "base address register + stack offset". If a load instruction that reads from the same stack slot is subsequently encountered, the page base address value recorded in that stack slot is restored to the load destination register. In this way, the address dependency chain of the caller-saved registers after stack overflow and subsequent restoration can be recovered.

[0130] When a function call instruction is detected, only the register and stack slot states that can continue to propagate reliably across the call are preserved, according to the AAPCS64 calling convention.

[0131] Regarding cross-function propagation, when traversing function call instructions, the state is trimmed according to the AAPCS64 calling convention. For caller-saved registers, they are removed from the set of traced registers if no explicit evidence is saved; for callee-saved registers, they are allowed to remain valid across calls; for values ​​already written to the stack slot, their stack slot state is retained so that they can be restored via stack loading after the call returns. This allows for address tracing across function boundaries without relying on source code information.

[0132] When a conditional jump instruction is detected, the data stream tracking state is simultaneously propagated along the branch target and sequential successor.

[0133] Regarding control flow propagation, if the current instruction is a conditional jump, the current state is propagated along both the branch target and the sequential successor; if the current instruction is an unconditional jump, propagation continues only along the jump target; if the current instruction is a return, unreachable trap, or other termination instruction, propagation along that path is stopped. To avoid exponential state inflation at control flow convergence points, this embodiment performs deduplication on the combination of "current instruction address + register state summary + stack slot state summary," and only expands on states that have not yet been accessed.

[0134] Step 3-3: During the above propagation process, when an instruction that uses the traced page base address value to construct the target address is identified, a corresponding pointer construction record is generated as the pointer construction record to be repaired.

[0135] When instructions such as ADD, LDR, LDUR, and LDP that construct addresses using the base address of the traced page are identified, the corresponding pointer construction record is recorded. Each record includes at least: the address of the construction instruction, the specific target address value constructed, and the base address source register. If multiple target addresses derived from the same ADRP are located on different pages, the ADRP tracing result is marked as inconsistent to avoid incorrectly performing unified page base address repair on this group of instructions in subsequent repair phases.

[0136] After the tracing is complete, the system further transforms the ADRP tracing results into pointer patch description objects. Each object includes at least one ADRP address, one target page address, and multiple lower 12-bit offset patch entries. Subsequently, when the code segment is migrated to .inst, the ADRP address and corresponding target address are first updated based on the instrumentation and section offset. Then, the ADRP and related ADD, LDR, LDUR, LDP, and other instructions in the object are patched in groups to maintain the consistency between its page base address and page offset. Thus, the original address semantics are preserved after code migration.

[0137] Step 4 specifically includes:

[0138] Step 4-1: Starting with the indirect jump instruction as the target, slice forward from its target register to determine the PC relative base address register and the table entry offset register;

[0139] In this embodiment, for each indirect jump instruction BR, a local slice is executed forward from its target register to determine which address synthesis instruction generates the target address, and then the PC relative base address and table entry offset loading relationship required to generate the target address are parsed forward. Specifically, the ADD instruction used to synthesize the final jump address is located first, and then the ADR instruction to form the PC relative base address and the LDRB, LDRH, LDRSW or LDR instruction to read the table entry offset are located forward.

[0140] Step 4-2: Position the table entry loading instruction forward, and determine the table entry width of the jump table according to the table entry loading instruction;

[0141] Step 4-3: On the control flow preceding path of the table entry loading instruction, search for candidate instruction pairs used to define the jump table base address;

[0142] Step 4-4: For each candidate instruction pair, read a preset number of entries based on its defined candidate base address, and verify whether the target address corresponding to the entry falls into the legal code region;

[0143] When an indirect jump is identified as conforming to a jump table access pattern, the following jump table metadata is recorded: original jump table address, entry width, number of entries, base address load instruction pair, entry load instruction address, address calculation base address, and jump target set. This metadata is maintained as a jump table object and will be used uniformly in subsequent address patching and shadow reconstruction phases.

[0144] When determining the jump table base address, it is not required to uniquely recover a precise original definition point. Instead, a combination of candidate base address search and pre-verification is used. The specific process is as follows: search for candidate base address definition instructions, such as ADR, ADRP+ADD, or equivalent load sequences, in the control flow preceding the entry loading instruction; for each candidate base address, read a preset number of preceding entries and substitute the entry values, address calculation base address, and displacement into the input to obtain several candidate jump targets; if most of these candidate jump targets fall within the legal code region, then the candidate base address is considered a valid base address.

[0145] Steps 4-5: When there are multiple candidate base addresses, the candidate base address that has passed the verification is selected first; if no candidate table base address has passed the verification completely, the candidate table base address with the most valid targets is selected.

[0146] Steps 4-6: Based on the verified candidate table base addresses and their corresponding entry widths and number of entries, determine the jump table base address, entry width, and target address set; establish a shadow jump table in the newly added data segment, uniformly expand the original compressed entries to an entry format that adapts to the rewritten address range, and establish a mapping relationship between the original jump table address and the shadow jump table.

[0147] After obtaining the jump table object, its address is normalized for the first time. Specifically, when the code segment is offset as a whole due to the addition of a new section, the base address loading instruction address, table entry loading address, address calculation base address, and all jump target addresses in the jump table object are updated according to the code segment offset. Then, the above addresses are compensated one by one according to the number of newly added instructions to eliminate the disturbance to the address space caused by the previous instrumentation operation.

[0148] During the shadow jump table construction phase, the system iterates through all identified jump table objects and sequentially creates a .jumptable section in the newly added data segment. For each original jump table, its 1-byte or 2-byte compressed entries are no longer retained; instead, they are uniformly expanded to 4-byte entries. Each shadow entry stores the "difference between the target address and the base address calculated from the target address, then inversely transformed by the shift amount," thus maintaining consistency with the address calculation formula for the original indirect jump. The system also establishes a mapping table from the original jump table address to the shadow jump table offset.

[0149] After the .jumptable section is constructed, the references to the jump table are updated. For ADRP instructions that reference the original jump table, their page base address is patched to the page where the shadow jump table is located; for the corresponding ADD instructions, their page offset is patched to the new offset of the shadow jump table; for ADR instructions in the address calculation sequence, they are patched to the new address calculation base address; for LDRB, LDRH, and other instructions that read table entries, they are converted into a loading form adapted to 4-byte table entries, and the register extension method is normalized to match the width of the new table entries.

[0150] If the patched ADR instruction exceeds its allowed encoding range, it is promoted to an ADRP+ADD double instruction sequence. This process ensures that target addresses exceeding the original compressed jump table encoding range after instrumentation or code migration can still be accessed correctly, thus guaranteeing that switch statements, computational jumps, and similar indirect dispatch logic continue to execute correctly after rewriting.

[0151] During the code cloning and instrumentation phase, the system constructs new sections based on the current operating mode. If in basic rewrite mode, at least the `.inst` and `.jumptable` sections are added; if in coverage instrumentation mode, a `.afl` section is added; if in BTI hardening mode, a `.plt.bti` section may be added, and the `NOTE` section may be supplemented. After completing the layout of the new sections, the system writes the instrumented code to the `.inst` section, writes the shadow jump table to the `.jumptable` section, and records the final virtual address of each new section.

[0152] Step 6 specifically includes:

[0153] Step 6-1: Update the address mapping relationship based on the number of new instructions added after inserting the target instrumentation logic and the inter-section offset between the original code segment and the new executable segment;

[0154] After cloning a code segment, the system records the mapping relationship between the original code address and the address of the newly added instrumented instruction. For each original address, if there are newly added instructions before it, the address is extended sequentially according to the number of newly added instructions, and then the section offset from .text to .inst is added to obtain its corresponding address in the new code segment. This address mapping relationship is used for two purposes: firstly, for subsequent branch patching and address construction, and secondly, for constructing the jump target for the stationary trampoline.

[0155] Step 6-2: Based on the updated address mapping relationship, recalculate the relative offsets for direct jump, call, and PC relative literal load instructions;

[0156] During the global address correction phase, the system performs unified repairs on branches, PC relative addressing, literal access, and pointer construction instructions in .inst based on the instrumentation location set, inter-section offset, and address mapping relationship; performs jumper redirection on function entries in .text; and synchronously updates internal function targets in various relocation tables.

[0157] Direct patching specifically includes the following categories: First, for B, BL, conditional jump, TBZ, TBNZ, and PC relative literal load instructions, the relative offset is recalculated based on the original target address and the new address mapping; Second, ADRP, ADR, and their subsequent address construction instructions are re-encoded so that they continue to point to the migrated legal page base address and page offset; Third, for pointer construction instructions such as ADD, LDR, LDUR, and LDP derived from ADRP, the entire process is patched according to the generated pointer construction record to ensure that all dependent instructions in the same ADRP group maintain consistency between the page base address and the lower 12-bit offset; Fourth, shadow jump table references and direct call targets are updated together to avoid control flow breaks.

[0158] Step 6-3: Before address patching, identify restricted instructions that may cause the patching target to exceed its encoding range due to address changes, and reserve subsequent empty slots for the restricted instructions;

[0159] In actual patching, some instructions may exceed their own coded range due to the target being too far away. For example, the addressing range of ADR is limited, and the jump range of TBZ and TBNZ is significantly smaller than that of B. To address this, this embodiment adopts the method of "reserving slots and then promoting coding": after the first code cloning, subsequent empty slots are reserved for potentially out-of-bounds instructions such as ADR, TBZ, and TBNZ.

[0160] Step 6-4: Based on the updated address mapping relationship and the pointer construction record, re-encode the ADRP instruction, ADR instruction and their subsequent address construction instructions, and repair multiple address construction instructions derived from the same ADRP instruction in a group manner;

[0161] Step 6-5: Based on the mapping relationship between the shadow jump table and the original jump table, modify the instructions in the instruction sequence that reference the base address and entry of the original jump table to reference the shadow jump table;

[0162] Step 6-6: When the target to be repaired exceeds the instruction encoding range, the reserved successor slot is used to extend it into a longer instruction sequence.

[0163] When it is subsequently confirmed that the target exceeds the limit, the empty slot is used to expand it into a longer instruction sequence, such as expanding ADR into ADRP+ADD, thereby completing the boost patch without breaking the consistency of subsequent address layout.

[0164] Step 7 specifically includes:

[0165] Step 7-1: Retain at least a portion of the original entry addresses unchanged in the original code segment;

[0166] Step 7-2: Insert a micro-jump instruction at the original entry address to forward the control flow to the corresponding new entry point in the cloned code;

[0167] After patching the internal code of the .inst segment, the system further rewrites the function entry points in the original .text segment. Specifically, for the identified function entry point address, the system writes a direct jump instruction at the original address location, causing it to jump to the corresponding new entry point in .inst. In this way, if there is already an indirect call path formed externally through function addresses, callback tables, initialization arrays, or absolute relocation, the original entry point can still be hit first, and then the execution can jump to the new code segment through that entry point.

[0168] The "trampoline safety net" refers to a system where, considering that some function pointers or callback targets in location-related code may be hidden in the data as absolute address constants and cannot be fully identified during the static phase, at least some entry addresses are preserved unchanged in the original code segment, and "trampolines" are implanted at these locations. This way, when the runtime control flow still falls on the original address, it can be forwarded to the cloned new code region via one or a few jump instructions. Therefore, even if hidden pointers are not completely discovered statically, the continuity of execution and functional correctness can be maintained through this safety net. This embodiment does not require exhaustively identifying all hidden pointers during the static phase, but rather controls the risk of unidentifiable pointers within an acceptable range by preserving the original entry points and constructing springboards.

[0169] Step 7-3: For addresses that are not accurately identified statically but may serve as indirect control flow targets at runtime, the control flow is redirected to the corresponding new code region using the micro-jump instruction;

[0170] Step 7-4: For absolute or relative relocation entries that point to the function entry point of the original code segment, update them synchronously to point to the corresponding entry point in the new code segment, thus reducing the worst-case scenario of unrecognized hidden pointers to controllable forwarding.

[0171] This embodiment also performs synchronous patching for multiple types of relocations. For R_AARCH64_RELATIVE relocations, if its appended value points to a function entry point in the original .text segment, it is updated to the corresponding new entry point in .inst. For R_AARCH64_ABS64 relocations, if its final evaluation result points to the original function entry point, the function symbol value is updated first, or the appended value is adjusted if necessary. For R_AARCH64_GLOB_DAT relocations, if it references a defined global function symbol, the symbol value is directly updated to the new entry point in .inst. Through the above processing, the absolute function pointers, GOT entries, and runtime relocation results in the data segment can be kept consistent with the rewritten control flow.

[0172] The shadow jump table is the third type of control flow reconstruction mechanism in this embodiment. For indirect control flows such as switch statements or computational jumps that are implemented by compressing the jump table, the original table entries are migrated to the newly added data segment and expanded into shadow table entries adapted to the rewritten address space. Then, the indirect jump logic is changed to access the shadow jump table, thereby ensuring that the target address after instrumentation or migration is still reachable.

[0173] During the indirect control flow reconstruction phase, the system handles control flows that cannot be fully covered by static patching alone. For example, for hidden pointers in location-related code, the system achieves controllable forwarding by retaining the original entry point and the in-place trampoline; for compressed jump tables, a shadow jump table ensures that the migrated target address remains reachable; for BTI hardening, landing points are added at legitimate entry points and PLT paths are patched. Finally, the modified sections and relocation information are rewritten back to the ELF file, and the rewritten binary program is output.

[0174] Example 2: Fuzzy Test Segmentation Application

[0175] In this embodiment, the static rewrite method is used for coverage-oriented fuzz testing. The system first identifies basic block boundaries based on the code segment disassembly results. The determination of basic block boundaries includes at least the following sources: function entry points, direct jump targets, conditional jump targets, jump successor addresses, and jump table target sets. During the identification process, if the disassembly results contain data items returned by skipdata, their possibility as control flow nodes is ignored, thereby avoiding misidentification of inline data as basic blocks.

[0176] After obtaining the set of basic blocks, the system inserts a coverage probe at the entry point of each valid basic block. This probe employs a lightweight "register save-coverage update-register restore" template. Specifically, it first saves the registers and link registers required to execute the probe; then, it writes the block identifier corresponding to the current basic block into the register; next, it calls the hot path callback function located in the newly added .afl section to update the shared memory bitmap; finally, it restores the context and continues executing the original instructions. To facilitate differentiation between different basic blocks, this embodiment assigns a random block identifier to each instrumented basic block and encodes it into the immediate numeric field of the probe.

[0177] To reduce the cost of probe calls, this embodiment additionally constructs a .afl section in the binary. This section includes at least three parts: the first part is a high-frequency coverage callback function, used to update the edge coverage count in shared memory; the second part is an initialization stub function, used to call the AFL runtime during program startup to obtain the shared memory mapping pointer and initialize the predecessor position state; the third part is a data slot area, used to store __afl_get_area_ptr, initAflForkServer, the address of the original constructor, and coverage runtime data.

[0178] During the initialization phase, this embodiment does not simply add a new constructor to .init_array. Instead, it reads DT_INIT_ARRAY and DT_INIT_ARRAYSZ from the dynamic section, locates the dynamic relocation item corresponding to init_array[0], and replaces its original constructor address with the initialization stub address generated in this embodiment. When the initialization stub is executed, it first calls initAflForkServer to establish a fork server, then calls __afl_get_area_ptr to obtain the shared memory bitmap pointer, then saves the pointer and the predecessor location data, and finally calls the original constructor to ensure that the original initialization semantics of the program are not destroyed.

[0179] To support the above calls, this embodiment adds a dynamic relocation entry to the function pointer slot in the .afl section, enabling the runtime linker to fill in the actual addresses of __afl_get_area_ptr and initAflForkServer during loading. Simultaneously, a relative relocation entry is added to the slot storing the original constructor address, so that subsequent unified relocation patching phases can continue to map it to the corresponding new entry in .inst.

[0180] Since the final virtual address of the .afl section is not fixed after it is added to the file, this embodiment also performs secondary repairs on the ADR or ADRP+ADD instructions in the callback function within the .afl section, so that it can correctly access the data slots and runtime state areas in the .afl section after the final layout is determined.

[0181] After completing the coverage probe insertion, .afl section construction, and AFL runtime hooking, the unified address patching, jump table reconstruction, and entry redirection of this invention are then executed. Because this invention has completed unified patching of direct branches, indirect jumps, jump tables, and address semantics, fuzz testing instrumentation can obtain stable and complete path feedback without relying on dynamic binary translation.

[0182] Example 3: BTI Automated Hardening Application

[0183] In this embodiment, the static rewrite method is used for branch target identification and hardening in ARMv8.5-A. The system identifies three types of legitimate target sets based on the control flow reconstruction results: legitimate indirect jump target sets, legitimate indirect call target sets, and overlapping sets that simultaneously possess both types of attributes. For each of the three sets, BTI J, BTI C, and BTI JC instructions are inserted respectively.

[0184] The set of legal targets for indirect jumps includes at least: jump targets obtained from jump table recovery, non-local control flow return targets such as setjmp / longjmp, and computational jump entry points identified through the dispatch table in position-independent code scenarios. The set of legal targets for indirect calls includes at least: exported function entry points and function entry points whose addresses are taken by indirect call analysis. The intersection of the two sets is considered to be reachable by both BR and BLR, therefore a BTI JC is inserted.

[0185] During the code insertion phase, the system traverses the instruction stream in the original .text segment. When an instruction address falls into the above-mentioned set of valid targets, a BTI instruction of the corresponding type is inserted before the instruction, and then the original instruction itself is written. If the location is also an identified indirect tail call entry point, and the register used by the tail call is not the x16 or x17 recommended by BTI, an additional register shift instruction is inserted at that location to transfer the original target register value to x16, and the original tail call is rewritten as BR x16 to satisfy BTI's constraints on the tail call landing point.

[0186] For call targets derived from static data in location-related code, this embodiment further identifies data segments, read-only data segments, read-only relocation segments, and 8-byte alignment values ​​in the GOT that overlap with the .text address range, treating these values ​​as potential function entry points. For such addresses, instead of directly deleting the original entry point, a combination of BTI JC and jump instructions is inserted at the original entry point location, ensuring that it satisfies the legality of the indirect call landing point while also allowing forwarding to the corresponding new entry point in .inst via a trampoline.

[0187] Besides ordinary function entry points, PLT stubs can also become indirect call targets. Therefore, this embodiment specifically parses the .plt section. If relocation sections such as .rela.plt, .rela.plt.sec, or .rela.iplt exist, the number of PLT stubs is calculated accordingly; otherwise, the stub entry point is identified by matching the typical PLT instruction pattern ADRP-LDR-ADD-BR. For each PLT stub, the system restores its GOT slot address and constructs a corresponding jump board in the new .plt.bti section: this jump board begins with BTI J, followed by ADRP, LDR, ADD, and BR instructions, used to jump to the actual target according to the original GOT logic. Subsequently, the first instruction of the original PLT stub is rewritten as BTI C, and a branch or equivalent long jump sequence is arranged after it to jump to the .plt.bti jump board, so that the indirect call also satisfies the BTI constraint when landing on the PLT stub.

[0188] To ensure that the output ELF file explicitly declares support for BTI, this embodiment also checks the .note.gnu.property section. If a GNU property note already exists, the BTI flag in the AArch64 feature bits is set; otherwise, a minimal GNU property note is added to declare to the loader that the binary supports the BTI feature.

[0189] After completing the collection of legitimate targets, insertion of BTI instructions, rewriting of the tail call register, patching of the PLT jump board, and writing of GNU property notes, address patching, entry redirection, and relocation updates are performed uniformly. Through this method, legitimate target markers required for BTI can be added to legacy binaries without recompiling, reducing the set of exploitable targets for code reuse attacks.

[0190] A static rewriting system for AArch64 desymbolized binary programs includes:

[0191] The disassembler and metadata extraction module is used to identify the code segment, function entry point, data region, and relocation-related information of the target binary program, and generate an ADRP tracing result set and a jump table object set. The disassembler and metadata extraction module outputs the following intermediate results: a list of function entry point addresses, the size of the code segment before instrumentation, a jump table object set, and an ADRP tracing result set.

[0192] The address-dependent tracing module is used to perform cross-block and cross-function data flow tracing of ADRP instructions and generate pointer construction records and pointer patch description objects. The address-dependent tracing module further generates pointer patch description objects based on the ADRP tracing result set. Each object includes at least one ADRP address, one target page address and multiple lower 12-bit offset patch items.

[0193] The jump table recovery module is used to perform reverse slicing, candidate base address verification, shadow jump table reconstruction, and jump table reference update for indirect jumps; the jump table recovery module outputs the shadow jump table content and the address mapping from the original table to the new table based on the jump table object set.

[0194] The code cloning and patching module is used to clone the original code segment to a new executable segment, establish a mapping from the address of the original code segment to the address of the new executable segment, and patch PC relative addressing, direct branching, literal access, relocation, and jump table references. The code cloning and patching module generates a mapping from the original .text address to the .inst address based on the instrumented new instruction address list, the original function entry list, and the section offset, and performs branch patching, entry redirection, and relocation updates accordingly.

[0195] The indirect control flow reconstruction module is used to redirect indirect control flows that cannot be statically determined completely through the stationary trampoline safety net.

[0196] The output module is used to generate the rewritten AArch64 binary program.

[0197] The system can be categorized into three modes based on application: basic rewrite mode, coverage instrumentation mode, and BTI hardening mode. Basic rewrite mode completes the construction of .inst and .jumptable sections, address patching, and in-situ trampoline security network deployment. Coverage instrumentation mode, in addition to basic rewrite mode, constructs .afl sections, injects coverage probes, and attaches them to the AFL runtime. BTI hardening mode, in addition to basic rewrite mode, inserts BTI C, BTI J, and BTI JC instructions, constructs .plt.bti sections, and supplements GNU propertynotes.

[0198] This invention provides a static rewriting method and system for AArch64 desymbolized binary programs. Many methods and approaches exist for implementing this technical solution; the above description is merely a preferred embodiment. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this invention, and these improvements and modifications should also be considered within the scope of protection of this invention. All components not explicitly stated in this embodiment can be implemented using existing technologies.

Claims

1. A static rewriting method for AArch64 desymbolized binary programs, characterized in that, Includes the following steps: Step 1: Read the ELF file of the target binary program, identify the code segments and related information, and perform disassembly on the code segments that supports inline data pool skipping to obtain the instruction stream and data region partitioning results; Step 2: Extract the function entry set based on the instruction stream, and generate an ADRP tracing result set, a jump table object set, and an instrumentation address set; Step 3: For the ADRP instruction in the instruction stream, establish a data flow tracing state across basic blocks and functions to identify the address construction chain formed by the combination of ADRP and subsequent instructions, and generate a pointer construction record to be repaired; Step 4: Perform reverse slicing and candidate base address search for indirect jump instructions to determine the jump table base address, table entry width and target address set, and reconstruct the original jump table into a shadow jump table accordingly; Step 5: Clone the original code segment to the new executable segment, insert the target instrumentation logic into the cloned code, and establish a mapping relationship between the address of the original code segment and the address of the new executable segment; Step 6: Based on the address mapping relationship, the pointer construction record, and the shadow jump table, repair the PC relative addressing, direct jump or call, and relocation information; Step 7: For indirect control flows that cannot be fully determined statically, retain the in-place trampoline safety net in the original code segment so that the original entry can forward the control flow to the cloned code or the patched legitimate target to generate the rewritten target binary program.

2. The method according to claim 1, characterized in that, Step 1 specifically includes: Step 1-1: Read the ELF file of the target binary program, identify the code segments and related information, including but not limited to relocation information, initialization arrays, termination arrays and exception unrolling information; Step 1-2: Based on the code segment, perform a full-coverage disassembly of the code segment by enabling the disassembler's skipdata skip data mode; Steps 1-3: During the disassembly process, when an undecodeable instruction word is encountered, it is marked as a data item and skipped according to the width alignment of the AArch64 instruction; Steps 1-4: Based on the instruction stream obtained from disassembly and the data items marked in Steps 1-3, establish a full-coverage byte mapping relationship for the code segment, thereby obtaining the instruction stream and data region partitioning results.

3. The method according to claim 1, characterized in that, The source of the function entry set described in step 2 includes at least one of the following: Function symbols in a symbol table or dynamic symbol table; The initial address corresponding to the frame description item in the exception expansion information; The addresses of functions in the initialization and terminating arrays; Program entry point; Candidate entry points extracted from address constants in the code segment.

4. The method according to claim 1, characterized in that, Step 3 specifically includes: Step 3-1: Using the destination register of the ADRP instruction as the initial trace register, record its page base address value, and use this instruction address as the starting point for tracing, propagate the data flow state backward along the control flow graph; the data flow state includes the set of registers being traced, the mapping from registers to page base address values, and the mapping from stack slots to page base address values; Step 3-2: During the propagation process, perform a status update based on the current instruction type: When a register copy instruction is detected and its source register is in the currently tracked register set, the page base address value is synchronously propagated to the target register; When a stack store instruction is detected and the register being written to is in the currently tracked register set, the page base address value is associated with the corresponding stack slot key; When a stack load instruction is detected and the load source corresponds to a stack slot with a recorded page base address value, the page base address value recorded in that stack slot is restored to the load destination register. When a function call instruction is detected, only the register and stack slot states that can continue to propagate reliably across the call are preserved, according to the AAPCS64 calling convention. When a conditional jump instruction is detected, the data stream tracking state is simultaneously propagated along the branch target and sequential successor. Step 3-3: During the above propagation process, when an instruction that uses the traced page base address value to construct the target address is identified, a corresponding pointer construction record is generated as the pointer construction record to be repaired.

5. The method according to claim 1, characterized in that, Step 4 specifically includes: Step 4-1: Starting with the indirect jump instruction as the target, slice forward from its target register to determine the PC relative base address register and the table entry offset register; Step 4-2: Position the table entry loading instruction forward, and determine the table entry width of the jump table according to the table entry loading instruction; Step 4-3: On the control flow preceding path of the table entry loading instruction, search for candidate instruction pairs used to define the jump table base address; Step 4-4: For each candidate instruction pair, read a preset number of entries based on its defined candidate base address, and verify whether the target address corresponding to the entry falls into the legal code region; Steps 4-5: When there are multiple candidate base addresses, the candidate base address that has passed the verification is selected first; if no candidate table base address has passed the verification completely, the candidate table base address with the most valid targets is selected. Steps 4-6: Based on the verified candidate table base addresses and their corresponding entry widths and number of entries, determine the jump table base address, entry width, and target address set; establish a shadow jump table in the newly added data segment, uniformly expand the original compressed entries to an entry format that adapts to the rewritten address range, and establish a mapping relationship between the original jump table address and the shadow jump table.

6. The method according to claim 1, characterized in that, Step 6 specifically includes: Step 6-1: Update the address mapping relationship based on the number of new instructions added after inserting the target instrumentation logic and the inter-section offset between the original code segment and the new executable segment; Step 6-2: Based on the updated address mapping relationship, recalculate the relative offsets for direct jump, call, and PC relative literal load instructions; Step 6-3: Before address patching, identify restricted instructions that may cause the patching target to exceed its encoding range due to address changes, and reserve subsequent empty slots for the restricted instructions; Step 6-4: Based on the updated address mapping relationship and the pointer construction record, re-encode the ADRP instruction, ADR instruction and their subsequent address construction instructions, and repair multiple address construction instructions derived from the same ADRP instruction in a group manner; Step 6-5: Based on the mapping relationship between the shadow jump table and the original jump table, modify the instructions in the instruction sequence that reference the base address and entry of the original jump table to reference the shadow jump table; Step 6-6: When the target to be repaired exceeds the instruction encoding range, the reserved successor slot is used to extend it into a longer instruction sequence.

7. The method according to claim 1, characterized in that, Step 7 specifically includes: Step 7-1: Retain at least a portion of the original entry addresses unchanged in the original code segment; Step 7-2: Insert a micro-jump instruction at the original entry address to forward the control flow to the corresponding new entry point in the cloned code; Step 7-3: For addresses that are not accurately identified statically but may serve as indirect control flow targets at runtime, the control flow is redirected to the corresponding new code region using the micro-jump instruction; Step 7-4: For absolute or relative relocation entries that point to the function entry point of the original code segment, update them synchronously to point to the corresponding entry point in the new code segment, thus reducing the worst-case scenario of unrecognized hidden pointers to controllable forwarding.

8. A static rewriting system for AArch64 desymbolized binary programs, characterized in that, include: The disassembler and metadata extraction module is used to identify the code segments, function entry points, data regions, and relocation-related information of the target binary program, and to generate an ADRP tracing result set and a jump table object set. The address dependency tracing module is used to perform cross-block and cross-function data flow tracing of ADRP instructions and generate pointer construction records and pointer patch description objects; The jump table recovery module is used to perform reverse slicing, candidate base address verification, shadow jump table reconstruction, and jump table reference update for indirect jumps; The code cloning and patching module is used to clone the original code segment to a new executable segment, establish a mapping from the address of the original code segment to the address of the new executable segment, and patch PC relative addressing, direct branching, literal access, relocation and jump table references. The indirect control flow reconstruction module is used to redirect indirect control flows that cannot be statically determined completely through the stationary trampoline safety net. The output module is used to generate the rewritten AArch64 binary program.

9. An electronic device, characterized in that, The device includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, causes the electronic device to perform the method according to any one of claims 1-8.

10. A readable storage medium, characterized in that, The readable storage medium stores instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-8.

Images