1
PLC-Bin2Src: Retrieving Corresponding Structured Text Source Files for PLC Binaries
arXiv:2609.08563v1 [cs.SE] 8 Sep 2026
Ang Jia, Yaxin Duan, He Jiang, Ming Fan, Zhilei Ren, and Xiaochen Li Abstract—Software reuse allows existing components and third-party libraries to be incorporated into new applications, but binary-only components can obscure their origins and implementations. Software composition analysis seeks to identify these reused components and trace their provenance, supporting dependency inventory, vulnerability assessment, and security auditing. For PLC applications, binary2source matching provides a core link in this analysis: given an opaque PLC binary artifact, retrieve its corresponding Structured Text (ST) source file from a collected source repository. However, this task is complicated by cross-platform compilation heterogeneity, the representation gap between PLC binaries and ST source code, and the granularity mismatch between recovered binary units and ST source files. This paper presents PLC-Bin2Src, a cross-platform binary2source matching framework for retrieving corresponding ST source files for binaries produced by CODESYS, GEB, OpenPLC v2, and OpenPLC v3. Platform-aware frontends construct comparable representations, and a shared backend equally combines control–data flow graph (CDFG), function call graph (FCG), and recovered-symbol similarities to rank source candidates. We evaluate PLC-Bin2Src on PLC-BEAD. Results show that PLC-Bin2Src achieves 95.89% Recall@1, 99.66% Recall@5, and an MRR of 0.9769 across four PLC platforms. Index Terms—PLC, Structured Text, Binary2Source Matching, Software Composition Analysis
✦
1
I NTRODUCTION
P
ROGRAMMABLE logic controllers (PLCs) are core execution components of industrial automation systems. By cyclically reading field inputs, executing control logic, and updating actuators, deployed PLC programs directly shape the behavior of physical processes [1], [2]. Software reuse allows PLC developers to incorporate existing components and third-party libraries into control applications. However, some reused libraries are delivered only in compiled form. For example, CODESYS supports compiled-library packages and recommends this form for library delivery; downstream developers can therefore integrate such packages without access to their source code or implementation details [3], [4]. Such binary-only reuse makes it difficult for downstream analysts to determine which components have been incorporated, what logic they implement, and where they originate. Software composition analysis addresses this visibility problem by identifying reused components and linking them to known source implementations. However, existing PLC binary reverse engineering frameworks, such as ICSREF [2] and PLC-BinX [5], only focus on reconstructing executable structure and control semantics from proprietary artifacts. They do not identify which ST source file corresponds to a binary artifact. Therefore, a binary2source matching framework is needed to retrieve the corresponding source implementations, supporting dependency inventory, vulnerability assessment, provenance tracing, and security auditing [6]–[8]. Different from the conventional binaries, PLC software is commonly written in Structured Text (ST), whereas executable artifacts are generated by platform-specific toolchains.
Corresponding author: He Jiang. E-mail: [email protected]. Ang Jia, Yaxin Duan, He Jiang, Zhilei Ren, and Xiaochen Li are with the School of Software, Dalian University of Technology, Dalian, China. Ming Fan is with the School of Cyber Science and Engineering, Xi’an Jiaotong University, Xi’an, China.
Fig. 1 illustrates the cross-platform representation gap and the source–binary semantic gap using ACOSH.ST from PLC-BEAD [9]. Binaries generated from this ST program yield three different ARM-level views: OpenPLC v3 exposes floating-point instructions and typed runtime calls; CODESYS v3 compiles SQRT to a floating-point square-root instruction and invokes REAL32__LN indirectly; and GEB combines floating-point operations with gebx math calls and geb_hook. Thus, even with the instruction set architecture held constant, instruction context, call targets, and recovered boundaries differ across platforms and share little surface syntax with ST. In summary, binary2source matching for PLC software presents three critical challenges: 1)
2)
3)
Cross-platform compilation heterogeneity. PLC platforms differ in binary formats, compilation toolchains, and runtime organization, so the same ST logic can yield different function boundaries, instruction patterns, and call structures. Binary–source representation gap. Compilation lowers high-level ST syntax, typed variables, and structured control constructs into machine instructions, memory accesses, temporary values, and runtime calls. File-level granularity mismatch. The logic of one ST file may be split or reorganized across recovered functions, wrappers, and slices, leaving no one-toone correspondence between recovered binary units and ST source files.
To address these challenges, we propose a binary2source matching framework named PLC-Bin2Src for PLC binaries. PLC-Bin2Src first uses platform-aware binary frontends and an ST-to-C source frontend to recover comparable representations across the four platforms. It then applies crossrepresentation normalization and constructs aligned CDFG and FCG channels for control–data relationships and call
2
(a) ST source file
(b) OpenPLC v3 binary
(c) CODESYS v3 binary
(d) GEB binary
ACOSH.ST
ACOSH @ 0x000410B4
ACOSH @ 0x00022050
dt_FN_ACOSH_exec @ 0x00011214
VMUL.F32 S15, S15, S15 VSUB.F32 S15, S15, S14 BL SQRT__REAL__REAL VADD.F32 S15, S14, S15 BL LN__REAL__REAL VSTR S0, [FP, #-0xC]
VMUL.F32 S16, S16, S17 VLDR S17, [PC, #0x60] ; 1.0 VSUB.F32 S16, S16, S17 VSQRT.F32 S16, S16 VLDR S17, [SL, #8] ; X VADD.F32 S16, S16, S17 ...
VMUL.F32 S15, S15, S15 VSUB.F32 S15, S15, S14 BL gebx_SQRT_REAL VADD.F32 S15, S14, S15 BL gebx_LN_REAL BL geb_hook
FUNCTION ACOSH : REAL VAR_INPUT X : REAL; END_VAR ACOSH := LN(SQRT( X * X - 1.0) + X); END_FUNCTION
MOV PC, R6 ; REAL32__LN • Program/function identifiers
• Key semantic operations
Fig. 1. Four views of ACOSH.ST: (a) ST source; (b) OpenPLC v3 ARM disassembly; (c) CODESYS v3 ARM disassembly; and (d) GEB ARM disassembly.
structures, together with a Symbols channel that aggregates lexical clues independently of graph topology. Finally, PLCBin2Src organizes function- and slice-level features into filelevel documents and uses fixed equal-weight fusion to rank the source repository. We evaluate PLC-Bin2Src on PLC-BEAD [9]. The results show that PLC-Bin2Src yields 95.89% Recall@1, 99.66% Recall@5, and an MRR of 0.9769 when retrieving corresponding ST source files for PLC binaries compiled on four platforms: CODESYS, GEB, OpenPLC v2, and OpenPLC v3. The main contributions of this paper are as follows: •
•
•
To the best of our knowledge, PLC-Bin2Src is the first binary2source matching framework for retrieving source programs for PLC binaries. PLC-Bin2Src proposes a multi-channel semantic representation comprising CDFG, FCG, and recoveredsymbol representations, and equally fuses their similarities to rank candidate ST files. We evaluate PLC-Bin2Src on PLC-BEAD. It achieves 95.89% Recall@1, 99.66% Recall@5, and an MRR of 0.9769 across the four platforms.
2
BACKGROUND
2.1
PLC Program Model and Compilation Process
PLCs typically execute control tasks according to a cyclic scan mechanism, including reading field inputs, running user control logic, and updating outputs [10]. The IEC 61131-3 standard specifies PLC programming languages and their program organization. ST is a textual language suitable for expressing conditional decisions, loops, numerical operations, and function calls. An ST program consists of program organization units (POUs), including PROGRAM, FUNCTION, and FUNCTION_BLOCK, and different POUs jointly describe control logic through variable access and function calls [1]. PLC source code must be transformed by a platform compilation toolchain into a binary that can execute on the controller. In OpenPLC, for example, MATIEC translates an IEC 61131-3 program into equivalent C code, which a native compiler then converts into an executable for the target platform [11]. Compilation introduces wrapper functions, cyclic scheduling, variable-access interfaces, temporary values, and runtime support logic. Disassembly can recover low-level arithmetic and calls, but source logic remains distributed across user functions, wrappers, and the
cyclic execution chain; this file-level granularity mismatch motivates binary2source matching. 2.2
Cross-Platform Differences in PLC Binaries
PLC platforms vary in binary format, target architecture, compilation toolchain, runtime organization, and symbolnaming rules [5], [9], [12]. Fig. 1 illustrates these differences using the same ACOSH.ST program. Panel (a) expresses the computation as a nested ST expression. In panel (b), OpenPLC v3 exposes ARM floating-point instructions together with typed mathematical runtime calls. Panel (c) shows the CODESYS v3 ACOSH code area: multiplication, subtraction, square root, and addition remain visible as floating-point instructions, while REAL32__LN is reached through an indirect call. Panel (d) shows that GEB retains related floating-point operations but uses gebx runtime calls and an additional hook. Thus, the same source program yields different function contexts, call targets, memory-access forms, and recoverable semantic units across platforms. The comparison also shows that surface-level similarity is not a reliable cross-platform signal. OpenPLC uses typed runtime calls, GEB uses gebx calls and a hook, and CODESYS combines a hardware square-root instruction with an indirect logarithm call. Binary2source matching must therefore localize the code regions that carry user control logic and normalize operations, calls, and identifiers from platform-specific representations before comparing them with ST source files.
3
M ETHOD
PLC-Bin2Src models binary2source matching as a sourcecandidate ranking problem. Fig. 2 summarizes its three stages: preprocessing, representation construction, and similarity calculation. The preprocessing stage recovers binaryside core functions, transforms source-side ST programs, and normalizes both representations. The representationconstruction stage builds control–data flow graph (CDFG), function call graph (FCG), and recovered-symbol features, converts them into term frequency–inverse document frequency (TF-IDF) vectors, and shows the three channels in blue, green, and orange, respectively. The similaritycalculation stage computes channel-wise cosine similarities, combines them with fixed equal weights, ranks every compatible ST file, and returns the top-k candidates. In the figure,
3
Input
Preprocessing Binary frontend
Representation Construction CDFG Binary-side
…
Disassembly
PLC binary
𝑆𝑐𝑑𝑓𝑔 𝑆𝑓𝑢𝑠𝑒𝑑
TF-IDF vector …
Core function extraction
∗ 𝑤𝑐𝑑𝑓𝑔
Decompilation
FCG Binary-side
TF-IDF vector …
Cosine similarity
𝑆𝑓𝑐𝑔 ∗ 𝑤𝑓𝑐𝑔 Top-k candidate selection
Σ
TF-IDF
Normalization
TF-IDF vector
Source-side
ST source
Weighted similarity
Cosine similarity
TF-IDF Source-side
C
Similarity Calculation
TF-IDF vector
…
Source frontend Rank 1
Core function extraction
∗ 𝑤𝑠𝑦𝑚𝑏𝑜𝑙
Symbol
ST → C Binary-side
TF-IDF vector …
Recovered Symbol
ST-to-C conversion
Recovered Symbol
Source-side ST
C
Cosine similarity
𝑆𝑆𝑦𝑚𝑏𝑜𝑙
TF-IDF
Rank 2 Rank 3 …
TF-IDF vector
Function Name
Rank k
…
Function Name
Fig. 2. Overview of the PLC-Bin2Src workflow.
Scdfg , Sfcg , and Ssymbol denote the three channel similarities; the corresponding w terms are all fixed at 1/3; and Sfused denotes the resulting score used for ranking. 3.1
Preprocessing
Fig. 3 illustrates how the two frontends transform ACOSH into comparable representations. The source frontend converts the ST program into a C representation, while the binary frontend extracts and decompiles core functions to obtain a C-like representation. In the figure, the upper and lower parts show source-side and binary-side processing, respectively; blue identifies program units and core functions, red highlights operations and calls traceable across representations, and ellipses indicate omitted auxiliary code. 3.1.1
Binary Frontend
The binary frontend extracts function-level representations related to user control logic from binaries produced by different PLC platforms. It comprises disassembly, corefunction extraction, and decompilation. The lower part of Fig. 3 shows the resulting representation for ACOSH. Disassembly: The system parses deployment artifacts and recovers the function identifiers, address ranges, and program structures required for core-function extraction. For OpenPLC and GEB ELF files, it obtains function names, boundaries, basic blocks, and call relationships from standard binary structures and disassembly. A CODESYS .app file is a proprietary application container without the header and section table of a standard ELF file, so it requires a different process. For CODESYS, the binary frontend uses executable ranges, instructions, basic blocks, control-flow edges, call
Source frontend (a) ST source file
(b) Source-side C representation
FUNCTION ACOSH:REAL VAR_INPUT X : REAL; END_VAR ACOSH := LN(SQRT(X*X-1.0)+X); END_FUNCTION
REAL ACOSH(..., REAL X){ ... ACOSH = LN__REAL__REAL(true, NULL, (REAL)(SQRT__REAL__REAL(true, NULL, (REAL)((X*X)-1.0))+X)); ...}
PROGRAM program0 VAR LocalVar0 : REAL; LocalOUT : REAL; END_VAR LocalOUT := ACOSH(LocalVar0); END_PROGRAM
void PROGRAM0_body__(...){ ... guarded_assign(..., ACOSH( true, NULL, (REAL)data__->LOCALVAR0 )); ...}
Binary frontend (c) Binary-side disassembly
(d) Binary-side C-like representation
PROGRAM0_body__ @ 0x00039978 ... 0x399A0 FLDS S15, [R3] 0x399B0 BL ACOSH 0x399BC FSTS S15, [R3,#8] ... ACOSH @ 0x000397FC ... 0x39858 FMULS S15,S15,S15 0x39860 FSUBS S15,S15,S14 0x39870 BL SQRT__REAL__REAL 0x3987C FADDS S15,S14,S15 0x3988C BL LN__REAL__REAL
int __fastcallPROGRAM0_body__(...){ ... if ( !(*(_BYTE *)(result + 12) & 2) ){ ... result = ACOSH(1, 0, a3); } } int __fastcallACOSH(..., float a3){ ... if ( (_BYTE)result ) { SQRT__REAL__REAL(1u, 0, a3); result = LN__REAL__REAL(1u, 0, v3); ... } }
Function/POU identifiers
Key operations and calls
Fig. 3. Source-side and binary-side frontend processing for ACOSH.
4
relationships, and metadata-linked POU names recovered by PLC-BinX as inputs [5]. The resulting boundaries, address ranges, and POU-name clues support subsequent CODESYS core-function extraction. Core-function extraction: Based on the recovered information, PLC-Bin2Src follows the core-function extraction method of PLC-BinX [5] and applies platform-specific rules. For OpenPLC, it retains the cyclic-execution wrapper and user functions. For GEB, it selects program-, function-, and function-block execution routines according to the dt_PR_*_exec, dt_FN_*_exec, and dt_FB_*_exec naming patterns. For CODESYS, it associates metadatalinked entry pointers with recovered function ranges and uses structural and cross-sample repetition evidence to identify POU execution candidates while reducing the priority of common templates and runtime routines. The extracted core functions are then passed to the decompilation stage. Decompilation: After core-function extraction, PLCBin2Src generates C-like representations for all platforms. For OpenPLC and GEB, target functions are selected from ELF function information and directly decompiled. For CODESYS, POU execution candidates are first recovered from function boundaries, disassembly, recovered symbols, and call information; the selected address ranges are then decompiled while preserving the associations among POU roots, helper functions, and related calls. 3.1.2 Source Frontend The source frontend transforms ST programs into functionlevel representations that can be compared with the binaryside representations. PLC-Bin2Src does not directly match raw ST text, but instead performs two steps in sequence: ST-to-C conversion and core-function extraction. The upper part of Fig. 3 shows the conversion result of ACOSH from ST source code to a C representation. ST-to-C conversion: For each ST source sample, PLCBin2Src reads the source program on a per-sample basis and uses the MATIEC compiler [11] to generate a C-style representation. It then uses a C preprocessor to resolve macros, variable-access wrappers, and conditional-compilation structures in the generated code, obtaining effective C code after macro replacement and conditional selection. Core-function extraction: From the generated C-like representation, the system extracts functions that represent user control logic. It excludes program0, initialization routines, and platform-support functions such as copy, print, and dump; it prioritizes the function or function-block body whose name corresponds to the current sample. When name clues are insufficient, the *_body__ body generated by the compilation toolchain is retained as a candidate, keeping the source-side representation focused on user control logic. 3.1.3 Normalization The source-side C representation and the binary-side Clike representation differ in variable names, temporary variables, type conversions, memory accesses, and libraryfunction names. Before representation construction, PLCBin2Src applies consistent normalization to both sides: it unifies Boolean values, constants, and null-pointer forms; eliminates numerical type suffixes and redundant type conversions; normalizes local variables and memory accesses;
and maps platform-specific mathematical functions and primitive-operation calls to unified semantic labels. For GEB, the system also filters runtime hooks and common-library noise on the binary side so that the two representations retain comparable control, data, and call semantics. 3.2
Representation Construction
After obtaining normalized function-level representations, PLC-Bin2Src does not rely on a single retrieval signal. Instead, it constructs the CDFG and FCG channels to capture intraprocedural and interprocedural structure, respectively. The Symbols channel separately summarizes recoveredsymbol and identifier evidence without encoding graph topology. 3.2.1 CDFG The CDFG channel describes control and data semantics within functions. A control-flow graph (CFG) characterizes program execution transitions, whereas a data-flow graph (DFG) describes variable definitions and uses and the propagation of operation results. A CDFG jointly expresses control and data relationships within the same structure [13], [14]. On this basis, PLC-Bin2Src constructs a task-oriented CDFG for binary2source matching. The conditions, operations, calls, variables, and dependencies available after preprocessing are organized around the extracted core functions to form function-level CDFG representations. On the basis of the normalized representations, PLCBin2Src extracts semantic events such as conditional decisions, loop control, assignment statements, function calls, memory reads and writes, and arithmetic expressions from the C-like representations and constructs CDFGs accordingly. The graph mainly includes three types of nodes: •
•
•
Operation nodes: program events such as conditional branches, loops, assignments, function calls, and returns; Arithmetic nodes: expression operations such as addition, subtraction, multiplication, division, comparison, and logical operations; Data nodes: local variables, memory objects, and constants.
Directed edges between nodes record control and data semantics: •
•
Control relationships describe conditional constraints and the local execution order of semantic events within a function; Data relationships describe propagation from variables or constants to arithmetic nodes, from operation results to subsequent operations, and from return values to target variables.
For function calls, the system further recovers call nodes and their argument order from the expression syntax structure, connects explicit variable definitions to subsequent uses, and, when determinable, establishes propagation relationships from call return values to temporary variables or return targets. Consecutive calls and their local execution order are also encoded as structural features so that call–data relationships recoverable on both the binary and source sides are retained.
5 a Binary-side CDFG
b Source-side CDFG
ACOSH
ACOSH
PROGRAM
X
PROGRAM
1
1
ACOSH
ACOSH
2
2
a3 (X) MUL
CALL SQRT
LIB 1.0
v3
LIB
SUB
CALL SQRT
Fig. 5. Binary-side and source-side function-call graphs of ACOSH.
CALL LN X
ADD
result CALL LN RET
acosh RET PROGRAM0_body__
PROGRAM program0 <root>
a3 (LocalVar0) CALL ACOSH SLOT0.value (LocalOUT)
data dependency
LocalVar0
<root>
CALL ACOSH LocalOUT
Using the core functions and call information obtained during preprocessing, PLC-Bin2Src constructs an FCG for each normalized binary- and source-side representation. It uses the program entry or extracted core function as the root semantic node and derives structural features from its callees, call relationships, and auxiliary-function roles. The FCG simultaneously encodes call topology and normalized function roles. Call edges are derived from direct or statically resolved indirect call relationships in the normalized function-level representations. Node labels use unified roles such as PROGRAM, CORE, LIB, and HELPER.
control flow
Fig. 4. Binary-side and source-side CDFG subgraphs of ACOSH.
After graph construction, PLC-Bin2Src converts the available control, data, and call items into CDFG documents. When statement-level graph structure is recoverable, it performs two iterations of Weisfeiler–Lehman graph kernel (WL) relabeling [15] and extracts first- to third-order token n-grams to describe local subgraph patterns and consecutive operation order. It further records recoverable call-related structures, including call nodes, arguments, definition–use relationships, and call sequences. All documents then enter the same CDFG channel and are mapped into a common feature space during vectorization. In Fig. 4, we select representative nodes and dependency edges to show the local CDFG semantic subgraphs formed around the core computation and function calls on the binary and source sides of ACOSH. Panels (a) and (b) correspond to the binary and source sides, respectively. The source side retains a relatively complete arithmetic hierarchy of the expression, whereas the binary side reflects the call results, temporary variables, and return-value propagation relationships that can be recovered during decompilation. Red edges indicate data dependencies, blue edges indicate control flow or local execution order, and <root> marks the program-entry node. 3.2.2 FCG The FCG channel describes the call organization among program units. Nodes represent functions, edges represent direct call relationships, and node labels distinguish roles such as program entries, core functions, library functions, and auxiliary functions [16]. Fig. 5 presents the call relationships on the binary and source sides of ACOSH. The left and right graphs show the binary and source sides, respectively; PROGRAM and LIB denote the program-entry and libraryfunction roles, and the numbers denote direct-call counts.
3.2.3 Symbols The Symbols component constructs an independent lexical summary from function names and related identifiers that can be extracted from source code and binaries. Unlike CDFG and FCG, this channel does not encode operations, dependencies, or call topology. For PLC binaries that have not been stripped or that retain partial symbol clues, such evidence can directly support binary2source matching [17]. The Symbols channel extracts recovered-symbol labels and related identifiers from the normalized binary and source representations, then maps them to semantic roles using associations provided by preprocessing. It excludes items assigned generic roles such as PROGRAM, INIT, and RUNTIME and generates two feature types, NAME_LABEL and NAME_ROLE. Local-variable names and ordinary syntactic identifiers are not used as the primary recovered-symbol evidence. For example, the binary-side and source-side Symbols documents for ACOSH each contain one occurrence of NAME_LABEL:ACOSH, which records the recovered function identity, and one occurrence of NAME_ROLE:CORE, which records its semantic role. In general, the feature counts depend on the recovered evidence available in each document. 3.2.4 TF-IDF Vectorization After extracting the three channel feature sets, PLC-Bin2Src transforms binary and source features into vectors with a common dimensionality within each channel. The CDFG feature set comprises normalized structural labels, token ngrams when statement-level graph structure is recoverable, and call-related features. The FCG feature set contains function-role nodes, call edges, and local call-structure features, whereas the Symbols feature set independently aggregates normalized recovered-symbol labels and their semantic roles. TF-IDF weighting is applied separately in each channel: it reduces the influence of features that occur widely across the candidate corpus and gives greater emphasis to more discriminative features. PLC-Bin2Src therefore obtains
6
the following vectors for binary sample b and source sample s: b vcdfg ,
b vfcg ,
b vsymbol ,
s vcdfg ,
s vfcg ,
s vsymbol .
At this point, the binary and source sides have both been transformed into comparable vector representations in each channel. 3.3
Sfused (b, s),
s ∈ Sb .
The candidate sequence is then obtained by sorting the fused scores in descending order:
πb = argsort↓s∈Sb Sfused (b, s).
Similarity Calculation
The similarity-calculation stage computes channel-wise similarities between a binary query and each source candidate, takes their equal-weight average, and orders the candidates by their fused scores. 3.3.1
3.3.3 Top-k Candidate Selection For a binary sample b, PLC-Bin2Src computes its fused score with every ST program in the given source-candidate set Sb and generates a candidate sequence by sorting the scores in descending order. Formally, let the source-candidate set of binary query b be Sb . PLC-Bin2Src computes the fused score between b and each candidate s ∈ Sb :
(3)
The position of the true source code in candidate sequence πb is denoted by rank(b). A smaller value indicates that the system ranks the correct correspondence closer to the top. The first k elements of πb form the top-k candidate set returned by PLC-Bin2Src.
Cosine Similarity
Given a binary query b and a source candidate s, PLC-Bin2Src separately compares their vector representations in the three channels. Let the channel set be
C = {cdfg, fcg, symbol}.
4
E VALUATION
The evaluation examines effectiveness of PLC-Bin2Src, the contribution of different channel combinations, and computational efficiency. It addresses the following research questions:
For any channel c ∈ C , the channel vectors of the binary query and source candidate are denoted by vcb and vcs , respectively. Their similarity in channel c is computed using cosine similarity:
•
vcb · vcs Sc (b, s) = . ∥vcb ∥2 ∥vcs ∥2
•
•
(1)
After independent computation, the system obtains the similarities of the three channels:
Scdfg (b, s),
Sfcg (b, s),
Ssymbol (b, s).
4.1
RQ1: How effective is PLC-Bin2Src in matching PLC binaries compiled by different platforms to their corresponding source files? RQ2: How do different combinations of the three semantic representations affect binary2source matching performance? RQ3: What is the runtime cost of each stage of PLCBin2Src? Experimental Setup
A single channel captures only one aspect of program semantics. PLC-Bin2Src therefore gives the three channel similarities equal contributions, allowing intraprocedural structure, program-level call relationships, and recoveredsymbol evidence to jointly determine candidate ranking. For any binary sample b and source candidate s, PLCBin2Src computes the final matching score as
4.1.1 Evaluation Dataset PLC-BEAD [9] contains 2431 samples. We evaluate 2358 samples for which a unique binary–source correspondence can be established and all three channel representations can be generated. These samples cover CODESYS, GEB, OpenPLC v2, and OpenPLC v3. All 73 excluded samples are from CODESYS. For 29 samples, the current MATIEC pipeline does not generate valid C-like representations because of unresolved library calls or POU types, compileraccess exceptions, or syntax and naming conflicts. For the remaining 44 samples, the existing data organization does not permit a unique, verifiable mapping to a source file. Table 1 reports the resulting platform distribution: 482 CODESYS samples, 617 GEB samples, 619 OpenPLC v2 samples, and 640 OpenPLC v3 samples.
1 (Scdfg (b, s) + Sfcg (b, s) + Ssymbol (b, s)) . 3 (2) Equivalently, the three weights shown in Fig. 2 satisfy wcdfg = wfcg = wsymbol = 1/3. The fixed rule treats the three forms of evidence symmetrically and requires no fitted parameter. The resulting scalar score is used for candidate ranking.
4.1.2 Experimental Configuration The evaluation contains 2358 binary queries: 482 from CODESYS, 617 from GEB, 619 from OpenPLC v2, and 640 from OpenPLC v3. For each toolchain, we construct a compatible candidate corpus containing the corresponding 482, 617, 619, or 640 ST programs. Every source program in a corpus can be compiled into a valid binary by that toolchain
The three scores quantify similarity in function-level control–data representations, program-level call representations, and recovered-symbol evidence, respectively, and form the inputs to equal-weight fusion. 3.3.2
Equal-Weight Similarity Fusion
Sfused (b, s) =
7
TABLE 1 Numbers of valid samples used in the experiments. Platform
Binary form
Number of samples
CODESYS GEB OpenPLC v2 OpenPLC v3
.app application container ARM ELF ARM ELF (.exe file) ARM ELF (.exe file)
482 617 619 640
Total
–
2358
and has a known binary correspondence. A source program is not inherently platform specific; if several toolchains compile the same ST program successfully, it can appear in several corpora. For each binary query, PLC-Bin2Src scores every source candidate in the compatible corpus and sorts the candidates by fused score. Implementation: The binary frontend uses IDA Pro and the Hex-Rays Decompiler to generate C-like representations of target functions [18]. When an OpenPLC wrapper function cannot be decompiled stably, the system uses Capstone to obtain instruction-level disassembly results [19] and reconstructs a C-style call framework through fallback recovery logic. The source frontend uses MATIEC to convert ST into a C-style representation [11] and finally uses a C preprocessor to perform macro expansion. The system constructs the CDFG, FCG, and Symbols feature documents, computes their channel-wise similarities, and applies fixed equal-weight fusion. The method does not need training. Its three-channel configuration fixes the CDFG, FCG, and Symbols weights at 1/3 each. In RQ2, a two-channel combination assigns 1/2 to each included channel, while a single-channel configuration assigns weight 1 to that channel. Every query is evaluated directly against its complete compatible source-candidate corpus. Candidates are ordered by descending fused score, with descending candidate index as a deterministic tiebreaker independent of the ground truth. Baseline selection: To the best of our knowledge, no existing approach directly supports binary2source matching between PLC binaries and ST source files. Existing generalpurpose binary2source methods primarily target conventional C/C++ binaries and function- or component-level matching [7], [8], [20], [21], and cannot be directly applied to the platform-specific PLC artifacts in PLC-BEAD without substantial frontend and task adaptation. Therefore, we do not report a direct external baseline. Instead, we use the individual CDFG, FCG, and Symbols channels and their pairwise combinations as controlled internal baselines to evaluate the contribution of each representation and their fusion. 4.1.3 Evaluation Metrics We use the following metrics to evaluate binary2source matching performance: • •
Recall@k : the proportion of queries for which the true source code appears among the top k candidates. Mean reciprocal rank (MRR): the mean of the reciprocal ranks of the correct answers for all samples, reflecting the overall ranking quality of the system.
For a query set B , let the position of the true source code in the candidate sequence for query b be rank(b). Recall@k is defined as 1 X Recall@ k = I(rank(b) ≤ k) . (4) |B| b∈B Here, I(·) is the indicator function. We report results for k = 1 and k = 5, which measure the proportions of queries for which the true source code is ranked first and within the top five, respectively. MRR is defined as 1 X 1 MRR = . (5) |B| b∈B rank(b) Unlike Recall@1 and Recall@5, which consider only whether a match occurs within a specific ranking range, MRR is more sensitive to the exact position of the true source code in the candidate list. When the true source code is ranked closer to the top, its reciprocal rank is larger and the MRR is higher. Recall@1, Recall@5, and MRR evaluate binary2source matching from three perspectives: first-position retrieval, coverage of the leading candidate set, and overall ranking quality, respectively. 4.2
RQ1: Overall and Platform-Level Matching Results
We aggregate the ranks of all queries and then disaggregate the results by platform. Table 2 reports Recall@1, Recall@5, and MRR overall and for each platform. TABLE 2 Overall and platform-level matching results.
Platform
Number of Number not samples Recall@1 Recall@5 MRR ranked first
CODESYS GEB OpenPLC v2 OpenPLC v3
482 617 619 640
98.55% 95.79% 94.83% 95.00%
99.38% 0.9895 99.84% 0.9770 99.68% 0.9716 99.69% 0.9725
7 26 32 32
Overall
2358
95.89%
99.66% 0.9769
97
On the 2358 valid samples, PLC-Bin2Src achieves 95.89% Recall@1, 99.66% Recall@5, and an MRR of 0.9769. Across the four platforms, Recall@1 ranges from 94.83% to 98.55%, and Recall@5 ranges from 99.38% to 99.84%. CODESYS has the highest Recall@1 and OpenPLC v2 the lowest, with a difference of 3.72 percentage points. Answer to RQ1: PLC-Bin2Src achieves 95.89% Recall@1 on 2358 queries. Among the 97 queries for which the true source is not ranked first, 89 still place it within the top five. 4.3
RQ2: Channel Combination Analysis
To compare the evidence provided by different representations, we evaluate all three individual channels, all three two-channel combinations, and the complete three-channel configuration. Each included channel contributes equally: a single channel receives weight 1, the two channels in a pair receive 1/2 each, and the three channels receive 1/3 each. Table 3 reports the results over all 2358 queries.
8
binary2source matching in only 0.92–2.87 s across the four platforms.
TABLE 3 Matching results for different channel combinations. Channel combination Recall@1 Recall@5
MRR
4.5
CDFG only FCG only Symbols only
73.11% 91.94% 81.89%
85.79% 98.52% 88.30%
0.7902 0.9501 0.8483
CDFG+FCG CDFG+Symbols FCG+Symbols
93.55% 93.21% 93.77%
98.69% 99.41% 99.24%
0.9594 0.9601 0.9633
PLC-Bin2Src
95.89%
99.66%
0.9769
Among the individual channels, FCG performs best, with 91.94% Recall@1. Equal pairwise fusion yields 93.55% Recall@1 for CDFG+FCG, 93.21% for CDFG+Symbols, and 93.77% for FCG+Symbols. The equal three-channel configuration reaches 95.89% Recall@1, 99.66% Recall@5, and an MRR of 0.9769, improving on the strongest two-channel configuration by 2.12 percentage points, 0.42 percentage points, and 0.0136, respectively. These results show that function-level control–data representations, program-level call representations, and topology-independent symbol evidence provide complementary signals for candidate ranking. Answer to RQ2: Fixed equal-weight three-channel fusion outperforms every individual channel and every equalweight two-channel combination, achieving 95.89% Recall@1, 99.66% Recall@5, and an MRR of 0.9769. 4.4
RQ3: Runtime Cost by Stage
We report runtime for three pipeline stages. Preprocessing covers the source and binary frontends, representation construction builds the CDFG, FCG, and Symbols representations, and similarity calculation performs TF-IDF vectorization, equalweight fusion, and candidate ranking. Source OpenPLC v2 775
Time (s)
1000
181
CODESYS OpenPLC v3
GEB
1141 939
468 68.0
45.6
100
77.3
10.3
10
2.87 2.27
0.92
2.42
1
Preprocessing
Representation construction
Similarity calculation
Fig. 6. Runtime evaluation by pipeline stage.
Figure 6 reports total runtime in seconds on a logarithmic scale. The source repository is preprocessed once in 180.81 s. Across the four platforms, binary preprocessing requires 467.73–1141.17 s and dominates the total cost, whereas representation construction requires 10.32–77.25 s and similarity calculation requires only 0.92–2.87 s. Answer to RQ3: Once preprocessing and representation construction are complete, PLC-Bin2Src performs full-corpus
Analysis of Results Not Ranked First
Among the 97 queries for which the true source is not ranked first, 89 still place it within the top five: 73 rank it second and 16 rank it third through fifth. The remaining eight place it outside the top five. The median score difference between the first-ranked incorrect candidate and the true source is 0.00975. Most errors therefore occur among leading candidates with similar scores, although a small number place the true source substantially lower. Four representative cases illustrate these errors. For the GEB query FT_TN16, FT_TN8 is ranked first and the true source is ranked third with an identical score. For STACK_32 on OpenPLC v2, STACK_16 is ranked first and the true source is ranked second; their FCG and Symbols scores are identical, while their CDFG scores differ by only 0.000028. For the CODESYS query _ARRAY_ADD, the recovered symbol slice is incorrectly associated with _ARRAY_ABS, causing all name-bearing representations to favor that candidate and placing the true source at rank 216. Finally, for the GEB query URL_TO_STRING, _RMP_B is ranked first and the true source is ranked 305th. In this case, no symbol is recovered, and neither the CDFG nor the FCG channel provides sufficiently discriminative features. The cases exhibit three recurring patterns. First, variants within the same function family can receive identical or highly similar channel scores. Second, differences in retained types, constants, or intermediate operations may leave too little fine-grained evidence to change the ranking. Third, inaccurate frontend associations can distort the resulting evidence, as in _ARRAY_ADD. Similar errors occur in OpenPLC v2 and v3, suggesting that related compilation toolchains preserve similar features for some function variants.
5
D ISCUSSION
The evaluated binaries naturally retain recoverable naming clues as outputs of the PLC compilation and packaging toolchains represented in PLC-BEAD; PLC-Bin2Src does not introduce these names from the source code. In GEB and OpenPLC, the binaries expose compiler-generated POU and function names, whereas CODESYS .app containers preserve binary-visible names and pointers in metadata records. PLC-BinX reports the same platform behavior and associates the recovered names with function-level representations; our setting therefore follows PLC-BEAD and PLC-BinX in analyzing these engineering-generated compiled artifacts [5], [9]. This use of information recoverable from compiled PLC artifacts is also consistent with prior PLC reverse-engineering studies [2], [12]. Recoverable symbols are useful but incomplete matching evidence. As shown in Table 3, the Symbols-only configuration achieves 81.89% Recall@1, whereas CDFG+Symbols and FCG+Symbols reach 93.21% and 93.77%, respectively, and equal three-channel fusion reaches 95.89%. Thus, even when naming clues are widely available, they do not uniquely determine source correspondence. CDFG and FCG contribute complementary control–data and call-organization evidence
9
that resolves candidates sharing similar names or function roles. PLC-Bin2Src therefore uses recovered symbols as one complementary channel rather than reducing binary2source matching to name comparison, consistent with namingaware binary-similarity research [17].
6
T HREATS TO VALIDITY
6.1
Construct Validity
The ground-truth correspondences in the experiments are inherited from the data organization of PLC-BEAD [9]. If the source–binary correspondences, platform labels, or compilation artifacts in the original samples contain errors, the associated errors will also enter the evaluation. 6.2
Internal Validity
Core-function extraction, decompilation, ST-to-C conversion, semantic normalization, and feature extraction depend on multiple analysis tools and rules. IDA Pro/Hex-Rays decompilation results, fallback recovery based on Capstone disassembly, MATIEC code generation, and the parsing and normalization processes in the project may all produce omissions or representation bias [11], [18], [19], [22]–[24]. The experiments use consistent frontend processes, candidate sets, and evaluation rules for all query corpora to reduce differences in processing conditions, but tool errors cannot be eliminated. 6.3
External Validity
This paper evaluates CODESYS, GEB, OpenPLC v2, and OpenPLC v3, but these platforms do not cover all PLC vendors, compilation toolchains, architectures, and optimization configurations. The evaluation follows PLC-BEAD and PLC-BinX in using engineering-generated compiled artifacts from the covered toolchains, which retain recoverable naming clues [5], [9]. The conclusions therefore concern these toolchains and artifact types; binaries subjected to deliberate symbol stripping or name obfuscation constitute additional conditions for future evaluation. The fixed equal-weight fusion rule also may not be optimal for datasets or platform distributions whose channel quality differs substantially from PLC-BEAD.
7
R ELATED W ORK
7.1
General-Purpose Binary2Source Matching
Binary2source matching identifies correspondences between binary artifacts and source code, supporting software composition analysis, code-reuse detection, and provenance tracing. Existing approaches can be broadly grouped by their principal matching evidence into string-based, structurebased, and learning-based methods. String-based methods. These methods exploit strings, identifiers, constants, and other lexical features that can be extracted from both source code and binaries. BAT combines strings with compression similarity and binary differencing to identify code reuse in firmware [25]. OSSPolice uses string and function features to detect open-source components in mobile applications [6], while B2SFinder matches source and binary feature instances for open-source reuse detection [26].
B2SMatcher uses string literals and exported function names for coarse matching and supplements them with functionlevel constants and call-graph degrees for fine-grained version identification [27]. Structure-based methods. These methods compare relations among program elements to reduce dependence on exact lexical correspondence. BinPro combines constants, library calls, function-call relationships, and iterative bipartite function matching to determine binary provenance [7]. BugGraph, GraphBinMatch, and BSMDG use attributed control-flow graphs, call relationships, or decompiler-derived graph structures to preserve program semantics across compilation [28]– [30]. Their designs are related to broader graph representations, including program dependence graphs [13], Weisfeiler– Lehman neighborhood aggregation [15], and ProGraML’s joint representation of control, data, and call relations [14]. Function-call graphs and recoverable names can provide additional program-level evidence [16], [17]. Learning-based methods. These methods learn a shared representation in which corresponding source and binary code are close to each other. CodeCMR uses a text model and a graph neural network to encode source and binary functions, respectively [20]. XLIR reduces cross-language and cross-representation differences through intermediate representations [21], while CrossCode2Vec combines abstractsyntax paths with hierarchical sequence models to learn crossrepresentation features [31]. BinaryAI combines transformerbased function embeddings with link-time locality for binary software composition analysis [8]. Recent work also uses strings, constants, and external calls as anchors before reranking source functions with a large language model [32]. Related learning-based binary-similarity methods, including Gemini, DeepBinDiff, Order Matters, and Trex, further demonstrate the value of structural and execution-semantic representations across compilation [33]–[36]. 7.2
PLC Binary Analysis
PLC binary analysis must account for platform-specific compilation toolchains, executable formats, and runtime organizations. ICSREF identifies domain-specific features in CODESYS binaries to recover function boundaries, call relationships, and control flow [2]. Benkraouda et al. show that programming language, compiler version, target architecture, and PLC vendor all affect binary representations [12]. Other studies reconstruct PLC control logic, recover program structures, or decompile proprietary artifacts by exploiting platform and runtime characteristics [37]–[40]. Recovered PLC structures also support downstream security analysis. ICSFuzz and ICS-QUARTZ use binarylevel control information for instrumented and scan-cycleaware fuzzing, while ICSPatch derives data-dependence information for vulnerability localization and runtime hotpatching [41]–[43]. PLC-BEAD provides 2431 paired binaries and ST programs spanning CODESYS, GEB, OpenPLC v2, and OpenPLC v3 [9]. Built on this corpus, PLC-BinX supports cross-platform core-function identification and function-level semantic recovery [5]. The two bodies of work address complementary aspects of PLC binary2source matching. Existing binary2source methods are mainly designed for general-purpose software
10
and conventional executable or decompiler representations. Existing PLC binary-analysis methods recover and analyze semantics from platform-specific artifacts, but do not identify the corresponding ST source file from a candidate repository. PLC-Bin2Src connects these directions through platformaware semantic recovery, aligned binary and source representations, and source-candidate ranking.
8
C ONCLUSION
This paper presents PLC-Bin2Src for retrieving corresponding ST source files for binary artifacts from CODESYS, GEB, OpenPLC v2, and OpenPLC v3. PLC-Bin2Src constructs comparable CDFG, FCG, and recovered-symbol representations and combines their similarities for candidate ranking. On PLC-BEAD, it achieves 95.89% Recall@1, 99.66% Recall@5, and an MRR of 0.9769 across the four platforms. These results demonstrate the feasibility of cross-platform binary2source matching for opaque PLC binaries and provide a foundation for broader provenance and composition analysis.
R EFERENCES International Electrotechnical Commission, IEC 61131-3:2013, Programmable Controllers—Part 3: Programming Languages, IEC Std., 2013. [2] A. Keliris and M. Maniatakos, “ICSREF: A framework for automated reverse engineering of industrial control systems binaries,” in Network and Distributed System Security Symposium (NDSS), 2019. [3] CODESYS GmbH, “Command: Save project as compiled library,” CODESYS Online Help. [Online]. Available: https:// content.helpme-codesys.com/en/CODESYS%20Development% 20System/_cds_cmd_save_project_as_compiled_library.html, accessed: Sep. 5, 2026. [4] ——, “Deployment and licensing,” CODESYS Library Development Summary. [Online]. Available: https://content. helpme-codesys.com/en/LibDevSummary/deployment.html, accessed: Aug. 30, 2026. [5] A. Jia, Y. Duan, H. Jiang, Z. Tian, Z. Ren, and X. Li, “PLC-BinX: A cross-platform binary code analysis framework for PLC binaries,” arXiv:2605.17392, 2026. [Online]. Available: https://arxiv.org/abs/2605.17392 [6] R. Duan, A. Bijlani, M. Xu, T. Kim, and W. Lee, “Identifying opensource license violation and 1-day security risk at large scale,” in 2017 ACM SIGSAC Conference on Computer and Communications Security, 2017, pp. 2169–2185. [7] D. Miyani, Z. Huang, and D. Lie, “BinPro: A tool for binary source code provenance,” arXiv:1711.00830, 2017. [Online]. Available: https://arxiv.org/abs/1711.00830 [8] L. Jiang, J. An, H. Huang, Q. Tang, S. Nie, S. Wu, and Y. Zhang, “BinaryAI: Binary software composition analysis via intelligent binary source code matching,” in IEEE/ACM 46th International Conference on Software Engineering, 2024, pp. 1–13. [9] Y. G. Achamyeleh, S. Y. Yu, G. Q. Araya, and M. A. A. Faruque, “Bridging the binary analysis gap: A cross-compiler dataset and neural framework for industrial control systems,” in 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining V.2, 2025, pp. 5260–5269. [10] E. López-Morales, U. Planta, C. Rubio-Medrano, A. Abbasi, and A. A. Cardenas, “SoK: Security of programmable logic controllers,” in 33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 7103–7122. [Online]. Available: https://www.usenix. org/conference/usenixsecurity24/presentation/lopez-morales [11] MATIEC Project, “MATIEC: IEC 61131-3 compiler,” Software documentation, accessed: Aug. 26, 2026. [Online]. Available: https://openplcproject.gitlab.io/matiec/ [12] H. Benkraouda, A. Agrawal, D. Tychalas, M. Sazos, and M. Maniatakos, “Towards PLC-specific binary analysis tools: An investigation of CODESYS-compiled PLC software applications,” in 5th Workshop on CPS and IoT Security and Privacy, 2023, pp. 83–89. [1]
[13] J. Ferrante, K. J. Ottenstein, and J. D. Warren, “The program dependence graph and its use in optimization,” ACM Transactions on Programming Languages and Systems, vol. 9, no. 3, pp. 319–349, 1987. [14] C. Cummins, Z. V. Fisches, T. Ben-Nun, T. Hoefler, M. F. P. O’Boyle, and H. Leather, “ProGraML: A graph-based program representation for data flow analysis and compiler optimizations,” in 38th International Conference on Machine Learning, ser. Proceedings of Machine Learning Research, vol. 139, 2021, pp. 2244– 2253. [Online]. Available: https://proceedings.mlr.press/v139/ cummins21a.html [15] N. Shervashidze, P. Schweitzer, E. J. van Leeuwen, K. Mehlhorn, and K. M. Borgwardt, “Weisfeiler-lehman graph kernels,” Journal of Machine Learning Research, vol. 12, pp. 2539–2561, 2011. [Online]. Available: https://www.jmlr.org/papers/v12/shervashidze11a. html [16] X. Hu, T.-c. Chiueh, and K. G. Shin, “Large-scale malware indexing using function-call graphs,” in 16th ACM Conference on Computer and Communications Security, 2009, pp. 611–620. [17] B. Xia, J. Pang, X. Zhou, Z. Shan, J. Wang, and F. Yue, “Binary code similarity analysis based on naming function and common vector space,” Scientific Reports, vol. 13, no. 1, 2023, art. no. 15676. [18] Hex-Rays, “IDA Pro disassembler and debugger,” Computer software, accessed: Aug. 26, 2026. [Online]. Available: https: //hex-rays.com/ida-pro/ [19] Capstone Project, “Capstone disassembly framework,” Computer software, accessed: Aug. 26, 2026. [Online]. Available: https: //www.capstone-engine.org/ [20] Z. Yu, W. Zheng, J. Wang, Q. Tang, S. Nie, and S. Wu, “CodeCMR: Cross-modal retrieval for functionlevel binary source code matching,” in Advances in Neural Information Processing Systems 33, 2020, pp. 3872–3883. [Online]. Available: https://papers.nips.cc/paper/2020/hash/ 285f89b802bcb2651801455c86d78f2a-Abstract.html [21] Y. Gui, Y. Wan, H. Zhang, H. Huang, Y. Sui, G. Xu, Z. Shao, and H. Jin, “Cross-language binary-source code matching with intermediate representations,” in IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), 2022, pp. 601–612. [22] D. Andriesse, X. Chen, V. van der Veen, A. Slowinska, and H. Bos, “An in-depth analysis of disassembly on full-scale x86/x64 binaries,” in 25th USENIX Security Symposium, 2016, pp. 583–600. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity16/technical-sessions/presentation/andriesse [23] K. Pei, J. Guan, D. Williams-King, J. Yang, and S. Jana, “XDA: Accurate, robust disassembly with transfer learning,” in Network and Distributed System Security Symposium (NDSS), 2021. [24] Z. Gao, Y. Cui, H. Wang, S. Qin, Y. Wang, Z. Bolun, and C. Zhang, “DecompileBench: A comprehensive benchmark for evaluating decompilers in real-world scenarios,” in Findings of the Association for Computational Linguistics: ACL 2025, 2025, pp. 23 250–23 267. [25] A. Hemel, K. T. Kalleberg, R. Vermaas, and E. Dolstra, “Finding software license violations through binary code clone detection,” in 8th Working Conference on Mining Software Repositories, 2011, pp. 63–72. [26] M. Feng, Z. Yuan, F. Li, G. Ban, Y. Xiao, S. Wang, Q. Tang, H. Su, C. Yu, J. Xu, A. Piao, J. Xue, and W. Huo, “B2SFinder: Detecting open-source software reuse in COTS software,” in 34th IEEE/ACM International Conference on Automated Software Engineering (ASE), 2019, pp. 1038–1049. [27] G. Ban, L. Xu, Y. Xiao, X. Li, Z. Yuan, and W. Huo, “B2SMatcher: Fine-grained version identification of open-source software in binary files,” Cybersecurity, vol. 4, 2021, art. no. 21. [28] Y. Ji, L. Cui, and H. H. Huang, “BugGraph: Differentiating sourcebinary code similarity with graph triplet-loss network,” in 2021 ACM Asia Conference on Computer and Communications Security, 2021, pp. 702–715. [29] A. TehraniJamsaz, H. Chen, and A. Jannesari, “GraphBinMatch: Graph-based similarity learning for cross-language binary and source code matching,” in 2024 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW), 2024, pp. 506–515. [30] G. Aljebreen, R. Alnanih, F. Eassa, M. Khemakhem, K. Jambi, and M. U. Ashraf, “Binary–source code matching based on decompilation techniques and graph analysis,” International Journal of Advanced Computer Science and Applications, vol. 16, no. 5, 2025.
11
[31] G. Yu, J. An, J. Lyu, W. Huang, W. Fan, Y. Cheng, and A. Sui, “CrossCode2Vec: A unified representation across source and binary functions for code similarity detection,” Neurocomputing, vol. 620, 2025, art. no. 129238. [32] C. E. Gagnon, S. H. H. Ding, P. Charland, and B. C. M. Fung, “Practical source code recovery from binary functions using anchor-based retrieval and LLM reasoning,” arXiv:2607.09452, 2026. [Online]. Available: https://arxiv.org/abs/2607.09452 [33] X. Xu, C. Liu, Q. Feng, H. Yin, L. Song, and D. Song, “Neural network-based graph embedding for cross-platform binary code similarity detection,” in 2017 ACM SIGSAC Conference on Computer and Communications Security, 2017, pp. 363–376. [34] Y. Duan, X. Li, J. Wang, and H. Yin, “DeepBinDiff: Learning program-wide code representations for binary diffing,” in Network and Distributed System Security Symposium (NDSS), 2020. [35] Z. Yu, R. Cao, Q. Tang, S. Nie, J. Huang, and S. Wu, “Order matters: Semantic-aware neural networks for binary code similarity detection,” Proceedings of the AAAI Conference on Artificial Intelligence, vol. 34, no. 1, pp. 1145–1152, 2020. [36] K. Pei, Z. Xuan, J. Yang, S. Jana, and B. Ray, “Learning approximate execution semantics from traces for binary function similarity,” IEEE Transactions on Software Engineering, vol. 49, no. 4, pp. 2776– 2790, 2023. [37] S. A. Qasim, J. Lopez, Jr., and I. Ahmed, “Automated reconstruction of control logic for programmable logic controller forensics,” in Information Security, ISC 2019. Springer, 2019, pp. 402–422. [38] S. A. Qasim, J. M. Smith, and I. Ahmed, “Control logic forensics framework using built-in decompiler of engineering software in industrial control systems,” Forensic Science International: Digital Investigation, vol. 33, 2020, art. no. 301013. [39] C. Sang, J. Wu, J. Li, and M. Guizani, “From control application to control logic: PLC decompile framework for industrial control system,” IEEE Transactions on Information Forensics and Security, vol. 19, pp. 8685–8700, 2024. [40] Y. Geng, X. Che, R. Ma, Q. Wei, M. Wang, and Y. Chen, “Control logic attack detection and forensics through reverse-engineering and verifying PLC control applications,” IEEE Internet of Things Journal, vol. 11, no. 5, pp. 8386–8400, 2024. [41] D. Tychalas, H. Benkraouda, and M. Maniatakos, “ICSFuzz: Manipulating I/Os and repurposing binary code to enable instrumented fuzzing in ICS control applications,” in 30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 2847– 2862. [Online]. Available: https://www.usenix.org/conference/ usenixsecurity21/presentation/tychalas [42] C. Villa, C. Doumanidis, H. Lamri, P. H. N. Rajput, and M. Maniatakos, “ICS-QUARTZ: Scan cycle-aware and vendor-agnostic fuzzing for industrial control systems,” in Network and Distributed System Security Symposium (NDSS), 2025. [43] P. H. N. Rajput, C. Doumanidis, and M. Maniatakos, “ICSPatch: Automated vulnerability localization and non-intrusive hotpatching in industrial control systems using data dependence graphs,” in 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 6861–6876. [Online]. Available: https://www.usenix. org/conference/usenixsecurity23/presentation/rajput