REA のネイティブ解析：「File too large」の条件を探す

01. エラーを入口にする

アプリがファイルを受け付けず、「File too large」と表示します。問題はバイト数、デコード後の画素数、圧縮後のサイズ、それともサービスの上限でしょうか。自分の実装を変える前に、判定を読み解いてください。

対象のメッセージを一つ正確に選び、ネイティブエンジンの解析済み文字列から探します。見つからなくても存在しない証拠にはなりません。翻訳済み、エンコード済み、実行時に組み立てる、実行ファイルの外に保存する、といった可能性があります。

npx -y rea-agents@6.4.0 search "/absolute/path/program" --pattern="File too large" --kind strings --provider ghidra --format json

02. 文字列を使う関数を探す

検索結果のアドレスを使い、参照元を調べます。参照先は判定そのものではなく、汎用のエラー表示ヘルパーかもしれません。エラーを出すか決める分岐が見つかるまで、呼び出し元を追ってください。

以下のプレースホルダーは、自分のバイナリに対して返されたアドレスへ置き換えてください。別ビルドのアドレスは流用できません。

npx -y rea-agents@6.4.0 xrefs "/absolute/path/program" --address="RETURNED_STRING_ADDRESS" --provider ghidra --format json
npx -y rea-agents@6.4.0 decompile "/absolute/path/program" --procedure="RETURNED_FUNCTION_ADDRESS" --provider ghidra --format json

03. 単位も含めて比較式を読み解く

比較の両辺を特定します。サイズ値の出所、比較前の計算、分岐が「より大きい」か「以上」かを追ってください。この細部が境界ケースを決めます。

逆コンパイルされた名前や型は仮説として扱います。結果が不完全なら、選択した関数の命令と呼び出し先を確認してください。擬似コードが単純に見えても、符号の有無、整数幅、変換順序で結果が変わります。

返された関数の根拠を使い、このエラーを出す分岐を説明してください。比較される値を入力までさかのぼり、しきい値、単位、符号の有無、正確な比較演算を特定します。逆コンパイルが不完全なら命令と関連ヘルパーを調べ、アドレスを示してください。不明な型は推測せず、未解決と記してください。

04. 正常な入力だけでなく境界を試す

読み解いたルールのしきい値が L なら、入力の実際の単位で L−1、L、L+1 をテストします。アプリが受け付ける範囲でゼロや不正な入力も試します。実行するのは、自分で管理するプログラムのコピーだけにしてください。

ファイルサイズの判定なら、バイト数と観測した結果を記録します。デコード後の画像の判定なら、ファイルのバイト数だけを変えても該当条件を試せないかもしれません。同じ入力を代替実装と比較し、不一致を保存します。

• L−1：受け付けるか拒否するか？
• L：しきい値と等しい場合は通るか？
• L+1：どのエラーを返すか？
• 不正な入力は、それ以前の別の分岐で失敗するか？

05. 結論を根拠の範囲に収める

成果物は、読み解いたルール一つと、それに対して実行したテストです。この記事では特定の対象に手順を実行したわけではありません。エラー文は例であり、自分の対象のものに置き換えてください。

同じ姿勢の実例として、REA は DX-Ball の音声パン関数を記録しています。報告では3,205件の入力比較と、別の63バイトのコンパイラー一致を区別しています。どちらもゲーム全体の再実装を意味しません。リンク先の公式ネイティブ解析ガイドとケーススタディをご覧ください。