A method of randomizing a structure layout at load time

Abstract

This invention proposes a method for randomizing structure layout during loading. The method first identifies the randomizable boundaries of structure types in the target program. Combining structure layout information from the abstract syntax tree with type conversion relationships and fixed offset access relationships in the LLVM intermediate representation and sparse value flow graph, a set of non-randomizable structure types is constructed. Subsequently, structure information is collected and transmitted for the remaining randomizable structures. Structure type information, field access information, access instruction locations, and the location information of static structure objects in the data segment are embedded into a dedicated section of the final binary file. During program loading, a customized loader parses the dedicated section, restores the original structure layout, generates a new randomized layout, and performs consistency correction on access instructions in the code segment that depend on the old field offsets and statically initialized structure objects in the data segment before starting the program.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method for randomizing the layout of structures during loading. Background Technology

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

[0003] In C programs, structures are the core mechanism for organizing complex data objects. Key data such as length fields, status flags, permission bits, object references, and function pointers are typically stored within structures. If these critical fields are tampered with by attackers using memory corruption vulnerabilities such as buffer overflows, use-after-free, type obfuscation, out-of-bounds writes, or object forgery, it can lead to anything from minor deviations from program semantics to serious issues like control flow hijacking, privilege escalation, sensitive information leakage, or data-driven attacks.

[0004] A crucial prerequisite for such attacks is that structure fields typically have fixed and predictable relative offsets after compilation. Even if attackers cannot directly control the overall address space of the program, they can still restore the field layout within the target structure through source code analysis, debugging information, binary reverse engineering, information leakage, or repeated probing, thereby achieving precise reading and writing of critical fields. Traditional address space layout randomization primarily alters the absolute position of an object in the virtual address space, without changing the relative offsets between fields within the structure. While mechanisms such as control flow integrity help compress the control flow attack surface, they cannot directly eliminate the exploitation conditions for attacks that only tamper with non-control data fields such as length, status, and permissions.

[0005] Therefore, structure layout randomization is considered an effective defense technique that can weaken attacks based on fixed offsets. The basic idea is to shuffle the order of structure fields during compile time, load time, or runtime, preventing attackers from relying on existing offset information to locate critical members. This increases the difficulty of implementing structure-driven attacks, data-driven attacks, UAF (Use-Based Offset) exploits, and overflow-based critical field overwriting attacks.

[0006] Compile-time randomization determines the field layout before the executable file is generated, making it relatively simple to implement and with minimal overhead. However, its randomization results are statically fixed in the target file, allowing attackers to recover the actual field offsets offline. Therefore, its protection strength is limited against attackers with publicly available binaries or reverse engineering capabilities. Runtime dynamic randomization, while capable of changing the layout multiple times during object creation or the object's lifecycle, requires continuously introducing runtime auxiliary logic, offset lookups, object copying, or metadata maintenance along the field access path, typically resulting in higher execution overhead.

[0007] Load-time randomization, situated between program generation and execution, theoretically offers both good protection and low runtime overhead. However, existing load-time or dynamic structure randomization schemes still face two key challenges that have not been effectively resolved.

[0008] First, how can we accurately identify which structure types can be randomized without compromising program semantics? Not all structures are suitable for reordering. When a program involves cross-type access, explicit or implicit type conversions, converting a structure pointer to char* or void* and then accessing fields with a fixed offset, or using undefined behavior access methods that depend on the original layout, performing field reordering on the relevant structures is highly likely to lead to semantic errors in the program. Existing methods often rely on front-end syntax information or conservative rules to identify such situations, which easily leads to a large number of false positives, excluding structures that could be safely randomized, significantly narrowing the scope of protection. On the other hand, if the identification is inaccurate, it may incorrectly randomize structures that actually depend on the original layout, thereby compromising program correctness.

[0009] Second, how can sufficient structure layout information be retained during the loading stage to truly implement layout reordering and access correction? Once a program has undergone front-end compilation, optimization, code generation, and linking, much high-level type information will be gradually lost or rewritten. Especially in the LLVM compilation chain, structure field access may successively undergo optimization processes such as getelementptr address calculation, load / store memory access, common subexpression elimination, instruction merging, constant folding, vectorization, and memory merging. Without a mechanism that can continuously pass and restore structure information across compilation, assembly, linking, and up to the loading stage, the loader will not be able to accurately know which field of which structure a certain memory access instruction originally accessed, nor will it be able to safely and synchronously modify statically initialized structure objects in the data segment.

[0010] Furthermore, structure layout randomization must adhere to underlying constraints such as field size, alignment, and bit field boundaries. Simply arbitrarily arranging fields can easily generate illegal layouts, leading to bit field overlap, misaligned access, or distortion of static object initialization. In engineering implementation, while backtracking search can theoretically yield a complete candidate set by enumerating all legal layouts, its time complexity is often insufficient to meet the efficiency requirements of the program loading phase.

[0011] Therefore, existing technologies still require a new structure layout randomization scheme that can accurately identify non-safely randomized structure types, clearly define randomization boundaries, retain and transmit structure-related information throughout the compilation, linking, and loading processes, and ultimately efficiently generate a legal new layout during loading. It can also uniformly correct layout dependencies in code segments and data segments, thereby improving protection capabilities while ensuring the semantic correctness of the program and minimizing runtime overhead. Summary of the Invention

[0012] Purpose of the invention: The technical problem to be solved by the present invention is to address the shortcomings of the existing technology in randomizing the structure layout, such as inaccurate identification of randomization boundaries and high dynamic randomization overhead, and to provide a method for randomizing the structure layout during loading.

[0013] In a first aspect, the present invention provides a method for randomizing the layout of a structure during loading, comprising the following steps:

[0014] Step 1: Compile and analyze the target program to be protected, and extract the structure layout information in the target program. The structure layout information includes structure type definition, field offset, field size, field access position, global static structure object position, and field access related instruction information.

[0015] Step 2: Based on the full program pointer analysis and the structure layout information extracted in Step 1, perform randomizable boundary identification on the target program, identify the non-randomizable structure types that will cause semantic errors in the program after randomization, and obtain the set of non-randomizable structure types and the set of randomizable structure types accordingly.

[0016] Step 3: Select the structure types that do not belong to the set of non-randomizable structure types as the set of structure types to be randomized, collect the structure information corresponding to each structure type to be randomized, and attach the structure access information related to the randomizable structure to the address calculation instructions and memory access instructions during the compilation, optimization, code generation and linking process, and write the information into the structure information section of the relocatable target file and the final executable file to maintain the transmissibility and recoverability of the structure information;

[0017] Step 4: Embed the processed structure information into a dedicated data section of the final generated binary file so that the loader can recover the original layout information of each structure type to be randomized and the location information of its associated code segment and data segment from it during the program loading stage;

[0018] Step 5: During the program loading phase, for each structure type to be randomized, a new structure field layout is generated based on its field boundaries, field size, and alignment constraints.

[0019] Step 6: Based on the new structure field layout, perform offset correction on memory access instructions in the code segment that depend on the original field offsets, and reorganize the statically initialized structure objects in the data segment so that the program retains its original semantics under the new structure layout.

[0020] In some embodiments, step 2 specifically includes the following steps:

[0021] Step 2-1: Construct a value flow graph based on the intermediate representation of the target program, and use the object versioning flow-sensitive pointer analysis algorithm to calculate the pointer set from the pointer to the abstract memory object in order to determine the alias relationship in the program;

[0022] Step 2-2: Extract the name information, field offset information, field type information and alignment constraints of the structure at the abstract syntax tree level, and construct the structure layout hash table accordingly;

[0023] Steps 2-3: In the LLVM intermediate representation and the value flow graph, identify and collect candidate nodes related to explicit type conversion, implicit type conversion, and fixed offset access, so as to construct the type conversion candidate set and the fixed offset access candidate set respectively;

[0024] Steps 2-4: Combining the alias relationship, structure layout hash table, construction type conversion candidate set, and fixed offset access candidate set, and according to the preset semantic violation judgment rules, the structure types that are determined to violate the original program semantics due to layout randomization are identified as the non-randomized structure types.

[0025] In some embodiments, the preset semantic violation determination rules in steps 2-4 specifically include:

[0026] Cross-type access judgment rule: When the analysis results show that two pointers belonging to different composite types may point to the same abstract memory object after type conversion, and the relationship between the two is not a pseudo-alias relationship caused by nested fields, the structure type involved is judged as a non-randomized structure type.

[0027] Fixed offset dependency determination rule: When the analysis results show that a base address pointer forms a memory access address with a constant offset and participates in memory access, and the actual access data type corresponding to the constant offset position is consistent with the original field type of the candidate structure at the offset, the candidate structure is determined to be a non-randomized structure type.

[0028] In some embodiments, the preset semantic violation determination rule in steps 2-4 further includes:

[0029] For fixed offset accesses in the candidate set whose actual access data type cannot be directly determined from the intermediate representation instruction, a breadth-first search is performed starting from the corresponding value flow graph node within a preset search depth to infer the actual access type; if the actual access type still cannot be determined after reaching the preset search depth, the relevant structure type is determined to be a non-randomized structure type.

[0030] In some embodiments, step 3 includes the following steps:

[0031] Step 3-1: Append the type information, field type information, and field offset information of the structure type to be randomized to the memory access instructions and address calculation instructions of the target program. Specifically, the appending involves associating the structure type, field type, and field offset with the memory access instructions and address calculation instructions as instruction-level metadata, and then transcribing them into a dedicated structure information record in the relocatable target file during the subsequent code generation stage. This ensures that the original structure field access semantics can still be tracked and recovered even when the field address calculation is separated from the final memory access operation.

[0032] Step 3-2: Write the collected structure access information into the structure information section of the relocatable target file, and form a structure information segment in the final binary file for the loader to read;

[0033] Step 3-3: During the linking phase, the dedicated structure information sections from multiple relocatable target files are merged, and the instruction positions and static object positions recorded in the structure access information are relocated and updated according to the final address offsets of the linked code segment and data segment.

[0034] Step 3-4: Write the updated structure access information from step 3-3 into a dedicated data section of the final generated binary executable file so that the loader can restore it during the program loading phase.

[0035] In some embodiments, step 3-1 further includes the following information collection and labeling rules:

[0036] For field access of a union type, set a union access flag to add it to a non-randomized set;

[0037] For accessing array-type fields, record the type information of the innermost element;

[0038] For bit fields, since the underlying metadata system has difficulty fully characterizing their access semantics, they are marked as non-randomized fields so that they can be treated as fixed boundaries in the subsequent layout generation stage.

[0039] In some embodiments, a structure information merging step in the linking phase is also included between steps 3 and 4, specifically:

[0040] Step S1: During the linking process, the structure access information from multiple relocatable target files is organized and merged according to the structure name. Specifically, the structure information records in each input target file are parsed, the names are normalized, grouped by structure name, field records are aligned, the relative offset within the target file is converted to the final link offset, and the static object offset list and code patch point list are reorganized.

[0041] Step S2: Obtain the final code segment offset, read-only data segment offset, data segment offset, and relocation read-only data segment offset calculated by the linker script or linker.

[0042] Step S3: Based on the final segment offset obtained in step S2, traverse and update the code position offset value of each memory access instruction recorded in the structure access information, as well as the storage position offset value of each static structure object in the corresponding data segment.

[0043] Step S4: Organize the structure information after relocation and update into the final binary format. The structure information includes at least: the number of fields of the structure type to be randomized, the field size, the original field offset, the number of related instructions to be corrected, the code position of each related instruction and the width of the immediate numeric segment to be corrected, and the offset information of the static structure object in the read-only data segment, the data segment and the relocation read-only data segment.

[0044] In some embodiments, the final binary preferably includes at least two structure information sections, wherein the first section is used to record the structure field layout, field association instructions and static object offsets, and the second section is used to record the entry position or index information of each structure information record in the structure information section; preferably, it can be implemented as the .tbaa section and .tbaa_header section in the ELF file.

[0045] In some embodiments, step 5 specifically includes the following steps:

[0046] To enhance the diversity of field layout candidates, additional padding units can be introduced into the structure header as one of the layout units participating in the arrangement.

[0047] Step 5-1: Using the bit field in the structure as a fixed dividing point, divide the original field sequence into several field groups, and perform the first random arrangement of non-bit field fields within each field group to obtain an initial legal random layout that meets the bit field boundary constraints, ensuring that it does not cross the bit field area and does not cause fields to overlap with bit fields.

[0048] Step 5-2: After the first random arrangement, the fields are re-divided into several equivalent groups according to the field size and alignment constraints, and the fields are randomly arranged a second time within the same equivalent group to increase the number of layouts that can be generated without compromising the legality of the layout.

[0049] The loader obtains random values ​​from a random source to generate a specific arrangement order, preferably / dev / urandom.

[0050] In some embodiments, step 6 specifically includes the following steps:

[0051] Step 6-1: The loader traverses the code locations of the instructions that need to be corrected recorded in the dedicated data section, and rewrites the memory access instructions that use the old field offset immediate value in the code segment in place according to the difference between the old and new offsets, so that they point to the new field offset corresponding to the new structure field layout.

[0052] Step 6-2: The loader rearranges the internal field contents of the statically initialized structure objects related to the structure type to be randomized in the read-only data segment, data segment, and relocated read-only data segment according to the new structure field layout.

[0053] Step 6-3: For structure types that are not included in the set of randomizable structure types, keep their original memory layout unchanged and do not perform any offset correction operations to ensure the semantic correctness of the program.

[0054] Compared with the prior art, the present invention has the following beneficial effects:

[0055] This invention employs a non-randomizable structure identification method based on full-program pointer analysis and value flow analysis. This method can more accurately distinguish between structure types that truly depend on the original layout and those that can be safely randomized than methods that rely solely on front-end syntax checking or conservative rules. This significantly reduces the false alarm rate and preserves more protectable structures.

[0056] This invention proposes a mechanism for the continuous transfer of structure information across the compilation chain by extending the collection, attachment, and cross-stage transfer mechanism of structure information. This mechanism extends structure semantics from the front end to IR, code generation, object files, linking results, and finally to the ELF. It also extends the scope of structure information attachment to address calculation instructions, so that the semantics of structure fields can still be recovered even when field address calculation is separated from the final memory access. Furthermore, it enables unified correction of code segment offsets and static data segment objects during the loading stage, making structure randomization during loading a complete closed loop that can be implemented in engineering. This preserves the structure semantics that would otherwise be gradually lost during the front end, optimization, code generation, and linking processes in the final binary file, giving the loader the necessary conditions to perform real layout rearrangement and offset correction.

[0057] This invention postpones the randomization timing to the program loading stage, achieving a balance between protection strength and runtime overhead. By delaying the randomization timing to the loading stage, it avoids the problem of compile-time fixed layouts being easily bypassed, while reducing the high overhead of continuously maintaining layout mappings at runtime. This allows the same program to obtain different structure layouts in different running instances, significantly increasing the difficulty for attackers to recover fixed offsets through static analysis, offline reverse engineering, and compile-time recovery. Compared to pure compile-time randomization, it has higher dynamism.

[0058] This invention employs a two-round layout generation mechanism to generate a valid layout while satisfying bit field boundaries and alignment constraints. Compared with backtracking search-based schemes, it has lower loading complexity and is more suitable for engineering deployment. Attached Figure Description

[0059] 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.

[0060] Figure 1 This is an overall workflow diagram of the present invention;

[0061] Figure 2 This is a flowchart for identifying non-randomized structures;

[0062] Figure 3 This is a schematic diagram of the information transmission mechanism of a structure. Detailed Implementation

[0063] The core idea of ​​this invention is to generate a new field layout for each type of structure that can be safely randomized in the final stage before program loading, and to simultaneously correct the code and static objects that depend on the original offset, thereby breaking the attacker's stable expectation of fixed field offsets.

[0064] like Figure 1-3 As shown, a method for randomizing the structure layout during loading includes the following steps:

[0065] Step 1: Compile and analyze the target program to be protected to extract the structure layout information in the target program;

[0066] Step 2: Based on the full program pointer analysis and the structure layout information extracted in Step 1, the target program is randomized boundary identified, and the non-randomized structure types that would cause semantic errors in the program after randomization are identified, and the set of non-randomized structure types is obtained accordingly.

[0067] Step 3: Select structure types that do not belong to the set of non-randomized structure types as the set of structure types to be randomized, collect the structure information corresponding to each structure type to be randomized, and maintain the transitivity and recoverability of structure information during compilation, optimization, code generation and linking; in the linking stage, use the modified GNUGold linker to enable it to read the .tbaa and .tbaa_header sections from the input object file, and merge and inject the new structure information sections into the final ELF.

[0068] Step 4: Embed the processed structure information into a dedicated data section of the final generated binary file so that the loader can recover the original layout information of each structure type to be randomized and the location information of its related code segment and data segment during the program loading stage; after linking, the target program will contain two structure information sections: .tbaa and .tbaa_header.

[0069] Step 5: During the program loading phase, for each structure type to be randomized, a new structure field layout is generated based on its field boundaries, field sizes, and alignment constraints. The loader is preferably a modified glibc dynamic loader, which supports parsing the .tbaa and .tbaa_header sections during loading and performing structure layout rearrangement and offset correction. The loader reads the structure information section, generates a new layout, and completes unified patching before the program entry point is executed.

[0070] Step 6: Based on the new structure field layout, correct the offsets of memory access instructions in the code segment that depend on the original field offsets, and reorganize the statically initialized structure objects in the data segment.

[0071] The engineering implementation of the method includes the following components: a modified clang frontend and LLVM backend for collecting and transmitting structure information; a modified GNU Gold linker for integrating structure information across object files and injecting structure information sections into the final ELF; a modified glibc dynamic loader rtld.c for reading structure information sections, generating new layouts, and performing patching during the loading phase; and a structure list file for randomized structure whitelist and blacklist control.

[0072] The compiler driver layer adds the following compilation options: the first option (e.g., -frandomize-struct-list-file=) <file>), used to specify the list file of structure types that can be randomized; the second option (e.g., -fno-randomize-struct-list-file= <file>The first option specifies a list of struct types for which randomization should be disabled; the second option (e.g., `-frandomize-struct-all`) attempts to enable randomization for all C language struct types that meet the criteria. These options can be directly passed through to subsequent compilation processes by the modified Clang Driver and are linked to struct information collection, layout filtering, and code generation logic. Preferably, the struct list file is saved in text or JSON format.

[0073] Step 2 specifically includes the following steps:

[0074] Step 2-1: Construct a value flow graph based on the intermediate representation of the target program. The intermediate representation is preferably LLVMIR, and the value flow graph is preferably SVFG. Use the object versioned flow-sensitive pointer analysis algorithm to calculate the pointer set to abstract memory objects in order to determine the alias relationship in the program.

[0075] Step 2-2: Extract the name information, field offset information, field type information and alignment constraints of the structure at the abstract syntax tree level, and build a structure layout hash table based on this information; the hash table uses the structure type name as the key and the field offset and field type as the value, which can not only support quick query of the corresponding field type by "structure type + offset", but also support the identification of whether a certain structure appears as a field type of another structure.

[0076] Steps 2-3: In the LLVM intermediate representation and the value flow graph, identify and collect candidate nodes related to explicit type conversion, implicit type conversion, and fixed offset access to construct a type conversion candidate set and a fixed offset access candidate set, respectively. The first type is cross-type access introduced by explicit or implicit type conversion. Specifically, identify type conversion instructions such as bitcast in LLVM IR and collect structure pointer nodes related to the conversion edge in SVFG. The second type is fixed offset access, specifically identifying statements that form an address by adding a constant offset to a base address pointer and ultimately participate in memory read and write operations.

[0077] Steps 2-4: Combining the alias relationships, structure layout hash table, construction type conversion candidate set, and fixed offset access candidate set, and based on the preset semantic violation judgment rules, the structure types that are determined to violate the original program semantics due to layout randomization are identified as the non-randomized structure types; wherein, in the cross-type access judgment, pseudo-aliases naturally generated by nested fields need to be further excluded, such as natural aliases between the outer structure and the structure embedded in its first field, otherwise the judgment will be overly conservative.

[0078] The preset semantic violation determination rules in steps 2-4 specifically include:

[0079] Cross-type access judgment rule: When the analysis results show that two pointers belonging to different composite types may point to the same abstract memory object after type conversion, and the relationship between the two is not a pseudo-alias relationship caused by nested fields, the structure type involved is judged as a non-randomized structure type.

[0080] Fixed offset dependency determination rule: When the analysis results show that a base address pointer forms a memory access address with a constant offset and participates in memory access, and the actual access data type corresponding to the constant offset position is consistent with the original field type of the candidate structure at the offset, the candidate structure is determined to be a non-randomized structure type.

[0081] The preset semantic violation determination rules in steps 2-4 also include:

[0082] For fixed offset accesses in the candidate set whose actual data type cannot be directly determined from the intermediate representation instruction, a breadth-first search is performed starting from the corresponding value flow graph node within a preset search depth to infer the actual access type. If the actual access type still cannot be determined after reaching the preset search depth, the relevant structure type is determined to be a non-randomized structure type. This method is applicable to accesses derived from void, i8, or generic untyped pointers.

[0083] Step 3 includes the following steps:

[0084] Step 3-1: The type information, field type information, and field offset information of the structure type to be randomized are attached to the memory access instructions and address calculation instructions of the target program. The modified compiler no longer only records the structure field metadata for load / store, but also records the structure type information, field offset information, field type information, and field size information for the getelementptr instruction. This allows the original structure field access semantics to be traced and restored even when the field address calculation is separated from the final memory access operation.

[0085] Step 3-2: Write the collected structure access information into the structure information section of the relocatable target file, and form a structure information segment for the loader to read in the final binary file; During the assembly / object file generation stage, two ELF sections are explicitly created, preferably .tbaa and .tbaa_header, where the .tbaa section is used to store the main information oriented towards the structure type, and the .tbaa_header section is used to record the entry position or index information of each structure information record in .tbaa; Each structure record in .tbaa may include: structure name, number of fields, offset list of static objects related to the structure type in .rodata, .data, .data.rel.ro, and description of each field; Each field description further includes the original field offset, the number of related instructions to be corrected, the field size, and several <instruction offset, immediate numeric field width> tuples;

[0086] Step 3-3: During the linking phase, the dedicated structure information sections from multiple relocatable target files are merged, and the instruction positions and static object positions recorded in the structure access information are relocated and updated according to the final address offsets of the linked code segment and data segment.

[0087] Step 3-4: Write the updated structure access information from step 3-3 into a dedicated data section of the final generated binary executable file so that the loader can restore it during the program loading phase.

[0088] To ensure that the layout rearrangement does not violate machine alignment requirements, the fields are organized according to the alignment constraints of the structure itself before writing the structure information. If a field, when used alone as a randomization unit, would violate the alignment requirements in some arrangements, it is merged with the previous field into a new randomization unit; for the last field, its tail size is adjusted according to the overall alignment requirements to ensure that the rearranged structure as a whole still meets the legal alignment.

[0089] During the compilation phase, the positions of static structure objects in different segments are also collected. Specifically, global variables can be categorized into .rodata, .data, and .data.rel.ro, and a mapping from structure names to offset lists within each segment can be established.

[0090] Since compiler optimizations may rewrite or eliminate critical instructions carrying structure information, the method performs customized adaptation processing for multiple optimization components. Through this method, structure semantics can be preserved in an engineering-implementable manner throughout the compilation chain, without relying on the continuous presence of high-level information from the compilation front end.

[0091] Step 3-1 further includes the following information collection and labeling rules:

[0092] For field access of a union type, set a union access flag to add it to a non-randomized set;

[0093] For accessing array-type fields, record the type information of the innermost element;

[0094] For bit fields, mark them as non-randomizable fields so that they can be treated as fixed boundaries in the subsequent layout generation stage.

[0095] Between steps 3 and 4, there is also a step of merging structure information during the linking phase, specifically:

[0096] Step S1: During the linking process, the linker first identifies the .tbaa and .tbaa_header sections in each input object file, and organizes and merges the structure access information from multiple relocatable object files according to the structure name; the linker can first parse the structure information in each input object into internal intermediate structures, and then merge them according to the structure name to generate new global .tbaa data and corresponding .tbaa_header data;

[0097] Step S2: Obtain the final code segment offset, read-only data segment offset, data segment offset, and relocation read-only data segment offset calculated by the linker script or linker.

[0098] Step S3: Based on the final segment offset obtained in step S2, traverse and update the code position offset value of each memory access instruction recorded in the structure access information, as well as the storage position offset value of each static structure object in the corresponding data segment.

[0099] Step S4: Organize the relocation and updated structure information into the final binary format. Finally, a temporary file can be output at the end of the linking process, and then the temporary file can be injected into the final ELF file as .tbaa and .tbaa_header sections using objcopy --add-section. The structure information includes at least: the number of fields, field size, original field offset, number of related instructions to be corrected, code position of each related instruction and width of the immediate numeric segment to be corrected, and offset information of the static structure object in the read-only data segment, data segment and relocation read-only data segment.

[0100] To support the collaborative randomization of structures with the same name between the main program and shared libraries, the linker retains the structure name when it detects a specific control mode and organizes the structure records by name during merging, so that the loader can reuse the same arrangement result according to the structure name later.

[0101] The core of the method's execution occurs during program loading. The glibc dynamic loader rtld.c is modified to parse .tbaa and .tbaa_header, generate a new structure layout, and perform unified patching before the ELF file mapping is complete but the program has actually started executing.

[0102] The loader first reads the control file (e.g., / tmp / random.log): if the file does not exist or its content is a preset first identifier (e.g., "-"), then a normal true random mode is used; if the content is a preset second identifier (e.g., "T"), then a non-randomized mode is used for testing; if the content is a preset third identifier (e.g., "-2"), then a deterministic field reversal mode is used; if the content is a preset fourth identifier (e.g., "-b"), then a name-based collaborative randomization mode is entered, ensuring that structures with the same name in different binary representations have the same arrangement. Preferably, the random numbers required for true randomness are obtained by reading / dev / urandom.

[0103] The loader traverses the current ELF file's section table, locating the positions and sizes of sections such as .text, .rodata, .data, .data.rel.ro, .tbaa, and .tbaa_header. If the target file lacks a structure information section, it indicates that the file has not enabled the compilation and linking process of this invention, and the loader can directly skip randomization processing. The loader first parses the record entries in .tbaa_header, and then reads the structure records one by one in .tbaa accordingly, restoring the number of fields, original field offsets, field sizes, the code positions associated with each field, the width of the immediate numeric field to be modified, and the offset list of static objects in different data segments.

[0104] Step 5 specifically includes the following steps:

[0105] Step 5-1: Using the bit-fields in the structure as fixed boundaries, scan the structure fields in the original field order. When a bit-field or immovable field is encountered, it is treated as a fixed boundary. Adjacent ordinary fields are grouped into a local field group, and within each field group, the non-bit-field fields are randomly arranged for the first time to obtain an initial legal random layout that meets the bit-field boundary constraints. Ensure that the groups maintain the relative order defined by the fixed boundaries, do not cross bit-field regions, and do not cause fields to overlap with bit-fields.

[0106] Step 5-2: After the first random arrangement, the fields are re-divided into several equivalent groups based on field size and alignment constraints. Within each equivalent group, a second random arrangement is performed on the fields to increase the number of generate layouts without compromising layout validity. The loader internally maintains arrays of field access visibility, field rearrangement mappings, field sizes, bit field markers, and rearrangement indices to support this process.

[0107] Step 6 specifically includes the following steps:

[0108] Step 6-1: The loader traverses the code locations of the instructions to be corrected recorded in the dedicated data section. For each <instruction offset, immediate field width> tuple recorded in the structure information, it locates the corresponding instruction byte in .text, reads the original immediate value, calculates the updated immediate value based on the difference between the new field offset and the original field offset, and rewrites the memory access instructions that use the old field offset immediate value in the code segment in-place, so that they point to the new field offset corresponding to the new structure field layout.

[0109] Step 6-2: The loader, based on the new structure field layout, reorganizes the object memory by field in the read-only data segment, data segment, and statically initialized structure objects related to the structure type to be randomized in the relocated read-only data segment, and rearranges their internal field contents according to the new field order.

[0110] Step 6-3: For structure types that are not included in the set of randomizable structure types, keep their original memory layout unchanged and do not perform any offset correction operations to ensure the semantic correctness of the program.

[0111] This invention provides a method and approach for randomizing the layout of structures during loading. 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.< / file> < / file>

Claims

1. A method for randomizing the layout of a structure during loading, characterized in that, Includes the following steps: Step 1: Compile and analyze the target program to be protected to extract the structure layout information in the target program; Step 2: Based on the full program pointer analysis and the structure layout information extracted in Step 1, the target program is randomized boundary identified, and the non-randomized structure types that would cause semantic errors in the program after randomization are identified, and the set of non-randomized structure types is obtained accordingly. Step 3: Select the structure types that do not belong to the set of non-randomized structure types as the set of structure types to be randomized, collect the structure information corresponding to each structure type to be randomized, and maintain the transitivity and recoverability of the structure information during compilation, optimization, code generation and linking. Step 4: Embed the processed structure information into a dedicated data section of the final generated binary file so that the loader can recover the original layout information of each structure type to be randomized and the location information of its associated code segment and data segment from it during the program loading stage; Step 5: During the program loading phase, for each structure type to be randomized, a new structure field layout is generated based on its field boundaries, field size, and alignment constraints. Step 6: Based on the new structure field layout, correct the offsets of memory access instructions in the code segment that depend on the original field offsets, and reorganize the statically initialized structure objects in the data segment.

2. The method according to claim 1, characterized in that, Step 2 specifically includes the following steps: Step 2-1: Construct a value flow graph based on the intermediate representation of the target program, and use the object versioning flow-sensitive pointer analysis algorithm to calculate the pointer set from the pointer to the abstract memory object in order to determine the alias relationship in the program; Step 2-2: Extract the name information, field offset information, field type information and alignment constraints of the structure at the abstract syntax tree level, and construct the structure layout hash table accordingly; Steps 2-3: In the LLVM intermediate representation and the value flow graph, identify and collect candidate nodes related to explicit type conversion, implicit type conversion, and fixed offset access, so as to construct the type conversion candidate set and the fixed offset access candidate set respectively; Steps 2-4: Combining the alias relationship, structure layout hash table, construction type conversion candidate set, and fixed offset access candidate set, and according to the preset semantic violation judgment rules, the structure types that are determined to violate the original program semantics due to layout randomization are identified as the non-randomized structure types.

3. The method according to claim 2, characterized in that, The preset semantic violation determination rules in steps 2-4 specifically include: Cross-type access judgment rule: When the analysis results show that two pointers belonging to different composite types may point to the same abstract memory object after type conversion, and the relationship between the two is not a pseudo-alias relationship caused by nested fields, the structure type involved is judged as a non-randomized structure type. Fixed offset dependency determination rule: When the analysis results show that a base address pointer forms a memory access address with a constant offset and participates in memory access, and the actual access data type corresponding to the constant offset position is consistent with the original field type of the candidate structure at the offset, the candidate structure is determined to be a non-randomized structure type.

4. The method according to claim 3, characterized in that, The preset semantic violation determination rules in steps 2-4 also include: For fixed offset accesses in the candidate set whose actual access data type cannot be directly determined from the intermediate representation instruction, a breadth-first search is performed starting from the corresponding value flow graph node within a preset search depth to infer the actual access type; if the actual access type still cannot be determined after reaching the preset search depth, the relevant structure type is determined to be a non-randomized structure type.

5. The method according to claim 1, characterized in that, Step 3 includes the following steps: Step 3-1: Append the type information, field type information, and field offset information of the structure type to be randomized to the memory access instructions and address calculation instructions of the target program, so that the original structure field access semantics can still be traced and recovered even when the field address calculation is separated from the final memory access operation. Step 3-2: Write the collected structure access information into the structure information section of the relocatable target file, and form a structure information segment in the final binary file for the loader to read; Step 3-3: During the linking phase, the dedicated structure information sections from multiple relocatable target files are merged, and the instruction positions and static object positions recorded in the structure access information are relocated and updated according to the final address offsets of the linked code segment and data segment. Step 3-4: Write the updated structure access information from step 3-3 into a dedicated data section of the final generated binary executable file so that the loader can restore it during the program loading phase.

6. The method according to claim 5, characterized in that, Step 3-1 further includes the following information collection and labeling rules: For field access of a union type, set a union access flag to add it to a non-randomized set; For accessing array-type fields, record the type information of the innermost element; For bit fields, mark them as non-randomizable fields so that they can be treated as fixed boundaries in the subsequent layout generation stage.

7. The method according to claim 1, characterized in that, Between steps 3 and 4, there is also a step of merging structure information during the linking phase, specifically: Step S1: During the linking process, organize and merge the structure access information from multiple relocatable target files according to the structure name; Step S2: Obtain the final code segment offset, read-only data segment offset, data segment offset, and relocation read-only data segment offset calculated by the linker script or linker. Step S3: Based on the final segment offset obtained in step S2, traverse and update the code position offset value of each memory access instruction recorded in the structure access information, as well as the storage position offset value of each static structure object in the corresponding data segment. Step S4: Organize the structure information after relocation and update into the final binary format. The structure information includes at least: the number of fields of the structure type to be randomized, the field size, the original field offset, the number of related instructions to be corrected, the code position of each related instruction and the width of the immediate numeric segment to be corrected, and the offset information of the static structure object in the read-only data segment, the data segment and the relocation read-only data segment.

8. The method according to claim 1, characterized in that, Step 5 specifically includes the following steps: Step 5-1: Using the bit field in the structure as a fixed dividing point, divide the original field sequence into several field groups, and perform the first random permutation of the non-bit field within each field group to obtain an initial legal random layout that meets the bit field boundary constraints. Step 5-2: After the first random arrangement, the fields are re-divided into several equivalent groups according to the field size and alignment constraints, and the fields are randomly arranged a second time within the same equivalent group to increase the number of layouts that can be generated without compromising the legality of the layout.

9. The method according to claim 1, characterized in that, Step 6 specifically includes the following steps: Step 6-1: The loader traverses the code locations of the instructions that need to be corrected recorded in the dedicated data section, and performs in-place byte rewriting on the memory access instructions that use the old field offset immediate value in the code segment, so that they point to the new field offset corresponding to the new structure field layout. Step 6-2: The loader rearranges the internal field contents of the statically initialized structure objects related to the structure type to be randomized in the read-only data segment, data segment, and relocated read-only data segment according to the new structure field layout. Step 6-3: For structure types that are not included in the set of randomizable structure types, keep their original memory layout unchanged and do not perform any offset correction operations to ensure the semantic correctness of the program.

10. A device, characterized in that, It includes at least one processor coupled to at least one memory, the at least one processor being configured to read a program stored in the at least one memory to execute the method as described in any one of claims 1-9.

Images