Cross-Platform Software Birthmarking for Real-World Binaries via Intermediate Representation Haruaki Tamada
arXiv:2606.21988v1 [cs.SE] 20 Jun 2026
Kyoto Sangyo University. Kyoto, Japan 0000-0003-1838-9184
Abstract—Software birthmarking detects plagiarism through characteristic program features, yet cross-platform resilience remains under-evaluated. This paper proposes a unified birthmarking approach for real-world binaries by lifting disparate formats into a common intermediate representation via Ghidra P-code. Experiments across diverse platforms and languages demonstrate exceptional consistency across CPU architectures (r = 0.9846), independent of ISA (Instruction Set Architecture) specific details. The study also identifies a “dilution effect” in Windows binaries, in which the proliferation of libraryderived functions degrades similarity scores. Despite this noise, the Simpson index demonstrates superior discriminative power. These findings clarify the practical capabilities and essential requirements for robust cross-platform birthmarking. Index Terms—software birthmarking, cross-platform, intermediate representation, ghidra p-code
I. I NTRODUCTION Software theft is difficult to detect because stolen software is often modified to conceal plagiarism, and identical source code can result in significantly different executables when compiled for different platforms. To address this problem, software birthmarking has been proposed as a technique that extracts characteristic features from software and measures similarities between programs[1], [2]. However, most existing birthmarking studies have focused on limited targets, such as Java bytecode, and have not sufficiently evaluated executables across heterogeneous platforms, including different operating systems, binary formats, and CPU architectures. The biggest problem with software birthmarking is that the target platforms in previous studies are limited to a few platforms. Additionally, it has not been evaluated for the robustness of the birthmarking techniques across platforms and architectures. In recent years, cross-compilation has become easier; we can compile a set of source codes and generate executables for various platforms. It originates from the rise of compiler infrastructure such as LLVM[3]. Let’s consider a scenario. Suppose a developer creates proprietary software X and releases it for macOS. Unfortunately, X is plagiarized, and an adversary releases it for a Windows platform after minor modifications. Then, how can we detect this plagiarism? Since the binary formats differ and the compilers used may also be different, it is generally difficult to compare them. The user should understand not only both binary formats, The part of this work was supported by JSPS Grant Number 26K14788.
but also the differences between them across platforms in analyzing plagiarism. Furthermore, to date, no evaluation has been conducted of how different the binaries generated by cross-compilation actually are. In this paper, we apply software birthmarking technology to executable files in real-world environments across multiple platforms and evaluate its performance. Today, the most prominent executable formats include Windows PE[4], macOS Mach-O[5], and Linux ELF[6]. No unified method for handling these formats has been established, and even if birthmarking techniques exist for each format, significant effort is required to compare them. On the other hand, LLVM uses a front-end mechanism to convert programs written in various languages into an intermediate language called LLVM IR, and then generates executable files for each platform using a back-end. In other words, by constructing a birthmarking method targeting this intermediate language, we can achieve plagiarism detection that is independent of both platform and language. Fortunately, a few binary lifting (decompilation) techniques have been proposed for converting executable files into a certain intermediate language. By leveraging these, we can expect to develop platform- and language-independent birthmarking techniques that can target a wide range of executable files. The rest of this paper is organized as follows. Section II reviews the related work. Section III defines software birthmarks and describes their properties. Section IV introduces the tool for the proposed birthmarking technique. Section V presents the experimental setup and results. Section VI discusses the results and the limitations of the proposed technique. Finally, Section VII concludes this paper. II. R ELATED W ORK Software birthmarking was first proposed for Java programs to detect software theft without the need for embedding the watermarking [1]. Early research focused on defining various types of birthmarks, such as those based on instruction sequences (k-grams) [7]. While these foundational works established the properties of credibility and resilience, they were primarily designed for high-level languages or specific instruction set architectures (ISAs). In contrast, our work aims to provide a cross-architecture solution by leveraging intermediate representations.
Binary code similarity has become a major research area, with applications in vulnerability discovery and malware analysis [8]. Recent studies have employed binary lifting to translate diverse ISAs into a common intermediate representation (IR) to mitigate architecture-specific differences. Tools like discovRE [9] and BinGo [10] use structural and semantic features from IR to identify similar code across platforms. Furthermore, state-of-the-art methods such as HermesSim utilize Ghidra P-code to build semantics-oriented graphs for high-precision matching via graph neural networks[11]. Our approach differs by using a training-free, deterministic matching algorithm that prioritizes explainability in the context of birthmarking. To handle the ever-increasing volume of software, scalable search-based detection systems have been developed. Mituba applies search engine technologies like inverted indexing to scale up software theft detection across millions of projects[12]. Similarly, Ghidra’s BSim uses locality-sensitive hashing on P-code features for rapid similarity lookups[13]. While these systems are excellent for large-scale screening, our proposed birthmarking technique provides a more rigorous, second-stage identification process that cross-checks suspected pairs across different architectures with high fidelity. III. S OFTWARE B IRTHMARKS A. Definitions of software birthmarks A software birthmark is a collection of unique characteristics of a given software, which can be used to identify the software. It is used to detect software theft, plagiarism, and tampering. Let B(p) be a function that extracts birthmarks from software p. Here, the birthmark can be extracted either statically or dynamically from p (possibly with a certain input I to p for dynamic birthmarks). Then, two birthmarks B(p) and B(q) provide a method for calculating the similarity, which reflects the similarity between the original software p and q. The similarity is a value between 0 and 1, where 1 means that the two software are identical, and 0 means that they are completely different. Hopefully, a software birthmark should satisfy the following two properties: • Credibility means that the similarity between two software programs developed independently should be low, even if they have identical functions, and • Resilience indicates that the similarity between an altered program and the original should remain high. B. The workflow of birthmark-based theft detection The primary purpose of software birthmarking is to detect software that is quite similar to the original software from the enormous number of software sets. To achieve this, the following steps should typically be employed. • Preparation Gather the set of software to be examined, • Extraction Extract birthmarks from each software, • Comparison Compare the extracted birthmarks, and
•
Detection Analyze the comparison results and identify software that may be stolen.
1) Preparation step: In the preparation step, we gather the set of software to be examined and compare them with the original software in the following steps. The software in the set is sourced from various sources, including software repositories and websites. If we have a specific suspicion of plagiarized software, the set will be smaller. However, if we are conducting a broad-based plagiarism check, a vast number of sets will be required. 2) Extraction step: In this step, we extract birthmarks from each software in the set and the original software. There are various types of birthmarks, such as opcode sequences, k-gram based opcodes, etc. However, the choice of which type of birthmarks to select is left to the user. Furthermore, since the performance of birthmark types has not yet been sufficiently investigated, a comprehensive study is needed in the future. 3) Comparison step: Generally, software consists of multiple modules, each containing several functions. Then, the unit for birthmark extraction is typically a function unit. Therefore, the comparison of birthmarks should be performed at the function unit level, and the similarities within each function unit should be aggregated to calculate the overall similarity of the software. Although comparison algorithms for function units have been discussed in previous studies, methods for calculating the similarity of the entire software have received less attention. In the earliest studies, a simple average was used[1], however, the average was pointed out to underestimate the similarity, and top-n selection was proposed by Fedorov et al.[14]. Other methods include using combinatorial optimization algorithms such as the Hungarian algorithm[15], [16], [17]. Here, we introduce the comparison algorithms used in previous research. For the definition of the birthmark comparison algorithms, let B(p) and B(q) be the birthmarks which contains sequences of elements extracted from two software p and q, respectively. Then, the comparison algorithms calculate the similarity between p and q based on the similarities between the birthmarks in B(p) = {ep1 , ep2 , . . . , epmp } and B(q) = {eq1 , eq2 , . . . , eqmq }. Also, let F(B(p)) be the function by vectorize the birthmark B(p) by its frequencies, and fp (i) and fq (i) be the frequency values of ei in B(p) and B(q), respectively. S(B(p)) be the function that extracts the set of elements in the birthmark B(p). Then, the comparison algorithms are defined as shown in Table I. 4) Detection step: Finally, we analyze the comparison results and identify software that may be stolen. The previous studies introduced the threshold-based method, which identifies software as stolen if the similarity exceeds a certain threshold (typical threshold value is ε = 0.75). Note that this paper does not consider such detection methods, since the main focus of this work is the similarity distributions of executables and the relationships between similarities and software characteristics, such as programming language, compiler, and features.
TABLE I: Comparison algorithms for birthmark similarity calculation Dice index
2|S(B(p)) ∩ S(B(q))| |S(B(p))| + |S(B(q))|
Jaccard index
|S(B(p)) ∩ S(B(q))| |S(B(p)) ∪ S(B(q))|
Simpson index
|S(B(p)) ∩ S(B(q))| min(|S(B(p))|, |S(B(q))|)
LCS (Longest Common Subsequence)
|lcs(B(p), B(q))| max(|B(p)|, |B(q)|)
Levenshtein similarity
1−
Euclidean similarity
1 − pP
Cosine similarity Weighted Jaccard index
V. E VALUATION
levenshtein(B(p), B(q)) max(|B(p)|, |B(q)|) pP (fp (i) − fq (i))2 fp (i)2 +
pP
fq (i)2
F (B(p)) · F (B(q)) ∥F (B(q))∥ P(B(p))∥∥F n min(fp (i), fq (i)) i=1
Pn i=1
the intermediate representation for executable files, since it is open-source and supports various architectures and platforms. Also, Ghidra supports the binary lifting (decompilation) of executable files into P-code, and thus we can easily convert executable files into the intermediate representation. Then, oinkie-IR is generated from the obtained P-code using a simple converter that extracts the symbol names, opcodes, and their operands, and stores them into a JSON file.
max(fp (i), fq (i))
IV. I MPLEMENTATION A. Oinkie: The birthmarking toolkit The author has developed Oinkie, a software birthmarking toolkit, which can extract several types of birthmarks from Oinkie-IR (Intermediate Representation) and compare them1 . Oinkie-IR is a simple JSON format, which includes a list of instructions (opcodes and their operands) for every function in an executable file. In the current version of oinkie, we can extract three types of birthmarks: opcode sequence (opseq), opcode frequency (opfreq), and opcode set (opset). Also it provides the comparison algorithm shown in Table I. B. Similarity calculation between two executables The algorithms shown in Table I calculate the similarities between two functions in the executables. However, the birthmarking scenario requires the similarity between two executables. Therefore, we should aggregate the similarity matrix among functions by some method. This paper employs the aggregation method top-n selection [14], and hungarian algorithm [15], [16]. Top-n selection finds the max similarities in each row and column of the similarity matrix, and calculates the average of the selected similarities. Hungarian algorithm is a combinatorial optimization algorithm, which finds the optimal matching between two sets of functions in the executables. In this paper, we use top-n selection with n = 1 and n = ∞ (all) for the evaluation. C. Binary lifting To apply the proposed birthmarking techniques to executable files, we firstly should convert the executables to oinkie-IR. Today, there are several intermediate representations for executable files, such as LLVM-IR/BC2 , Ghidra Pcode3 , IDA Pro microcode4 , Binary Ninja IL (Intermediate Language)5 , and etc. In this paper, we use Ghidra P-code as
A. Setup Through the following experiments, we evaluate the birthmarks by the following steps. 1) obtain the target software binaries (such as Mach-O, PE, and/or ELF), 2) lift the obtained binaries into P-code using Ghidra, 3) convert the obtained P-code into oinkie-IR, 4) extract opseq, opfreq, or opset birthmarks from the obtained oinkie-IR, and 5) compare the extracted birthmarks and calculate the similarities. B. Resemblance Evaluation 1) Target software: In the first experiment, we compare the birthmarks of the essentially near-identical software to confirm that they exhibit high similarity. This evaluation is crucial for establishing a baseline before assessing the similarities of different software in subsequent experiments. By “essentially identical,” we refer to software that shares the same OS, architecture, programming language, and compiler, with only slight modifications. For this purpose, we utilize binaries from different versions of bzip2 (versions 1.0.1 to 1.0.8), a widely used data compression utility. These binaries were obtained from the official website6 . The differences of the source code between these versions are shown in Figure 1 with stacked chart, calculated by difflib in Python7 . The horizontal axis represents the compared version pairs, grouped by the base version. The bars show the ratio of unchanged, deleted, and inserted lines relative to the total lines of the older version. From figure 1, we can see that the differences among versions are quite small, with only a few percent of code added, and removed. Next, we compile these versions of bzip2 from source code into arm64 Mach-O executables on macOS using clang without any compile options. Then, we applied the proposed birthmarking techniques to calculate the similarities among these versions. Since the updates between these versions mainly involve bug fixes and minor improvements, their core logic remains largely unchanged, making them ideal for evaluating the resemblance of birthmarks. 1 https://github.com/tamada/oinkie 2 https://llvm.org/docs/LangRef.html 3 https://ghidra.re/ghidra docs/languages/html/pcoderef.html 4 https://hex-rays.com/blog/microcode-in-pictures 5 https://docs.binary.ninja/dev/bnil-overview.html 6 https://sourceware.org/pub/bzip2/ 7 https://docs.python.org/ja/3/library/difflib.html
TABLE II: The target software for the credibility evaluation 1.0.3
1.0.4
1.0.5
1.0.7
inserted 1.0.2
1.0.6
unchanged deleted 1.0.1 1.2
Label bzip2_gcc bzip2_go bzip2_rs md5_gcc md5_go md5_rs
Language C Go Rust C Go Rust
Label sha256_gcc sha256_go sha256_rs factorize_gcc factorize_go factorize_rs
(a) Dice
(b) Jaccard
(c) Simpson
(d) Euclidean
(e) LCS
(f) Levenshtein
(g) Cosine
(h) W-Jaccard
1 0.8 0.6 0.4
Language C Go Rust C Go Rust
0.2
1.0.2 1.0.3 1.0.4 1.0.5 1.0.6 1.0.7 1.0.8 1.0.3 1.0.4 1.0.5 1.0.6 1.0.7 1.0.8 1.0.4 1.0.5 1.0.6 1.0.7 1.0.8 1.0.5 1.0.6 1.0.7 1.0.8 1.0.6 1.0.7 1.0.8 1.0.7 1.0.8 1.0.8
0
Fig. 1: The differences between the versions of bzip2 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1
Hungarian
Top n (n=all)
Top n (n=1)
D Ja ice c Si card m Eu pso cl n id ea n Le ve LC ns S ht e C in W os -J ine ac ca rd D Ja ice cc Si ard m Eu pso cl n id ea n Le ve LC ns S ht e C in W os -J ine ac ca rd D Ja ice cc Si ard m Eu pso cl n id ea n Le ve LC ns S ht e C in W os -J ine ac ca rd
0
Fig. 3: The similarities among the targets shown in Table II (Hungarian method) 0.0
0.25
0.5
0.75
1.0
Fig. 2: Similarities among the different versions of bzip2
Fig. 4: The similarity scale for the heatmap images
2) Results: Figure 2 shows the boxplot of similarities among the different versions of bzip2. The horizontal axis represents the different comparison algorithms, and the vertical axis represents the similarity values. The results show that the similarities among the different versions of bzip2 are quite high, with all values exceeding 0.75 and many close to 1.0. In the results, the lowest similarity is 0.77 between version 1.0.1 and 1.0.3 by Levenshtein similarity (Hungarian and topn (n = ∞)). Although this similarity is lower than the other comparison results, it is still sufficiently high to be considered as the same software. Comparing the three aggregation methods, the Hungarian algorithm provided the most discriminative results, capturing subtle differences between versions that were sometimes overlooked by the top-n methods. Given its mathematical rigor and sensitivity, we will focus on the results obtained via the Hungarian algorithm in the subsequent experiments.
we requested generative AI, Google Gemini to implement factorization, MD5, and SHA256 in C, Go, and Rust. The prompt to generative AI was ”Write the SPEC logic in LANGUAGE without standard libraries.” The italic words were replaced with the corresponding specification and language. Of course, there are many other famous programming languages. However, we chose C, Go, and Rust, since they can generate executables and are easy to implement. Moreover, the algorithms of bzip2, md5, and sha256 use many bit calculations, and thus are expected to have similar instruction sets and high similarities. On the other hand, the algorithm of factorization is implemented by trial division, which uses multiplication and remainder calculations, and no bit calculations. Therefore, it is expected to have a different instruction set and low similarities from the other three software. Next, we compile the obtained four software in three languages to arm64 Mach-O executables on macOS. We employ clang for C, go for Go, and rustc for Rust. No compile options were specified in any cases. Finally, we obtain 12 executables shown in Table II. Then, we apply the proposed birthmarking techniques to calculate the similarities among them. 2) Result: Figure 3 shows the similarity distributions as the heatmap among the targets shown in Table II. The horizontal axis and vertical axis of each figure represent the target shown
C. Credibility evaluation 1) Target software: This experiment evaluates differences of the birthmarks from the different software. For this purpose, we should choose software with the same purpose and different authors. Therefore, we first selected bzip2 as the target software8 . We also chose a Go implementation of bzip2 (bzip2go)9 . In addition, the author implemented a Rust version of bzip2 (bzip2rs) because none existed10 . On the other hand, we evaluate differences in birthmarks across programming language levels. For this, we should use the same algorithm in different languages. Therefore,
8 https://sourceware.org/git/?p=bzip2.git;a=summary (hash: af79253) 9 https://github.com/pedroalbanese/bzip2 (hash: 575eca0) 10 https://github.com/tamada/bzip2rs (hash: 6972810)
TABLE III: The target software for the resilience evaluation
Euclidean
LCS
Levenshtein
Cosine
0 0
0.2
0.4
Similarity
Weighted Jaccard 0.6
0.8
macOS
Jaccard
Simpson
Linux
0.2
Dice
Windows
0.4
OS
amd64
0.6
Arch.
amd64
0.8
amd64
Cumulative Probability
1
1
arm64
macOS
arm64
Linux Windows
in Table II, and the color of each cell is represented in Figure 4, which shows the similarity between the two targets. From Figure 3, the diagonal cells are all red, representing identical software (similarity 1). In contrast, red parts in the middle of Figure 3 correspond to the pairs of md5_gcc and sha256_gcc. This is because both algorithms involve many bit calculations and have similar opcode sets. Also, Figure 5 shows the chart of ECDF (Empirical Cumulative Distribution Function). The horizontal and vertical axes represent the similarity and the cumulative probability, respectively. From the figure, all of lines rise to about 0.8 under 0.4 similarity, which means that about 80% of the pairs have similarity less than 0.4. This result shows that the proposed birthmarks can capture the differences between different software, and thus the similarities between different software are quite low.
arm64
Fig. 5: ECDF of similarities between independent software.
D. Resilience evaluation 1) Target software: This experiment evaluates the similarities in the birthmarks produced by the same software compiled for different architectures and platforms. We employ bzip2 and its Go and Rust implementations as the target software, which is the same software as in Section V-C1. We compile bzip2 for macOS Mach-O, Linux ELF, and Windows PE in amd64 and arm64 architectures. Note that the number of functions in the source code is: 129 (bzip2), 5 (bzip2go), and 22 (bzip2rs) via ctags. We prepare the executables using clang and gcc for C, go and TinyGo11 for Go, and rustc for Rust. Note that bzip2rs has two features for compression: a pure Rust implementation and a delegate to libbz2. We chose one at compile time. In the Windows environment, we also use msvc (Microsoft Visual C++) for bzip2. Almost all compilations were performed in GitHub Actions12 . Also, we use Docker images (golang:1.26.3-bookworm and tinygo/tinygo:0.40.0) to compile bzip2go across all three platforms. Compiling bzip2rs was performed on the local macOS machine with zigbuild for linking13 . Specifically, for the Windows platform, we use xwin14 for bzip2rs on macOS, with target pcwindows-msvc for amd64 and arm64 architectures. Unfortunately, we could not compile bzip2go with TinyGo on Windows platform because it does not support Windows well.
Compiler clang gcc go tinygo rustc (pure) rustc (lib) clang gcc go tinygo rustc (pure) rustc (lib) clang gcc msvc go tinygo rustc (pure) rustc (lib) clang gcc go tinygo rustc (pure) rustc (lib) clang gcc go tinygo rustc (pure) rustc (lib) clang gcc msvc go tinygo rustc (pure) rustc (lib)
Version 21.0.0 14.3.0 1.26.3 0.40.0 1.95.0 1.95.0 14.0.0 13.3.0 1.26.3 0.40.0 1.95.0 1.95.0 19.1.5 15.2.0 14.44 1.26.3 — 1.95.0 1.95.0 21.0.0 14.3.0 1.26.3 0.40.0 1.95.0 1.95.0 21.1.8 15.2.0 1.26.3 0.40.0 1.95.0 1.95.0 19.1.5 15.0.1 14.44 1.26.3 — 1.95.0 1.95.0
File size 115,768 107,720 3,221,776 526,808 2,420,576 2,409,496 252,936 307,104 3,293,291 1,706,784 2,180,616 2,169,688 885,760 359,898 104,960 3,277,312 N/A 5,268,480 5,237,248 129,240 129,320 3,095,906 546,352 2,267,184 2,264,000 276,400 335,912 3,235,563 1,928,896 1,879,272 1,859,128 664,576 566,310 101,376 3,062,272 N/A 4,332,032 4,304,896
#Func. 63 67 2,559 576 3,413 3,369 68 75 2,572 701 3,387 3,337 2,098 111 134 2,326 22,767 22,232 64 69 2,518 989 3,336 3,331 70 83 2,514 1,213 3,382 3,331 2,597 107 130 1,739 19,921 19,480
In addition, in macOS environment, gcc is actually clang. Therefore, we should install it explicitly to use the actual gcc15 . The resulting 36 executables are shown in Table III, which also includes their file sizes, the compilers used, their versions, and the number of functions in the Oinkie-IR (birthmarks). The number of bzip2 functions is reduced after compiling and lifting, which may cause inline expansion or unused functions. Besides, clang, TinyGo, and rustc use LLVM, while gcc, msvc, and go rely on distinct backend technologies. This is reflected in the file sizes in Table III. Go’s feature-rich runtime yields the largest executables, followed by TinyGo’s garbage-collected runtime. Rust’s thin runtime and C’s lowlevel nature result in smaller binaries. Ideally, the compiler versions should be the same across all platforms, however, due to the complexity of preparing, we could not achieve that. Then, we apply the proposed birthmarking techniques to calculate their similarities. 11 https://tinygo.org 12 https://github.com/tamada/2026snpd tamada experiments 13 https://github.com/rust-cross/cargo-zigbuild 14 https://github.com/rust-cross/cargo-xwin 15 see the version information of gcc on macOS environment.
1
0.6 0.4
0.9 0.8 0.7
Cumulative probability
0.8
amd64
1
Cosine Dice Euclidean Jaccard LCS Levenshtein Simpson Weighted-Jaccard
0.2
0.6 0.5 0.4 0.3 0.2 0.1 0 0
0 0
0.2
0.4
arm64
0.6
0.8
1
Fig. 6: Scatter plot of similarities between different architectures (r = 0.9846). 2) Result I: Cross-architecture: First, we evaluated the impact of architectural differences by examining whether relative similarity rankings are preserved across architectures (i.e., whether a pair with high similarity on amd64 also shows high similarity on arm64). Figure 6 shows the correlation between these similarities; the horizontal axis represents amd64 pairs, and the vertical axis represents the corresponding arm64 pairs (correlation coefficient r = 0.9846, p < 0.0001). This result suggests that the proposed birthmark focuses on aspects closer to the essence of the algorithm, such as data flow and types of operations, rather than physical operations like register names or stack manipulations. However, this may also depend on the decompilation performance of Ghidra. 3) Result II: Analysis of Platform-Specific Anomalies: To examine the overall trends, Figure 7 shows ECDF plots for cross-arch, cross-os, cross-compiler, and cross-language, using cosine similarity to normalize for instruction count variations, focusing on the absolute similarity levels rather than the relative rankings examined in Section V-D2. The horizontal axis in Figure 7 represents similarity, and the vertical axis represents the cumulative proportion up to that similarity. Furthermore, cross-X uses the average of pairs where only X differs from the overall comparison. From Figure 7, Cross-Arch rises after 0.5 and increases sharply after 0.75. This indicates that the minimum similarity for Cross-Arch is 0.5, and that most cases have a similarity of 0.75 or higher. On the other hand, Cross-OS and Cross-Compiler exhibited an anomalous bimodal distribution, with similarity rising sharply at both 0.2 and 0.7. Upon investigating this “gap,” it was found that the group with low similarity consisted entirely of comparisons involving the Windows platform. For example, the similarity for clang (Linux vs. Win) was a mere 0.03. The root cause lies in the explosive increase in the number of functions, shown in Table III. The Windows version of clang contained 2,098 functions, whereas the Linux version had only 68. This surge in functions, caused by the static linking of the C runtime library and system stubs, triggered a severe “dilution effect” in the Hungarian method, causing bzip2’s core logic to be buried under thousands of non-matching library functions. This bimodal pattern also extends to Cross-Compiler com-
0.2 Cross-Arch
0.4 Cross-OS
0.6 Similarity Cross-Compiler
0.8
1
Cross-Language
Fig. 7: ECDF of cross-factor using cosine similarities. 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 Rust (libbz2) vs Rust (libbz2) vs Rust (Pure) vs Rust (libbz2) vs Rust (Pure) vs Rust (Pure) Clang Clang Gcc Gcc
Fig. 8: Box plot of the similarities among Rust and C implementations parisons restricted to the Windows platform (e.g., Windowsclang vs. Windows-gcc), since clang’s extensive function inflation dilutes its birthmark regardless of the comparison target’s origin. Furthermore, this noise caused an unexpected reversal: Windows-clang exhibited a higher similarity (0.74) to Go (Linux) than its own Linux-clang counterpart. This reversal can be explained by the comparable degree of dilution—both Windows-clang (2,098 functions) and LinuxGo (2,572 functions) contain a similarly large number of functions, whereas Linux-clang (68 functions) does not, so the apparent similarity likely reflects comparable noise levels rather than genuine logical commonality. This suggests that environmental noise can override the characteristics of compilers and languages, implying that in certain environments, noise-robust aggregation methods such as top-n selection are necessary. 4) Result III: Analysis of Language Barrier (Rust vs. C): As shown in the ECDF (Fig. 7), the “Cross-Language” category exhibits the lowest similarity among all categories, indicating that the choice of programming language is the most dominant factor in birthmark variation. To evaluate this barrier, we analyzed the similarities between C and Rust implementations using four compiler/feature sets: rustc (lib), rustc (pure), clang, and gcc. The results are shown in Fig. 8. As predicted by the ECDF, inter-language similarities remained consistently low, ranging from 0.1 to 0.3. Notably, even the Rust implementation utiliz-
1 0.9 0.8 0.7 0.6 0.5
1 0.9 0.8 0.7 0.6 0.5
1 0.9 0.8 0.7 0.6 0.5
0.4 0.3 0.2 0.1 0
0.4 0.3 0.2 0.1 0
0.4 0.3 0.2 0.1 0
0
0.2
0.4 C
0.6 Go
0.8
1
0
0.2
Rust
0.4 C
(a) Dice
0.6 Go
0.8
0
1
(b) Jaccard 1 0.9 0.8 0.7 0.6 0.5
0.4 0.3 0.2 0.1 0
0.4 0.3 0.2 0.1 0
0.4 0.3 0.2 0.1 0
0.4 C
0.6 Go
0.8
0
1
0.2
(d) Euclidean 1 0.9 0.8 0.7 0.6 0.5
0.4 0.3 0.2 0.1 0
0.4 0.3 0.2 0.1 0
0.2
0.4 C
0.6 Go
Rust
(g) Cosine
0.6 Go
0.8
1
Rust
0.8
1
0
0.2
0.4 C
0.8
1
0.8
1
Rust
0.2
0.4
0.6 Go
Rust
(f) Levenshtein
0.6 Go
0
C
(e) LCS
1 0.9 0.8 0.7 0.6 0.5
0
0.4 C
Rust
0.6 Go
(c) Simpson
1 0.9 0.8 0.7 0.6 0.5
0.2
0.4 C
1 0.9 0.8 0.7 0.6 0.5
0
0.2
Rust
0.8
1
Rust
(h) Weighted Jaccard
Fig. 9: Scatter plots of similarities across different operating systems and compilers.
ing the C-based libbz2 library failed to show high similarity to the original C binaries. This confirms that the distinct runtime environments and memory management mechanisms of each language dominate the resulting binary structure, overriding the underlying logical commonality. While intralanguage similarities remain high (median was approximately 0.626), overcoming the cross-language barrier remains a significant challenge. 5) Result IV: Comparative Analysis of Comparison Algorithms: To evaluate the robustness and discriminative power of the eight comparison algorithms, we visualized the similarities of inter-OS pairs (horizontal axis) and inter-compiler pairs (vertical axis) as scatter plots in Fig. 9. In these plots, the upper-right quadrant represents high resilience to both operating system and compiler variations. Rust (diamonds) is distributed along the top of the plots. It forms two distinct clusters: one in the upper-right (Unix-toUnix comparisons) and another in the upper-left (Windowsto-Unix comparisons), indicating high compiler resilience but persistent OS sensitivity. Go (triangles) is clustered in the lower-right quadrant, showing high stability across OSes but weakness against compiler differences (Go vs. TinyGo). In contrast to Rust and Go, C (circles) is distributed across all four quadrants. This diversity indicates that C birthmarks are highly sensitive to the specific combination of OS and
compiler; while Unix-based C binaries show high resilience in the upper-right, any comparison involving the Windows environment inevitably falls into the lower-left corner due to the dilution effect. Set-based methods (Dice, Jaccard, Simpson) and Cosine similarity exhibited more pronounced patterns than others, preserving clear clusters by focusing on logical orientation or set overlap; Cosine similarity was notably resilient to proportional changes in instruction counts. In contrast, sequence-based methods (Euclidean, LCS, Levenshtein) and Weighted Jaccard yielded more conservative, lower scores, being highly sensitive to instruction order or frequency variations across compiler backends. Among all tested algorithms, the Simpson index demonstrated the highest discriminative power, with dots most clearly clustered toward the corners of the plot. VI. D ISCUSSION A. Computational Efficiency and Algorithm Selection The experimental results highlight a significant trade-off between the precision of comparison algorithms and their computational overhead. We conducted the experiments on an Apple MacBook Air M5 with 32GB of unified memory (macOS 26.5.1). As described in Section V-A, the number of comparisons increases quadratically with the number of
binaries (n C2 + n). For the robustness evaluation (36 binaries, 666 comparisons), set-based algorithms completed within approximately 8 hours. In contrast, sequence-based algorithms like Levenshtein and LCS required approximately 56 hours. This significantly higher cost is due to their O(L2 ) complexity per pair, where L denotes the maximum opcode sequence length. Despite the higher cost, sequence-based methods did not show a proportional increase in discriminative power for our Oinkie-IR-based birthmarks. In fact, set-based methods such as Simpson and Jaccard demonstrated a clearer separation between similar and dissimilar pairs. For practical cases, we recommend a tiered approach: employing set-based methods for rapid initial screening and reserving sequence-based methods for deep verification of high-similarity candidates. B. Cross-Platform Robustness and Practical Implications The high correlation coefficient (0.9846) observed in our cross-architecture experiments (Section V-D2) provides empirical evidence that Oinkie-IR-based birthmarking effectively abstracts away low-level ISA differences. By focusing on data flow and operation types in Ghidra’s P-code, the birthmarks capture the software’s underlying logic. This resilience suggests that our method is viable for real-world scenarios, such as detecting software plagiarism or license violations across different operating systems and CPU architectures. C. Threats to Validity 1) Internal Validity: A potential threat lies in our use of AI-generated code (from Google Gemini) as a proxy for independent software in the credibility evaluation. There is a concern that LLMs might produce similar code for identical prompts, potentially inflating similarity scores. However, our results consistently showed low similarity between AIgenerated samples and original implementations, indicating that the birthmarks are sensitive to implementation-level differences even when functional requirements are identical. 2) External Validity: Our evaluation was limited to the bzip2 utility and its variants. While bzip2 is a standard benchmark for birthmarking, the results may not generalize to GUI-heavy applications, kernel-level code, or software with heavy obfuscation. 3) Construct Validity: The stability of the birthmarks depends on the quality of the binary lifting and the environmentspecific binary structure. The observed drop in similarity when using clang on Windows (Section V-D3) is primarily attributed to the proliferation of library-derived functions, which dilute the logical birthmarks of the target software. This indicates that the current birthmarking process is sensitive to the surrounding environment and runtime libraries. Further investigation into normalizing P-code and implementing automated library code filtering is required to enhance the resilience of the Oinkie-IR against such environmental noise. VII. C ONCLUSION This paper evaluated IR-based cross-platform birthmarking via binary lifting. Experiments confirm that the method
provides high similarity for identical logic and exceptional consistency across CPU architectures (r = 0.9846), abstracting away ISA-specific details. While programming language remains a significant barrier, we identified that environmental noise on platforms like Windows causes a “dilution effect” that degrades similarities. Analysis of eight algorithms shows that set-based methods, especially the Simpson index, offer superior discriminative power by isolating logical commonality from such noise. While highly effective for cross-architecture analysis, IR-based birthmarking requires further improvements in cross-language robustness. Future work will focus on automated library filtering to mitigate environmental impacts and optimizing similarity computations for enhanced scalability. R EFERENCES [1] H. Tamada, M. Nakamura, A. Monden, and K. Matsumoto, “Java birthmarks —detecting the software theft —,” IEICE Transactions on Information and Systems, vol. E88-D, no. 9, pp. 2148–2158, Sept. 2005. [2] S. Nazir, S. Shahzad, and N. Mukhtar, “Software birthmark design and estimation: A systematic literature review,” Arabian Journal for Science and Engineering, vol. 44, no. 4, pp. 3342–3387, Jan. 2019. [3] C. Lattner and V. Adve, “LLVM: A compilation framework for lifelong program analysis & transformation,” in Proc. International Symposium on Code Generation and Optimization (CGO 2004), 2004, pp. 75–86. [4] Microsoft Corporation, “Microsoft portable executable and common object file format specification,” 1999. [Online]. Available: https: //learn.microsoft.com/en-us/windows/win32/debug/pe-format [5] Apple Inc., “Mach-O runtime architecture,” 2004. [Online]. Available: https://math-atlas.sourceforge.net/devel/assembly/MachORuntime.pdf [6] T. Committee, “Tool interface standard (TIS) executable and linking format (ELF) specification,” 1995. [Online]. Available: https://refspecs. linuxfoundation.org/elf/elf.pdf [7] G. Myles and C. Collberg, “k-gram based software birthmarks,” in Proc. 2005 ACM Symposium on Applied Computing (SAC ’05), 2005, pp. 314– 318. [8] I. U. Haq and J. Caballero, “A survey of binary code similarity,” ACM Computing Surveys, vol. 54, no. 3, pp. 1–38, 2021. [9] S. Eschweiler, K. Yakdan, and E. Gerhards-Padilla, “discovre: Efficient cross-architecture identification of bugs in binary code,” in Proc. 23rd Annual Network and Distributed System Security Symposium (NDSS 2016), 2016. [10] M. Chandramohan, Y. Xue, Z. Xu, Y. Liu, C. Y. Cho, and H. B. K. Tan, “BinGo: Cross-architecture cross-OS binary search,” in Proc. 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE 2016), 2016, pp. 678–689. [11] H. He, X. Lin, Z. Weng, R. Zhao, S. Gan, L. Chen, Y. Ji, J. Wang, and Z. Xue, “Code is not natural language: Unlock the power of semanticsoriented graph representation for binary code similarity detection,” in Proc. 33rd USENIX Security Symposium, 2024. [12] J. Nakamura and H. Tamada, “mituba: Scaling up software theft detection with the search engine,” in Proc. International Conference on Software Engineering and Information Management (ICSIM 2018), 2018, pp. 6–10. [13] National Security Agency, “BSim: Ghidra behavioral similarity,” 2023. [14] N. Fedorov, H. Tamada, H. Inayoshi, and A. Monden, “Comparison of similarity functions for n-gram software birthmarks,” in Proc. 6th World Symposium on Software Engineering (WSSE 2024), Dec. 2024, pp. 169–176. [15] H. W. Kuhn, “The hungarian method for the assignment problem,” Naval Research Logistics Quarterly, vol. 2, no. 1-2, pp. 83–97, 1955. [16] R. Jonker and A. Volgenant, “A shortest augmenting path algorithm for dense and sparse linear assignment problems,” Computing, vol. 38, no. 4, pp. 325–340, 1987. [17] T. Yokoi and H. Tamada, “Improvement of the dynamic software birthmark process by reducing the time of the extraction,” International Journal of Networked and Distributed Computing, vol. 6, no. 4, pp. 224–231, Sept. 2018.