Part of Embedded Firmware & Control · related to Obsolete Electronics Replacement
Firmware reverse engineering: extraction, behaviour analysis and reimplementation for industrial equipment
Micro Digital Engineering works with existing firmware in industrial equipment when the source code is lost, the microcontroller is obsolete or the functions have to move to new hardware. Depending on the device and your goal, we extract the available executable image, analyse what the firmware does, or implement its functions as new firmware with source code. An extracted binary is not source code: the original source code and development project cannot be reliably reconstructed from it.
Confidential task? We sign an NDA before you share technical files.
Can recovered firmware be migrated when the original source code is unavailable?
Yes, by reimplementation. The behaviour of the existing firmware is established from the extracted image where possible, from measurements on working equipment and from available documentation. These become the requirements for new firmware, which is then tested against the original behaviour. If the microcontroller is read-protected, the image may not be extractable, and the new implementation is based on observed behaviour and documentation.
Three results
Extracted firmware image
A copy of the existing executable image, read through the device’s standard programming and debug interfaces where the device permits read-out. It can be programmed into replacement chips of the same type, but it is not source code and does not make the functions easy to change.
Behaviour analysis
A description of what the firmware does: inputs and outputs, sequences, timing, communication protocols and reactions to faults. It is built from the extracted image where available, from measurements on working equipment and from existing documentation.
New implementation or migration
New firmware with source code that reproduces the agreed functions, on the original or a new microcontroller. When the functions move to a new microcontroller, our firmware work is based on STM32 devices. The new firmware is tested against the behaviour of the original.
What each result gives you
| Result | What you get | What you do not get |
|---|---|---|
| Extracted firmware image | A binary for programming replacement chips of the same type | The original source code; easy changes to the functions |
| Behaviour analysis | A documented description of the functions, interfaces, timing and fault reactions | Working firmware |
| New implementation or migration | New firmware with source code and build instructions, tested against the original behaviour | A bit-for-bit copy of the original program |
Which result is possible depends on the device and is assessed in the first stage. The agreed result is defined in the project agreement.
When new firmware is the better route
- The microcontroller is read-protected, so the image cannot be read out.
- The microcontroller is obsolete, so an extracted image has nothing to run on.
- The functions have to change, or you need source code to maintain the equipment.
- The available image is incomplete or its version is uncertain.
In these cases the work moves from extraction to behaviour analysis and reimplementation.
How the result is verified on real equipment
- An extracted image is programmed into a target unit and tested in the equipment or on a bench that reproduces it.
- Reimplemented firmware is tested against the original: the same inputs and operating sequences are applied, and outputs, timing, protocol messages and fault reactions are compared, measured with calibrated instruments.
- When many cases have to be compared, the comparison can be automated on a test bench, see functional test benches.
The behaviours to be compared are agreed in the requirements before implementation starts.
What firmware reverse engineering cannot promise
- The original source code or development project: it cannot be reliably reconstructed from a firmware binary. Disassembly gives a view of the program, not the developer’s source.
- Read-out of protected microcontrollers: read protection is not bypassed.
- Identical behaviour in states nobody has documented or observed: the new firmware reproduces the behaviours agreed and tested.
When you need this
- A controller fails and the firmware for its replacement is not available.
- The microcontroller is obsolete and the functions have to move to a current one.
- The source code is lost and the equipment needs a change.
- You need to know what the existing firmware does before redesigning the hardware.
What’s included
Assessment of the device and the available firmware, extraction of the image where possible and permitted, analysis of the behaviour, definition of requirements for new firmware, implementation, tests against the original behaviour and documentation.
What you receive
| Deliverable | Format | How it is checked |
|---|---|---|
| Assessment report | Document: what is possible, risks, recommended route | Review with you |
| Extracted image, when agreed | Binary file with its source device and read-out record | Programming and test on a target unit |
| Behaviour description | Document: inputs, outputs, protocols, timing, fault reactions | Measurements on working equipment |
| New firmware, when agreed | Source code with build instructions and image | Tests against the original behaviour |
| Comparison test report, for new firmware | Document | Results of the agreed comparison tests |
How the work runs
- You confirm that you own the equipment or are authorised to maintain it; the goal is agreed.
- The device and the available firmware are assessed, and the route is recommended.
- The image is extracted where possible and permitted.
- The behaviour is analysed and documented.
- When agreed, the new firmware is implemented to the documented behaviour.
- The result is verified on real equipment against the original.
- Images, source code and reports are handed over.
What to send us
- A description of the equipment and the controller.
- Samples of the device, including a working unit if available.
- Any documentation, protocol descriptions or old source fragments.
- What you need: a copy for spare parts, a migration or new functions.
- Confirmation that you own the equipment or are authorised to maintain it.
Common questions
Will we receive the original source code?
No. The original source code and development project cannot be reliably reconstructed from a firmware binary. If maintainable source code is required, we assess reimplementation of the agreed functions, and the new firmware is delivered with its source.
Can you extract firmware from any microcontroller?
No. It depends on the device and its protection settings, and is assessed in the first stage. Read protection is not bypassed, and we work only on equipment you own or are authorised to maintain.
Can the new firmware run on a different microcontroller?
Yes. Moving the functions to a current microcontroller is a typical reason for reimplementation, usually together with a redesign of the board, see obsolete electronics replacement.
How do we know the new firmware behaves like the old one?
The behaviours to compare are agreed in the requirements and tested on real equipment with the same inputs and sequences as the original.
Related services
- Embedded firmware and control — new firmware development.
- Obsolete electronics replacement — replacement of the controller board.
- PCB reverse engineering — analysis of the board around the controller.
- Test benches — test equipment to compare new and original behaviour.
Discuss the firmware
Describe the equipment, the controller and what you need to achieve.
Confidential task? We sign an NDA before you share technical files.