エプスタインPDFを、生データのエンコードされた添付ファイルから再構築する

（注）以下は、元の英語記事を日本語に翻訳したものです。文章量が非常に多いため、長文になることをご承知ください。

---

最近公開されたエプスタインアーカイブの最新バージョンに関して、司法省（DoJ）が行った作業の「能力」や「論理」に対し、多くの不満が寄せられています。共謀者の名前を隠蔽したり、ランダムな女性の写真を不当に編集して個人をより罪悪感を抱かせるようにすること、Reddit全体がエプスタインのアカウントにログインできる資格情報を削除し忘れたことで証拠を踏みにじったり、さらに最新バッチの多くが誤って変換されたQuoted‑Printableエンコーディングの障害で破損したことなど、Pam Bondi の司法省はこの膨大（かつ巨大）なプロジェクトに「最善と最高を注ぐ」姿勢を示せていません。
しかしながら、もっとも罪悪感を与える証拠が完全に赤字化されているわけではありません…というのは、実際には違います。

最新ダンプが公開された日に、SNS上で氾濫する誤情報や推測に対し、Quoted‑Printableエンコーディングの乱れについて記事を書こうと考えました。そこで、メールヘッダーを探すために最新アーカイブを掘り下げている最中に、不思議なアーティファクトに出会いました。メールは単純テキストへ悪く変換されただけでなく、一部のバイナリ添付ファイルが実際にはbase64形式（SMTPプロトコルを破らずにメールに含めるため）でダンプに入っており、担当インターンはそれらが何か重要なものだと理解せず、意味不明と思われたページ数分の16進文字列を検閲する必要性を見いだせませんでした。

まず EFTA00400459 をご覧ください。これは、おそらくエプスタインのアシスタントと共謀者であるボリス・ニコリッチ（Boris Nikolic）および彼の友人サム・ジャラデ（Sam Jaradeh）が招待される███████ブレネフィットに関するやり取りです。

この16進文字列は76ページにわたり、

DBC12 One Page Invite with Reply.pdf

というファイルをbase64でエンコードしたもので、SMTPプロトコルを壊さずメール内に埋め込むために使用されています。理論上は、以下のようにコピー＆ペーストして

base64 -d > output.pdf

を実行すれば元のPDFへ復元できるはずです… ただし、完全に赤字化されたスキャン画像（不十分なOCRを適用したもの）ではなく、オリジナルの「悪く変換された」メールが必要になります。

DoJ がデジタイズしたテキストをコピーしてテキストエディタに貼り付けた場合、次のようになります：

EFTA00400459

は2行目で無視してください。これは各ページの下部に印刷される証拠識別子（変数名）で、base64テキスト内に散在します。
それ以外には何が見えるでしょうか？ヒント：正しい base64 は次のような形です。

ここではサンプルを示すために monospace フォントで整列した状態を表示しています…

OCR によるPDFからテキストをコピー＆ペーストすると、余計な文字が挿入され、

,

や

[

など base64 には無効な文字も含まれます。結果として、

base64 -d

が失敗します。

最初に試したのは Adobe Acrobat Pro の OCR プロセスですが、結局さらに悪い結果になりました。空白が挿入され、その他の文字が完全に誤認識されたためです。そこで、Tesseract を使って手動でOCRを行うことにしました。ただし Tesseract は PDF 入力を直接扱えないので、ImageMagick/ghostscript でPDFを PNG に変換する必要があります。しかし

convert

コマンドはリソース不足で失敗します。

そこで

pdftoppm

（Poppler ユーティリティ）を使い、各ページを PNG に変換しました。次に Tesseract を呼び出し、

--psm 6

（単一ブロックのテキストとみなす）と base64 の有効文字のみ許可するように設定しましたが、結果はまだ不安定でした。特に行長がバラつき、途中で空白が挿入されるケースが多く、さらに Courier New フォントの悪さ（1 と l を区別しづらい）も影響していました。

Courier New は IBM のセレクティックタイプライタから派生したフォントで、明瞭な太字や文字間隔が不足しています。結果として、16進文字列を OCR する際に「1」と「l」を区別できないケースが多発します。JPEG スキャンの低解像度と DCT アーティファクトも重なり、さらに困難です。

Tesseract の限界に直面した私は、Amazon Textract を試しました。Textract は大きくは成功し、行長の誤差は平均1〜2文字程度でしたが、完全ではありませんでした。そこで DPI を 200% にスケールアップして再処理することで精度を向上させました。

Textract の出力から

base64 -i

（無効なデータを無視）でテキストを抽出し、PDF 内の PDF 添付ファイルが部分的に (de)flate エンコードされていることが判明しました。PDF はバイナリ形式で圧縮が施されるため、

strings

など単純な手段では内容を取得できません。

qpdf --qdf --object-streams=disable input.pdf decompressed.pdf

を試みましたが、入力ファイルが破損している場合は失敗します。

OCR の不安定さと「1 vs l」の問題から、最終的に「従来型の機械学習」アプローチを検討しました。フォントが既知であることと、圧縮方式もおおよそ分かっているため、専用モデルを構築すれば解決できる可能性があります。ただし、時間的余裕が無いため、この記事の執筆に集中しています。

---

ここから挑戦です

1. Content‑Transfer‑Encoding: base64 に含まれるオリジナル PDF を復元できますか？
   難しいと思われますが、実際にはそれほど難しくありません。

2. 最新のエプスタインダンプに含まれる他の添付ファイルを同様に再構築できるでしょうか？
   

   Content-Transfer-Encoding

   と

   base64

   を検索すると数多くヒットしますが、多くは途中で切れている、あるいは Apple Mail のヘッダーだけが抽出されているなど、使えないケースが多数です。

---

共有リソース

• EFTA00400459.pdf（Epstein Dataset 9 から取得）
  Internet Archive にアップロード済み。
• ページ別にロスレスでエンコードされた WebP 画像も同梱。
• Amazon Textract OCR テキスト（2×拡大した画像から抽出）も公開。

---

追加ヒント

「1 vs l」を判定するために、100% 正確に行うには試行錯誤が必要です。Tesseract を使って手動で行を入力し、その結果を基に修正します。ただし、この方法はプレーンテキスト部分（ヘッダーなど）に限定されます。PDF の flate 圧縮セクションではさらに難易度が上がります。

---

連絡先

• Twitter: @mqudsi
• Signal:

  mqudsi.42

  （機密情報共有可）
• Hacker News / r/netsec でディスカッションに参加してください。

コメントや質問、アイデアがあればぜひ下へ書き込んでください。

---

補足

この記事のシェル例は fish スクリプトです。fish は文字列操作に優れた

string

ビルトインを備えており、外部コマンドを呼び出すことなく多くの処理が可能です。私自身もプロジェクトへの貢献で汗と涙を注いだため、この選択は自然なものです。

PNG から PDF に戻す作業は行わず、品質低下を防ぐためにそのまま扱っています。