PaperlayerView exact revision on arXiv

Source-linked AI summary

PLC-Bin2Src: Retrieving Corresponding Structured Text Source Files for PLC Binaries

Ang Jia, Yaxin Duan, He Jiang, Ming Fan, Zhilei Ren, Xiaochen Li

arXiv:2609.08563v2cs.SE

TL;DR

Binary-only PLC component reuse makes it difficult to identify components and their origins, while matching binaries to source files is complicated by platform and representation differences. PLC-Bin2Src aligns binary and ST representations and ranks candidate source files; on PLC-BEAD, it achieves 95.89% Recall@1 across four platforms.

  • Problem

    Binary-only reuse makes it difficult to identify PLC components and their origins, and existing PLC reverse-engineering frameworks do not identify the corresponding source file.

    Source: §1 · p. 1

  • Method

    PLC-Bin2Src recovers binary-side logic, converts and normalizes ST, constructs CDFGs, FCGs, and symbol representations, then combines their similarities to rank source candidates.

    Source: §1 · p. 2

  • Results

    On PLC-BEAD, PLC-Bin2Src achieves 95.89% Recall@1, 99.66% Recall@5, and an MRR of 0.9769 across four PLC platforms.

    Source: §8 · p. 10

  • Takeaways & Limitations

    The results demonstrate the feasibility of cross-platform binary2source matching for opaque PLC binaries and provide a foundation for broader provenance and composition analysis.

    Source: §8 · p. 10

    The evaluation covers four platforms and engineering-generated artifacts that retain recoverable naming clues; deliberately stripped or name-obfuscated binaries remain for future evaluation.

    Source: §6.3 · p. 9

Abstract

from arXiv · show

PLC developers reuse existing components and third-party libraries to reduce the cost of developing new applications, but this reuse can also introduce security risks. When components are distributed only in binary form, provenance tracing, vulnerability assessment, and security auditing become more difficult. To support these analyses, binary2source matching can retrieve the corresponding Structured Text (ST) source file for a PLC binary from a candidate source repository. However, due to the properties of PLC software, this task faces three challenges: cross-platform compilation heterogeneity, a binary-source representation gap, and inadequate representations of PLC semantics. Therefore, we present PLC-Bin2Src, a cross-platform binary2source matching framework that retrieves corresponding ST source files for binaries produced by CODESYS, GEB, OpenPLC v2, and OpenPLC v3. First, PLC-Bin2Src uses platform-aware binary frontends to recover user control logic across toolchains. Then, ST-to-C conversion and shared normalization are used to reduce syntactic differences between source- and binary-side representations. Next, control-data flow graphs (CDFGs) and function call graphs (FCGs) are constructed to capture program semantics, while recovered symbols provide complementary identity evidence. Finally, PLC-Bin2Src compares these representations and combines their similarity scores to rank source candidates. We evaluate PLC-Bin2Src on PLC-BEAD. The results show that PLC-Bin2Src achieves 95.89% Recall@1, 99.66% Recall@5, and an MRR of 0.9769 across four PLC platforms.

1 INTRODUCTION

Binary-only PLC component reuse makes it difficult to identify components, logic, and origins, while PLC binaries and ST sources differ across platforms and representations. PLC-Bin2Src addresses these challenges by aligning and comparing program representations, achieving high retrieval results across four platforms.

1 INTRODUCTION

  • Binary-only component reuse makes it difficult to identify incorporated components, their logic, and their origins; binary2source matching can support dependency inventories, vulnerability assessment, provenance tracing, and security auditing.Source: §1 · p. 1
  • PLC binary2source matching faces cross-platform compilation heterogeneity, a binary–source representation gap, and inadequate semantic representations that may fail to distinguish candidates with different control logic.Incomplete binary-level evidence makes those distinctions harder to capture reliably.Source: §1 · pp. 1–2
  • PLC-Bin2Src uses platform-aware binary frontends, ST-to-C conversion, shared normalization, CDFGs, FCGs, and recovered symbols to compare representations and rank source candidates.The framework combines similarity scores from the three representations.Source: §1 · p. 2
  • On PLC-BEAD, PLC-Bin2Src achieves 95.89% Recall@1, 99.66% Recall@5, and an MRR of 0.9769 across CODESYS, GEB, OpenPLC v2, and OpenPLC v3.The evaluation retrieves corresponding ST source files for binaries compiled on these platforms.Source: §1 · p. 2
  • The paper presents PLC-Bin2Src as the first framework for retrieving corresponding ST source files for PLC binaries.Source: §1 · p. 2

2 BACKGROUND

PLC programs execute user control logic within a compilation and runtime process that adds wrappers and support code. Across platforms, even the same ST program can yield different binary contexts, calls, and memory-access forms.

2.1 PLC Program Model and Compilation Process

  • ST programs contain PROGRAM, FUNCTION, and FUNCTION_BLOCK units whose variable accesses and calls jointly describe control logic.PLC toolchains compile source code into executable binaries, adding wrappers, cyclic scheduling, variable-access interfaces, temporary values, and runtime support logic.Source: §2.1 · p. 2
  • Disassembly can recover low-level arithmetic and calls, but user logic remains distributed across functions, wrappers, and the cyclic execution chain.Source: §2.1 · p. 2

2.2 Cross-Platform Differences in PLC Binaries

  • The same ST program can produce different function contexts, call targets, memory-access forms, and recoverable semantic units across PLC platforms.The ACOSH example contrasts OpenPLC v3 typed runtime calls, CODESYS hardware and indirect calls, and GEB runtime calls and a hook.Source: §2.2 · pp. 2–3
  • Surface-level similarity is unreliable across platforms, so matching must localize user-control code and normalize operations, calls, and identifiers before comparing binaries with ST files.Source: §2.2 · p. 3

3 METHOD

PLC-Bin2Src treats binary2source matching as ranking candidate ST files. It preprocesses both sides, builds three representations, then combines their similarities to return top candidates.

3 METHOD

  • PLC-Bin2Src models binary2source matching as a source-candidate ranking problem.Source: §3 · p. 3
  • Preprocessing recovers binary-side core functions, transforms source-side ST programs, and normalizes both sides before representation construction.Source: §3 · p. 3
  • CDFG, FCG, and recovered-symbol features become TF-IDF vectors; separate cosine similarities are fused with fixed equal weights to rank compatible ST files.The figure identifies each weight as 1/3 and the fused score as the ranking score.Source: §3 · p. 3

3.1 Preprocessing

Preprocessing brings binary- and source-side user logic into comparable C-like forms. Platform-specific binary recovery and ST-to-C conversion are followed by normalization of operations, accesses, and constants.

3.1 Preprocessing

  • The two frontends transform ACOSH into comparable representations, with binary-side processing above and source-side processing below in Fig. 3.The binary frontend extracts and decompiles core functions; the source frontend converts ST into C.Source: §3.1 · p. 3, §3.1.1 · p. 3, §3.1.2 · p. 3

3.1.1 Binary Frontend

  • Platform-aware binary processing recovers function identifiers, ranges, and structures, then selects user-logic functions using toolchain-specific rules and decompiles them into C-like code.OpenPLC retains the cyclic wrapper and user functions; GEB uses execution-routine naming patterns; CODESYS uses metadata, function ranges, and calls to identify POU candidates.Source: §3.1.1 · p. 3

3.1.2 Source Frontend

  • The source frontend uses MATIEC to convert ST to C, preprocesses macros and conditional compilation, and selects functions representing user control logic.It excludes program0, initialization, and platform-support functions, prioritizing the function or function-block body corresponding to the sample.Source: §3.1.2 · p. 3

3.1.3 Normalization

  • Shared normalization aligns operation names, variable and memory-access forms, and numeric literals across source and binary representations.Platform-specific calls can map to common operation labels; memory patterns are abstracted into common labels, and numeric forms such as 0x02 normalize to 2.Source: §3.1.3 · pp. 3–5

3.2 Representation Construction

PLC-Bin2Src builds CDFG, FCG, and Symbols representations from normalized binary- and source-side programs, then maps their features into comparable vector spaces. These representations capture within-function control and data semantics, program-unit call structure, and recovered identity evidence.

3.2.1 CDFG

  • CDFGs organize control and data semantics around extracted core functions, using operation, arithmetic, and data nodes linked by control and data relationships.They capture semantic events including decisions, loops, assignments, calls, memory accesses, and arithmetic; recoverable call arguments, definition–use links, return propagation, and consecutive-call order add local structure.Source: §3.2.1 · p. 5

3.2.2 FCG

  • FCGs represent program-unit call organization with function nodes, direct-call edges, and labels for roles such as program entries, core functions, and libraries.The graphs use direct or statically resolved indirect calls and normalized roles, including INIT, PROGRAM, CORE, LIB, RUNTIME, and HELPER.Source: §3.2.2 · pp. 5–6

3.2.3 Symbols

  • Symbols independently summarize recovered function names and related identifiers, complementing graph representations with identity evidence when binaries retain symbol clues.The feature types are NAME_LABEL and NAME_ROLE; generic roles such as PROGRAM, INIT, and RUNTIME are excluded, and ordinary local-variable names are not primary evidence.Source: §3.2.3 · p. 6

3.2.4 TF-IDF Vectorization

  • TF-IDF vectorization maps binary and source features into comparable spaces separately for each representation, reducing common-feature influence and emphasizing discriminative features.CDFG features include WL structural labels, normalized-token n-grams, and call-label sequences; FCG features encode function roles and caller–callee relationships, while Symbols encode recovered names and roles.Source: §3.2.4 · p. 6

3.3 Similarity Calculation

PLC-Bin2Src computes cosine similarities between each binary query and source candidate across CDFG, FCG, and Symbols vectors, then averages the scores equally. It ranks candidates by the resulting fused score in descending order.

3.3.1 Cosine Similarity

  • Cosine similarity is computed separately for CDFG, FCG, and Symbols vectors, yielding scores for within-function semantics, call structure, and recovered-symbol evidence.The three scores are inputs to equal-weight fusion.Source: §3.3.1 · p. 6

3.3.2 Equal-Weight Similarity Fusion

  • The fused matching score is the equal-weight average of the CDFG, FCG, and Symbols similarity scores.Each representation receives weight 1/3, so intraprocedural structure, program-level calls, and recovered-symbol evidence jointly determine ranking.Source: §3.3.2 · p. 6

3.3.3 Top-k Candidate Selection

  • For each binary query, PLC-Bin2Src sorts fused scores for all source candidates in descending order to produce the candidate ranking.The position of the true source in that sequence is its rank, and the first k candidates form the returned top-k set.Source: §3.3.3 · p. 7

4 EVALUATION

Evaluation tests matching effectiveness across four PLC toolchains, representation combinations, and pipeline runtime on PLC-BEAD. Results include high retrieval accuracy, fast matching after preprocessing, and identifiable error patterns.

4.1.1 Evaluation Dataset

  • 2,358 of 2,431 PLC-BEAD samples were evaluated; all 73 exclusions were CODESYS, and each platform's candidate corpus contained compatible programs with known binary matches.The four platform corpora contain 482 CODESYS, 617 GEB, 619 OpenPLC v2, and 640 OpenPLC v3 samples.Source: §4.1.1 · p. 7

4.1.2 Evaluation Metrics

  • Recall@1 and Recall@5 measure first-rank and top-five coverage, while MRR reflects the true source's rank position and overall ranking quality.The evaluation reports Recall at k=1 and k=5.Source: §4.1.2 · pp. 7–8

4.2 RQ1: Overall and Platform-Level Matching Results

  • 95.89% Recall@1, 99.66% Recall@5, and 0.9769 MRR overall; platform Recall@1 spans 94.83%–98.55%, with CODESYS 3.72 points above OpenPLC v2.The platform-level comparison is reported alongside the overall results.Source: Table 2 · p. 8, §4.2 · p. 8

4.3 RQ2: Representation Combination Analysis

  • 95.89% Recall@1, 99.66% Recall@5, and 0.9769 MRR: equal-weight three-way fusion beat the strongest pair by 2.12 and 0.42 percentage points, and 0.0136, respectively.The three-way configuration also outperformed every individual representation and pairwise combination.Source: Table 3 · p. 8, §4.3 · p. 8

4.4 RQ3: Runtime Cost by Stage

  • 0.67–2.15 s for matching after preprocessing and representation construction; binary preprocessing dominates at 467.73–1141.17 s, while source preprocessing is performed once in 180.81 s.Figure 6 reports total runtime in seconds on a logarithmic scale.Source: Figure 6 · p. 8, §4.4 · p. 8

4.5 Analysis of Results Not Ranked First

  • 89 of 97 queries not ranked first still place the true source in the top five; errors include normalized-name collisions, wrong symbol associations, and nondiscriminative features.Most errors occur among leading candidates with similar scores, though a small number rank the true source substantially lower.Source: §4.5 · pp. 8–9

5 DISCUSSION

The discussion treats recoverable symbols as useful but incomplete evidence for matching. Control-data and call-organization evidence complements names when candidates share similar names or function roles.

5 DISCUSSION

  • Recoverable naming clues are available in the evaluated PLC-BEAD artifacts, but symbols alone do not uniquely determine source correspondence.Symbols-only achieves 81.89% Recall@1, compared with 95.89% for equal-weight fusion of CDFG, FCG, and Symbols.Source: §5 · p. 9
  • CDFG and FCG add control-data and call-organization evidence that distinguishes candidates sharing similar names or function roles.The paper uses recovered symbols as a complementary representation rather than reducing matching to name comparison.Source: §5 · p. 9

6 THREATS TO VALIDITY

The evaluation’s validity is bounded by its inherited PLC-BEAD ground truth, tool-dependent analysis, and limited platform and artifact coverage.

6.1 Construct Validity

  • Evaluation ground truth follows PLC-BEAD’s data organization, so errors in source–binary correspondences, platform labels, or compilation artifacts in its samples also enter the evaluation.Source: §6.1 · p. 9

6.2 Internal Validity

  • Analysis tools and rules may introduce omissions or representation bias, and consistent frontends, candidate sets, and evaluation rules cannot eliminate tool errors.The cited processes include decompilation, disassembly, ST-to-C generation, parsing, and normalization.Source: §6.2 · p. 9

6.3 External Validity

  • Conclusions cover four PLC platforms and engineering-generated artifacts with recoverable naming clues, not all vendors, toolchains, architectures, or optimization settings.Deliberately stripped or name-obfuscated binaries remain conditions for future evaluation; equal-weight fusion may also be suboptimal under different representation quality or platform distributions.Source: §6.3 · p. 9, §6.1 · p. 9

7 RELATED WORK

Related work addresses binary-to-source matching in general-purpose software and semantic recovery in PLC binaries; PLC-Bin2Src connects these directions to rank corresponding ST files.

7.1 General-Purpose Binary2Source Matching

  • General-purpose binary2source methods use lexical features, structural relations, or learned shared representations to match source and binary code.Examples span string-based reuse detection and version identification –, graph-based matching [7], –, and learning-based approaches,,,, [32]–.Source: §7.1 · pp. 9–10

7.2 PLC Binary Analysis

  • PLC binary-analysis work exploits platform and runtime characteristics to recover structures and control logic, while recovered information also supports fuzzing, vulnerability localization, and patching.PLC-BEAD contains 2431 paired binaries and ST programs across CODESYS, GEB, OpenPLC v2, and OpenPLC v3.Source: §7.2 · p. 10
  • General-purpose matching methods do not target PLC-specific artifacts, while PLC binary-analysis methods do not identify the corresponding ST source file from a candidate repository.Source: §7.2 · p. 10
  • PLC-Bin2Src connects the two areas through platform-aware semantic recovery, aligned binary and source representations, and source-candidate ranking.Source: §7.2 · p. 10

8 CONCLUSION

PLC-Bin2Src retrieves corresponding ST source files for binaries from four PLC platforms by matching comparable program representations. On PLC-BEAD, it achieves high retrieval scores across those platforms.

8 CONCLUSION

  • The framework retrieves ST files corresponding to binary artifacts from CODESYS, GEB, OpenPLC v2, and OpenPLC v3.Source: §8 · p. 10
  • 95.89% Recall@1, 99.66% Recall@5, and an MRR of 0.9769 across four platforms on PLC-BEAD.Source: §8 · p. 10
  • PLC-Bin2Src ranks source candidates by combining similarity scores for comparable CDFG, FCG, and recovered-symbol representations.Source: §8 · p. 10
Loading 2609.08563v2…