Guide
Forensics: what a file really is
Static analysis of a file you already hold. Nothing is executed, and nothing is sent to a third party.
The short version
- Upload a file, or import one from a filio.dk share. Uploading runs nothing.
- Press Analyse. That is a separate, deliberate act, because the parsers behind it have a CVE history.
- Read the type verdict first: the extension is the least reliable thing about a file.
- Check the personal-data section before you forward anything to anybody.
- Delete the file when you are done. Its report goes with it, on purpose.
The idea
Static analysis of a file you already hold. It answers four questions: what is this really, what is inside it, whose metadata is in it, and does it carry personal data or credentials.
Nothing is executed and nothing is uploaded to anybody. The signature scan and the detection rules run on this box. VirusTotal, if you have a key, is a hash lookup only — a file under investigation is frequently evidence, and evidence you have quietly shared with a third party and its partner network is evidence you have published.
Upload, then analyse — and why they are separate
Uploading is cheap and inert. Nothing runs. Then you press Analyse and that is when the tools start.
This is not an extra click, it is the design. The analyser points a stack of C and Perl parsers — exiftool, binwalk, poppler, readpe, libmagic — at bytes an attacker chose, and those parsers have a CVE history. Running them only when a human presses the button means an attacker cannot choose the moment.
Results are cached, because a full pass costs real CPU and re-running it on every page view would be a self-inflicted denial of service. Re-analysing is a button. A report produced by an older version of the analyser is shown and labelled stale, never silently trusted.
Getting a file in
- Upload — up to the limit shown on the page. This tool accepts any file type; the timeline does not, because they are doing different jobs.
- filio.dk — paste a share link. Higher ceiling, and the durable copy stays yours.
- From the leak collector — tick Forensics beside a file and it arrives here automatically once retrieved. See that guide.
Reading the report
What it actually is
Read this first, always. The tool identifies the file from its content and compares that with what
the name claims. The extension is the least reliable thing about a file, and a
mismatch between the two is frequently the entire finding — an invoice.pdf that is
really an HTML document, a .jpg that is a ZIP.
Verdicts and flags
A short vocabulary at the top, so you can triage without reading the whole report:
av-hit | A signature matched. The signature name is given. |
av-error | The scanner did not complete. Not a clean result — an unknown one. |
yara-hit | A detection rule matched at medium severity or above. |
yara-info | A rule matched, informationally. |
near-duplicate | Fuzzy hashing found something similar already here. Often the most interesting line in the report. |
pii | Personal data was found in the bytes. |
No flags is not the same as safe. The report says so in as many words, and it is worth internalising: a clean result from a scanner that cannot see inside the container is not a clean file. An encrypted archive, a novel sample and a benign file all produce the same empty flag list.
Hashes
MD5, SHA-1, SHA-256 for identification and for handing to somebody else, plus a fuzzy hash. The fuzzy hash is the one that earns its place: it finds files that are similar rather than identical, which is how you spot the same document with the header changed, or the same dropper recompiled.
Personal data
Check this before you forward anything to anybody. It looks for the shapes that matter — names, addresses, identifiers, contact details, credentials — in the extracted strings, the metadata and the structure.
It is a detector, not an oracle: it will miss things and it will occasionally flag a false one. Read it as "here is where to look", not "here is everything".
Metadata
Often the richest part, and the part whoever produced the file forgot about. Authors, organisations, software versions, camera and device serial numbers, GPS coordinates, edit history, printer identifiers, embedded thumbnails that were never updated when the visible image was cropped.
Structure and embedded content
What is inside the container, and — importantly — signatures found past offset 0. A file that is a valid image for its first 40 kilobytes and a ZIP archive after that is a polyglot, and that is essentially never an accident.
Indicators in the bytes
Extracted strings grouped into categories: URLs, hosts, IPs, email addresses, file paths, credentials, registry keys, commands. This is where you find the command-and-control host or the hard-coded password.
What actually ran
The last section, and it is the one that keeps the rest honest. Every tool, whether it ran, how long it took, and how it ended. A tool that was missing or that failed is listed as such rather than contributing a silent nothing to a clean-looking report.
Deleting
Deleting a file takes its report with it. That is deliberate: a forensic report contains the file's own strings, metadata and any personal data found in it, so it must not outlive the file it describes.
Who can see it
You, and platform administrators. Nobody else, and there is no share setting — a forensic upload has nothing to publish. It is somebody's file and its report is full of that file's personal data.