Reverse engineering
Undocumented Visual Basic software from the 1990s for an industrial kiln, worked out and rebuilt offline.
- Role
- Sole engineer
- Client
- Owner of an industrial wood-drying kiln (confidential)
- Year
- 2026
- Status
- Verified offline, not yet run on the kiln
- Stack
- Python, SQLite, React, Vite, Playwright, Unicorn, Capstone, pefile
The system
Four Windows programs from the late 1990s supervise an industrial wood-drying kiln. The owner wanted them preserved and replaced with maintainable software, without putting the kiln at risk.
In numbers
- 1,709 installed files, inventoried and hashed
- 296 real drying recipes read by the new application
- 220 automated tests, all of them running offline
- Zero connections to the kiln: every step ran against simulated hardware
What was known
The four programs as installed: an operator application, a helper that talks to the kiln's controller over a serial port, and two small utilities. With them came their configuration, 296 drying recipes, 481 history files, six language sets and a scanned wiring drawing: 1,709 files in all. Also a decompiler's partial recovery of the code, in which several modules came back empty, and earlier notes and traffic recordings of unknown origin.
What had to be found out
How the programs talk to each other and to the controller. What each field in the recipe and history files means, and in what units. How alarms are recorded. Which side runs the drying program: the software or the controller. None of it was written down anywhere reliable, and some of what was written was wrong.
How it was taken apart
-
Inventory.
Every installed file was hashed and listed before anything else, so nothing could change unnoticed.
-
Read, never touch.
The files and the recovered code were read offline. The running kiln was never contacted, not even to read a value.
-
Run the original.
Its own routines ran in an x86 emulator and a private copy of its Visual Basic runtime, fed controlled inputs and edge cases: rounding, negative values, accented names.
-
Match or mark.
Behavior counted as verified only when the new code matched the original's output. Everything else is labeled inferred or unknown.
The new offline application after a simulated loss of communication. Captured on the simulator, with no machinery connected.
- The last readings stay on screen.
- The process state reads unknown instead of repeating the last known value.
- The sample is marked stale.
- Start and stop stay disabled until the link is restored.
What it made possible
The kiln's software is documented, and an offline replacement already reads its real data.
The documentation covers how its programs talk to each other, what its files contain and how it records alarms. The new application reads all 296 real recipes and the original history, simulates start, stop and a lost connection, and records every action so a session can be replayed exactly.
The new code was checked against the original program's own routines. For the real recipes tested, the data it prepares for the controller matched the original byte for byte, and all 120 fields of the alarm history decode the same way. There are 220 automated tests that run offline.
It has not been connected to the kiln, and will not be until a supervised test is authorized.
AI in this project
Yes. AI coding agents worked on the analysis and the code, under two rules I set: every finding had to be labeled verified, inferred or unknown, and nothing could connect to the kiln.