BluePaper

How it works

A disposable sandbox renders the document to pixels. A trusted worker rebuilds the PDF. A parser-free scan lists what the original bytes contained.

The principle

Safety comes from destruction, not detection. BluePaper does not try to decide whether a document is malicious. It throws the document away and keeps only what it looked like.

Every page is rendered to raw RGB pixels inside an isolated sandbox. A new PDF is built from those pixels. JavaScript, macros, embedded executables, malformed-parser exploits, and most metadata have nowhere to live in a grid of pixels, so they do not reach the output.

This is the approach of Dangerzone. BluePaper keeps Dangerzone’s doc_to_pixels and pixels_to_pdf close to upstream and runs them as a network service.

Lifecycle of a conversion

  1. Pin. The API checks the file type and size, hashes the bytes with SHA-256, stores them as an immutable blob, records the job, queues it, and returns a conversion id. It never opens the file with a document parser.
  2. Scan and sandbox, in parallel. A worker leases the job. It starts the byte-indicator scan on the original bytes and creates a fresh sandbox from a clean disk image.
  3. Render. Inside the sandbox, doc_to_pixels opens the document with LibreOffice, Poppler, and Dangerzone’s other converters and streams each page out as width, height, and RGB bytes.
  4. Destroy. The worker deletes the sandbox. A sandbox that has seen a document is never snapshotted or reused.
  5. Rebuild. On the trusted side, pixels_to_pdf assembles a new PDF from the pixels, adds an OCR text layer if you asked for one, and compresses it.
  6. Publish. The worker stores the safe PDF and the JSON report. The console polls the status, then shows the report and a preview.

Two planes

Plane What runs there Trust
Sandbox doc_to_pixels (LibreOffice, pdftoppm, and others) Untrusted. Document in, RGB page stream out.
Worker pixels_to_pdf, optional Tesseract OCR, compression, byte scan Trusted. Sees pixels and raw bytes, never parses the document.

Isolation

Each conversion gets its own Azure Container Apps sandbox, a hardware-isolated microVM. It replaces Dangerzone’s local Podman and gVisor stack.

  • All outbound network access is denied.
  • The sandbox has no identity that can read storage. The worker copies the document in and the pixel stream out; the sandbox never talks to storage itself.
  • It starts from a clean image, or from a snapshot taken before any document was introduced, and is deleted when the job ends.
  • It runs at the largest resource tier (4 vCPU, 8 GB), because LibreOffice is heavy.

A sandbox compromise must not yield network access, secrets, or another job’s files. That is the boundary the design is built around.

The byte-indicator scan

While the sandbox renders, the trusted worker scans the original bytes against a fixed, versioned pattern catalog. There are no user-supplied patterns. Matching is linear-time with a wall-clock cap, because regular-expression denial of service is in the threat model.

The scan uses no PDF parser, no OLE parser, and no decompression. #HH escapes in PDF names are expanded, so /Java#53cript counts as /JavaScript. Other encodings are not interpreted.

Catalog 1.0.0

Group Indicators
PDF /JavaScript, /JS, /OpenAction, /AA, /Launch, /EmbeddedFile, /RichMedia, /XFA, /SubmitForm, /GoToR, /URI, /Encrypt, /ObjStm
Office vbaProject.bin, OLE compound-file magic, DDE markers, external relationship and oleObject markers, ActiveX markers
Polyglot %PDF not at offset 0, ZIP and PDF in one file, HTML or HTA markers alongside a document

This is deliberately shallower than PDFiD-style object inspection. The point is a cheap, parser-free list of raw byte indicators.

Reading the report

Each hit records the indicator id, how many times it appeared, and the byte offset of the first match.

Hits and a safe PDF

Raw byte indicators were found. A match is not proof that an active construct was present; the same bytes can occur in metadata or other inert data. The safe PDF was rebuilt from pixels either way.

No hits and a safe PDF

No obvious indicators were found. Absence of patterns is not a malware verdict: compression and encodings can hide them. Conversion still rebuilt the document from pixels.

Conversion failed

The report leads with “No safe PDF was produced.” It does not claim that anything was stripped. If the scan finished, its hits are still listed. A failure is not a malicious verdict: timeouts, sandbox kills, and exhausted budgets all fail.

conversion_justified

The API report includes conversion_justified. It is true only when conversion succeeded and at least one indicator was found. It means indicators were present, not that an active construct was.

Limits and budgets

The operator configures these. The values below are the defaults.

Upload size
32 MiB
Conversion time
10 minutes
Byte scan time
30 seconds
Pixel stream
512 MiB
Running jobs
4; while 4 are running, new uploads return HTTP 429
Queue depth
100; a full queue returns HTTP 503

Unsupported file types return HTTP 415 before a sandbox is created. Files that are too large return 413.

What BluePaper does not do

  • It does not give a malicious or clean verdict, and it does not replace antivirus.
  • It does not detect visual phishing. A fake login page, a lure, or a QR code on the page is reproduced faithfully as pixels.
  • It does not keep links, form fields, attachments, or digital signatures. They are not pixels.
  • It does not parse or detonate the original for forensics: no dual-parser PDF analysis, no JavaScript analysis, no reader detonation.
  • It does not fetch URLs on your behalf.
  • It does not keep your file on your machine. If a document must never leave your computer, use Dangerzone locally.

Current version

Service
BluePaper 0.1.0
Pattern catalog
1.0.0
Report schema
1.0.0
Converters
Dangerzone doc_to_pixels and pixels_to_pdf
License
AGPL-3.0
Last updated