S/03 · Services
Reverse engineering
When the documentation left with the vendor.
Binaries, Android apps, protocols, file formats and legacy systems nobody documented — taken apart, understood and explained, so you can integrate with them, replace them or keep them running.
- Targets
- Binaries, Android apps, protocols, firmware, formats
- You get
- Findings, specs, working code
- Always
- On systems you own or may analyse
- 01
A vendor disappeared and took the documentation with them.
- 02
You need to talk to a device, app or system that has no public API.
- 03
A legacy system works, but nobody knows how.
- 04
You want to know what a piece of software really does.
- D/01
Protocol specifications
We capture the traffic between a device or program and whatever it talks to, then work out every message, field and state from the bytes. The result is a specification your developers can implement against, with real captures attached as proof.
Included
- The frame layout, byte by byte, with field types
- Every message type, and the reply it expects
- The state machine: what is allowed, and when
- Checksums, encodings and any encryption in use
docs/protocol/kiosk-v2.md Kiosk protocol v2 · TCP 5020
Recovered from 212 captured sessions · rev 3
Frame
- 0x02 · length u16 BE · type u8 · payload · crc16 · 0x03
Messages
- 0x10 HELLO → 0x11 HELLO_ACK: device id, firmware version.
- 0x20 TICKET_REQ → 0x21 TICKET: number, counter, time.
States
- IDLE → AUTH → READY. A bad checksum sends it back to IDLE.
Checksum
- CRC-16/CCITT over type and payload, initial value 0xFFFF.
- D/02
Android apps (APK)
We decompile the app, read its native libraries, and watch its traffic on a test device, certificate pinning included. You get the API it talks to written up as a spec, what it stores on the phone and what it sends, so you can integrate with it, recover a lost codebase or check what your own app exposes.
Included
- Decompiled code, mapped and annotated, native .so libraries included
- The app’s API, recovered from live traffic and written up as OpenAPI
- What it stores on the device and sends, and to where
- Security notes: hard-coded keys, weak crypto, exposed components
analysis/com.example.queue · v4.2.0 $ apktool d queue-4.2.0.apk -o out/
✓ 3 dex files · 2 native libs (arm64-v8a)
$ jadx -d src/ queue-4.2.0.apk
! obfuscated with R8 · names restored from strings: 412
$ frida -U -f com.example.queue -l unpin.js
✓ certificate pinning bypassed on the test device
→ POST /api/v3/tickets {branch_id, service, phone}
→ GET /api/v3/queue/12 polling every 5 s
! API key hard-coded in libnative.so
✓ 14 endpoints written to docs/api/openapi.yaml
- D/03
Format documentation
Files and databases from closed systems are decoded field by field: offsets, types, encodings and what each flag means. Once the format is written down, your data is no longer locked inside one vendor’s software.
Included
- A field map with offsets, sizes and types
- Text encodings and date formats, identified
- Edge cases: deleted records, padding, older versions
- A parser that reads real sample files
docs/formats/sched-dat.md Offset Size Type Meaning 0x00 4 char[4] Magic, always SCH1 0x04 2 u16 LE Number of records 0x10 4 u32 LE Date, in days since 1 Jan 1900 0x14 2 u16 LE Time, in minutes after midnight 0x16 40 cp1256 Patient name, padded with spaces 0x3E 1 flags 1 booked · 2 arrived · 4 cancelled - D/04
Behaviour reports
We run the software in a controlled environment and record what it does: which files it touches, which hosts it calls, what it sends and what it keeps. Every claim in the report comes with the capture or trace that shows it.
Included
- Network traffic: destinations, timing and content
- Files, registry keys and local databases it uses
- Anything it sends out about your users or machines
- Captures and traces attached as evidence
captures/agent-trace.log $ mitmdump -w agent.flow --mode transparent
POST telemetry.vendor.example/v1/u · every 15 min
body: hostname, MAC address, installed software
$ frida -f agent.exe -l trace-files.js
open C:\ProgramData\Agent\cache.db (read/write)
! cache.db holds patient names in plain text
✓ 14 behaviours documented, each with a capture
- D/05
Interoperable code
We prove the findings by writing code that talks to the real system. You get a library and a small command-line tool that speak the recovered protocol, tested against recorded traffic, so your own software can use it straight away.
Included
- A library in Go, or the language your team uses
- Tests that replay real captured traffic
- Fuzz tests on the parser
- A command-line tool for trying things by hand
repository - kioskproto/
- frame.goencode · decode
- crc.goCRC-16/CCITT
- client.goHELLO, TICKET, STATUS
- frame_test.goreplays captures
- fuzz_test.gogo test -fuzz
- testdata/
- captures/212 sessions
- cmd/
- main.gotry it by hand
- README.mdstart here
- D/06
Migration paths
When the goal is to leave a closed system, we read its data directly, convert it and load it into one you control. Every run is checked against the source with counts and checksums, so you know nothing was lost on the way.
Included
- An extractor that works on a read-only copy
- A mapping from the old fields to the new schema
- Checks per table: row counts, totals and checksums
- A full dry run before the real cut-over
docs/migration.mmd - D/07
Risk notes
Taking software apart shows its weak spots: hard-coded passwords, home-made encryption, unsigned updates. We write each one down with its severity and a way to reduce the risk while the system is still in use.
Included
- Each issue, with where it lives in the binary
- Its severity, and who could exploit it
- A workaround while the system stays in service
- Notes for the vendor, if they can still be reached
docs/risk-notes.md - Firmware updates are not signedhigh
- An admin password is hard-coded in agent.exehigh
- The local cache stores patient names unencryptedmedium
- The licence check uses a fixed XOR keylow
- Uploads check the server’s TLS certificatefine
- 01
Scope & permission
We confirm what you own and are allowed to analyse before we start.
- 02
Observe
Traffic captures, file samples and runtime behaviour, gathered systematically.
- 03
Take apart
Static and dynamic analysis until every part of the puzzle has a name.
- 04
Prove it
We build working code against our findings — if it interoperates, the spec is right.
Most reverse-engineering projects take three to eight weeks, depending on the target and how well it is protected. You get a short written update every week, so you can stop as soon as you know enough.
- Days 1–3
We confirm ownership and permission, agree the goal, and collect the software, devices and sample data.
- Week 1
Traffic captures, file samples and runtime traces, recorded in a controlled lab.
- Weeks 2–4
Static and dynamic analysis, with the specification written as each part becomes clear.
- Weeks 5–6
Working code built against the findings and tested on the real system.
- Week 7
Handover of the specification, code and risk notes, with a walkthrough for your team.
The specifications
Protocols and formats written up so any developer can implement them.
The evidence
Captures, traces and an annotated Ghidra project behind every finding.
Working code
The library, its tests and the command-line tool, in your repository.
Analysis scripts
Parsers, Frida scripts and Wireshark dissectors, documented for reuse.
The risk notes
Every weakness we found, with its severity and a workaround.
A follow-up session
A call a few weeks later for the questions that come up once you build on it.
- Ghidra
- IDA Pro
- radare2
- Frida
- jadx
- apktool
- Wireshark
- mitmproxy
- binwalk
- x64dbg
Is this legal?
We only work on systems you own or are entitled to analyse, typically for interoperability, security or data recovery. We confirm that before starting.
Can you reverse engineer an Android app?
Yes, one you own or are entitled to analyse: your own app whose source was lost, a vendor’s app you are licensed to integrate with, or your app before a security review. We decompile it, trace it on a test device and document what it does.
What if it is obfuscated or encrypted?
That slows things down rather than stopping them. We tell you early how deep the work is likely to go.
Do you hand over the tools you build?
Yes — scripts, parsers and adapters are yours, documented and tested.
How long does it take?
Usually three to eight weeks. After the first week we can tell you how deep the target goes and whether the goal is realistic.
What do you need from us?
Proof that you own the system or may analyse it, the software or device itself, and a working installation if one exists. Sample files and data help a lot.
Tell us what you are building.
Every project starts with a consultation: you bring the idea and everything you know, we turn it into a design you can build on.
Book a consultation