When the vendor is gone and the manual never existed.
A controller whose maker closed, an application whose source left with the contractor who wrote it, a device that talks a protocol nobody documented, a file format only one retired program can read. If you own it or operate it and need to keep it running, connect it to something new, assess its security or replace it safely, we work out how it actually behaves and write it down.
Why it matters
Plenty of equipment outlives its support. The vendor is acquired or closes, the documentation was never delivered, the integrator who knew it has moved on, and the thing still sits in the middle of work everyone depends on. The usual choices are to leave it alone and hope, or to rip it out on a deadline. Knowing how it works gives you a third.
You cannot secure, integrate or migrate what nobody understands. A replacement project that starts without knowing what the old device actually sent, stored or accepted tends to find out during cut-over.
We keep this on the right side of the line. The work is on equipment and software you own or are responsible for operating, for interoperability, security, maintenance and migration. We do not defeat licensing or copy protection, and we say so at the scoping call if a request crosses that line.
What it covers
- Protocols and interfaces
- Undocumented serial, fieldbus and TCP/UDP protocols recovered from captures of the device doing its normal job: message framing, checksums, addressing, command and register maps, and the timing the other end expects.
- Firmware and embedded devices
- Firmware read from an update file or, where needed, from the device's own flash on a bench unit: the file system extracted, services and hard-coded credentials identified, and the update and boot path examined for how it could be abused.
- Software and file formats
- Orphaned applications and the formats they keep data in: configuration files, project files and databases a current tool cannot open, recovered well enough to read, convert or migrate the data out.
- Security assessment of a black box
- When a device or application has no vendor left to answer questions, we assess it directly: exposed services, authentication, cryptography, update integrity, and what an attacker on the same network could make it do.
How it runs
Agree what you own and what you need
Confirm ownership or operating responsibility, the goal (keep it running, connect it, assess it, replace it), and what we may and may not touch. Live equipment stays in service; anything intrusive happens on a spare unit or a bench.
Observe it working
Captures, logs and file snapshots of the device or program doing its normal job, before any static analysis. Behaviour on the wire is the ground truth a disassembly has to agree with.
Take it apart
Static and dynamic analysis of the firmware or binary, on a bench or in an emulator, until each observed behaviour is explained rather than assumed.
Prove it and write it down
A written specification of what we recovered, checked by driving the real equipment or a bench unit from it, and whatever you asked for on top: a findings report, an interface for integration, a data export or a replacement plan.
A page of what you are handed
ARTA CYBER
Representative deliverable — site and figures redacted.
Recovered register map — excerpt
| Register | Access | Type | Meaning | How confirmed |
|---|---|---|---|---|
| 0x0010 | read | int16, big-endian | Temperature, probe 1, °C × 10 | Tracked a reference thermometer at three points on the bench unit. Negative values are two’s complement. |
| 0x0012 | read | uint16 | Relative humidity, % × 10 | Matched the unit’s own front-panel reading across a day of captures. |
| 0x0014 | read | bitfield | Bit 0 leak sensor, bit 1 door contact, bit 2 probe fault | Each input toggled on the bench and the bit observed. |
| 0x0020 | read/write | int16 | High-temperature alarm threshold, °C × 10 | Values outside the display’s range are stored and acted on, not rejected. Confirmed on the bench unit only. |
| 0x0030 | write | uint16 | Command: 0x0001 clear alarms, 0x00A5 enter service mode | Service mode accepts threshold and network changes from any host with no password. Raised as finding RE-03. |
What you are left holding
- Written specification of the recovered protocol, interface or file format: framing, fields, commands and error behaviour, with the captures it was derived from.
- Register, command or point map, checked against the real equipment or a bench unit.
- Firmware or application security findings with evidence and a specific fix or compensating control.
- Where it is needed, a small reference tool or parser that reads the format or talks the protocol, handed over with its source.
- Migration or replacement notes: what the new equipment has to reproduce so nothing downstream notices the change.
- A clear statement of what we could not recover, and why.
Worked to
- OWASP Firmware Security Testing Methodology
- NIST SP 800-115
- CVSS v4.0
Once a protocol is recovered, we can stand a virtual copy of the device up in our OT Asset Simulator and test an integration or a replacement against it, so the old unit does not have to come out of service to be the test target. This works today where the device speaks Modbus TCP or DNP3.
OT Asset SimulatorQuestions we are asked first
Can this disturb equipment that is still in service?
Not if we can help it, and we agree the limits before starting. Observation of live equipment is passive: a capture of normal traffic, or a copy of a file. Anything that means writing to the device, opening it or reading its flash happens on a spare unit or a bench. If there is no spare, we say what that limits and agree it with you.
Is this legitimate work?
Analysing equipment and software you own or are responsible for, to keep it working, make it interoperate, assess its security or move off it, is the work we take on. We confirm ownership and purpose at scoping, and we do not take on work to defeat licensing, copy protection or someone else's product. Where a contract or licence term bears on the work, we flag it so you can check it with counsel before we start.
What do you need from us to start?
Whatever exists: the device or a spare unit, update files or installers, old manuals or screenshots, captures if you can take them, and a description of what it does on a normal day. Partial documentation is still useful, because it tells us what to check rather than what to believe.
What if you cannot recover everything?
Then the report says what is known, what is inferred and what is still unknown, and what it would take to close the gap. We do not fill a gap with a guess and present it as a specification.
Can you build a bridge or a replacement from what you find?
Often, yes. The specification is what our software and integration work builds from, whether that is a small bridge that lets the old device talk to a new platform, a data export, or the acceptance tests for its replacement.
Related work
Tell us what is bothering you.
An email is enough to start with. A scoping call is free and there is nothing to commit to, and where we are not the right people we will say so and point you at someone who is.
A first call about one site. No charge, and nothing to commit to.
Our named next step: we come to one site and hand you an assessment you can act on.