Many machines, test stands and control systems run on software nobody fully understands anymore. The original developer has left, the documentation is missing, and sometimes the source code is too. Reverse engineering recovers what that software actually does, so it can be supported, modernized or replaced safely. Sciotex can often reverse engineer old, undocumented industrial systems and modernize their software.
Why undocumented industrial software is a risk
- Nobody can fix it confidently when it fails
- Small changes cause unexpected side effects
- Hardware cannot be replaced because nobody knows how it is used
- Knowledge depends on one person, or on no one
- Audits and quality reviews cannot show how results are produced
What reverse engineering recovers
| What | How it is recovered |
|---|---|
| Logic and sequences | Reading source code, compiled programs, PLC and DCS projects, scripts and configuration files |
| Signals and hardware | Tracing wiring, I/O channels, device addresses and communication protocols |
| Timing | Measuring how fast loops run, when outputs change and how devices are synchronized |
| Data | Decoding file formats, databases and messages the system reads and writes |
| Behavior | Recording inputs and outputs across normal runs, faults and edge cases |
How the process works
When the source code is missing
Missing source code makes the job harder, but not always impossible. Compiled programs, PLC uploads, configuration files, log data and careful observation of the running system can often reveal enough to rebuild the software with confidence. In the worst cases, the requirements are rebuilt from behavior alone, with the old system kept available for side-by-side comparison.
What comes after reverse engineering
Recovered knowledge is the foundation for every next step: documenting and maintaining the system, refactoring or rewriting it, replacing obsolete hardware, or upgrading the operator interface. See the industrial software modernization guide for the full process.
Frequently asked questions
Often, yes. Reverse engineering recovers the logic, signals and behavior of the existing system, which then guides documentation, refactoring, re-platforming or a rewrite.
Sometimes. Compiled programs, PLC uploads, configuration and log files, and observation of the running system can reveal enough to rebuild it, with the old system kept for side-by-side comparison.
By recording the old system’s inputs and outputs across normal runs, faults and edge cases, and using those recordings as acceptance tests for the new software.
It shouldn’t. Most of the work uses copies of the software and passive observation of the running system, scheduled around production.
