Allegations of software copying are often framed as a search for identical source code. That framing is too narrow for many real investigations.
Source may have been rewritten, identifiers renamed, code obfuscated, the original repository made unavailable, or the systems made comparable only through compiled binaries and observed operation. In those circumstances, the absence of a direct textual match does not resolve the technical question. It changes the question that must be examined.
A defensible investigation asks whether independently observable relationships exist across multiple layers of the systems: source and binary structure, control and data dependencies, architecture, data models, workflows, runtime behaviour and development provenance. It records what those relationships establish, what alternative explanations remain possible and what requires expert interpretation.
Similarity measurements are technical evidence, not automatic proof of copying, derivation or infringement. The examination should therefore combine preservation, provenance, complementary analysis methods, reproducibility and a clear separation between fact, data, inference and legal conclusion.
The evidentiary problem is broader than source-code comparison
Two systems can differ textually while retaining relationships at other levels. A rewritten implementation may preserve aspects of an algorithmic structure. A compiled binary may contain function relationships that are not apparent from source text. Two products may expose similar interfaces, reproduce unusual edge-case behaviour or implement comparable component interactions.
Those observations can be relevant, but they do not all mean the same thing. Similarity may arise from common libraries, standard algorithms, shared requirements, independent reimplementation or access to an earlier implementation. The technical task is to test competing explanations against preserved evidence rather than select the most convenient explanation.
A software investigation should therefore be designed as a layered examination. Each method contributes a defined type of observation, and the results should be capable of review and reconstruction.
Start with preservation and provenance
The first practical risk is losing the evidence needed to explain how a result was obtained. Before comparative analysis, investigators should identify and preserve the available materials from both the exemplar and suspect systems. Depending on the matter, this may include:
- Executables, binaries and installers;
- Available source code and version-control repository dumps;
- Configuration files, documentation, API specifications and database schemas;
- Deployment artefacts, package manifests and dependency records;
- Build logs, compiler toolchains and container or virtual-machine images;
- Relevant operating-system images and timestamps; and
- Publicly archived code or other provenance sources.
Cryptographic hashes can support later integrity checking of acquired materials. They should be recorded within a documented acquisition and handling process that also addresses access, custody, analysis activity and relevant authority. A hash does not by itself establish authenticity, provenance, completeness, acquisition authority or chain of custody. Fuzzy or similarity digests may assist with bulk comparison and fragment identification, but they should not be treated as conclusive evidence of derivation.
Where code is available in public archives, provenance reconstruction may include recording exact commit identifiers or Software Heritage identifiers. Such anchors can help establish that particular material was available in an archive and preserve a reference to the examined object. They do not, by themselves, establish authorship, ownership, who accessed the material, or whether it was used.
ISO/IEC 27037 provides guidance for identification, collection, acquisition and preservation of digital evidence. ISO/IEC 27042 addresses analysis and interpretation. These standards provide a process foundation; they do not prescribe a single software-similarity test or resolve the legal meaning of a technical finding.
Define the allegation as testable artefacts
Allegations such as “the workflow was copied” or “the business logic is the same” are too broad to analyse without further definition. The investigation should map the allegation to observable artefacts and test cases.
For example, an asserted workflow may be represented through user stories, API sequences, input/output examples, state transitions and end-to-end scenarios. An alleged architectural relationship may be examined through component diagrams, message flows, database schemas and API surfaces. A claimed algorithmic relationship may require controlled inputs, output comparisons and structural analysis of the relevant implementation.
This scope-mapping stage helps distinguish what is actually being compared. It also prevents a general feature, common interface or expected industry function from being treated as a uniquely identifying technical relationship.
Use multiple analytical layers
1. Textual and lexical comparison
Where source or source-like text is available, token-based, tree-based and fingerprinting methods can provide rapid triage. Lexical analysers and source-code comparison approaches, including the MOSS tool referenced in the available material, can identify potentially similar passages or fragments. No named tool should be treated as universally suitable or validated for every forensic context.
For rewritten or obfuscated material, comparisons may be repeated after normalisation, such as removing formatting differences, neutralising identifier names and controlling for comments or whitespace. The output should preserve matching contexts, parameters and exclusions so that a reviewer can assess what was actually compared.
Textual comparison is useful, but it is fragile. Common libraries, standard algorithms, shared templates and identical comments can create matches that do not indicate copying. A similarity percentage from one tool should therefore be presented as a measured output in context, not as a conclusion about derivation.
2. Syntactic and structural comparison
Abstract Syntax Trees and Control Flow Graphs allow comparison beyond literal text. Tree structures, subtrees, control-flow relationships and structural fingerprints may remain comparable after formatting changes or identifier renaming.
A robust examination should avoid relying on a single structural algorithm. Different methods, such as subtree matching and tree-edit comparisons, can expose different aspects of a relationship. The choice of methods and their limitations should be documented, with raw outputs retained for review.
The purpose is to test whether relationships persist at a different representation of the program, not to make structural similarity appear conclusive by itself.
3. Semantic analysis through dependencies and code graphs
Program Dependence Graph and Code Property Graph approaches can represent relationships involving data and control dependencies. These representations may help examine semantic or algorithmic structure that survives some renaming and refactoring.
PDG-based analysis and CPG frameworks can support queries across functions, dependencies and other program properties. Their outputs remain dependent on the input material, processing choices and interpretation of the resulting relationships. They should therefore be used as part of a comparative methodology, with the relevant graphs, mappings and parameters preserved.
A semantic relationship may be consistent with reuse of an algorithmic approach. It may also be consistent with independent implementation of a known or shared approach. The distinction cannot be made from a graph result alone.
4. Binary and function-level comparison
When source is unavailable or has been substantially rewritten, the examination may move to compiled artefacts. Binary-diffing, function matching and fuzzy function hashing can compare functions, call graphs and other binary-level characteristics.
Compiler choice, optimisation, target architecture and link-time decisions can materially change binary artefacts. A failure to match at binary level therefore does not establish independent development. Conversely, a match may reflect a shared library or common third-party component rather than copying of original functionality.
For that reason, binary analysis should use more than one independent technique where practicable. Static disassembly and control-flow matching may be combined with dynamic trace comparison or function-embedding approaches. Compiler and optimisation hypotheses should be recorded and, where possible, tested through controlled cross-compilation experiments.
The limitations of each method should remain visible. The supplied material does not support treating one binary-similarity tool or algorithm as infallible, or converting its output into a probability of derivation.
5. Behavioural and dynamic analysis
Runtime behaviour provides another way to compare systems when source-level evidence is incomplete. Controlled tests may examine input/output mappings, error messages, timing characteristics, network traces, protocol sequences and state transitions.
Functional harnesses, API calls, UI automation and workload replay can be used to apply comparable scenarios. System-call traces, network captures, logs and execution traces may provide additional observations about how the systems behave under those scenarios.
Behavioural similarity can be informative, particularly where the same unusual workflow or edge-case behaviour is reproduced. Similar behaviour may also result from shared requirements, common dependencies, compatible standards or independent design decisions. Test cases, environmental conditions and captured outputs should be recorded so that the finding can be independently understood.
6. Architecture, data models and system structure
Source-code analysis should not obscure the larger system. Architectural comparison may examine component boundaries, sequence relationships, database schemas, API surfaces, message flows and deployment structure.
Normalised architecture models can help identify where components and interactions correspond. Business-logic allegations can be expressed through workflows, state transitions and input/output relationships rather than left as broad assertions.
A relationship at this level may be relevant to the investigation, but it remains necessary to assess whether the structure is distinctive, technically constrained, required by an external specification or otherwise explainable without derivation. The technical record should show both the observed overlap and the alternatives considered.
Provenance can change the meaning of similarity
Similarity findings are stronger when they can be assessed alongside evidence about how the systems were developed and what materials were available. Relevant provenance may include version-control history, build logs, package manifests, archived source snapshots, dependency records and timestamp records whose source, integrity, clock context and corroboration have been evaluated.
The aim is not to use provenance as a substitute for technical comparison. It is to contextualise the comparison. A function relationship, architecture overlap or unusual behavioural match may carry a different significance depending on whether a common library, public archive, shared specification or documented development path provides an alternative explanation.
Attribution to a specific individual, access event or time requires particular care. Similarity alone does not establish attribution. Relevant metadata, such as version-control access records, logs or timestamp records, requires assessment of its source, integrity, clock context and corroboration, together with qualified human expert review.
Separate facts, data, inferences and hypotheses
A technically defensible report should make the level of each statement clear. A useful structure distinguishes at least five categories.
Fact is a verifiable observation. For example, a particular binary contains a reported relationship to a function in another binary under a specified extraction process, representation, fuzzy-hashing algorithm and parameter set. That output is dependent on those choices and does not establish functional identity or derivation. Another example is a controlled test that produced a specified output.
Data consists of the preserved raw material and outputs: hashes, logs, traces, graph mappings, tool reports, captured network traffic and reproduction records.
Inference is an expert interpretation that connects observations to possible explanations. It should state assumptions, confidence qualifiers and alternative explanations. For example, an overlap may be consistent with reuse of an algorithmic approach, while independent implementation or a common library remains possible.
Hypothesis is a testable explanation. One hypothesis might be that both systems incorporated a common open-source library. The report should specify what additional evidence could confirm or refute that explanation.
Recommendation identifies the next technical or evidentiary step, such as obtaining repository history, preserving build logs, running controlled rebuilds or performing targeted dynamic tests.
This structure prevents a raw tool output from being presented as an expert conclusion and prevents an inference from being mistaken for a directly observed fact.
Reproducibility is part of the evidence
A result that cannot be reconstructed is difficult to evaluate, particularly when the analysis may be examined by another expert. Every analysis artefact should therefore have a provenance record containing, as applicable:
- The original file path and cryptographic checksum;
- The tool name and exact version;
- The operating-system and analysis environment;
- Parameters, filters and configuration values;
- Scripts, seed data and test cases;
- Container or virtual-machine snapshots; and
- Raw outputs and the steps used to derive reported results.
Analysis pipelines may be captured in containers or other immutable environments. A reproducibility bundle can include checksums, scripts, relevant tool configurations and a runbook that enables another qualified examiner to repeat the core derivations.
The NIST Computer Forensics Tool Testing Program material can be used as a resource for structured documentation of tool-testing procedures, test sets, versions and configurations where relevant. It should not be treated as a general guarantee of forensic reliability, a universal reproducibility standard or validation of every similarity-analysis method. Where possible, tools should be assessed against controlled material appropriate to the method. Models, weights and training metadata should also be preserved when machine-learning methods are used.
Reproducibility does not remove interpretation. It makes the underlying process available for scrutiny.
Weight convergence, not isolated scores
There is no universally accepted quantitative conversion from multi-modal similarity evidence into a probability of derivation or copying. There are also no standardised fusion rules that combine textual, structural, semantic, binary and behavioural findings into a single metric accepted across jurisdictions.
Accordingly, a decision framework should focus on convergence and explanation rather than an artificial numerical threshold:
- Single-modality similarity, such as a lexical match alone, generally requires substantial contextualisation and corroboration.
- Convergence across independent technical modalities may provide a stronger basis for technical inference, particularly where the same modules or features align in different representations.
- Convergence combined with provenance, such as version-control history, build records, archived material or distinctive data-model relationships, may provide a stronger technical foundation for an expert opinion.
Technical convergence remains subject to the applicable jurisdiction, procedural rules and expert review. It does not itself determine a legal conclusion about copying or infringement.
Common limitations and alternative explanations
A credible examination should address reasons why a result may be misleading or incomplete.
Textual matches may reflect common libraries, standard algorithms, templates or comments. Fuzzy hashes can assist in identifying similar fragments but may be affected by targeted obfuscation and should not be used alone to assert derivation.
Binary comparisons can produce false negatives because of compiler, optimisation, architecture or link-time differences. Positive matches can also arise from shared libraries or third-party components. Obfuscation, control-flow flattening, inlining and packing may reduce the reliability of some static methods.
Semantic and behavioural methods may be more resilient to some transformations, but they can require greater resources and still depend on the quality of the test design and interpretation. Machine-learning or embedding-based scores are probabilistic and require explainability, model preservation and careful review.
These limitations define what can responsibly be claimed from the methods. They do not justify treating a score or overlap as a categorical conclusion.
Practical implications for litigation and investigations teams
For counsel and investigations professionals, important decisions often occur before a similarity result exists.
Preserve exemplar and suspect systems early, including binaries, repositories where available, build records, dependencies and relevant environments. Define the alleged relationship in terms that can be tested. Record refusals or gaps in production rather than silently treating missing material as evidence of one explanation.
Ask the technical team to preserve raw outputs, not only summary scores. Require the report to identify tools, versions, parameters, environments and hashes. Ask which independent modalities were used, what alternative explanations were tested and which conclusions remain dependent on expert review.
A technical examination can establish documented observations and support qualified inferences about relationships between systems. It should not turn a similarity score into a categorical assertion of copying, infringement or individual responsibility.
A disciplined route to digital evidence intelligence
When source code differs, the absence of a direct textual match is not the end of the investigation. It is a reason to examine the systems at the levels at which relationships may persist: structure, dependencies, compiled functions, architecture, workflows, runtime behaviour and provenance.
The defensible approach is layered and reproducible. Preserve first. Define the allegation precisely. Use complementary methods. Record raw data and analytical conditions. Test alternative explanations. Distinguish facts from inferences. Route attribution and derivation conclusions through qualified expert review, and keep legal conclusions with legal counsel.
For litigation and investigations teams, the value of this approach is not a more dramatic similarity score. It is a clearer account of what the digital evidence actually establishes, what it does not establish and what further work is required.
IVIDENTIA’s perspective is that software-related evidence should be treated as an intelligence problem before it is treated as a conclusion: establish the provenance, examine the relationships, preserve the reasoning and make uncertainty explicit.
If a matter involves alleged software copying or derivation where direct source-code matches are absent, the appropriate next step is a scoped, standards-aligned technical assessment of the available evidence and the questions it can reliably answer, subject to applicable jurisdictional and procedural requirements.
Sources
- Computer Forensics Tool Testing Program (CFTT), NIST.
- ISO/IEC 27037:2012 — Guidelines for identification, collection, acquisition and preservation of digital evidence, ISO.
- ISO/IEC 27042:2015 — Guidelines for the analysis and interpretation of digital evidence, ISO.
- A Survey on Software Clone Detection Research, Citeseerx / Roy & Cordy.
- Review of Code Similarity and Plagiarism Detection Research Studies, MDPI, Applied Sciences.
- GPLAG: Detection of software plagiarism by program dependence graph analysis, IBM Research / KDD 2006.
- Joern / Code Property Graph documentation, Joern Project / shiftleft.
- BinDiff manual, Google / BinDiff.
- Blanket Execution: Dynamic Similarity Testing (BLEX), USENIX Security.
- A Survey of Binary Code Similarity, academic survey.
- ssdeep — Fuzzy hashing program, ssdeep Project.
- Plagiarism Detection (MOSS), Stanford University.
- Software Heritage — universal source code archive and provenance, Software Heritage.
- How Machine Learning Is Solving the Binary Function Similarity Problem, Cisco-Talos / USENIX Security research and dataset.
