When the design basis has to be recovered, not remembered

Legacy safety-critical software often carries significant capability — and significant risk. When the design basis is incomplete, undocumented, or no longer trustworthy, reverse engineering provides the path from code that works in practice to software that can be formally understood, safely modified, and defended under regulatory review.

What reverse engineering actually recovers

The goal of reverse engineering in a safety-critical context is not to reproduce the code or generate a narrative description of what it does. It is to extract the actual design: the state behavior, interface contracts, data flow, control logic, and structural partitioning that the software was built around — whether or not those decisions were ever made explicit. The recovered documentation becomes the engineering basis for everything that follows: requirements traceability, code review, test planning, and formal assessment.

This is an engineering activity, not a clerical one. A recovered design artifact is evaluated for soundness, not just completeness. Where the implementation reflects a coherent design, that design is documented. Where it does not — where undocumented assumptions, boundary conditions, or structural inconsistencies exist — those findings are part of the deliverable.

When this work is needed

Reverse engineering is typically required when a program has inherited software without its design materials, when documentation has diverged from the implementation over years of undocumented modification, when anomalous behavior cannot be explained from available artifacts, or when prototype or experimental software must be brought under formal engineering control for a regulated application. It appears frequently in programs transitioning legacy aerospace, medical device, or industrial control software to a higher assurance level or a new certification standard.

The need often surfaces at program transitions: a change in ownership or supplier, a regulatory submission that requires design evidence the program does not have, or a safety incident that demands a credible technical explanation. In each case, the work that should have been done during original development must now be done in reverse.

Standards applicability

DO-178C, IEC 62304, and IEC 61508 all require that software be developed and verified against documented design artifacts. When those artifacts do not exist or cannot be trusted, reverse engineering provides the path to reconstruct them from the implementation itself. Under DO-178C, recovered design documentation establishes the architectural and detailed design baseline against which code review and structural coverage analysis are conducted. Under IEC 62304 and IEC 61508, it supports creation or repair of the design record required to demonstrate that software performs its intended safety function. Without a recovered design basis, programs cannot credibly demonstrate compliance regardless of how the software behaves in testing.

What an engagement produces

Depending on program scope and downstream needs, a reverse engineering engagement may produce recovered architecture descriptions, interface specifications, state models, data flow diagrams, and behavioral descriptions derived directly from source code analysis and available system context. These artifacts then serve as the design baseline for traceability, verification planning, and formal review. The engagement may also produce a findings assessment identifying structural risks, undocumented assumptions, or design areas that require correction before downstream activities can proceed reliably.

Scope and duration

A focused engagement on a discrete component or subsystem typically takes one to three weeks. A broader effort covering full software architecture — including all interfaces, state management, and behavioral partitioning — typically takes four to eight weeks or more. Scoping begins with a review of available materials and a definition of what the recovered documentation must cover to support downstream verification and certification activities.

SafeCode has provided reverse engineering support for embedded software in aerospace, medical device, and industrial safety applications. If your program is working with legacy software whose design basis needs to be recovered or established, contact SafeCode to discuss scope.

Frequently asked questions

What is reverse engineering in the context of safety-critical software?
Reverse engineering for safety-critical software is the disciplined process of recovering design understanding from an existing codebase when the original documentation is incomplete, missing, or no longer trustworthy. The goal is not to reproduce the code, but to extract the actual design — the state behavior, interface assumptions, data flow, and control logic — so the software can be understood, safely modified, and brought under formal engineering control. In regulated environments, this recovered understanding becomes the engineering basis for verification, traceability, and certification activities.
When does a safety-critical program need reverse engineering?
Reverse engineering is typically needed when a program has inherited software whose original developers are no longer available, when documentation was never created or has diverged from the actual implementation, when anomalous behavior cannot be explained from available materials, or when an experimental or prototype capability must be brought under formal engineering control for a regulated application. It is also common in programs transitioning legacy aerospace, medical device, or industrial control software to a new standard or assurance level where the existing evidence base is insufficient.
What does a reverse engineering engagement produce?
A reverse engineering engagement typically produces recovered design documentation — architecture descriptions, interface specifications, state models, data flow diagrams, and behavioral descriptions — derived directly from analysis of the source code and available system context. This documentation then serves as the design baseline for requirements traceability, test planning, code review, and formal review. Depending on program needs, the output may also include an assessment of areas where the design is structurally unsound or where undocumented assumptions create risk.
How does reverse engineering support DO-178C, IEC 62304, or IEC 61508 compliance?
All three standards require that software be developed and verified against documented design artifacts. When legacy software lacks those artifacts, reverse engineering provides a path to reconstruct them from the implementation itself. Under DO-178C, recovered design documentation establishes the architectural and detailed design baseline against which code review and structural coverage analysis are conducted. Under IEC 62304 and IEC 61508, it supports creation or repair of the design record needed to demonstrate that the software performs its intended safety function. Without this recovered basis, programs cannot credibly demonstrate compliance regardless of how the software actually behaves.
Is reverse engineering the same as re-documenting code?
No — and the distinction matters. Re-documentation is a clerical activity: converting what the code does into prose or diagrams without engineering judgment. Reverse engineering is an analytical activity that identifies what the software was designed to do, how that intent is expressed in the implementation, where the design is coherent and where it is not, and what the actual behavioral and interface contracts are. The result is an engineering artifact, not a transcription. In safety-critical contexts, the difference is significant because regulators and reviewers assess design documentation for engineering soundness, not just completeness.
What types of legacy software are good candidates for reverse engineering?
Good candidates include embedded software developed under earlier or less formal processes that must now meet regulated standards, prototype or research code being transitioned to a production or certified application, software inherited through acquisition or supplier change where design materials were not transferred, and codebases where behavior has drifted from documentation over years of undocumented modification. Software written in C, Ada, or assembly in long-running aerospace, defense, industrial, or medical programs is particularly common in this category.
How long does a reverse engineering engagement take?
Duration depends on codebase size, language complexity, availability of partial documentation, and how much behavioral analysis is required. A focused engagement on a discrete software component or subsystem may take one to three weeks. A broader effort covering a full software architecture — including all interfaces, state management, and behavioral partitioning — typically takes four to eight weeks or more. Scoping begins with an assessment of available materials and a clear definition of what the recovered documentation must cover to satisfy downstream verification and certification needs.
Can reverse engineering be used to isolate the cause of anomalous behavior?
Yes. When a system exhibits unexpected behavior that cannot be explained from available documentation, reverse engineering provides the analytical basis for tracing that behavior to its structural cause. This may involve recovering the state model to find unexpected transitions, analyzing data flow to locate unintended side effects, or reconstructing interface assumptions to identify where boundary conditions are handled incorrectly. In safety-critical programs, this kind of analysis is often prerequisite to any corrective action because the fix must address the actual design, not just the symptom.