Batch Unlock Multiple PDFs — Automation Guide

Scenario 1 — Same password for all files

Many organisations use one document-level password for all internal PDFs. If you know it, batch unlocking is trivial: loop qpdf --decrypt over the files. On Windows the same loop runs through Get-ChildItem and ForEach-Object. QPDF is available on every platform via conda, apt or the QPDF website.

Performance: qpdf decryption is CPU-bound, so throughput scales with the cores you run in parallel; for large files disk I/O becomes the limit. Rather than trusting a rule-of-thumb rate, benchmark a few hundred representative files from your own batch and size the job from that.

Verify each output: QPDF exits 0 on success and non-zero on failure. Check exit codes in the loop and log failures for manual review. Files that fail with the shared password may have a different password, or may be corrupted.

Scenario 2 — Known passwords per file

If you have a password map, a spreadsheet or CSV linking filename to password, automate it with a Python script. Read the CSV, iterate over the files, and call qpdf with the per-file password. Python's subprocess module runs qpdf and captures exit codes.

The approach: read passwords.csv with columns filename,password; for each row call qpdf --decrypt --password=ROW_PASSWORD; log success or failure per file to an output CSV. Files that fail may have a wrong entry in the map — flag them for review.

This is common in enterprise content migration, where the document system stores per-document passwords in a database. Export the table as CSV, match by filename, and run the batch. Expect throughput below a plain shell loop, because each file also spawns a process and performs a lookup — benchmark before committing to a schedule.

Scenario 3 — All passwords unknown

When none of the passwords are known you need batch cracking, the most demanding scenario. The approach: extract hashes from every PDF, classify by encryption mode, and run Hashcat on the batch.

Step 1: use pdf2john.pl, John the Ripper's PDF hash extractor, to pull one hash line per file with its encryption parameters.

Step 2: sort the hashes by mode. Mode 10400 (40-bit RC4) should be separated from mode 10700 (AES-256) because different strategies apply. Mode 10400 (V=1/R=2) is recoverable in practice for these old files because the file key is only 40 bits; mode 10700 requires dictionary and rule attacks.

Step 3: run Hashcat in dictionary mode against the batch, for example hashcat -m 10700 pdf_hashes.txt wordlist.txt -r best66.rule. Hashcat processes all hashes simultaneously — one cracked hash means that file's password was found. Files not cracked after the dictionary phase go on to a mask attack.

Hashcat batch optimisations

When cracking many PDF hashes at once, Hashcat shares candidate generation and removes per-run overhead — but cost scales with the number of distinct-salt files. Each PDF's hash carries its own salt (/O, /U, /P, /ID), so the derivation is recomputed for every file for every candidate: a batch of 1,000 mode 10700 hashes against a 10-million-word dictionary costs on the order of 1,000 times a single hash.

Use --outfile-autohex-disable for clean plaintext output, and --show after the run to list every cracked password. The potfile tracks per-hash status automatically, so re-running the same batch skips already-cracked hashes.

For mode 10400 batch cracking, remember that Hashcat tests candidate passwords: it derives the file key and decrypts the known padding in /U for each candidate, so a mask attack over short candidate passwords is the practical route — not enumeration of the 2^40 key space. Recovering the RC4 key directly from the known padding is a real technique, but it needs separate tooling Hashcat does not implement. Because the key is only 40 bits, mask attacks against these old files are cheap.

Automation infrastructure recommendations

Local GPU cluster: 4-8 high-end GPUs (RTX 5090 or equivalent). Cost scales with the number of distinct-salt files, so testing 10,000-50,000 mode 10700 hashes against a 10M-word dictionary with 50 rules is a multi-day job for a small cluster — every file pays the revision-6 derivation again for every candidate.

Cloud GPU instances: AWS EC2 G6e (L40S) or G6 (L4), Azure NC A100 v4, or Vast.ai rentals. Cloud GPUs are cost-effective for one-time batch jobs — stop the instance when done and pay only for compute time.

Job management: use --potfile-disable for fully isolated per-run tracking, or --potfile-path to set a custom path per batch. For large batches, split the hash list into sub-batches of 500-1,000 and run them on separate GPU instances to scale horizontally.

Handling mixed encryption tiers in a batch

Not every PDF in a batch uses the same encryption. A corporate archive spanning 2000-2026 likely contains mode 10400 (PDF 1.1-1.3, pre-2001), mode 10500 (V=2/R=3 RC4-128 and V=4/R=4 AES-128), mode 10600 (PDF 1.7 extension level 3 / Acrobat 9) and mode 10700 (PDF 1.7 extension level 8 / Acrobat 10-11).

Extract all hashes with pdf2john.pl, which tags each line with the filename and encryption parameters. Then filter on the hash prefix — the fields are version*revision*keylength, so '$pdf$1*2*40' selects mode 10400, '$pdf$2*3*128' mode 10500, '$pdf$5*5*256' mode 10600 and '$pdf$5*6*256' mode 10700 — and crack each group with the appropriate strategy.

Mode 10400: mask attack over candidate passwords, since the small 40-bit key makes it cheap. Modes 10500 and 10600: dictionary plus rule attack, because human-chosen passwords are likely. Mode 10700: dictionary plus rule first, then a mask attack with character-class constraints if that fails.

Batch output verification and quality control

After batch cracking, run qpdf --decrypt with the found password to verify each output opens. Use a script to check exit codes and file sizes. Files that did not decrypt — wrong password, or no password found — should be quarantined for separate handling.

If Hashcat found a password but qpdf rejects it, verify the hash extraction was correct by re-running pdf2john.pl and hashcat --show. Some PDFs are corrupted badly enough to prevent decryption even with the right password — a PDF has a single /Encrypt dictionary, so a rejection means a bad extraction or a damaged file, not another layer to peel.

Document the batch thoroughly, especially which mode groups failed and why. For a corporate migration the pattern is qualitative rather than percentage-based: files whose passwords were human-chosen usually fall to dictionary and rule attacks within the batch window, while files protected by long random passwords generally do not fall at all, on any tier.