Executable binary file segmentation method based on mamba

Abstract

The application relates to a Mamba-based executable binary file segmentation method. The method comprises the following steps: reading the original byte sequence of a binary file to be segmented and converting the original byte sequence into a byte token sequence; adopting an overlapping sliding window block and generating an effective position mask; inputting the input block into a bidirectional Mamba model to obtain the prediction probability of each byte as the starting point of the source file; obtaining a final probability sequence through overlapping area probability fusion; performing threshold screening and boundary deduplication to obtain a source file starting boundary sequence; and finally segmenting and outputting an offset range. The method can improve the consistency of the segmentation boundary and the real source file boundary, reduce the engineering complexity and error accumulation, is suitable for real analysis scenes such as stripped binary files, and provides a structured fragment grouping for downstream binary code analysis.

Description

Technical Field

[0001] This application relates to the field of static analysis technology for binary software, and in particular to a method for splitting executable binary files based on Mamba. Background Technology

[0002] With the increasing prevalence of closed-source software and the continuous expansion of software scale, executable binary files, including Windows PE and Linux ELF formats, have become the main form of software distribution, and their source code is often inaccessible. In scenarios such as software security, reverse engineering, and code auditing, analysts need to perform static analysis directly on binary files to understand program structure, discover vulnerabilities, or detect code reuse. Because executable files contain multiple levels of information, including file headers, sections, code, and data, and because compilation optimization and symbol stripping further weaken semantic clues, dividing large binary files into manageable program segments / chunks is a common method to improve the efficiency of subsequent modeling and analysis.

[0003] Based on existing research and industrial practice, binary file segmentation methods can be categorized as follows: The first type is fixed-length segmentation. This method does not rely on the format information, symbol information, or disassembly results of the binary file. Instead, it treats the entire binary file as a continuous sequence of bytes and segments it into equal lengths according to a preset length. The basic process is as follows: first, read the original byte stream of the binary file; then, set a fixed window size and step size; finally, sequentially extract segments starting from the beginning of the file until the end. This method is simple to implement and fast, suitable for batch preprocessing of a large number of binary samples. However, the segmentation boundary is determined by a manually set length parameter, which cannot align with the actual source file boundaries. Code compiled from the same source file may be segmented into multiple segments, and code generated from different source files may be mixed in the same segment.

[0004] The second type is section-aware hierarchical segmentation. This method utilizes existing structured metadata in the executable file format for segmentation. Typical binary formats such as PE, ELF, and Mach-O usually contain section or segment information, carrying code, read-only data, writable data, resources, etc. This type of method typically first parses the binary file header information, reads the section table or program header table, and obtains the file offset, virtual address, size, and access permissions for each section or loaded segment. Then, based on this structural information, the file is divided into different parts such as code regions, data regions, and resource regions. However, this method is too coarse-grained. A .text section usually contains a large number of functions and code snippets compiled from the source files, and the section boundaries are not equivalent to the source file boundaries, making it impossible to directly obtain source file-level segmentation results.

[0005] The third type is control flow-aware code region segmentation. This method is based on disassembly results and divides the code according to the control transfer relationships during program execution. Typically, the binary code is first disassembled into an instruction sequence, then jumps, conditional branches, calls, returns, and other control transfer instructions are identified. These instructions are used to determine basic block boundaries, and a control flow graph (CFG) is further constructed. This type of method is closer to the actual execution structure of the program, but it is highly dependent on the quality of the disassembly. In the presence of indirect jumps, skip lists, exception handling, compiler optimizations, obfuscation, or disassembly techniques, control flow recovery may fail. Furthermore, its segmentation target is usually the execution path or code block, rather than the starting position of the source file.

[0006] The fourth type is function-level segmentation. This method uses the start and end addresses of functions as boundaries to divide code regions such as .text into several function segments. Function boundaries can be obtained using mature disassemblers such as IDA Pro and Ghidra, or specialized machine learning / deep learning methods. This method achieves a good balance between granularity and semantics and is widely used. However, its basic unit is a function rather than the source file. To further recover the source file structure, function clustering or file boundary inference is needed on top of the function-level segmentation results. Furthermore, in cases of symbol stripping, high optimization, and function inlining, function boundary identification may be biased, and the error will be further propagated to the source file boundary judgment.

[0007] The fifth category is source file / module-level structure recovery-driven segmentation. This type of method uses functions as basic nodes to construct a graph of relationships between functions (including call relationships, data reference relationships, string reference relationships, etc.). Then, it uses methods such as graph clustering, community detection, and dynamic programming to divide the functions into several groups, making functions within the same group more likely to come from the same source file or module. However, this type of method usually involves multiple preliminary steps, including disassembly, function identification, relationship extraction, graph construction, and clustering optimization. Errors in any of these steps will affect the final recovery result, and the engineering implementation complexity and computational cost are also relatively high. Summary of the Invention

[0008] Therefore, it is necessary to provide a Mamba-based executable binary file segmentation method that can improve the consistency between the segmentation boundary and the real source file boundary, reduce the dependence on the quality of disassembly and function identification, and reduce error accumulation, in order to address the above-mentioned technical problems.

[0009] A method for splitting executable binary files based on Mamba, the method comprising: Receive the executable binary file to be segmented, read the file content in binary mode, and obtain the original byte sequence; The original byte sequence is digitized by mapping each byte value to a corresponding integer token, thus generating a byte token sequence. The byte token sequence is divided into blocks using an overlapping sliding window method to obtain multiple input blocks of the same length. Input blocks that are not long enough are padded and a valid position mask is generated. The valid position mask is used to mark the positions of the actual bytes and the padded bytes in the input block. Each input block is fed into a pre-trained bidirectional Mamba source file boundary prediction model to obtain a predicted probability sequence of each byte position in each input block as the starting byte of the source file; The predicted probability sequence corresponding to each input block is mapped back to the corresponding file offset position of the original byte sequence. Multiple predicted probabilities of the same byte position in the overlapping area are fused and calculated to obtain the final predicted probability of each byte position in the original byte sequence. The final predicted probabilities are filtered according to the preset classification threshold to obtain a set of candidate source file starting boundaries. The candidate source file starting boundary set is then deduplicated to obtain the final source file starting boundary sequence. Based on the final source file start boundary sequence, the original byte sequence is divided into multiple consecutive source file-level binary segments, and the file offset range corresponding to each segment is output.

[0010] The aforementioned Mamba-based executable binary file segmentation method, through its core innovation of transforming the source file-level segmentation task into a binary byte sequence labeling task, directly uses the original byte sequence as model input. This eliminates the need for intermediate steps such as disassembly, function identification, and control flow graph construction, fundamentally preventing the propagation of errors from intermediate steps to the source file-level segmentation task. This solves the problems of existing control flow-aware and function-level segmentation methods being highly dependent on disassembly quality and prone to accumulating function identification errors. Furthermore, it overcomes the limitation of section-aware segmentation, which can only achieve coarse-grained division between code and non-code regions, and can accurately identify multiple source file boundaries within the same code section or load segment. The Mamba state-space model is used for... Bidirectional modeling of long-distance byte context is used to capture both local byte patterns and global context features of the starting byte of the source file. This solves the problems of low efficiency in context modeling of long binary files and the inability of unidirectional models to utilize complete information before and after the boundary at the same time, thus improving the accuracy of boundary recognition. By adapting to the memory limitations of neural networks through block training and combining overlapping sliding window inference and probabilistic fusion techniques to smooth single-block prediction errors, the problem of processing ultra-long binary files is solved and the overall prediction stability is improved. Moreover, the final segmentation boundary is determined by the source file features learned by the model rather than a fixed window set by the user. This completely solves the defect that fixed-length segmentation cannot align with the real source file boundary, and significantly reduces the complexity of engineering implementation and the risk of multi-step error accumulation. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating an executable binary file splitting method based on Mamba in one embodiment; Figure 2 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0013] In one embodiment, such as Figure 1 As shown, a method for splitting executable binary files based on Mamba is provided, including the following steps: Step 102: Receive the executable binary file to be segmented, read the file content in binary mode to obtain the original byte sequence; perform numerical processing on the original byte sequence, map each byte value to the corresponding integer token, and generate a byte token sequence.

[0014] An executable binary file is a file that can be directly loaded and executed by the operating system. Different operating systems correspond to different formats. This method does not restrict the specific file format. Executable binary files include, but are not limited to, ELF, PE, Mach-O, and other formats. The file can be a file with a symbol table or a stripped file after the symbols have been removed. The raw byte sequence refers to the raw binary representation of the file on the storage medium, with each byte having a value ranging from 0 to 255. The integer token is a discrete symbol that converts the byte values ​​into a form that the model can process.

[0015] Read the file content in binary mode to obtain the original byte sequence: ; in This indicates the total number of bytes contained in the file. , indicating the first in the file The value of each byte.

[0016] Each byte value is used as a discrete token input to the model. To adapt to neural network training, byte values ​​can be mapped to integer tokens: ,in Indicates the first Each byte corresponds to a token number. For padding positions, an additional special token can be set, for example: Therefore, the byte vocabulary size of the model can be set to 257, where 0 to 255 represent the actual byte values ​​and 256 represents the padding tags.

[0017] It directly uses raw binary bytes as input, without requiring the input file to contain debugging symbols, source code paths, function symbols, or complete disassembly results. This fundamentally reduces the dependence on disassembly and symbol information, and solves the problem of poor applicability of existing control flow awareness and function-level segmentation methods in symbol stripping and compilation optimization scenarios.

[0018] Step 104: The byte token sequence is divided into blocks using an overlapping sliding window method to obtain multiple input blocks of the same length. Input blocks with insufficient length are padded and a valid position mask is generated. The valid position mask is used to mark the actual byte position and the padded byte position in the input block.

[0019] Overlapping sliding windows refer to a block-based approach where the sliding window overlaps with the previous window during its movement. An input block is a fixed-length data unit input into the neural network model. Padding is used to fill in the remaining space at the end of the file with special symbols to reach the fixed length when the file is shorter than the length of an input block. An effective position mask is a sequence of markers of the same length as the input block, used to distinguish between real data and padding data. Since executable binary files are typically long, directly inputting the entire file into the model at once would result in excessive memory usage, reduced training efficiency, and difficulties in long-sequence computation. This application addresses these issues through block processing. Furthermore, it clarifies that fixed-length blocks are only used to adapt to the model's computational needs, and the final segmentation boundary is determined by the model's prediction, avoiding the limitation of fixed-length segmentation methods failing to align with the boundaries of the real source file. The use of an effective position mask ensures that model training and inference only target real byte data, preventing padding data from interfering with the results. It should be noted that although this application uses fixed-length blocks in the model input stage, its purpose is only to adapt to the computational needs of neural network training and inference, and not to use the fixed window boundary as the final segmentation boundary. The final segmentation boundary is determined by the starting byte position of the source file predicted by the Mamba model.

[0020] Specifically, the length of the model input block is set to... This refers to the number of bytes contained in each input sample, which can be set to 4096, 8192, 16384, or other lengths suitable for model training.

[0021] During the training phase, the sliding step size can be set to... .

[0022] If overlapping sampling is not used, then If overlapping sampling is used, then .in Indicates the overlap ratio.

[0023] For byte sequences Perform a sliding window capture to obtain the first... One input block: ; The corresponding tag block is: ; If the end of the file is insufficient If there are 10 bytes, padding tokens are used to fill in the gaps. At the same time, attentionmask or validmask is constructed to mark which positions are real bytes and which positions are padding bytes.

[0024] Let the effective location mask be: If the first Each position represents a real byte; If the first Each position is a padding byte; During model training and loss calculation, only for The location is used to calculate the loss.

[0025] Step 106: Input each input block into the pre-trained bidirectional Mamba source file boundary prediction model to obtain the prediction probability sequence of each byte position in each input block as the starting byte of the source file; map the prediction probability sequence corresponding to each input block back to the corresponding file offset position of the original byte sequence, and perform fusion calculation on multiple prediction probabilities of the same byte position in the overlapping area to obtain the final prediction probability of each byte position in the original byte sequence.

[0026] The core of this application is the bidirectional Mamba source file boundary prediction model, which learns the contextual features of the starting byte of the source file from the byte sequence and outputs the prediction probability. File offset refers to the position number of the byte in the original binary file. Probability fusion refers to merging the prediction results of the same byte in multiple overlapping input blocks. This application leverages the linear complexity advantage of the Mamba state-space model to efficiently handle contextual modeling of long byte sequences. The bidirectional Mamba structure utilizes contextual information before and after the source file boundary, improving the accuracy of boundary identification. Probability fusion of overlapping regions smooths the error of single-block prediction, enhancing the stability and reliability of the overall prediction results.

[0027] Step 108: Filter the final predicted probabilities according to the preset classification threshold to obtain a set of candidate source file starting boundaries. Perform deduplication on the set of candidate source file starting boundaries to obtain the final source file starting boundary sequence.

[0028] The classification threshold is a probability cutoff value used to determine whether a byte is the starting boundary of the source file; the candidate starting boundary of the source file refers to the byte position where the predicted probability is greater than or equal to the threshold; boundary deduplication refers to eliminating adjacent duplicate candidate boundaries. Multiple consecutive bytes near the start position of the source file may have high predicted probabilities. Without deduplication, a large number of duplicate boundaries will be generated, leading to overly fine segmentation. Specifically: a threshold for determining the starting byte of the source file is set. When the predicted probability of a certain byte position is greater than the threshold, it is determined as the starting boundary of the candidate source file.

[0029] For complete probability sequences Perform threshold determination: ; in, Indicates the first One byte was determined as the starting boundary of the candidate source file.

[0030] The candidate boundary set is: ; Since multiple consecutive bytes near the start of the source file may have a high prediction probability, this application performs deduplication on candidate boundaries to avoid duplicate boundaries. False positive predictions are reduced by using a high-confidence threshold for screening, and boundary deduplication ensures the uniqueness and rationality of the segmentation boundaries, thus improving the accuracy of the segmentation results.

[0031] Step 110: Based on the final source file start boundary sequence, divide the original byte sequence into multiple consecutive source file-level binary segments, and output the file offset range corresponding to each segment.

[0032] Source file-level binary segments refer to contiguous binary regions predicted to originate from the same source code file; file offset range refers to the start and end positions of the segment within the original file.

[0033] Generate source file-level fragments based on the final source file start boundary sequence. Let the final boundary sequence be: ; Then the first The segment is: ; For the last segment: ; Final output segmentation result: ; Each segment corresponds to a predicted source file-level binary region.

[0034] The source file-level fragments output by this application are not only finer than section segmentation, which can distinguish different source files within the same section, but also have a more holistic context than function segmentation, which is in line with the organizational perspective of software development. This provides a more reasonable analysis unit for downstream program understanding, vulnerability auditing, code reuse analysis, and malware family analysis.

[0035] The aforementioned Mamba-based executable binary file segmentation method completely abandons the fixed-length segmentation method's approach of manually pre-setting window sizes to determine boundaries. Instead, it uses fixed-length blocks only as a means to adapt to the memory limitations and training efficiency of neural networks. Ultimately, the segmentation boundaries are entirely determined by the local patterns and global context features of the source file's starting bytes learned by the model. This fundamentally solves the problem of fixed-length segmentation easily splitting the same source file content into multiple segments or mixing different source file contents into the same segment, significantly improving the consistency between segmentation boundaries and the actual source file boundaries. In terms of segmentation granularity, it overcomes the limitation of section-aware segmentation, which can only achieve coarse-grained division of code and non-code regions based on sections such as .text, .data, and .rodata or loaded segments. Through byte-level prediction of the source file's starting position, it can accurately identify multiple source file boundaries within the same code section or loaded segment, recovering more accurate data. The fine-grained source file-level structure makes the output fragments closer to the original organization of the source code compilation unit. Regarding input dependencies, it completely eliminates the strong dependence of control flow-aware segmentation and function-level segmentation on disassembly, basic block identification, function boundary detection, and control flow graph construction. It directly uses the original binary byte sequence as the sole input to the model, thoroughly avoiding the propagation of errors from intermediate steps in complex scenarios such as symbol stripping, high-level compilation optimization, indirect jumps, tail calls, function inlining, and code obfuscation to the source file-level segmentation task, significantly improving its applicability in scenarios with unstable disassembly quality. In terms of training label construction, it innovatively utilizes compilation unit information from binary files with debugging information to extract the virtual address range of the source file. It maps the virtual address to the file offset using the precise address conversion formula: file offset = virtual address - virtual start address + file start offset. Simultaneously, it removes .debug_* and .symtab characters from the binary file after label extraction.The use of debugging and symbol information such as strtab ensures strict alignment between the generated byte-level supervision labels and the binary byte sequence, reducing training errors caused by label offsets. It also allows the model to access only the symbol-stripped binary byte content during training, enabling it to learn source file boundary features without relying on source filenames, function names, or debugging symbols. This supports training and inference on stripped binary files, perfectly adapting to real-world analysis scenarios where source code and debugging information are unavailable, such as closed-source software, malware, and firmware files. In terms of model architecture, a bidirectional Mamba state-space model is used to model long-distance byte contexts. Leveraging Mamba's linear complexity, it efficiently handles ultra-long sequence inputs like executable binary files. Simultaneously, a forward Mamba encoder extracts the preceding context features at the current position, and a reverse Mamba encoder extracts the following context features, which are then concatenated and fused. This allows the model to simultaneously capture the termination pattern of the source file's end region and the initialization pattern of the new source file's start region, obtaining a more complete boundary context representation and significantly improving the accuracy of source file start byte identification. In terms of process design, it integrates the functions of function identification, relation modeling, and cluster optimization found in traditional source file recovery methods. The multi-stage serial process of boundary recovery is simplified into an end-to-end prediction process of byte sequence input, Mamba encoding, and boundary probability output. This not only significantly reduces the engineering implementation complexity but also fundamentally reduces the risk of multi-step error accumulation, improving the overall stability of the source file-level segmentation process. Regarding the handling of class imbalance, addressing the extreme imbalance characteristic where the starting byte of the source file accounts for a very small percentage of the entire binary file, a loss function is employed, along with class balance factors and hard sample adjustment factors. This effectively reduces the dominant role of a large number of easily classified negative samples in the training process, allowing the model to focus more on a small number of hard-to-classify boundary samples. By combining high-confidence classification threshold filtering with boundary deduplication post-processing based on minimum boundary intervals, the accuracy and F1 score of source file start byte prediction are significantly improved. Regarding downstream task adaptability, the output source file-level structured fragments not only address the problem of excessively fine-grained function-level segmentation leading to high analysis costs for large programs, but also compensate for the deficiency of coarse-grained section-level segmentation in failing to reflect the organizational relationships of source code compilation units. This better aligns with the source file organization perspective in the software development phase, providing more reasonable and interpretable analysis units for downstream tasks such as program understanding, component-level security auditing, code reuse analysis, and malware family analysis.

[0036] In one embodiment, the executable binary file includes ELF, PE, or Mach-O format files, and the executable binary file is a symbol table file or a stripped file after symbols have been removed.

[0037] Specifically, ELF format is a commonly used executable file format in operating systems such as Linux and Unix; PE format is a commonly used executable file format in operating systems such as Windows; Mach-O format is a commonly used executable file format in operating systems such as macOS and iOS; symbol table files contain symbol information such as function names and variable names; stripped files refer to executable files with symbol tables and debugging information removed, and are the main analysis objects in actual reverse engineering, malware analysis, and closed-source software auditing scenarios. This method supports multiple mainstream executable file formats and is applicable to both symbol and stripped files, without relying on any symbols or debugging information, and has broad applicability to various scenarios.

[0038] In one embodiment, byte values ​​from 0 to 255 are directly mapped to integer tokens numbered from 0 to 255, and a special token numbered 256 is set as a padding token. The byte vocabulary size of the model is 257.

[0039] Specifically, byte values ​​are integers from 0 to 255, and direct mapping requires no additional encoding conversion; padding tokens are used to complete input blocks that are not long enough and do not represent any actual byte data; the vocabulary size is the total number of different tokens that the model can process. This embodiment adopts the simplest and most direct byte-to-token mapping method, which does not require complex feature engineering, reduces the complexity of data preprocessing, and at the same time ensures the integrity of the original byte information, enabling the model to directly learn the source file boundary features implicit in the byte sequence.

[0040] In one embodiment, the effective location mask is a 1 for the actual byte location and a 0 for the padding byte location.

[0041] Specifically, the effective position mask has the same length as the input block, and the value of each position corresponds to the byte type of the same position in the input block. During model training, the loss is calculated only for the real byte positions marked as 1 in the effective position mask; during inference, the prediction results are fused and post-processed only for the positions marked as 1. By clearly distinguishing between real data and padded data through the effective position mask, the interference of padded positions on model training and inference is avoided, ensuring the accuracy of loss calculation and the reliability of prediction results.

[0042] In one embodiment, each input block is fed into a pre-trained bidirectional Mamba source file boundary prediction model to obtain a predicted probability sequence for each byte position in each input block that corresponds to the starting byte of the source file, including: Input the input block into the byte embedding layer, and convert each byte token into a corresponding dense embedding vector to obtain the embedding sequence; The embedded sequence is input into the forward Mamba encoder and scanned in the direction of increasing binary file offset to obtain the forward context features of each byte position; The embedded sequence is input into the inverse Mamba encoder and scanned in the direction of decreasing offset of the binary file to obtain the inverse context features of each byte position; By concatenating the positive and negative context features at the same byte position, a bidirectional context representation of that byte position is obtained. The bidirectional context representation of each byte position is input into the classification layer, and the predicted probability that the byte position is the starting byte of the source file is output through the Sigmoid function.

[0043] The byte embedding layer transforms discrete integer tokens into low-dimensional dense vector representations, enabling the model to capture semantic relationships between bytes. The forward Mamba encoder scans from the start to the end of the input block, extracting contextual features for each byte position based on all its preceding bytes. The backward Mamba encoder scans from the end to the start of the input block, extracting contextual features for each byte position based on all its subsequent bytes. Feature concatenation merges the contextual features from both directions to form a representation containing complete contextual information. The sigmoid function maps the logit value output by the classification layer to the 0-1 range, representing the probability that the byte is the starting byte of the source file. Employing a bidirectional Mamba structure, utilizing contextual information from both the end region of the source file and the start region of the new source file simultaneously overcomes the limitation of unidirectional models that can only utilize one side of the context, significantly improving the accuracy of source file start byte identification. The specific steps include: Step 1: Byte Embedding Layer For the input block: ; First, each byte of the token is input into the embedding layer to obtain a dense vector representation: , ; Indicates vocabulary size, This indicates the embedding dimension. If 256 actual bytes and 1 padding token are set, then... .

[0044] The input block is processed by the embedding layer to obtain the embedding sequence. , ; This embedded sequence serves as the input to the bidirectional Mamba encoder.

[0045] Step 2: Mamba State Space Encoding The embedded sequence is input into the Mamba state-space model. The Mamba model models long sequences by scanning them using a selective state-space mechanism, and its hidden states can be represented as: ; in, Indicates the first Hidden state at each byte position, This indicates the hidden state of the previous position. This represents the state update function controlled by the Mamba parameter.

[0046] The state update of the Mamba layer can be abstractly represented as: ; ; in, For the first A state vector at each byte position For the first Context representation of a byte position, , , To match the current input Relevant selectivity parameters; The selectivity parameter can be dynamically generated by the linear projection layer based on the current input.

[0047] Unlike traditional fixed convolutional window or local context models, Mamba can model long byte sequences with linear complexity, making it suitable for handling long input objects such as executable binary files.

[0048] Step 3: Forward Mamba Encoding The byte embedding sequence is fed into the forward Mamba encoder in ascending order of binary file offset. The forward Mamba encoder scans from the start to the end of the input block to obtain a feature representation of each byte position based on its preceding context.

[0049] For the The position of each byte, the forward Mamba encoding result is represented as: ; in, Indicates a forward Mamba encoder. Indicates the first Positive context features for each byte position.

[0050] Step 4: Reverse Mamba Encoding The byte embedding sequence is fed into the inverse Mamba encoder in descending order of the binary file offset. The inverse Mamba encoder scans from the end of the input block to the beginning, obtaining a feature representation of each byte position based on its subsequent context.

[0051] For the The reverse Mamba encoding result for each byte position is as follows: ; in, Indicates a reverse Mamba encoder. Indicates the first Reverse context features of byte positions.

[0052] Step 5: Bidirectional Contextual Feature Fusion By concatenating the forward Mamba encoding result with the reverse Mamba encoding result, a bidirectional context representation of each byte position is obtained: ; in, This indicates a vector concatenation operation.

[0053] Through this bidirectional structure, the model utilizes contextual information from bytes before and after the start byte of the source file. The determination of the source file boundary position depends not only on the ending pattern before the boundary but also on the starting pattern of the new source file region after the boundary. Therefore, bidirectional Mamba encoding can provide more complete contextual features for predicting the start byte of the source file.

[0054] Step 6: Byte-level boundary classification Input the bidirectional context representation of each byte position into the classification layer, and output the predicted probability that the byte position is the starting byte of the source file: ; ; in, Indicates the first Logit classifies byte positions. Indicates the first The predicted probability of the first byte position in the source file. and For classification layer parameters, This is the Sigmoid function.

[0055] The model outputs the following probability predictions for the input byte block: ; in, The larger the value, the higher the value. The more bytes a file contains, the more likely it is to be the starting byte of the source file.

[0056] Step 7: Determine the start byte of the source file based on a threshold During the inference phase, the model determines the starting bytes of candidate source files based on predicted probabilities. Let the classification threshold be: When the first The byte positions satisfy: ; Then the position is determined as the starting byte of the candidate source file.

[0057] In one embodiment, the training phase of the bidirectional Mamba source file boundary prediction model includes a label construction step, which includes: Receive executable binary files with debugging information, parse the compilation unit entries in the debugging information, and extract the virtual address range corresponding to each source file; Parse the load segment information of the executable binary file with debugging information, establish a mapping relationship between virtual addresses and file offsets, and convert the virtual address range of the source file into a file offset range; remove the debugging information and symbol information from the executable binary file with debugging information to obtain the stripped binary file; Generate a label sequence of the same length as the stripped binary file. Initially, all positions are marked as negative samples, and the positions corresponding to the starting file offset of the source file are marked as positive samples.

[0058] A compilation unit (CU) is a target file unit generated by the compiler after compiling each source file. In a binary file with debugging information, each CU records the name of the corresponding source file, the compilation directory, and the code range in the virtual address space. A virtual address is the address used by the program after it is loaded into memory and executed. A file offset is the storage location of bytes in the original binary file. This embodiment utilizes the native debugging information generated by the compiler to automatically construct high-precision supervision labels, avoiding the errors and high costs of manual annotation. After extracting the labels, the debugging information in the binary file is removed, ensuring that the model training only sees the contents of the stripped binary file, guaranteeing that the trained model can be directly applied to real-world scenarios without debugging information. Specifically, the following steps are included: Step 1: Extract the virtual address range of the source file based on CU information During the tag generation phase, an executable binary file with debugging information is input. This file contains debugging information generated by the compiler, where each source file or compilation unit typically corresponds to a CU (Code Unit). Each CU records the name of the source file, the compilation directory, and the code range of that compilation unit in the binary virtual address space. This embodiment parses the CU entries in the debugging information to extract the virtual address range corresponding to each source file.

[0059] Step 2: Parse the binary load segment and establish address mapping relationships Since the Mamba model processes consecutive byte sequences in binary files, model labels must be file offsets and cannot directly use virtual addresses. Therefore, this embodiment parses the executable file's load segment information to establish a mapping relationship between virtual addresses and file offsets. Through this mapping relationship, the constructed source file virtual address range is converted into a file offset range.

[0060] Step 3: Export source file boundary labels After completing the conversion from the virtual address range of the source file to the file offset range, this embodiment exports the source file boundary information as a CSV file, which will be used as a label file in the subsequent model training stage.

[0061] Step 4: Remove debugging information from the original binary files in the dataset. Retaining debug information during binary file construction is primarily for extracting the file offset address range corresponding to the source file. However, during model training, this debug information introduces additional features, preventing the model from being directly applied to real-world projects. Therefore, after successfully extracting the address range of the source file, the debug information in the binary file needs to be removed. It's important to note that removing debug information only removes debug-related sections at the end of the binary file, such as .debug_*, .symtab, and .strtab. These operations do not affect the address layout or content of the preceding parts of the file. Therefore, the extracted source file offset address range remains unchanged.

[0062] Step 5: Generate a byte-level source file start tag sequence A sequence of tags of equal length for binary files after setting and removing debug information. ; Initially, all positions are set as negative samples: ; in, Indicates the first Each byte represents the starting byte of the corresponding binary region in a source code file; Indicates the first These bytes are not the starting bytes of the source file.

[0063] Then, the file offset address in the CSV file exported in step 3 is read, and the position corresponding to the starting offset address of the source file is marked as a positive sample.

[0064] In one embodiment, establishing a mapping relationship between virtual addresses and file offsets includes: The mapping relationship between virtual addresses and file offsets satisfies the formula: File offset = Virtual address - Virtual start address + File start offset Wherein, the virtual start address is the starting address of the loaded segment in the virtual address space, and the file start offset is the starting offset of the loaded segment in the binary file.

[0065] Specifically, a loaded segment is a contiguous region in the executable file that is loaded into memory by the operating system. Each loaded segment has a corresponding virtual start address and file start offset. Since the model processes a continuous sequence of bytes in a binary file, the training labels must be file offsets and cannot directly use virtual addresses. This embodiment achieves accurate address conversion through the above formula, precisely mapping the source file boundary to the actual byte position in the binary file. This solves the label offset problem caused by the inconsistency between virtual addresses and file offsets, and improves the accuracy of training labels.

[0066] In one embodiment, the training phase of the bidirectional Mamba source file boundary prediction model employs a preset loss function. During training, a corresponding effective location mask is generated for each training input block, and the loss is calculated only for the positions marked as real bytes in the effective location mask. The preset loss function is: ; In the formula, For the first i The loss value at each byte position, As a category balance factor, Difficult sample adjustment factor, For the first i The actual label at each byte position, with a value of either 0 or 1. For the first i The predicted probability of the first byte of the source file being located at a given byte position; The total loss of the input block is the average of the loss values ​​at all real byte positions. ; in, Indicates the actual byte position. Indicates the fill position.

[0067] The gradient of the loss function with respect to the model parameters is calculated through backpropagation, and the model parameters are updated using Adam, AdamW, or other gradient optimization algorithms. ; in, This represents all trainable parameters of the model. This represents the learning rate.

[0068] After training, save the model parameters for subsequent source file boundary prediction of unknown binary files.

[0069] Specifically, the pre-defined loss function reduces the weight of easily classified samples, making the model pay more attention to a small number of difficult-to-classify samples; the class balance factor α is used to balance the weights of positive and negative samples; the difficult sample adjustment factor γ is used to adjust the weights of difficult samples, effectively alleviating the problem of imbalance between positive and negative samples, improving the model's ability to learn the boundary positions of sparse source files, and improving the accuracy of boundary prediction and F1 score; at the same time, the loss is calculated only for the real byte positions, avoiding the interference of padding positions on the loss calculation.

[0070] In one embodiment, multiple predicted probabilities for the same byte position within an overlapping region are fused to obtain the final predicted probability for each byte position in the original byte sequence, including: By fusing multiple predicted probabilities for the same byte position within the overlapping region, the final predicted probability for each byte position in the original byte sequence is obtained as follows: ; in, For the first byte in the original byte sequence i The final predicted probability of each byte position. For the first i The total number of times each byte position is predicted. For the first j In the second prediction i The predicted probability of each byte position.

[0071] Specifically, due to the use of overlapping sliding window blocks, there are many overlapping areas between adjacent input blocks, so each byte in the overlapping area will be predicted multiple times by multiple input blocks.

[0072] During the inference phase, the input binary file to be analyzed is typically unlabeled. This embodiment uses a pre-trained Mamba model to perform sliding window prediction on the complete binary file, and improves the stability of boundary prediction through overlapping inference and probability fusion. Specifically, it includes the following steps: Step 1: Read the binary file to be split Read the executable binary file to be split and obtain the byte sequence: ; Step 2: Overlapping sliding window segmentation Let the length of the inference block be... The overlap ratio is Then the sliding step size is: ; Step 3: Block-by-block prediction For each input block Input the trained Mamba model to obtain the corresponding probability sequence: ; Map the position within the block back to the original file offset position.

[0073] Step 4: Probabilistic Fusion of Overlapping Regions Because adjacent blocks overlap, the same byte position may be predicted multiple times by multiple input blocks. Let the original file contain the byte position... One byte was predicted. The corresponding prediction probability is: ; The final probability after fusion is obtained by averaging the fusion methods. ; The final result is a probability sequence in the complete binary file where each byte position is the starting boundary of the source file: ; This embodiment uses an average fusion method to calculate the final prediction probability, which can effectively smooth the random error of individual input block prediction, especially the prediction error at the edge position of the input block, and significantly improve the stability and accuracy of long binary file boundary prediction.

[0074] In one embodiment, the deduplication process includes: During boundary deduplication, a minimum boundary interval Δ is set. For any two candidate boundaries, if their file offset difference is less than Δ, only the candidate boundary with the higher prediction probability is retained.

[0075] Specifically, the minimum boundary interval is set as follows: For any two candidate boundaries and ,like If two points are not directly related, they are considered to belong to the same candidate boundary region, and only the position with the higher predicted probability is retained. This embodiment merges candidate boundaries that are too close together into one by setting a minimum boundary interval, and only retains the position with the highest predicted probability as the final boundary, thus avoiding the problems of overly fine segmentation granularity and duplicate boundaries, and ensuring the rationality of the segmentation results.

[0076] It should be understood that, although Figure 1 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 1At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0077] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 2 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When executed by the processor, the computer program implements a Mamba-based executable binary file segmentation method. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0078] Those skilled in the art will understand that Figure 2 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0079] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0080] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0081] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for splitting executable binary files based on Mamba, characterized in that, The method includes: Receive the executable binary file to be segmented, read the file content in binary mode, and obtain the original byte sequence; The original byte sequence is numerically processed, and each byte value is mapped to a corresponding integer token to generate a byte token sequence; The byte token sequence is divided into blocks using an overlapping sliding window method to obtain multiple input blocks of the same length. Input blocks that are not long enough are padded and a valid position mask is generated. The valid position mask is used to mark the positions of the actual bytes and the padded bytes in the input block. Each input block is input into a pre-trained bidirectional Mamba source file boundary prediction model to obtain a predicted probability sequence of each byte position in each input block as the starting byte of the source file; The predicted probability sequence corresponding to each input block is mapped back to the corresponding file offset position of the original byte sequence. Multiple predicted probabilities of the same byte position in the overlapping area are fused and calculated to obtain the final predicted probability of each byte position in the original byte sequence. The final predicted probabilities are filtered according to a preset classification threshold to obtain a set of candidate source file starting boundaries. The set of candidate source file starting boundaries is then deduplicated to obtain the final source file starting boundary sequence. Based on the final source file start boundary sequence, the original byte sequence is divided into multiple consecutive source file-level binary segments, and the file offset range corresponding to each segment is output.

2. The method according to claim 1, characterized in that, The executable binary file includes ELF, PE, or Mach-O format files, and the executable binary file is a file with a symbol table or a stripped file after removing symbols.

3. The method according to claim 1, characterized in that, The method further includes: The byte values ​​from 0 to 255 are directly mapped to integer tokens numbered from 0 to 255. A special token numbered 256 is set as the padding token. The byte vocabulary size of the model is 257.

4. The method according to claim 1, characterized in that, The effective position mask is defined as follows: the actual byte position is marked as 1, and the padding byte position is marked as 0.

5. The method according to claim 1, characterized in that, Each input block is fed into a pre-trained bidirectional Mamba source file boundary prediction model to obtain a predicted probability sequence for each byte position in each input block that corresponds to the starting byte of the source file, including: Input the input block into the byte embedding layer, and convert each byte token into a corresponding dense embedding vector to obtain the embedding sequence; The embedded sequence is input into a forward Mamba encoder and scanned in the direction of increasing binary file offset to obtain the forward context features of each byte position; The embedded sequence is input into the inverse Mamba encoder and scanned in the direction of decreasing binary file offset to obtain the inverse context features of each byte position; By concatenating the positive and negative context features at the same byte position, a bidirectional context representation of that byte position is obtained. The bidirectional context representation of each byte position is input into the classification layer, and the predicted probability that the byte position is the starting byte of the source file is output through the Sigmoid function.

6. The method according to claim 1, characterized in that, The training phase of the bidirectional Mamba source file boundary prediction model includes a label construction step, which includes: Receive executable binary files with debugging information, parse the compilation unit entries in the debugging information, and extract the virtual address range corresponding to each source file; The load segment information of the executable binary file with debugging information is parsed to establish a mapping relationship between virtual addresses and file offsets, and the virtual address range of the source file is converted into a file offset range; the debugging information and symbol information in the executable binary file with debugging information are removed to obtain the stripped binary file; Generate a label sequence of the same length as the stripped binary file. Initially, all positions are marked as negative samples, and the positions corresponding to the starting file offset of the source file are marked as positive samples.

7. The method according to claim 1, characterized in that, Establishing a mapping relationship between virtual addresses and file offsets includes: The mapping relationship between the virtual address and the file offset satisfies the formula: File offset = Virtual address - Virtual start address + File start offset Wherein, the virtual start address is the starting address of the loaded segment in the virtual address space, and the file start offset is the starting offset of the loaded segment in the binary file.

8. The method according to claim 1, characterized in that, The training phase of the bidirectional Mamba source file boundary prediction model employs a preset loss function. During training, a corresponding effective position mask is generated for each training input block, and the loss is calculated only for positions marked as real bytes in the effective position mask. The preset loss function is: In the formula, For the first i The loss value at each byte position, As a category balance factor, Difficult sample adjustment factor, For the first i The actual label at each byte position, with a value of either 0 or 1. For the first i The predicted probability of the first byte of the source file being located at a given byte position; The total loss of the input block is the average of the loss values ​​at all real byte positions.

9. The method according to claim 1, characterized in that, Multiple predicted probabilities for the same byte position within an overlapping region are fused to obtain the final predicted probability for each byte position in the original byte sequence, including: By fusing multiple predicted probabilities for the same byte position within the overlapping region, the final predicted probability for each byte position in the original byte sequence is obtained as follows: in, For the first byte in the original byte sequence i The final predicted probability of each byte position. For the first i The total number of times each byte position is predicted. For the first j In the second prediction i The predicted probability of each byte position.

10. The method according to claim 1, characterized in that, The deduplication process includes: During boundary deduplication, a minimum boundary interval Δ is set. For any two candidate boundaries, if their file offset difference is less than Δ, only the candidate boundary with the higher prediction probability is retained.

Images