PDF になぜスクリプトがあるのか
PDF は Acrobat 3 の時代から JavaScript に対応しています。フォームが列を合計し、書式の誤った日付をはねつけ、チェックが入るまで欄を無効にするのは、これのおかげです。そして悪意ある PDF を送る価値が生まれるのも、これのせいです。
PDF の JavaScript を検出すると謳うツールの多くは /Names /JavaScript しか見ません。そこは文書レベルの置き場で、実務のフォームではたいてい空です。面白いコードは個々のフィールドに結び付いています。
調べる場所すべて
/Names /JavaScript— 文書レベルの名前ツリー。リストではなく木なので、ルート配列しか読まないツールはスクリプトの多いファイルで何も見つけられません。/OpenAction— 文書を開いた瞬間、まだ一語も読まないうちに走ります。- 文書の追加アクション — 閉じる前、保存の前後、印刷の前後。
- ページアクション — ページを開いたとき、閉じたとき。
- 注釈アクション — リンクやボタンの
/Aアクション、加えてマウスの出入り、押下、離し、フォーカスの取得と喪失。 - フォームフィールドのアクション — キーストローク、書式、検証、そして計算。何かをするフォームのコードは、実際にはここにあります。
/AcroForm /CO— 計算順序。互いに依存する二つの合計のどちらが勝つかを決めます。
/Next によるアクションの連鎖も追います。最初の輪で止まれば、無害な部分だけ読んで受け渡し先を見逃すからです。
判定ではなく観察
app.launchURL、this.submitForm、this.exportDataObject、Net.HTTP、eval、そして長く続く \uNNNN エスケープは、スクリプトを 読む 理由として印を付けます。どれも何かの証明ではありません。まっとうな経費精算フォームは submitForm を呼びますし、まっとうなテンプレートは util.printf を呼びます。印はどこを見ればよいかを示すだけです。
何も実行しません
スクリプトはオブジェクトグラフからテキストとして読み出して表示するだけです。評価もせず、このページに注入もせず、ネットワークから取得もしません。1 本をコピーする、.js として保存する、あるいは JSON レポートとまとめて ZIP で持ち出すこともできます。
プライバシー
ファイルはブラウザ内だけで解析され、アップロードされません。調べている相手が「信用していないファイル」であるときほど、これが効いてきます。
Tiny Online Tools






