Build a representative corpus
One file encourages false conclusions. Collect files from different versions, sizes and known application states, plus deliberately created samples where one known value changes at a time. Preserve originals and record provenance.
| Technique | Clue |
|---|---|
| Signatures and headers | Magic values, version, flags, counts or offsets |
| Offset/repetition comparison | Fixed records, tables, indexes or chunk boundaries |
| Entropy inspection | Plain structures versus compression, encryption or dense binary data |
| Known-value mapping | Candidate integers, floats, dates, text encodings and field order |
| Tail/checksum comparison | Integrity fields, directory structures or block checksums |
Test the model
- Propose header fields and offsets from multiple samples.
- Write a parser that rejects impossible lengths and out-of-range offsets.
- Map parsed fields to values visible in the original application.
- Validate records not used to derive the structure.
- Document unknown bytes rather than forcing an explanation.
- Compare extracted counts, totals and relationships with business expectations.
Format understanding versus damaged-file recovery
A correct format specification may still be unable to recover blocks that were overwritten or truncated. Conversely, an intact file may be fully extractable even when the original application is gone. Recovery results should distinguish validated records, partially inferred fields and unrecoverable regions.
Use executable analysis to observe how the producing application reads/writes files. Database-like containers may start with database identification. Broader investigation is described in software reverse engineering, while structured database recovery belongs in database recovery services.
Provide
Multiple files with provenance, original application, known values/screenshots, version differences, damaged and healthy examples and the fields that must be recovered.