Method, Apparatus and System for Function Identification of Executable Binaries Based on Static Analysis

Abstract

According to the present specification, a method performed by an execution binary function identification device comprises: a step of converting each of a plurality of function unit code blocks separated from an execution binary using a hierarchical singularity marker into a function unit representation; a step of performing sequence alignment by expanding bidirectionally based on a seed determined from a partial matching interval between the function unit representation and a function unit representation stored in a reference database; a step of selecting a function with the highest relative matching degree among a plurality of candidate functions based on the sequence alignment result; and a step of generating a Software Bill of Materials (SBOM) by mapping library and version information corresponding to the selected function.

Description

Technology Field

[0001] This specification relates to a method, apparatus, and system for identifying functions of an executable binary based on static analysis. Background Technology

[0003] Recent software development trends are shifting toward actively utilizing open-source libraries and external components rather than relying on in-house implementation. This code is ultimately distributed in the form of executable files or binaries; particularly in commercial products, SaaS environments, embedded devices, and closed-network systems, it is common for only the executable binary to be delivered without any source code. Furthermore, as the importance of software supply chain security increases, various regulations require the submission of a Software Bill of Materials (SBOM) that clearly identifies which open-source and external libraries are included in the distributed software. In such environments, it is essential to verify which libraries the functions contained within the executable binary originate from, or whether specific versions of vulnerable code are included.

[0004] However, most existing software configuration analysis tools operate based on source code or build information. Typical methods utilize string-based clues such as source filenames, comments, license markers, and Git metadata; however, these methods can no longer be applied to statically linked binaries from which symbol tables or function names have been removed. Furthermore, instruction-level or Control Flow Graph (CFG)-based static comparisons suffer from issues where identical functions are recognized as different, as code structures are significantly altered depending on the compiler type and optimization options. While dynamic analysis methods exist, they have limitations, such as requiring sandbox or virtual execution environments, input vector design, and platform constraints. Execution-based approaches are not practical, particularly in industrial systems or closed-network equipment, where execution itself is often impossible.

[0005] Under these circumstances, there is a need for technology capable of accurately identifying functions within a binary solely through static analysis without execution. The problem to be solved

[0007] The purpose of this specification is to provide a method, apparatus, and system for identifying functions of an executable binary based on static analysis.

[0008] Meanwhile, the technical problems of this specification are not limited to those mentioned above, and other unmentioned technical problems will be clearly understood by a person skilled in the art from the description below. means of solving the problem

[0010] According to the present specification, a method performed by an execution binary function identification device may include: a step of converting each of a plurality of function unit code blocks separated from an execution binary using a hierarchical singularity marker into a function unit representation; a step of performing sequence alignment by expanding bidirectionally based on a seed determined from a partial matching interval between the function unit representation and a function unit representation stored in a reference database; a step of selecting a function with the highest relative matching degree among a plurality of candidate functions based on the sequence alignment result; and a step of generating a Software Bill of Materials (SBOM) by mapping library and version information corresponding to the selected function.

[0011] Additionally, the present specification describes an execution binary function identification device, wherein the device comprises: one or more processors; and a memory in which program instructions executed by the one or more processors are stored, wherein the program instructions include: a step of converting each of a plurality of function unit code blocks separated from an execution binary using a hierarchical singularity marker into a function unit representation; a step of performing sequence alignment by expanding bidirectionally based on a seed determined from a partial match interval between the function unit representation and the function unit representation stored in a reference database; a step of selecting a function with the highest relative match among a plurality of candidate functions based on the sequence alignment result; and a step of generating a Software Bill of Materials (SBOM) by mapping library and version information corresponding to the selected function. Effects of the invention

[0013] The present specification has the effect of providing a method, device, and system for identifying functions of an executable binary based on static analysis.

[0014] The effects obtainable through the specific examples of this specification are not limited to those listed above. For example, there may be various technical effects that a person with ordinary skill in the related art can understand or derive from this specification. Accordingly, the specific effects of this specification are not limited to those explicitly described herein, but may include various effects that can be understood or derived from the technical features of this specification. Brief explanation of the drawing

[0016] The following drawings are prepared to illustrate a specific example of the present specification. The names of specific devices or specific signals / messages / fields described in the drawings are presented as examples, and therefore the technical features of the present specification are not limited to the specific names used in the following drawings. FIG. 1 is a block diagram showing the overall configuration of a static analysis-based execution binary function identification system according to one embodiment of the present specification. FIG. 2 is a flowchart illustrating the flow of an offline learning process performed in a static analysis-based execution binary function identification device according to one embodiment of the present specification. FIG. 3 is a flowchart showing the flow of an online analysis process performed in a static analysis-based execution binary function identification device according to one embodiment of the present specification. FIG. 4 is a flowchart illustrating an example of a method performed by an execution binary function identification device according to one embodiment of the present specification. FIG. 5 is a diagram showing an example of the configuration of a device (500) according to one embodiment of the present specification. Specific details for implementing the invention

[0017] As the present specification is susceptible to various modifications and may have various embodiments, specific embodiments are illustrated in the drawings and described in detail in the detailed description. However, this is not intended to limit the present specification to specific embodiments, and it should be understood that it includes all modifications, equivalents, and substitutions that fall within the spirit and scope of the present specification. Similar reference numerals have been used for similar components in the description of each drawing.

[0018] In this specification, terms such as "first," "second," "A," "B," etc., may be used to describe various components, but said components should not be limited by said terms. These terms are used solely for the purpose of distinguishing one component from another. For example, without departing from the scope of this specification, the first component may be named the second component, and similarly, the second component may be named the first component. Additionally, the term "and / or" includes a combination of multiple related described items or any one of the multiple related described items.

[0019] When it is stated that one component is "connected" or "connected" to another component, it should be understood that while it may be directly connected or connected to that other component, there may also be other components in between. On the other hand, when it is stated that one component is "directly connected" or "directly connected" to another component, it should be understood that there are no other components in between.

[0020] The terms used herein are used merely to describe specific embodiments and are not intended to limit the specification. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this specification, terms such as “comprising” or “having” are intended to indicate the presence of the features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0021] Unless otherwise defined, terms used in this specification, including technical or scientific terms, have the same meaning as generally understood by those skilled in the art to which this specification pertains. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and should not be interpreted in an ideal or overly formal sense unless explicitly defined in this specification.

[0022] Hereinafter, preferred embodiments according to the present specification will be described in detail with reference to the attached drawings.

[0023] Recently, there has been an increasing trend in software distribution where only executable files (executable binaries) are provided instead of source code. With the emergence of software supply chain security and the necessity of SBOMs (Software Bill of Materials), there is a demand for technology that can accurately identify functions and libraries contained within executable binaries. However, conventional binary analysis techniques mostly rely on execution-based (dynamic) or structure-based (static) analysis, and thus have the following limitations.

[0024] First, conventional execution-based analysis methods utilize a approach where the binary is actually executed in a virtual machine or a specific execution environment to observe the output behavior in relation to the input. This entails significant costs and constraints, such as the need to set up an execution environment, require emulation for different platforms or architectures, and design input vectors for binary analysis. Furthermore, this approach is difficult to apply in industrial equipment, closed network environments, and embedded systems, as binary execution itself is impossible or not permitted for security reasons.

[0025] Second, other conventional techniques use methods to calculate similarity by comparing low-level structural features such as Control Flow Graphs (CFGs) or instruction sequences. However, since the instruction composition and code structure can vary significantly depending on compiler options or optimization levels, there is a problem where identical functions are judged to be different. For example, while a function prologue clearly exists in one implementation, it may be removed by optimization in another, making accurate identification impossible using a simple instruction comparison method.

[0026] Third, some conventional technologies calculate similarity by combining multiple feature values ​​and make judgments based on a single threshold. However, this approach results in numerous false positives when candidate functions have similar scores and cannot effectively distinguish between them in situations where specific functions (such as memcpy and memmove) share high similarity scores. Consequently, a manual verification step becomes necessary, making automated identification impossible.

[0027] Due to these problems, there is a need for technology that can accurately identify functions based on their semantics (functions) through static analysis alone, without execution, while ignoring compiler and optimization differences.

[0028] To address these requirements, the present specification provides a system that disassembles an executable binary, statically detects a function start point using a Hierarchical Multi-Specificity Marker, abstracts instructions within the detected function into Functional Codons to express the meaning of the function, and then selects a uniquely identified function among multiple candidates through a Uniqueness Score-based Cross-Reactivity Filter.

[0029] According to the present specification, functions that perform the same function regardless of the structure or instruction configuration of the function are converted into the same functional codon sequence and can be reliably identified regardless of differences in compiler type or optimization options. In addition, by eliminating false positives using a Relative Specificity Score rather than a single threshold, the accuracy of function identification can be significantly improved in an automated manner.

[0030] FIG. 1 is a block diagram showing the overall configuration of a static analysis-based execution binary function identification system according to one embodiment of the present specification.

[0031] Referring to FIG. 1, the static analysis-based execution binary function identification system (100) largely includes an offline learning unit (110) and an online analysis unit (120).

[0032] First, the offline learning unit (110) receives a binary or code corpus used for learning, generates a Hierarchical Specificity Marker (HSM) library, defines a Functional Codon library based on the generated HSM, and constructs an inverted index database by indexing these codon sequences. The offline learning unit (110) is performed once and plays a role in generating the library, codon dictionary, and inverted index database that are referenced during the subsequent online analysis process.

[0033] The online analysis unit (120) receives the target executable binary as input, performs disassembly, and statically detects the starting point of a function within the binary using an HSM generated by the offline learning unit (110). The instruction sequence of the detected function is converted into a functional codon, and the corresponding codon sequence is compared with reference functions stored in an inverted index database. Subsequently, Seed-and-Extend-based matching and a Uniqueness Score-Based Cross-Reactivity Filter are used to finally identify which function in which library corresponds to a function within the target binary. The result of the online analysis unit (120) can be output in the form of a Software Bill of Materials (SBOM) or a library identification report.

[0034] Meanwhile, the static analysis-based execution binary function identification system (100) described in this specification may be implemented by a hardware device (static analysis-based execution binary function identification device) comprising one or more processors and memory, and program instructions for performing the method of the present invention may be stored in the memory. These program instructions may be executed by the processor and configured to perform respective functions in the offline learning unit (110) and the online analysis unit (120). In addition, the present system may be implemented in the form of software or firmware on various types of hardware platforms, such as physical servers, embedded equipment, and cloud instances.

[0035] FIG. 2 is a flowchart illustrating the flow of an offline learning process performed in a static analysis-based execution binary function identification device according to one embodiment of the present specification.

[0036] Referring to FIG. 2, the device first receives a learning corpus consisting of binaries or code used for learning (210). The learning corpus may include pre-obtained function implementation code, open source libraries, or executable binaries built with various compiler / optimization options.

[0037] The device analyzes the functions included in the learning corpus and extracts a Hierarchical Specificity Marker (HSM) that indicates the starting point of the function (220). The HSM includes byte sequences or feature information that can identify function boundaries, such as instruction patterns, opcode combinations, and register manipulation patterns.

[0038] Next, the device defines a functional codon by abstracting the instruction sequence of each function into a functional unit based on the extracted HSM (230). A functional codon is a semantic-based representation of a specific combination of instructions or behaviors, and functions that perform the same function can be represented by the same codon sequence even if the compiler or optimization options are different.

[0039] Subsequently, the device constructs an inverted index database that stores mapping relationships between each function and functional codon using a defined functional codon sequence as a key (240). The inverted index database is subsequently used in the online analysis phase to quickly search for codon sequences extracted within the target execution binary and to derive candidate functions.

[0040] As such, the offline learning process illustrated in FIG. 2 is performed once, and the resulting HSM library, codon dictionary, and inverted index database are referenced during the online analysis process.

[0041] FIG. 3 is a flowchart showing the flow of an online analysis process performed in a static analysis-based execution binary function identification device according to one embodiment of the present specification.

[0042] Referring to FIG. 3, the device first receives an executable binary to be analyzed (310). The input executable binary may be in various forms, such as a static link binary with symbol information removed or an executable file obtained from an embedded device.

[0043] Afterward, the device performs a scan of the target executable binary using a Hierarchical Specificity Marker (HSM) generated during the offline learning process and statically detects the starting point of a function (320). In this process, the device analyzes the disassembled result to detect a byte sequence or opcode pattern corresponding to the entry point of a function.

[0044] Next, the device extracts functional codons from the instruction sequence of each detected function (330). Functional codons are abstractions of individual instructions into semantic-based units, and functions that perform the same function are represented to have the same codon sequence even if the compiler or optimization settings are different.

[0045] Subsequently, the device searches an inverted index database using the extracted codon sequence as a key value and extracts a matching candidate function (340). The inverted index database stores information mapped to the codon sequences of reference functions generated during the offline learning process.

[0046] Next, the device performs Seed-and-Extend-based sequence alignment and Uniqueness Score-based Cross-Reactivity Filtering on candidate functions to finally determine which function in the target binary corresponds to (350). The uniqueness score is used as a relative identification criterion to exclude cases where the similarity between identical candidates is similar.

[0047] Next, the device generates a Software Bill of Materials (SBOM) based on the identified function and library information (360). The generated SBOM may include a list of libraries and functions included in the target executable binary, version information, etc., and may be provided to or stored in an external system.

[0048] As such, FIG. 3 illustrates the overall flow in which a static analysis-based execution binary function identification device performs analysis on a target binary to extract function and library information and generates an SBOM.

[0049] Hereinafter, detailed components according to one embodiment of the present specification will be described.

[0050] Hierarchical Specificity Marker (HSM)

[0051] Hereinafter, a hierarchical specificity marker according to one embodiment of the present specification is described.

[0052] Technical concept

[0053] Hierarchical Specificity Markers (HSMs) are sets of byte sequence patterns that indicate function entry points with high probability within binary code. These patterns are extracted by statistically analyzing characteristic opcode combinations in function prologue regions, which vary depending on the architecture, compiler type, and optimization level.

[0054] The specificity of each marker pattern is quantified using (i) the proportion of the entire function where the pattern is detected at the actual function start location, and (ii) the false positive rate in the region outside the function. Based on this specificity score, markers are classified into three tiers: High Specificity (≥ 0.85), Medium Specificity (0.60–0.85), and Low Specificity (0.40–0.60). Through this hierarchical classification, the system can perform parallel searches while maintaining a balance between accuracy and detection rate, and determine function boundaries using only pure static analysis without the need for virtual machine execution or the construction of a Control Flow Graph (CFG). Furthermore, detection reliability can be enhanced by correcting the specificity of the corresponding pattern based on context after a candidate is detected.

[0055] Below, the process of constructing a marker library by extracting marker patterns from a large-scale training corpus and evaluating specificity is explained in more detail. The constructed marker library is used to detect function start points during target binary analysis.

[0056] Differentiation from conventional technology

[0057] In conventional technology, execution-based or structure-based analysis has been primarily used to identify functions within executable binaries. For example, conventional technology identifies functions by converting the executable binary into a platform-independent Intermediate Representation (IR), executing it on a virtual machine, and collecting the function's input-output relationships. However, this approach is highly dependent on the execution environment, results in slow analysis speeds due to the need for execution via a virtual machine, and has limited applicability in environments where execution itself is impossible, such as embedded systems or closed-network devices.

[0058] In another conventional technique, structure-based analysis methods extract structural features of a function based on a Control Flow Graph (CFG) or Tracelet and identify the function by comparing them. However, since the CFG structure can vary significantly depending on the compiler type, optimization options (-O0, -O2, -O3, etc.), and build environment even for the same function, this method has the problem of low reliability in function identification and frequent false positives and misses.

[0059] On the other hand, the Hierarchical Specificity Marker according to one embodiment of this specification does not depend on the structure or execution results of a function, and detects function entry points using statistically meaningful byte patterns in binary code. Since the marker according to one embodiment of this specification is automatically generated and updated by reflecting various architectures, compilers, and optimization levels through a data-driven learning algorithm, stable function boundary detection is possible solely through static analysis without execution.

[0060] Structure and Operating Principles

[0061] The Hierarchical Specificity Marker (HSM) of this specification is a data-based detection mechanism for detecting the starting location of a function solely through static analysis without execution, and its configuration and operating principles are described in detail below.

[0062] First, the system analyzes a large-scale binary corpus (samples with thousands to tens of thousands or more known function boundaries) to automatically collect byte sequences that appear repeatedly around the start of a function (e.g., the preceding 4 to 8-byte interval). For the collected byte sequence patterns, the True Positive Ratio, which is the rate at which the pattern is detected at the actual function start location, and the False Positive Ratio, which is the rate at which it is incorrectly detected within the function or at any intermediate location, are calculated. In this specification, the specificity of each pattern is defined as Specificity = 1 - False Positive Rate, and this is used as a reliability indicator for function start point detection.

[0063] Second, based on the calculated specificity scores, the system classifies markers into three tiers: High Specificity (≥ 0.85), Medium Specificity (0.60 ≤ score < 0.85), and Low Specificity (0.40 ≤ score < 0.60). High Specificity markers accurately indicate the function start location in most environments, Medium Specificity markers can handle some variations or compiler differences, and Low Specificity markers are used as auxiliary features to compensate for cases where function start patterns are modified by compiler settings, optimization levels, or architectural differences. This hierarchical classification is intended to ensure a balance between detection accuracy and coverage.

[0064] Third, during the binary analysis phase, the system scans the entire binary in parallel by simultaneously applying high, medium, and low singularity markers. Each set of markers is executed in a distributed manner per thread or process, significantly improving search speed compared to sequential search. Unlike conventional techniques that execute the binary to collect I / O relationships, this method is a deterministic approach that performs purely static byte matching.

[0065] Fourth, for the detected candidate locations, the system evaluates the likelihood of a function starting by utilizing binary context information, such as whether it is a code section (.text), instruction alignment unit (e.g., 16-byte alignment), and distance from the previous RET instruction. This context-based score is reflected as a priority and is input into the subsequent stages of functional codon extraction and normalization.

[0066] Fifth, the markers in this specification are not static and fixed, but are automatically updated by recalculating occurrence frequencies and specificity scores whenever a new binary corpus is obtained. Accordingly, they can respond to new compiler versions, architectures, or optimization options without human intervention and have a data-driven learning structure with continuously improving precision.

[0067] As such, the hierarchical singularity markers of the present specification overcome the limitations of execution-based analysis or CFG-based structural analysis and can statically detect function boundaries by utilizing the byte sequence patterns and statistical characteristics of binary code.

[0068] example

[0069] (Example 1)

[0070] Hereinafter, an example of automatically collecting function start patterns in the learning step for generating the Hierarchical Specificity Marker (HSM) library of this specification is described.

[0071] The training corpus can be configured to include various architectures, compiler options, and library types.

[0072] An example of corpus composition is shown in Table 1 below.

[0073] Architecture: x86-64(ELF), ARMv7-M(ELF), AArch64(ELF) Compiler / Option: GCC 9 / 11(-O0, -O2, -O3), Clang 14 / 16(-O2) Sample Libraries: OpenSSL 1.1.1k, mbedTLS 2.28, zlib 1.2.13, musl libc 1.2.x, wolfSSL 5.x, BusyBox parts, 3 types of vendor firmware Total Functions (with boundary labels): 18,420 (x86-64: 9,870 / ARMv7-M: 4,960 / AArch64: 3,590)

[0074] Examples of collection methods are shown in Table 2 below.

[0075] Extract a 4–8 byte sliding window from the start offset of each function. Obtain comparison samples by exhaustively scanning a window of the same length within the non-function region (intermediate position) of the same binary. Normalize patterns into exact bytes or partial wildcards (e.g., 48 83 EC ?? : sub rsp in x86-64, imm8 / imm32).

[0076] Examples of collection methods are shown in Table 3 below.

[0077] Pattern (Hexa) Meaning (Reference) Number of observations (start of function) Number of observations (non-function position) 55 48 89 E5 push rbp; mov rbp,rsp 3,967 74 48 83 EC ?? sub rsp, imm 2,742 511 F3 0F 1E FA ENDBR64 (IBT) 1,168 412 C8 ?? ?? 00 enter imm16,0 211 39 Note: ENDBR64 appears only in Clang / IBT configurations, so it depends on corpus conditions. Wildcards are a normalization used to accommodate variable fields such as immediate values ​​and offsets.

[0078] (Example 2)

[0079] Below, an example of calculating the TP (True Positive) / FP (False Positive) ratio for calculating the specificity score of the Hierarchical Specificity Marker (HSM) defined in the specification is explained.

[0080] The definition for calculating the TP / FP ratio can be configured as shown in Table 4 below.

[0081] TP (True Positive) Count: The number of times the corresponding pattern was observed at the function start position FP (False Positive) Count: The number of times the same pattern was observed at a position other than the function start position TP Rate (Recall Characteristic) = TP / (Total Number of Functions) FP Rate = FP / (Number of Non-Function Check Points) Specificity Score (Definition of the Present Invention) = 1 - FP Rate

[0082] Example patterns for calculating the TP / FP ratio are shown in Table 5 below.

[0083] Total number of functions (with labels): 9,870 Observations at function start: TP = 3,967 Total number of non-function scan points: 4,000,000 (All windows within the text section) Observations in non-functions: FP = 74

[0084] An example of the TP / FP ratio calculation result is shown in Table 6 below.

[0085] TP Rate = 3,967 / 9,870 = 0.402 FP Rate = 74 / 4,000,000 = 0.0000185 (0.00185%) Specificity Score = 1 - 0.0000185 0.99998 (High specificity)

[0086] The calculation result of the example above can be interpreted as a “strong marker where the frequency is at the 40% level, but the false positive is virtually close to 0, so it is ‘almost a function start when it is detected’.”

[0087] (Example 3)

[0088] While multiple candidate offsets for function start may be detected during the parallel scanning process, not all candidates are actual function start locations. In order to determine the function start point more reliably, a context score is assigned to each candidate location, taking into account its surrounding context.

[0089] The context-based priority score is calculated by reflecting surrounding information such as location, section, alignment, and previous instruction type, in addition to whether simple byte patterns match.

[0090] Examples of some function start candidates detected as a result of parallel scanning the target binary using Hierarchical Singularity Markers (HSM) are shown in Table 7 below.

[0091] Offset (hex) Detection marker Specificity score 0x00004120 55 48 89 E5 0.9998 0x00004123 48 83 EC 18 0.9962 0x000041A0 C8 20 00 00 0.9999 0x000046D3 F3 0F 1E FA 0.9975

[0092] In the example above, all four offsets are candidates detected during the parallel search phase as “possibly function start,” but in reality, only some may be function start points and the rest may be internal function instructions. (Example 4)

[0093] In the Hierarchical Singularity Marker (HSM)-based search process of this specification, context-based features are automatically extracted for each function start candidate detected as a result of a parallel scan, and the possibility of a function start is quantitatively evaluated using these features. Context features are structural / positional information that cannot be determined solely by whether byte patterns match, and can be derived solely through static analysis.

[0094] Table 8 below shows examples of key context features extracted from candidate locations and weights corresponding to each feature.

[0095]

[0096] All of the features in Table 8 above can be values ​​derived from static analysis.

[0097] In this specification, to quantitatively evaluate the reliability of a function start candidate, a ContextScore is calculated based on a marker specificity score (S), a context feature value (f), and a weight (w).

[0098] The final score is calculated by the following mathematical formula.

[0099] [Mathematical Formula 1]

[0100]

[0101] Here, S (Marker Specificity Score) is a score representing the probability that a pattern will appear at the function's starting position, and it represents a real value ranging from 0 to 1 (e.g., specificity 0.99998 => a pattern with a very high probability of starting the function).

[0102] f (Context Feature Value) is a value indicating whether the corresponding context feature exists at the candidate location, and is determined to be 1 if it exists and 0 if it does not.

[0103] w (Feature Weight) is the weight assigned to each context feature and varies depending on the importance of each feature (e.g., +0.2 for .text sections, +0.4 if the previous instruction was ret or jmp, etc.).

[0104] That is, the final score has a structure that calculates the final probability of a candidate's function start by adding the structural / contextual confidence (Σ wf) of the location to the confidence (S) of the pattern indicating the function start point.

[0105] The table below shows an example of the actual final score calculation.

[0106] offset section array Previous command distance reference Marker score Context correction Final score 0x00004120 .text 16B alignment ret 24B Refer to the function table 0.9998 +0.2+0.3+0.4+0.2+0.5=+1.6 2.5998 0x00004123 .text 1B offset mov 3B No reference 0.9962 +0.2-0.3+0+0+0=-0.1 0.8962 0x000041A0 .text 8B alignment ret 96B No reference 0.9999 +0.2+0.1-0.1+0=+0.2 1.1999 0x000046D3 .rodata misalignment - - doesn't exist 0.9975 -1.0 -0.0025

[0107] Regarding the score interpretation criteria, if the score is 2.0 or higher, it is set to be confirmed (Function Start), 1.0 to 2.0 is deferred, and less than 1.0 is removed. In the table above, 0x00004120 is confirmed as the actual function start, 0x000041A0 is maintained as a candidate, and 0x00004123 and 0x000046D3 are removed. In summary, the Hierarchical Specificity Marker (HSM) of this specification is a component for (i) statistically learning the byte pattern of the function entry from a large binary corpus, (ii) classifying it into three layers of high specificity, medium specificity, and low specificity according to the specificity level of the pattern, and (iii) detecting the actual function start point quickly and with high accuracy through parallel search and context-based priority evaluation. Unlike conventional execution-based analysis or control flow graph (CFG)-based structural analysis, this enables the identification of binary functions solely through pure static and deterministic analysis without the need for execution environment construction or complex graph comparison processes, and serves as the starting point and differentiating factor for the entire method proposed in this specification.

[0108] Functional Codon

[0109] Hereinafter, a functional codon according to one embodiment of the present specification will be described in detail.

[0110] Technical concept

[0111] As used in this specification, a functional codon is an abstraction unit that represents the function-level semantics of a binary instruction sequence. In other words, a functional codon represents the purposeful operation performed by multiple low-level instructions, such as “creating a stack frame,” “loop iteration,” or “performing a cryptographic operation,” as a single functionally equivalent unit.

[0112] According to the present specification, functional codons are based on a principle similar to the process in biology where a three-base sequence (codon) of DNA is abstracted into a single amino acid that makes up a protein when interpreting genetic information. In binary code as well, instead of focusing on the sequence of individual instructions, the functions that the instructions implement are expressed, thereby allowing for the absorption of formal differences in instructions (compiler version, optimization options, register selection, assembly conversion, etc.).

[0113] In other words, by using functional codons, functions that perform the same task are represented by the same sequence of functional codons even when a) different compilers, b) different build options, and c) instruction-level optimizations are applied; this enables "functional equivalence" comparisons based on meaning rather than form.

[0114] Differentiation from conventional technology

[0115] While existing technologies require converting instructions into intermediate representations (IR) and executing them to observe the operation of a function, the technology according to the present specification infers a function solely from instruction patterns without execution. Furthermore, other prior art technologies utilize CFG structures or instruction statistics, which can only evaluate structural similarity where "identical if form is the same," whereas the technology according to the present specification determines functional equivalence where "identical if meaning is the same," thereby possessing an essential distinction that allows it to recognize functions as the same even if the optimization options differ.

[0116] The table below summarizes the differences between the prior art and the technology according to this specification.

[0117] division Conventional technology Technology according to the present specification Comparison criteria Instruction string, CFG structure, statistical features Functional semantic unit of a command Level of analysis Low-level Semantic-level Processing method Requires execution or approximate execution (IBM patent) / Structural pattern-based (BinSign, BinShape) Semantic abstraction based on static analysis Compiler dependency High (discrepancy due to -O0 / -O3 difference) Low (absorbed by normalization rule) Possibilities of application Limited to searching for specific structures Multipurpose, including functional equivalence verification, SBOM, and malware lineage analysis

[0118] Example of configuring a functional codon library in an offline environment

[0119] According to the embodiments of this specification, a functional codon library is pre-built in an offline environment. The codon library is a database that abstracts and represents instruction sequences performing specific functions into semantic units, and serves as a standard for converting instructions of a target binary into corresponding codons during online analysis.

[0120] To this end, a set of training binaries with clearly known function boundaries is first prepared. For example, ELF object files built from the same source code using different compilers and optimization options, such as GCC 11, Clang 15, and MSVC 19, can be used; these files contain approximately 10,000 annotated function definitions. The total number of functions obtained through this training set is about 60,000, and the number of instructions to be analyzed reaches approximately 48 million. Each instruction consists of, on average, 4 to 6 bytes.

[0121] Procedure for Building a Functional Codon Library

[0122] Hereinafter, a procedure for constructing a functional codon library according to one embodiment of the present specification is described.

[0123] (1) Function unit separation and disassembly

[0124] First, instructions are extracted from a learning binary with clearly annotated function boundaries, provided that the start offset and end offset of each function are provided. The extracted bytecode is converted into a sequence of machine instructions using a disassembler. For example, assume there is a function as shown in Table 11 below.

[0125] Example: 00000000<func_add> :55 push rbp48 89 E5 mov rbp,rsp89 7D EC mov [rbp-0x14], edi8B 45 EC mov eax,[rbp-0x14]83 C0 01 add eax,0x15D pop rbpC3 ret

[0126] This stage is a preprocessing step that collects instruction sequences purely on a function-by-function basis.

[0127] (2) Instruction sequence windowing

[0128] A sliding window of length 2 to 6 is applied to the disassembled result inside the function to generate all possible consecutive instruction sequences as candidates.

[0129] Windows examples are as shown in the table below.

[0130] Windows sequence Function context W1 push rbp; mov rbp,rsp; mov [rbp-0x14],edi function start W2 mov rbp,rsp; mov [rbp-0x14],edi; mov eax,[rbp-0x14] function body W3 add eax,0x1; pop rbp; ret Function termination

[0131] According to the above example, approximately 310 million sequences can be generated.(3) Calculation of C (Context Specificity)

[0132] Context Specificity (C) is an indicator that quantifies the degree to which a specific codon appears 'concentratedly' within a given context. Here, context includes, for example, the start or end of a function, loop headers / conditional branches, before and after a call, and the general body. In other words, it measures "where the corresponding codon primarily appears" based on the sharpness of the probability distribution.

[0133] (3-1) Definition of Context Sets

[0134] The context in which codon candidate S is observed in the analyzed corpus is calculated as shown in the table below.

[0135] : Function Start : Function Termination / Epilogue : Loop header / condition branch : Call Site / Wrapper : General text (other)

[0136] Each context at The number of observations , total sum of observations Let (3-2) Calculate the a posteriori probability after Laplace smoothing

[0137] Macro constants to reduce distortion caused by sparse data By applying Laplace smoothing using , the context-specific a posteriori probability is defined as Equation 2 below ( = number of contexts).

[0138] [Mathematical Formula 2]

[0139] (3-3) Concentration-based singularity (normalized entropy)

[0140] The more codons are concentrated in a specific context, the more specific they become. To increase the value, Shannon entropy is normalized and used as shown in the mathematical formula below.

[0141] [Mathematical Formula 3]

[0142]

[0143] If you get stuck in only one context since (High specificity).

[0144] If it is equal in all contexts since (Low specificity).

[0145] Consequently It indicates “how sharply the corresponding codon is focused on a specific positional context (function start / end, etc.),” and is subsequently combined with U (uniqueness) to determine the final validity. It forms one axis of the mountain.

[0146] (4) Calculation of U (uniqueness)

[0147] U (Uniqueness) is a value that quantifies whether a specific codon has an independent functional meaning that is not confused with other codons. In other words, it is an indicator that evaluates whether “this codon clearly groups into a specific functional group” and “is the score difference with the second-place candidate sufficiently large?”

[0148] (4-1) Calculation of Codon Group (Label) Distribution

[0149] Codon candidates in the training corpus It aggregates the frequency of which function group (e.g., FRAME_SETUP, ARG_SAVE, CALL, TEARDOWN, LOOP_BEGIN, etc.) it is classified into.

[0150] Here, a specific functional group The frequency belonging to , total frequency It is defined as such, and to mitigate sparse data distortion, Laplace smoothing is applied to calculate the a posteriori probability as shown in the following mathematical formula:

[0151] [Mathematical Formula 4]

[0152]

[0153] (4-2) Two Uniqueness Indicators

[0154] (A) Entropy-based uniqueness (dispersion)

[0155] The more codons are concentrated in a single functional group, the higher their uniqueness, which can be expressed as shown in the mathematical formula below.

[0156] [Mathematical Formula 5]

[0157]

[0158] Here, if it is concentrated in only one function group , if it spreads to several groups It can be.

[0159] (B) Top-2 Margin gap

[0160] The probability difference between the most likely function group and the next most likely function group is evaluated using the following mathematical formula.

[0161] [Mathematical Formula 6]

[0162]

[0163] Here, the greater the difference, the more it can be interpreted as a “non-confusing,” that is, a codon with high uniqueness.

[0164] The final uniqueness U can be calculated by combining the two indicators above according to the mathematical formula below.

[0165] [Mathematical Formula 7]

[0166]

[0167] In summary, U is a value that quantifies "how unique the meaning of this codon is." In other words, if C (context-specificity) indicates "where it appears," U (uniqueness) indicates "what it means."

[0168] (5) Definition of the initial codon group (Bootstrap Phase)

[0169] Since function groups do not yet exist when the functional codon library is initially constructed, this specification determines the function groups through a rule-based initial classification step and a retraining process.

[0170] First, the disassembled instruction sequence is classified into initial codon groups based on its positional meaning within the function. For example, sequences appearing at the beginning of the function (instruction range 0 through 5) are classified into the PROLOG group, and sequences immediately before the end of the function are classified into the EPILOG group. Sequences containing the call instruction are classified into the CALL_WRAPPER group because they have the characteristics of a call wrapper function, and sequences where a loop structure (jmp back) appears are classified into the LOOP group. Instruction sequences appearing at other locations are temporarily classified into the BODY group.

[0171] Once the initial group classification is complete, a validity score V is calculated for each codon candidate. Here, context specificity C is calculated from the distribution of the location context in which the sequence appears, and uniqueness U is calculated from the distribution based on the initial feature group classification. The calculated values ​​are combined as follows to obtain the initial validity score shown below.

[0172] [Mathematical Formula 8]

[0173]

[0174] At this time Candidates with a value of 0.70 or higher are considered to be codons with clear meaning and are registered in the initial codon library.

[0175] Subsequently, in the Refinement stage, the co-occurrence patterns and functional similarities of the initially registered codons are reanalyzed to reconstruct the groups. If necessary, if candidates that appeared to be different codon groups are confirmed to be semantically identical, they are merged into a single codon group; conversely, if a single group is excessively broad, it is subdivided into subgroups.

[0176] Once retraining is complete, the function groups are finalized, and the final score is calculated by recalculating context specificity and uniqueness. Calculate. In this specification, register to the final codon library only if the threshold value of 0.80 or higher is satisfied.

[0177] (6) Calculation and refinement of validity scores

[0178] Validity score is a value that quantitatively evaluates whether a codon candidate is a “functional unit that is semantically clear and not confused with other functions.” In this specification, the two previously calculated axes, context specificity (The degree to which it appears intensively in a specific context) and uniqueness It is calculated by combining (the degree to which it is not confused with other functional groups) and can be expressed as shown in the mathematical formula below.

[0179] [Mathematical Formula 9]

[0180]

[0181] (7) Register Codon Library

[0182] Validity score calculated in the previous step Based on this, codon candidates are classified into register / hold / exclude. The following thresholds are applied in this specification.

[0183] → Confirm as a valid codon and register

[0184] → Deferred (Subject to subsequent combination / learning)

[0185] → Exclude

[0186] Exceptionally, single instruction sequences with extremely high context specificity, such as ret and call, may be allowed as a single codon even if their length is 1, and they are registered by naturally obtaining a high score during the preceding C·U calculation process.

[0187] In addition, to prevent data bias, z-normalization based on the mean and standard deviation of the C and U distributions can be applied in each training round, followed by 0-1 mapping (min-max or logistic scaling). This prevents score distortion caused by differences in corpus size or machine type (x86 / ARM).

[0188] The following is an example of determining whether to register a codon library.

[0189] Candidate ID Representative sequence C U V verdict C001 push rbp; mov rbp,rsp; sub rsp,imm 0.98 0.97 0.978 confirmed C002 mov [rbp-imm],rdi 0.76 0.83 0.787 hold C003 xor eax,eax 0.18 0.13 0.164 eliminate C004 add rsp,imm; pop rbp; ret 0.97 0.96 0.967 confirmed

[0190] In the table above, candidates determined to be confirmed are finally registered in the 'codon library' after passing the validity criteria. Each entry may contain information such as that shown in Table 15 below.

[0191] Field explanation Codon ID C0001, C0002, ... Command patterns byte sequence or disassembled string context Function start / middle / end, etc. Functional classification STACK_SETUP, CALL_WRAPPER, etc. Validity score (V) 0~1 Frequency of appearance Proportions within the corpus Uniqueness (U) Separation between functional groups

[0192] (8) Update and stabilization (operational phase)

[0193] The codon library operates not as a static structure built and maintained once, but as an adaptive dictionary that is continuously updated whenever a new binary is analyzed. During the operational phase, stability and reliability are maintained through the following mechanisms.

[0194] 1) Round-by-round relearning (Incremental Learning)

[0195] When a new binary is input, the context frequency observed in that code and codon group distribution It is updated, and C, U, and the final validity score V are recalculated based on the updated data. This ensures that the codon library consistently reflects the latest build environment and code style.

[0196] 2) Drift Detection (Score Drift Detection)

[0197] Validity score of a specific codon candidate If it drops sharply by 0.15 or more compared to the last round, a review flag is set for the candidate. This is to detect code pattern variations caused by changes in compiler version or optimization options (-O0, -O2, etc.). If necessary, the candidate is moved to a pending state or reclassified.

[0198] 3) Maintaining independence by architecture (Architecture Isolation)

[0199] Since different Instruction Set Architectures (ISAs) such as x86, ARM, and RISC-V differ in instruction structures and optimization trends, context set K, feature codon group F, and smoothing coefficients λ and μ are maintained separately for each architecture. This prevents analysis distortion that may occur when corpora of different architectures are mixed and ensures that only patterns within the same ISA are learned.

[0200] (9) Summary of the entire procedure and examples

[0201] Overall Procedure (Summary)

[0202] The entire procedure described above is summarized as follows.

[0203] 1. Candidate sequence Frequency by context Aggregate -> calculate

[0204] 2. Candidate Frequency by codon group Aggregate -> calculate

[0205] 3. Combine -> Valid / Pending / Exclude Determination

[0206] numerical example

[0207] The examples described below assume the following.

[0208] Assumption: Context , codon group , ,

[0209] Example-1) STACK_SETUP Candidate

[0210] STACK_SETUP candidate Examples are as shown in the table below.

[0211]

[0212] Example-2) Single instruction xor eax,eax candidate Single instruction xor eax,eax candidate Examples are as shown in the table below.

[0213]

[0214] Example-3) Single instruction ret candidate (Exceptional single codon)

[0215] Single instruction ret candidate Examples of (exceptional single codons) are shown in the table below.

[0216]

[0217] Extract Inverted Index

[0218] An inverted index is a data structure designed to quickly look up in reverse the location and function where a functional codon appears. Similar to the concept of storing "words -> lists of documents containing those words" in general document search, this specification maps functional codons to "words" and functions to "documents." Through this structure, it is possible to immediately look up which functions a specific codon or combination of codons appears repeatedly. In other words, an inverted index stores mapping relationships such as "codon => (occurring function ID, offset location where the codon was found)."

[0219] Example of Inverted Index Construction Procedure

[0220] (1) Input data

[0221] To construct the inverted index, the sequence of functional codons for each function extracted during the offline training process is first used as input. In this case, a single function consists of multiple codons, and each codon is listed while maintaining its order of appearance within the function.

[0222] As a result of analyzing the training corpus, codon sequences as shown in the table below can be generated for each function.

[0223] Function ID codon sequence F001 [STACK_SETUP, ARG_SAVE, FUNC_CALL, RETURN] F002 [STACK_SETUP, ARG_SAVE, LOOP_BEGIN, LOOP_END, RETURN] F003 [STACK_SETUP, ARG_SAVE, FUNC_CALL, FUNC_CALL, RETURN]

[0224] (2) Construction of Forward Index: First, for each function for which functional codon analysis is completed, the codon sequences appearing within that function are stored. Since this data structure represents a mapping relationship in the direction of function -> codon sequence, it is called a Forward Index.

[0225] Forward indexes can be configured as shown in the table below.

[0226]

[0227] (3) Create an Inverted Index table

[0228] Once a forward index (function -> codon sequence) is prepared, this specification converts it in reverse to generate an inverted index table. The inverted index table is a data structure for quickly querying which function or offset location a specific codon appears in, and has a mapping relationship such as “codon -> (function ID, location within the corresponding function).”

[0229] An example of an inverted index table is shown in Table 21 below.

[0230] codon List of appearing functions (Function ID:Offset) C1 (STACK_SETUP) F001:0, F002:0, F003:0 C2 (ARG_SAVE) F001:1, F002:1, F003:1 C3 (FUNC_CALL) F001:2, F003:2, F003:3 C4 (RETURN) F001:3, F002:4, F003:4 C5 (LOOP_BEGIN) F002:2 C6 (LOOP_END) F002:3

[0231] (4) Example of inverted index-based search

[0232] By using an inverted index structure, functions containing a specific codon pattern can be searched very quickly. For example, assume a user performs the following query.

[0233] Which function has FUNC_CALL appearing after STACK_SETUP?

[0234] The search process is as follows.

[0235] 1) First, query the list of all functions where STACK_SETUP(C1) appears in the inverted index table. Here, the query result is {F001, F002, F003}.

[0236] 2) Next, query the list of functions where FUNC_CALL(C3) appears. Here, the query result is {F001, F003}.

[0237] 3) The intersection of the two results is {F001, F003}.

[0238] 4) Finally, check the offset difference (order relationship) between the two codons to verify whether FUNC_CALL actually appears after STACK_SETUP. Since both functions satisfy this condition, the final search result is {F001, F003}.

[0239] In other words, using an inverted index table allows codon pattern searching to be performed immediately, just like string searching, and enables efficient searching by significantly narrowing the range of candidate functions.

[0240] (5) Extended structure

[0241] The inverted index of this specification is not limited to simply storing a “list of functions in which a codon appears,” but can be expanded into a three-layer structure to perform efficient searching in large-scale data.

[0242] Examples are as shown in the table below.

[0243] hierarchy Index Key Saved content note 1st floor Codon ID (Function ID, Offset) List Basic search 2nd floor (codon pair / sequence) appearance function of consecutive codons Pattern search 3rd floor (Codon semantic group) Matching the entire function group Semantic-based search

[0244] This allows users to perform queries not only for single codons but also for “semantic functional structure units.” Below is an example of actual binary-based data. It is assumed that the following instructions are extracted from the binary as a result of disassembly, and that each instruction is mapped to a corresponding functional codon.

[0245] function address Disassembly result Extracted codons 0x401000 push rbp; mov rbp,rsp; sub rsp,0x20 STACK_SETUP 0x40100C mov [rbp-0x14],edi ARG_SAVE 0x401015 call printf FUNC_CALL 0x401020 add rsp,0x20; pop rbp; ret RETURN

[0246] This information is stored in the inverted index structure as follows.

[0247] STACK_SETUP →(func_401000, offset 0x0)ARG_SAVE →(func_401000, offset 0xC)FUNC_CALL →(func_401000, offset 0x15)RETURN →(func_401000, offset 0x20)

[0248] Parallel marker scan

[0249] Parallel marker scanning is a step of rapidly detecting function start candidates in a target binary through static analysis alone without execution, using the Hierarchical Specificity Marker (HSM) proposed in this specification.

[0250] In this stage, unlike the existing method of sequentially searching the file from beginning to end, the binary to be analyzed is divided into chunks of a fixed size, and each chunk is assigned to a different thread or process to perform a parallel search. In other words, rather than a method of “finding patterns by reading the byte stream line by line,” it is structured to scan multiple areas simultaneously. This allows for a significant reduction in search time, even when analyzing large-capacity binaries (ranging from hundreds of MB to several GB).

[0251] In the parallel search process, each worker loads the HSM library generated during the offline training phase and detects candidate function start locations by applying high, medium, and low specificity markers. The detected results are written to a shared buffer or central repository and used as input for actual function analysis in a subsequent step (codon extraction).

[0252] Step-by-step structure example

[0253] Parallel marker scanning is a parallel processing structure for rapidly searching for Hierarchical Singularity Markers (HSMs) in large-scale executable binaries.

[0254] (1) Input

[0255] First, the input uses the executable binary to be analyzed (a 1GB ELF file) and a list of HSM patterns already extracted during the offline training phase. For example, it may include specific function prologue patterns such as 55 48 89 e5(push rbp; mov rbp,rsp), 41 57 41 56(push r15; push r14), and 48 83 ec ??(sub rsp, imm).

[0256] (2) Parallel division

[0257] Next, in the parallel splitting stage, the target file is divided into multiple segments and searched in parallel. For example, a 1GB file is divided into 16 segments (64MB each), and each segment is processed simultaneously by different threads or the GPU kernel. That is, Thread_0 handles Segment_0 and Thread_1 handles Segment_1, and a simultaneous scan of the entire file is performed.

[0258]

[0259] (3) Example of search logic within each thread

[0260] Subsequently, the search logic for searching for HSM candidates within each thread can be configured as follows.

[0261]

[0262] In other words, each thread reads a byte stream in fixed units (8 bytes) from the segment allocated to it and checks if the range matches one of the HSM patterns. If a byte at a specific position matches a marker such as push rbp; mov rbp,rsp or sub rsp,imm, the thread records the marker ID matched with that offset. The results recorded by each thread are then aggregated to generate a list of function start candidates.

[0263] As a result, Thread 3 can produce the following result.

[0264]

[0265] (Matching rate calculation)

[0266] The “match rate” defined in this specification is not merely a determination of whether detected bytes are identical, but a value representing, as a probability or score, how semantically similar a specific marker pattern is to an actual instruction sequence.

[0267] In other words, the degree of similarity between a detected sequence and a predefined Hierarchical Specificity Marker (HSM) pattern or codon signature is quantified as a real value between 0 and 1. A matching rate of 1.0 indicates a perfect match, meaning both the instruction composition and sequence are identical. A level of 0.9 is judged as a "sequential match," which implies that while the instructions used are identical, there are only minor changes, such as immediate constant values ​​or register numbers. Conversely, if the matching rate drops below 0.7, it is determined that while the semantic purpose may be similar, the instruction composition itself differs or a mismatch occurs; in this case, the sequence is excluded from the candidates or assigned a lower priority.

[0268] The formula for calculating the matching rate can be constructed as follows.

[0269] [Mathematical Formula 10]

[0270]

[0271] The meaning of each factor in the above mathematical formula is as follows.

[0272]

[0273] Below, we look at an example of matching rate calculation.

[0274] This example is as shown in the table below.

[0275]

[0276] That is, it is recognized as a “partially different prologue,” and in the HSM detection result, if it is 0.8 or higher, it is considered a match.

[0277] In this example, Sb is the byte-level match rate, representing the ratio of exact byte-by-byte matches between the pattern and the detected sequence.

[0278] The formula can be constructed as “Sb = (number of matched bytes) / (total number of bytes)”.

[0279] Examples of Sb calculations are shown in the table below.

[0280]

[0281] In addition, in this example, Si is the instruction-level match and represents the opcode (operator) match rate of the disassembled instruction.

[0282] The calculation formula is structured as “Si = (number of matching instructions) / (total number of instructions)”, and a method is used in which the byte sequence is disassembled to separate into instruction units and only the opcode of each instruction is compared (ignoring operands).

[0283] Examples of Si calculations are shown in the table below.

[0284]

[0285] In addition, in this example, So represents operand similarity and is a parameter used to measure how similar the operands (registers, immediate values, memory addresses) of an instruction are. The formula for So can be constructed as “Σ(operand similarity of each instruction) / (total number of instructions)”.

[0286] The similarity rules for each operand are as shown in the table below.

[0287]

[0288] Examples of similarity calculations for each operand are shown in the table below.

[0289]

[0290] As another example of matching rate calculation, the case of (command addition / omission) is explained according to the example below.

[0291]

[0292] (4) Centralized Integration (Reducer Stage)

[0293] The results of HSM patterns detected by each thread or GPU kernel through parallel scanning are collected individually, and the same function start address may be reported repeatedly by multiple threads. Therefore, in this step, all scan results are aggregated centrally and merged based on addresses (deduplication), and the pattern sets detected at those addresses are grouped into one.

[0294] Specifically, after receiving the results reported by each thread as a list in the form of <address, pattern ID>, the following is performed using a hash table with the address as the key or a sort-based mapping structure.

[0295] 1) Remove duplicates if the same address is reported by multiple threads.

[0296] 2) Aggregate all HSM patterns reported at the address and store them as a pattern combination list.

[0297] 3) Finally, output in the form of <function start candidate address, pattern combination detected at the address>.

[0298] For example, if thread 0 detects pattern P1 and thread 7 detects P3 at address 0x00401000, the central integration stage combines them into a single result and records it as P1, P3.

[0299] If P2 and P3 patterns are detected at address 0x004020C0, they are similarly generated as a single result.

[0300] This process is similar to the Reducer or MapReduce structures of Hadoop or Spark, refining the large volume of detection candidates generated during the parallel scanning phase without duplication and converting them into compressed results.

[0301] Through this, a “function start candidate list” is finally generated and used as an input to make a final determination on whether to start the function in subsequent steps (calculation of confidence score based on matching rate, CFG confirmation analysis, etc.).

[0302] Searching for the starting point

[0303] The process of finding the starting point using the pattern combination described above is explained below.

[0304] (1) Prerequisite: Prepare marker grade and matching rate

[0305] 1) First, classify markers only by specificity grade.

[0306] High(H) / Medium(M) / Low(L) (e.g., graded based on 1-FPR)

[0307] 2) In this case, for each match, write the matching rate r ∈ [0,1] (the same value as the previously calculated 0.84).

[0308] (2) Weighted sum score

[0309] Markers captured within a certain range (e.g., ±8B) at offset i are grouped, and the score is determined as the sum of (grade weight × matching rate).

[0310] The criteria are as follows.

[0311]

[0312] An example is as follows.

[0313] Example A)

[0314]

[0315] Example B)

[0316]

[0317] Visualizing this results in the following.

[0318]

[0319] When the parallel scan is completed, the marker results detected by each thread or GPU kernel are collected by the central process. The central process first sorts all detection results by address to remove duplicate records. Subsequently, markers that appear intensively at the same address (or a small offset range around the same address) are grouped into a single candidate group, and statistical values ​​are calculated for that address based on the previously derived marker grade, matching rate, and context correction score. Through this process, the central process generates a Function Start Probability Map (HSM) that quantifies the probability that each address is an actual function start point.

[0320] In other words, if parallel scanning is merely the “pattern discovery phase,” the central integration phase corresponds to the “determining phase” of the results. For each address, the following information is calculated.

[0321] 1) Number of HSMs detected at that address (including statistics by High / Medium / Low)

[0322] 2) Average and maximum matching rates of each HSM

[0323] 3) Result of applying context correction factors (section position, alignment, etc.)

[0324] 4) Final Score

[0325] The central process combines this information to generate an HSM map that expresses the function start probability of each address in the form of a probability or score, and confirms function start point candidates in order of highest score. Consequently, the HSM map can be utilized as a “function start probability heatmap” for the entire binary, and in subsequent analysis steps, the overall analysis cost can be significantly reduced by selectively searching only for high-probability addresses.

[0326] Codon Extraction and Normalization Example

[0327] Codon extraction and normalization is a step of recognizing functional semantic units (codons) in a binary instruction sequence and converting them into a comparable format.

[0328] The list of function start points obtained in the previous step (parallel marker scan) is taken as input, and the section from each start point to the next start point (or the point where the ret instruction appears) is divided into a single function region. For the instruction stream within this segmented function region, semantically related instruction groups are first searched and extracted as codons. For example, a unit of operation such as setting a stack frame, initializing a specific register, or moving memory can constitute a codon. Subsequently, all variable elements appearing within the codon, such as constant values, address values, and register names, are abstracted to perform normalization.

[0329] In this process, "code with identical functionality but different constants" and "cases where the same operation is performed but different registers are used" are integrated so that they are represented by codons with the same meaning. In other words, by eliminating syntactic differences in instructions while retaining functional equivalence, it enables the iterative search and comparison of identical functional units across different functions or binaries. This codon extraction and normalization process is mechanically repeatable and is utilized in subsequent stages for function structure comparison, clustering, and signature generation.

[0330] Step-by-step example

[0331] The codon extraction and normalization step is a process that takes the list of function start addresses derived from the preceding parallel scan as input and analyzes the internal instruction stream of each function.

[0332] (1) Input: command sequence

[0333] For example, assume that the disassembled result of a function corresponding to a specific starting address is as follows.

[0334]

[0335] (2) Codon Boundary Detection

[0336] Codon Boundary Detection is a process that analyzes instruction flow to automatically identify points where functional semantic units change. By sequentially reading the instruction sequence within a function, it is naturally separated into semantic units (codons) based on the instruction's pattern and role.

[0337] The codon boundary detection results are as follows.

[0338]

[0339] That is, when instructions that constitute a stack frame appear consecutively, such as push rbp; mov rbp, rsp; sub rsp, imm, they are grouped into a single section and classified as the STACK_SETUP codon. Subsequently, when instruction patterns that save function arguments to the local variable area appear, such as mov [rbp-imm], edi; mov [rbp-imm], esi, they are separated into the ARG_SAVE codon. Afterwards, the FUNC_CALL codon is created when a call instruction appears, such as call memcpy, and finally, the set of instructions that restore the stack and return from the function, such as add rsp, imm; pop rbp; ret, is defined as the RETURN codon.

[0340] Codon boundaries are detected by HSMs (Hierarchical Singularity Markers) or determined by transition rule sets between codons. In other words, because boundaries are defined based on the “functional meaning performed by the instruction” rather than the instruction itself, the same functional flow can be extracted into the same codon sequence even across different binaries. These identified codons are subsequently abstracted into constant and register names during the normalization phase, becoming the basic unit of a function signature comparable between functions.

[0341] (3) Instruction Normalization

[0342] Instruction normalization is the process of generalizing (symbolic abstraction) the operands, constants, and addresses contained within extracted codons so that the same functional units can be compared using the same representation across different binaries.

[0343] An example is as follows.

[0344] Original command Normalized expression explanation sub rsp, 0x30 sub rsp, imm Remove constant value mov [rbp-0x10], edi mov [rbp-imm], reg Offset generalization call memcpy call <func>< / func> External call name abstraction mov eax, 0 mov reg, 0 →zero_init Pattern regularization

[0345] In other words, instructions where the stack frame size can vary by function, such as `sub rsp, 0x30`, are expressed as `sub rsp, imm` by removing the constant value during normalization. Additionally, instructions using a specific offset or register, such as `mov [rbp-0x10], edi`, are converted to `mov [rbp-imm], reg` by abstracting the address and register, as semantically, this is the operation of "storing an argument in the local variable area." The external function call instruction (`call memcpy`) is also converted to `call` because the name of the target function can vary. <func>Normalization is performed to retain only the meaning of a function call, as shown above. If necessary, value initialization operations such as `mov eax, 0` are explicitly generalized into patterns like `mov reg, 0 -> zero_init` to simplify the expression and enable semantic-based comparison. Once normalization is complete, each codon is represented as a fixed token sequence. In other words, since differences in constants or register names have been eliminated, functionally identical operations are matched to the same codon, even if the function has different compilation options, optimization levels, or is in a different binary. As a result, the previously extracted codons are organized into a fixed sequence as follows.

[0346] STACK_SETUP →[push rbp, mov rbp,rsp, sub rsp,imm]ARG_SAVE →[mov [rbp-imm], reg]+FUNC_CALL →[call <func> ]RETURN →[add rsp,imm, pop rbp, ret]< / func>

[0347] (4) Integration of duplicates / variants (Codon Normalization Table)

[0348] Codon Normalization Table is a step that compares instruction sequences generated by different functions or compilation environments to integrate code patterns performing the same meaning into a single codon ID. Since instruction composition or order often varies depending on the compiler or optimization options even when performing the same function, codon IDs are assigned based on representative sequences, and other modified sequences are mapped to the same codon ID.

[0349] An example is as follows.

[0350] Codon ID Representative sequence Variation sequence example C001 push rbp; mov rbp,rsp; sub rsp,imm enter imm,0 C002 mov [rbp-imm], reg mov [rsp+imm], reg C003 call <func>< / func> jmp <func>< / func> C004 add rsp,imm; pop rbp; ret leave; ret

[0351] In other words, stack setup sequences in the form of `push rbp; mov rbp,rsp; sub rsp,imm` are assigned Codon ID C001, and replacement sequences performing the same function, such as `enter imm,0`, are grouped under the same codon. Local variable storage operations, such as `mov [rbp-imm]` and `reg`, are classified under Codon ID C002, and are treated with the same meaning even if the offset calculation method changes to the `[rsp+imm]` form. `call` <func>Cleanup and return sequences such as C003, add rsp,imm; pop rbp; ret are mapped to C004, and even if optimization is applied and shortened into a form such as leave; ret, they are integrated into the same codon.

[0352] By normalizing codons and integrating them based on IDs in this way, they can be consistently identified as the same semantic unit, regardless of how specific code is written or what optimizations the compiler has applied. As a result, it is highly stable for structural comparisons and pattern analysis between binaries, and enables comparisons based on codon IDs during the function signature generation process.

[0353] (5) Output normalized codon sequence

[0354] In the normalized codon sequence output stage, the previously extracted and normalized codons are concatenated at the level of the entire function to generate the final Function Codon Sequence. That is, functional units such as stack frame setup, argument storage, function call, and return are represented by individual codons and arranged sequentially according to the flow of the function. In the case of the example function, the final normalized output is expressed as "[STACK_SETUP] -> [ARG_SAVE] -> [FUNC_CALL] -> [RETURN]”.

[0355] Such a sequence is stored as the functional representation of the function and is used in subsequent steps to calculate the validity score (V) or the codon transition probability (P). In other words, the function can no longer be compared or analyzed as a sequence of individual instructions, but rather as a token sequence summarized based on meaning.

[0356] Statistical Correction After Normalization (Normalization Scoring)

[0357] Normalized codons do not stop at simply separating them into functional units; they undergo a statistical quality correction (Normalization Scoring) process to evaluate whether each codon can actually represent the structure of the function. To this end, statistical factors such as codon frequency, commonality between functions, and reusability are recalculated.

[0358] The example is as follows.

[0359] codon Frequency of appearance Commonality between functions Validity score (V) STACK_SETUP 9,870 height 0.98 ARG_SAVE 6,100 middle 0.83 FUNC_CALL 7,230 middle 0.87 RETURN 8,900 height 0.97

[0360] In other words, the STACK_SETUP and RETURN codons are common structural elements that appear in most functions, so their commonality between functions is highly evaluated, with validity scores of 0.98 and 0.97, respectively. On the other hand, the ARG_SAVE and FUNC_CALL codons have relatively low validity scores (0.83 and 0.87) because the variability in their appearance patterns is relatively large, but they are still maintained as important units for explaining code semantics.

[0361] The final score of the codon It is calculated as the following weighted sum.

[0362] [Mathematical Formula 11]

[0363]

[0364] is context specificity, is uniqueness, represents context-specific weights (e.g., start part α=0.8, internal part α=0.3).

[0365] Seed-and-extend sorting

[0366] Seed-and-extend alignment is a step that calculates the structural similarity between functions by comparing normalized codon sequences. Rather than simply comparing the entire sequence from beginning to end, it first searches for a short, highly matching codon segment (seed) in the two function sequences, and then extends the alignment range around that point to produce the final alignment result. In other words, it is a method that "starts from a matching key clue and matches the surroundings, rather than comparing the entire sequence." This follows the same principle as the BLAST algorithm used in DNA alignment, proceeding in the order of short, high-confidence seed -> bidirectional extension -> alignment score calculation.

[0367] For example, assume that the codon sequences of function A and function B are as follows.

[0368] Function A: [STACK_SETUP][ARG_SAVE][FUNC_CALL][RETURN]

[0369] Function B: [STACK_SETUP][ARG_SAVE][ARG_SAVE][CALL_MEMCPY][RETURN]

[0370] In this case, the [STACK_SETUP][ARG_SAVE] interval, which has the exact same meaning in both functions, is selected as the seed. Once the seed is determined, the sorting algorithm expands forward and backward relative to this seed to check for the existence of identical or semantically similar codons. During the expansion process, it utilizes the codon validity score (V) and transition probability (P) to determine the optimal sorting path. This allows the algorithm to find the most natural sorting structure globally, even if there is an inserted [ARG_SAVE] or [FUNC_CALL] / [CALL_MEMCPY], whose names have changed due to optimization.

[0371] This step is a matching phase performed after outputting the normalized codon sequence. Specifically, it takes a codon sequence that characteristically summarizes the function's operation as input and compares it with existing function signatures within the reference library built in Phase 1. During this process, Seed-and-extend alignment quickly determines whether there is even partial semantic agreement between the two, and alignment extension calculates whether they are identical functions or if they have structural similarity. Consequently, this step is a core procedure for identifying functions based on structural semantics (local alignment) rather than simple text comparison.

[0372] Step-by-step example

[0373] (1) Seed search step

[0374] First, find short, distinct semantic units (seeds) that appear in the same order in the codon sequences of the two functions.

[0375] (Example)

[0376] Function A: [STACK_SETUP][ARG_SAVE][FUNC_CALL][RETURN]

[0377] Function B: [STACK_SETUP][ARG_SAVE][ARG_SAVE][CALL_MEMCPY][RETURN]

[0378] In the example above, both function A and function B contain the same "[STACK_SETUP][ARG_SAVE]” codon combination.

[0379] This section is confirmed as a seed because it is a part that matches exactly in order in both sequences. Even if the seed is short in length, it is significant in that it is a "definitely common functional unit."

[0380] (2) Extend step

[0381] Once the seed is determined, the next step attempts to expand left and right around the seed to search for additional matching codons. This is called the Extend step. The sorting algorithm compares codons one by one at both ends of the seed, and expands the sorting range if the same semantic unit appears consecutively. Conversely, if a non-matching codon appears, it immediately stops expanding in that direction.

[0382] (Example)

[0383] Function A: [STACK_SETUP][ARG_SAVE][FUNC_CALL][RETURN]

[0384] Function B: [STACK_SETUP][ARG_SAVE][ARG_SAVE][CALL_MEMCPY][RETURN]

[0385] In the above example, when expanding to the right based on seed [STACK_SETUP][ARG_SAVE], FUNC_CALL appears in function A and ARG_SAVE appears in function B, so it is determined to be a mismatch and the expansion to the right is terminated. When attempting to expand to the left, the sequence's starting point has already been reached, so no further expansion occurs.

[0386] Consequently, there are no additional extended match segments other than the seed, and the final extended match length becomes 2 codons (the seed itself).

[0387] (3) Score calculation

[0388] Once the expansion process is complete, sequence similarity scoring is performed based on the found match / mismatch results. The score can be expressed by the following mathematical formula.

[0389] [Mathematical Formula 12]

[0390]

[0391] Here, M is the reward value for a match (e.g., +3), and P is the penalty value for a mismatch (e.g., -1). is the number of matched codons, means the number of mismatched codons.

[0392] In the example, since there are 2 matching codons found through the seed and 1 mismatch occurred during expansion, If the final score exceeds a threshold (e.g., 4), these two functions can be considered partially identical. In other words, "even if the code has been partially modified, if structural similarity is maintained around the core flow (seed), it is likely that they are the same function."

[0393] The aforementioned process is visually represented in the table below.

[0394]

[0395] In other words, adjacent intervals are compared by expanding from the seed (↑); the stronger the initial matching, the longer the expansion length becomes, and consequently, "partial function identity" or "prologue similarity" detection is possible.

[0396] example

[0397] Additional examples are as follows.

[0398]

[0399] That is, first, the byte sequences of the two functions are compared to search for seed candidates. Since the beginning of the two sequences, 55 48 89 e5, is completely identical, this region is confirmed as the seed. This also corresponds to the HSM marker obtained in the previous step.

[0400] Once Seed is determined, right expansion is performed next. As a result of comparing the bytes after Seed, they are identical up to 48 83 ec, so expansion continues. However, since some discrepancies occur in the subsequent bytes due to stack size differences, such as 0x20 vs 0x10, expansion ends at that point.

[0401] The expansion results are as follows.

[0402] 1) Seed length: 4 bytes

[0403] 2) Extended additional match length: 3 bytes

[0404] 3) Inconsistency occurred: 1 time

[0405] The alignment score is calculated using mathematical formula 12.

[0406] thus, It can be calculated as such, and since the score is calculated to be very high, it can be determined that the two functions have the same starting point and are structurally almost identical.

[0407] Candidate function selection (Top-N based)

[0408] After calculating the sorting score for all function pairs, keep only a small number of candidates in order of highest score.

[0409] Only the top 100 functions based on similarity scores are retained. For the rest, throughput is reduced by maintaining only local sorting information where the sorting results are significant. In other words, only high-scoring functions proceed to the next stage (precision comparison stage), and Seed-and-extend acts as a filter to screen out only the most likely candidates among many functions.

[0410] The Seed-and-Extend sorting method is significantly more efficient than comparing the entire sequence from beginning to end and is suitable for real-world binary / code comparison environments. Its greatest advantage is speed. Because it first identifies a small common area (seed) and then expands only around it for sorting, the amount of comparison required is significantly reduced compared to full sorting. It also possesses strengths in terms of stability. Since the sorting is expanded based on the seed even if there are variations at the instruction, codon, or byte levels, it can robustly detect structural similarities.

[0411] In terms of application, it is very broad. Various applications are possible, such as detecting internal function block reuse, analyzing protocol similarity, and tracing functions based on signatures. Finally, another advantage is that there are no limitations on the scope of application. This method can be applied in the same way not only to instruction-level analysis but also to codon-level and even byte-level analysis. In other words, the same principle can be used regardless of the level of representation being aligned.

[0412] Cross-reactive filter

[0413] The cross-reactivity filter is an algorithm designed to eliminate false positives that occur between similar candidate functions during the binary function identification process. Unlike conventional methods that judge functions based solely on a single similarity score, this filter introduces the concept of a "Uniqueness Score" to quantify the relative differences between candidates. The Uniqueness Score numerically represents whether a specific function matches only a specific candidate or appears similar to multiple candidates.

[0414] In other words, rather than evaluating the absolute value of the similarity score, it determines how independent the matching is relative to other candidates (relative specificity). This concept is inspired by the principle in bioinformatics of distinguishing between specificity and cross-reactivity that occur when an antibody binds to a specific antigen, and this specification applies this concept of "relative binding specificity" to binary function matching.

[0415] Existing technologies mostly determined whether functions were identical based on a single similarity score during function matching. For example, conventional technology performs matching using output vector similarity and employs an absolute threshold method that determines they are identical functions if they exceed a certain threshold (e.g., similarity ≥ 0.8). Another conventional technology uses CFG-based Tracelet similarity and similarly applies a single score criterion. Yet another conventional technology uses weight-based feature vector similarity, but the filtering criterion still only considers "whether the similarity score is above a threshold." Since all of these methods determine results based on the absolute value of the score, it is difficult to eliminate false positives when multiple candidates have similar scores, and there were problems such as the need for manual verification or unstable results.

[0416] On the other hand, the cross-reactive filter of this specification selects candidates based on relative specificity. Rather than simply "considering if similarity ≥ 0.8 as the same function," when the same function appears similar to multiple candidates, a Uniqueness Score is calculated, and the candidate is selected only when it shows an exceptionally high match with a specific candidate. In other words, the present invention filters by quantifying the difference between the highest candidate and the next highest candidate, rather than the absolute value of similarity.

[0417] In addition, while existing technologies required manual verification or had cases where processing was impossible in false positive processing, this specification enables statistical-based automatic filtering. Furthermore, while existing technologies did not apply bioinformatics concepts, this specification applies the concept of cross-reactivity in BLAST and antibody-antigen binding to binary function matching.

[0418] In summary, existing technology used absolute criteria such as "if the similarity score is 0.8 or higher, it is considered the same function," but this specification uses a relative filtering mechanism such as "even if it is 0.80, it is excluded if it is similar to other candidates."

[0419] The cross-reactive filter takes a "list of multiple candidate functions", which is the output of the Seed-and-extend sort, as input and determines the final function.

[0420] The entire operation of the function identification process

[0421] The function identification process of the present specification consists of the following steps.

[0422] First, in the existing function preparation phase, functional codon sequences are obtained from the reference function. That is, internal instructions within the function are analyzed to generate codon sequences that are extracted and normalized by functional unit.

[0423] Second, in the candidate extraction stage, candidate functions similar to the reference function are searched using a Seed-and-Extend method. At this stage, instead of comparing the entire set, the candidate pool is narrowed down quickly and efficiently by expanding based on a short and distinct seed.

[0424] Third, in the codon-unit mapping step, the codon sequences of candidate functions are matched one-to-one with the codon sequences of the reference function. This checks how well each codon matches or does not match, and where structural differences occur.

[0425] Fourth, in the cross-reactivity evaluation step, uniqueness is evaluated based on the agreement rate, the disagreement rate, and the common pattern ratio. That is, the possibility of false positives is eliminated by determining whether a specific candidate has high similarity only to the reference function or appears similar to multiple candidates.

[0426] Finally, in the final filtering step, the final candidates are determined by removing cases where commonality is excessively high and specificity is lacking (non-specific), or cases where similarity is excessively low and is judged as a separate function (dissimilar).

[0427] example

[0428] In this specification, for the sake of understanding, one target function It is assumed that a functional codon sequence for ) has already been obtained. For example, consider the case where the codon sequence of the reference function is composed as follows.

[0429] [COD_A] [COD_B] [COD_C] [COD_D] [COD_E]

[0430] Each codon has a specific functional meaning and represents the following actions.

[0431] COD_A: Initialization routine (push rbp; mov rbp,rsp)

[0432] COD_B: Create buffer (sub rsp,imm)

[0433] COD_C: call memcpy

[0434] COD_D: Conditional branch (cmp; jne)

[0435] COD_E: Return processing (add rsp,imm; pop rbp; ret)

[0436] In other words, Seed-and-extend alignment and cross-reactive filtering are applied while the internal operations of the function are structured in semantic-based units.

[0437] Reference function When a Seed-and-extend sort is performed by inputting a codon sequence, several candidate functions are extracted. Each candidate is represented by the expanded codon sequence after seed matching and the final similarity score, and an example is as follows.

[0438]

[0439] The purpose of this step is to narrow down the set of potential candidates and to prioritize the selection of candidates with expandable structural commonalities, rather than absolutely identical candidates.

[0440] Now, the standard function The codon sequence of and the codon sequence of each candidate function are aligned by codon (based on seed-and-extend results) to calculate the degree of agreement. In this specification, a cross-reactivity score is calculated together with the simple similarity score.

[0441] The scoring formula (simplified version) is as follows.

[0442] [Mathematical Formula 13]

[0443]

[0444] In addition, cross-reactivity scores is defined as follows.

[0445] [Mathematical Formula 14]

[0446]

[0447]

[0448] In other words, if a specific candidate shows a high degree of agreement only with the standard function If the value is large and shows a shape similar to several candidates The value becomes smaller. In conclusion, Seed-and-extend is the "step of finding similar-looking candidates first," and the cross-reactive filter is the "step of determining the candidate that uniquely fits the function well among them."

[0449] The calculation example is as follows.

[0450]

[0451] That is, candidate In this case, 5 codons match and there are no mismatches, resulting in a Score of 15. The crossover rate is very low at 0.05, which means there is almost no overlap with other candidates. Therefore It is determined that it is a function almost identical to the standard function (valid candidate).

[0452] Candidate It has 2 matching codons and 2 mismatching codons, so the Score is calculated to be low at 4. Additionally, the cross-reaction rate is high at 0.35, indicating that it shares a common pattern with several candidate functions. In other words, it is filtered out because it is determined to be a case where it cannot correspond independently to a specific function and responds redundantly with other functions.

[0453] Candidate Although 4 codons match, there is 1 mismatch, so the score is calculated as 11. However, the crossover response rate is 0.20, which means that the agreement with the criterion function is not clearly independent. Therefore, it is classified as a candidate with insufficient confidence despite some structural variations and is excluded.

[0454] In conclusion, as a result of applying the cross-reactivity filter, uniquely Only those that pass both the agreement rate and cross-reactivity criteria remain as final candidates. On the other hand, and It is treated as "too many common patterns with other functions (low specificity)" and removed.

[0455] Action Flow Summary

[0456] The function identification process proposed in this specification consists of the following steps. First, a reference function Obtain functional codon sequences from. Then, through Seed search, candidate functions that partially match the reference function ( ) is extracted. For the extracted candidates, the region surrounding the seed is expanded in the Extend and Score step, and partial match scores are calculated. Next, in the Codon Mapping step, the codon sequences of the reference function and each candidate function are aligned based on functional units to check for matches or mismatches. Subsequently, a cross-reactivity filter is applied to remove non-specific candidates exhibiting structures common to multiple candidates, leaving only those candidates that uniquely correspond to the reference function. Finally, the function that passes this process ( ) is determined as a valid candidate.

[0457] Full System Integration and SBOM Generation

[0458] This specification proposes a system that automatically generates a Software Bill of Materials (SBOM) of an executable binary through static analysis alone by combining the detailed components described above, namely (1) hierarchical specificity markers, (2) functional codons, (3) inverse index and Seed-and-Extend alignment, and (4) cross-reactive filters into a single integrated pipeline.

[0459] Existing SBOM generation tools (such as Syft and ScanCode) analyze based on source code or metadata from the build phase, which has resulted in discrepancies with the actual distributed executable binary or a failure to reflect libraries inserted or removed during the packaging process. In contrast, the present specification directly analyzes executable files (ELF, PE, Mach-O, etc.) to track included open source libraries and versions at the function level. This enables the generation of a binary-level SBOM based on the actual distributed binary, even in situations where source code is unavailable or build records are missing.

[0460] That is, the present specification operates in a structure that generates an SBOM by tracing the source of functions included in the actual deployment result, rather than a build-centric SBOM.

[0461] Existing Software Composition Analysis (SCA) or SBOM generation technologies are limited in their analysis unit to source code or build phase information. Consequently, discrepancies may occur with the final distributed executable binary. Furthermore, since string-based signature matching is primarily used, detection accuracy suffers when code structures are altered or symbols are removed. Additionally, because these tools require build environments or metadata, analysis is often impossible when only the executable binary is provided.

[0462] On the other hand, the system proposed in this specification places the unit of analysis as the executable binary itself and identifies libraries and versions at the function level using functional codons and alignment-based matching. This method does not require a build environment and can derive results through static analysis alone. In terms of detection accuracy, while existing technologies provide partial detection results at the level of approximately 70–85%, the method of this specification achieves a high accuracy of 95–99% through structural matching and cross-reactivity filters at the function level.

[0463] There is also a difference in terms of false positive handling. While existing technologies require a human to verify and manually filter results after detection, this specification automatically selects only those candidates that uniquely correspond to a specific function through a cross-reactive filter, thereby ensuring the reliability of the results without manual intervention. Furthermore, regarding output format, some existing tools support only certain fields of SPDX, whereas the method of this specification fully supports both SPDX and CycloneDX SBOM formats, offering high compatibility with distribution and management systems.

[0464] In other words, while existing SBOM tools remain at the level of "filename-based static detection," this specification is fundamentally different in that it simultaneously secures function-level accuracy and execution binary-based independence through functional semantic-based identification.

[0465] System Configuration and Operation Procedures

[0466] The system proposed in this specification operates in the following procedure to generate a functional unit SBOM from an executable binary.

[0467] First, in the input stage (binary collection and preprocessing), the user inputs the executable file to be analyzed ( / usr / bin / openssl) into the system. The system analyzes the ELF or PE header of the binary to extract the .text code section, and then splits it into functions using a disassembler module. Function start locations are statically detected by Hierarchical Singularity Markers (HSMs), and neither source code nor a build environment is required for this process.

[0468] Next, in the codon transformation stage (functional semantics extraction), the machine code sequences of each partitioned function are converted into functional codons. Differences such as register names, constants, and addresses are eliminated by normalization rules, and instruction differences resulting from compiler optimizations are absorbed into codon abstraction. As a result, functions performing the same function, even in different binaries, are integrated into the same "functional codon sequence" representation.

[0469] Subsequently, in the matching step (inverted index and alignment-based identification), the transformed codon sequence queries the inverted index database to search for candidate functions that have identical or similar seeds. Once a seed is identified, Seed-and-Extend alignment is performed to calculate the functional similarity between functions. Functions whose alignment scores exceed a threshold are registered as matching candidates; because this process compares functions at the functional unit level (seed-based), it is faster than full matching and more robust against errors.

[0470] Next, in the false positive elimination step (cross-reactive filtering), a relative uniqueness score is calculated for each candidate, as multiple candidate matches may exist for the same target function. If a specific candidate matches only the reference function, a high uniqueness score is calculated, and that candidate is confirmed. Conversely, candidates that appear similar to multiple functions are calculated with a low uniqueness score and are automatically eliminated. This step is a core procedure that systematically handles the false positive elimination work that was previously performed manually by humans in existing technologies.

[0471] Finally, in the aggregation and SBOM generation step, all confirmed function-library matching results are collected and grouped by library and version. The system outputs the results in SPDX 2.3 JSON or CycloneDX 1.6 XML format, and each SBOM entry includes the library name (e.g., OpenSSL), version (e.g., 1.1.1k), a list of functions used for detection (AES_encrypt, BIO_new, X509_free, etc.), average uniqueness score, and detection confidence (HIGH / MEDIUM / LOW). As such, the system of this specification can generate function-unit SBOMs using only executable binaries.

[0472] effect

[0473] Since the system according to the present specification generates an SBOM by directly analyzing the executable binary, it can accurately detect statically linked functions or linker-linked libraries that existing source-based SBOM generation tools might miss. In other words, the greatest advantage is that it can accurately calculate an execution-based SBOM by extracting components based on the actual distribution. Furthermore, the system has no dependency on the execution environment or operating system during the analysis process and can be executed independently without a network connection. Therefore, it provides environmental independence, allowing it to be utilized as is even in environments where external connections are restricted, such as closed network environments or defense and industrial control networks.

[0474] In addition, by applying an inverted index structure and a parallel scanning method, it can process even large-capacity binaries quickly, and possesses high-speed and high-volume processing performance capable of generating an SBOM for, for example, a 1GB executable file within minutes. Finally, through a cross-reactive filter, it can automatically select functions based on relative uniqueness even when multiple candidate functions are detected similarly, thereby minimizing false positives and omission rates. Through these effects, the system of this specification simultaneously achieves high accuracy, fast analysis speed, and high reliability.

[0475] FIG. 4 is a flowchart illustrating an example of a method performed by an execution binary function identification device according to one embodiment of the present specification.

[0476] First, the execution binary function identification device can convert each of the multiple function unit code blocks separated from the execution binary using hierarchical singularity markers into a function unit representation (410).

[0477] Afterwards, the execution binary function identification device can perform sequence alignment by expanding bidirectionally based on a seed determined from a partial matching interval between the function unit representation and the function unit representation stored in the reference database (420).

[0478] Afterwards, the execution binary function identification device can select the function with the highest relative agreement among a plurality of candidate functions based on the sequence alignment result (430).

[0479] Next, the executable binary function identification device can generate a Software Bill of Materials (SBOM) by mapping library and version information corresponding to the selected function.

[0480] FIG. 5 is a diagram showing an example of the configuration of a device (500) according to one embodiment of the present specification.

[0481] Referring to FIG. 5, the electronic device (500) includes a processor (510) and a memory (520).

[0482] First, the processor (510) controls the overall operation of the electronic device (500) and performs various functions by executing program instructions stored in memory (520). The processor (510) can be implemented in various forms such as a central processing unit (CPU), a microcontroller (MCU), a graphics processing unit (GPU), or an Application Specific Integrated Circuit (ASIC), and can be composed of a single processor or multiple processors.

[0483] Next, the memory (520) stores program instructions, data generated during execution, or device setting information. The memory (520) may be composed of volatile memory (RAM) or non-volatile memory (ROM, flash memory, etc.) and serves as a storage medium for storing instructions executed by the processor (510).

[0484] The aforementioned components may be integrated within a single device or implemented in a distributed form through a network. Additionally, some components may be implemented in hardware, software, or a combination thereof. By executing program instructions stored in memory (520) by the processor (510), the function according to the embodiment of the present specification may be performed.

[0486] In the exemplary system described above, methods that may be implemented according to the features of this specification described above have been described based on flowcharts. For convenience, methods have been described as a series of steps or blocks; however, the claimed features of this specification are not limited to the order of steps or blocks, and some steps may occur with other steps in a different order or simultaneously with those described above. Furthermore, those skilled in the art will understand that the steps shown in the flowcharts are not exclusive, and that other steps may be included, or that one or more steps of the flowcharts may be omitted without affecting the scope of this specification.

[0487] Various embodiments of the present specification may be implemented by hardware, firmware, software, or a combination thereof. In the case of implementation by hardware, it may be implemented by one or more ASICs (Application Specific Integrated Circuits), DSPs (Digital Signal Processors), DSPDs (Digital Signal Processing Devices), PLDs (Programmable Logic Devices), FPGAs (Field Programmable Gate Arrays), general processors, controllers, microcontrollers, microprocessors, etc.

[0488] The scope of this specification includes software or machine-executable instructions (e.g., operating systems, applications, firmware, programs, etc.) that enable operations according to the methods of various embodiments to be executed on a device or computer, and a non-transitory computer-readable medium on which such software or instructions, etc. are stored and executable on a device or computer. Examples of computer-readable media include hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, etc. Examples of program instructions include machine code, such as that produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The hardware devices described above may be configured to operate as at least one software module to perform the operations of this specification, and vice versa.

[0489] The methods according to this specification may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. A computer-readable medium may include program instructions, data files, data structures, etc., either alone or in combination. Program instructions recorded on a computer-readable medium may be those specifically designed and configured for this specification, or they may be those known and available to those skilled in the art of computer software. The operation of the method according to the embodiments of this specification may be implemented as a computer-readable program or code on a computer-readable recording medium. A computer-readable recording medium includes any type of recording device in which information that can be read by a computer system is stored. Additionally, a computer-readable recording medium may be distributed across networked computer systems, and computer-readable programs or code may be stored and executed in a distributed manner.

[0490] Some aspects of this specification have been described in the context of a device, but may also be described according to a corresponding method, wherein a block or device corresponds to a method step or a feature of a method step. Similarly, aspects described in the context of a method may also be described according to a corresponding block or item or a feature of a corresponding device. Some or all of the method steps may be performed by (or using) a hardware device, such as, for example, a microprocessor, a programmable computer, or an electronic circuit. In some embodiments, at least one of the most important method steps may be performed by such a device.

[0491] In the embodiments, a programmable logic device (e.g., a field-programmable gate array) may be used to perform some or all of the functions of the methods described herein. In the embodiments, the field-programmable gate array may operate with a microprocessor to perform one of the methods described herein. Generally, it is preferable that the methods be performed by some hardware device.

[0492] The exemplary methods of this specification are described as a series of operations for clarity of description, but this is not intended to limit the order in which the steps are performed, and if necessary, each step may be performed simultaneously or in a different order. To implement the methods according to this specification, additional steps may be included in addition to the steps exemplified, steps excluding some steps and including the remaining steps, or steps excluding some steps and including additional steps.

[0493] The various embodiments of this specification are not intended to list all possible combinations but to describe representative aspects of this specification, and the matters described in the various embodiments may be applied independently or in combination of two or more.

[0494] Although the present specification has been described with reference to preferred embodiments, those skilled in the art will understand that various modifications and changes can be made to the present specification without departing from the spirit and scope of the present specification as set forth in the following claims.

[0495] The claims described in this specification may be combined in various ways. For example, the technical features of the method claims of this specification may be combined to be implemented as a device, and the technical features of the device claims of this specification may be combined to be implemented as a method. Furthermore, the technical features of the method claims and the technical features of the device claims of this specification may be combined to be implemented as a device, and the technical features of the method claims and the technical features of the device claims of this specification may be combined to be implemented as a method. Moreover, the embodiments described in this specification may be combined within a range that is not mutually incompatible.< / func> < / func>

Claims

Claim 1 A method performed by an execution binary function identification device, wherein the method comprises: a step of converting each of a plurality of function unit code blocks separated from an execution binary using a hierarchical singularity marker into a function unit representation; a step of performing sequence alignment by expanding bidirectionally based on a seed determined from a partial matching interval between the function unit representation and a function unit representation stored in a reference database; a step of selecting a function with the highest relative match among a plurality of candidate functions based on the sequence alignment result; and a step of generating a Software Bill of Materials (SBOM) by mapping library and version information corresponding to the selected function, wherein the step of converting into a function unit representation comprises: a step of extracting semantically related instruction bundles for an instruction stream within a function region into function unit codons; and a step of performing normalization through abstraction of variable elements included within the codons, wherein the function unit codons are selected according to a validity score calculated as a weighted sum of singularity and uniqueness within the context of the execution binary. Claim 2 delete Claim 3 A method according to claim 1, wherein the variable elements include a register, a constant value, and an address value. Claim 4 A method according to claim 1, wherein the sequence alignment is performed between the functional unit representation and the functional unit representation stored in the reference database corresponding to the candidate function, and the similarity score of the candidate function is calculated by adding a score for functional unit representations that match between the functional unit representation and the functional unit representation stored in the reference database, and subtracting a score for functional unit representations that do not match between the functional unit representation and the functional unit representation stored in the reference database. Claim 5 A method according to claim 1, wherein the function with the highest relative agreement is a function that has a high degree of agreement with the functional unit representation and a low degree of agreement with the remaining candidate functions. Claim 6 A method according to claim 5, wherein the relative agreement is calculated as the ratio obtained by dividing the matching score of the target function by the average matching score of the plurality of candidate functions. Claim 7 delete Claim 8 A method according to claim 1, wherein the reference database comprises an inverted index structure having the function unit codon as a key, and the function identifier and offset as values. Claim 9 The method of claim 1 further comprises the step of, after the sequence alignment, evaluating the cross-reactivity between the plurality of candidate functions and removing candidates in which the common pattern is greater than or equal to a specific value. Claim 10 An execution binary function identification device, wherein the device comprises: one or more processors; and a memory in which program instructions executed by the one or more processors are stored, wherein the program instructions include: a step of converting each of a plurality of function unit code blocks separated from an execution binary using a hierarchical singularity marker into a function unit representation; a step of performing sequence alignment by expanding bidirectionally based on a seed determined from a partial match interval between the function unit representation and a function unit representation stored in a reference database; a step of selecting a function with the highest relative match among a plurality of candidate functions based on the sequence alignment result; and a step of generating a Software Bill of Materials (SBOM) by mapping library and version information corresponding to the selected function, wherein the step of converting into a function unit representation includes: a step of extracting semantically related instruction bundles for an instruction stream within a function region into function unit codons; and a step of performing normalization through abstraction of variable elements included within the codons, wherein the function unit codons are selected according to a validity score calculated as a weighted sum of singularity and uniqueness within the context of the execution binary. Claim 11 delete Claim 12 In claim 10, the device wherein the variable elements include a register, a constant value, and an address value. Claim 13 A device according to claim 10, wherein the sequence alignment is performed between the functional unit representation and the functional unit representation stored in the reference database corresponding to the candidate function, and the similarity score of the candidate function is calculated by adding a score for functional unit representations that match between the functional unit representation and the functional unit representation stored in the reference database, and subtracting a score for functional unit representations that do not match between the functional unit representation and the functional unit representation stored in the reference database. Claim 14 In claim 10, the device is such that the function with the highest relative agreement is a function that has a high degree of agreement with the functional unit representation and a low degree of agreement with the remaining candidate functions. Claim 15 In claim 14, the relative agreement is calculated as a ratio obtained by dividing the matching score of the target function by the average matching score of the plurality of candidate functions. Claim 16 delete Claim 17 In claim 10, the device comprises a reference database including an inverted index structure in which the function unit codon is the key and the function identifier and offset are the values. Claim 18 In claim 10, the device further comprises the step of, after the sequence alignment, evaluating the cross-reactivity between the plurality of candidate functions to remove candidates in which the common pattern is greater than or equal to a specific value.

Images