When a binary, driver or firmware image has no source, no documentation and no vendor left to call, reverse engineering rebuilds the missing picture: what the code actually does, how it talks to other systems, and where the risk lives, so you can maintain, replace or integrate with it on evidence, not assumption.
Software reverse engineering is a scoped investigation of a specific artefact you own or are authorised to have examined. It is not cracking, licence bypass, or a promise to resurrect lost source trees.
Typical targets include Windows executables and libraries, Linux binaries, embedded firmware images, drivers and undocumented file formats or wire protocols. The engagement is built around the engineering questions you need answered, not a generic disassembly dump.
Four outcomes a reverse-engineering engagement can support
Document and keep
The system is ugly but understood, monitored, and cheaper than replacement.
Wrap and isolate
Put a better-controlled interface in front and stop adding features to the old binary.
Reimplement
The behaviour map becomes the specification for a new component, costed as a software project.
Retire
Once you know what the binary was really doing, the business process may move elsewhere.
Original-source recovery is not one of the four. Decompilers emit approximations. The professional artefact is a behaviour map your engineers can maintain. Longer treatment: reverse engineering a legacy binary.
Current landscape
Replace legacy technology, not just patch around it.
ASD’s ACSC treats operational technology (OT), edge appliances and unsupported legacy technology as a national-scale problem. The Annual Cyber Threat Report 2024–25 tells Australian organisations to replace legacy technology, not just patch around it. Reverse engineering is how you decide whether an undocumented binary, driver or firmware image is still an asset worth keeping, or an unpatchable attack surface.
Public cases keep showing the same pattern at the firmware and appliance layer. Mandiant documented zero-day exploitation of Ivanti Connect Secure (CVE-2025-0282) from mid-December 2024, including malware that faked a successful upgrade so administrators thought they had applied the vendor’s fix. That is not a configuration miss. It is firmware and implant behaviour that only static and dynamic analysis of the authorised image will explain.
Supply-chain implants in VPN, firewall and file-transfer appliances also sit in this service, not in a scan. Progress MOVEit’s 2023 SQL injection (CVE-2023-34362) and later critical waves through 2026 showed how a single managed-file-transfer product became a repeated vulnerability class. If you inherited the appliance and have no source, authorised reverse engineering is how you map persistence, covert channels and what “patched” actually changed.
When this fits
The vendor is gone
A legacy binary or embedded firmware image is business-critical, but the original developer, documentation or source is gone.
Trust before production
You need to confirm what a third-party or acquired component actually does before you trust it in production.
Undocumented interfaces
You need to interoperate with an undocumented protocol, file format or hardware interface.
Due diligence
You are evaluating a vendor or acquisition and need independent technical due diligence on their firmware or binaries.
Decisions and outcomes
Every engagement is scoped to answer specific engineering questions: what does this component do, step by step; does it behave differently to how it is documented; is it safe to keep running as-is; and what would it take to reimplement, patch or retire it. Findings are delivered as documentation your team can act on, not raw disassembly.
Scope
Typically included
- Static analysis, disassembly, decompilation, control-flow and data-flow reconstruction, of the authorised target
- Dynamic analysis, instrumented execution, tracing and protocol capture, in a controlled environment
- Documented behaviour maps, state machines or protocol/file-format specifications
- Vulnerability and defect findings surfaced during analysis, ranked by exploitability and impact
Not included unless agreed
- Licence, DRM, anti-cheat or copy-protection bypass, or any work intended to defeat access controls you are not authorised to defeat
- Analysis of targets outside the signed, written scope
- A guarantee of fully reconstructed, compilable original source, reverse engineering documents behaviour, it does not resurrect lost source trees
Deliverables
- A written behaviour map or protocol/file-format specification, structured for engineering re-use
- A findings report that separates confirmed behaviour from inference
- Prioritised integration, hardening or migration recommendations
Process
Authorise
Confirm ownership or written authority for the exact target.
Scope
Agree the artefact, platform and questions to answer.
Analyse
Static and dynamic analysis in a controlled environment.
Report and remediate
Deliver findings and practical next steps.
Methods and standards
Analysis combines manual reverse engineering with disassembly and decompilation tooling appropriate to the target architecture, cross-checked against dynamic execution evidence so conclusions are demonstrated rather than assumed. Supported architectures and toolchains are confirmed during scoping for the specific artefact, we do not publish a blanket platform list that we cannot currently evidence.
Security and evidence
No public evidence upload
This page never accepts malware, source code or evidence. Secure transfer is agreed only after authorisation and scoping, outside this website.
Limitations
What this engagement cannot promise
Reverse engineering documents observed behaviour to the depth the artefact and authorised time allow. It does not reconstruct original source code or developer intent, and it does not guarantee every code path has been exercised.
Common questions
Can you recover the original source code of an EXE or DLL?
No. A professional reverse-engineering engagement documents behaviour, control flow, data structures and interfaces. Decompilation can produce readable approximations, but it is not the original source tree, comments or build system. If your decision is “recover source versus rewrite”, the report is written to support that decision honestly.
Do you reverse engineer software I do not own?
No. We require documentary ownership or written authority for the exact target before work begins. Submitting an enquiry is not authority. See legal and ethical engagement.
How is this different from running a decompiler ourselves?
A decompiler is a starting point. The value is a scoped investigation: which paths matter, what the protocol actually does on the wire, which claims in the documentation are false, and what a maintainer should do next. You receive a behaviour map and decisions, not a folder of unreviewed output.
What do you need from us to start?
Written authority, the authorised artefact (transferred privately after scoping, never through this website), any existing documentation, and the questions the work must answer. Platform and toolchain constraints are confirmed in scoping.
Case Studies
Current published case studies. Public-source illustrations are labelled clearly and are not presented as client engagements. View all case studies.
Six gift cards and a forged executive
A courier employee bought six $500 prepaid cards after mail that looked like it came from an executive. There was no malware. The missing control sat in the payment process.
More than $150,000 to a supplier who never changed banks
A construction firm paid an invoice twice after a supplier mailbox was taken over. No callback. No funds recovered.
The backup that encrypted itself
Ransomware at an auto parts store encrypted the live files and the backup disk still plugged into the same machine. Years of data went with the old system.
Related
Ready to talk about your situation?
Tell us the high-level scope. No malware, source code or evidence – just enough for us to route you safely.