出来上がった物から、作られる前へ戻る
通常のengineeringは、目的や要求から始まる。
何を作るか決める
↓
設計する
↓
部品やプログラムへ分ける
↓
組み立てる
↓
製品・システムが動く
reverse engineeringは、この流れを完成品の側から逆向きにたどる。
製品・システムがある
↓
観察する
↓
部品、信号、データ、処理を見つける
↓
相互関係を推測する
↓
設計や原理を復元する
日本語では、逆行工学、逆解析、リバース・エンジニアリングなどと呼ばれる。
しかし、単に逆方向へ工程をなぞるだけではない。
設計図、ソースコード、仕様書、開発者の説明がない状態で、目の前に残った物と、その応答だけから、内部にあった判断を再構成する行為である。
reverse engineeringとは、完成品を過去へ戻すことではない。完成品から、失われた設計をもう一度発生させることだ。
分解することと、理解すること
機械を分解すれば、中の部品は見える。
だが、部品が見えただけでは、その機械を理解したことにはならない。
- なぜこの部品が選ばれたのか
- どの信号がどこへ流れるのか
- どの条件で処理が分岐するのか
- 何を正常と判断しているのか
- どの情報を本物として信用しているのか
- 故障したとき、どこまで動き続けるのか
reverse engineeringで復元するのは、物の一覧ではなく、関係と判断である。
1990年、Elliot J. ChikofskyとJames H. Cross IIは、ソフトウェア工学における用語を整理し、reverse engineeringを、システムの構成要素と相互関係を識別し、それを別の形式またはより高い抽象度で表現する過程として定義した。
短く抜き出せば、中心にあるのは、
“components and their interrelationships”
である。
ねじを外したことではなく、なぜそのねじがそこにあり、外すと全体がどう変わるかまで説明できることが重要になる。
コピーとは違う
reverse engineeringは、しばしば模倣やコピーと同じものとして語られる。
実際、競合製品を調べ、同じ機能を持つ製品を作るために使われることもある。
しかし、行為の中心は複製そのものではない。
コピー
= 同じ物を増やす
reverse engineering
= その物が成立する構造を読み取る
読み取った結果から、互換品を作ることも、修理することも、脆弱性を見つけることも、偽物を判別することもできる。
同じ解析行為が、保存、競争、防御、模倣、攻撃へ分岐する。
そのため、この語は技術の名称であると同時に、目的を問われる境界の名称でもある。
外から読む――black-box reverse engineering
対象を壊したり開けたりしなくても、reverse engineeringはできる。
入力を与え、返ってくる出力を観察する。
入力A → 応答X
入力B → 応答Y
入力C → エラー
入力D → 応答まで長く待つ
この差を集めると、内部の規則を推測できる。
- どの入力を同じ種類として扱うか
- どこで形式を検査するか
- どの順序で処理しているか
- 失敗を何種類に分けているか
- 状態を記憶しているか
- 外部の別システムへ問い合わせているか
これはblack-box testingと近いが、目的が違う。
テストが「期待どおり動くか」を確認するのに対し、reverse engineeringは「どのような内部構造なら、この応答になるか」を組み立てる。
ブラックボックスは、何も語らない箱ではない。入力するたび、設計の一部を応答として漏らす箱である。
phreakingは、網を相手にしたreverse engineeringだった
電話網は、利用者が所有できる機械ではなかった。
交換機を分解することも、内部の設計書を読むこともできない。
それでも、受話器から番号、音、間、切断、案内、課金の変化を観察できた。
番号を入力する
↓
網が応答する
↓
応答の差を記録する
↓
交換・信号・課金の規則を推測する
この意味で、phreakingは巨大な電話網に対するblack-box reverse engineeringだった。
無線では空間へ流れ出した信号を読む。
phreakingでは、網へ問いかけ、その返事から内部を読む。
そしてreverse engineeringという語は、この二つをさらに広い場所でつなぐ。
所有していないシステムでも、端末と応答があれば、設計を逆向きに読むことができる。
ソフトウェアでは、形が見えない
ソフトウェアには、ねじも配線もない。
利用者の手元にあるのは、多くの場合、ソースコードではなく実行可能なバイナリである。
そこで解析は複数の層に分かれる。
静的解析
プログラムを実行せず、ファイル形式、文字列、命令、データ構造、参照関係などを調べる。
動的解析
プログラムを動かし、入力、出力、メモリ、ファイル、通信、例外、処理の分岐などを観察する。
逆アセンブル
機械語を、人が読めるアセンブリ言語の命令表現へ変換する。
逆コンパイル
低水準のコードから、元のソースコードに似た高水準の表現を再構成する。
ただし、元の変数名、コメント、設計意図までそのまま戻るわけではない。
コンパイル時に失われた情報は、観察者が推測して補う。
元のソースコード
↓ コンパイル
意味の一部が失われた実行形式
↓ 逆解析
別の人が作る説明・仮説・擬似コード
reverse engineeringは、機械的な変換だけでは終わらない。
最後には、人間が「この処理は何をしようとしているのか」と意味を与えなければならない。
disassembly、decompilation、crackingとの違い
これらの語は重なるが、同じではない。
disassembly
= 機械語を命令列として読みやすくする手法
decompilation
= 低水準コードから高水準表現を再構成する手法
reverse engineering
= 観察や各種手法を使い、構造・機能・設計を理解する全体過程
cracking
= 保護、認証、制限などを破る目的または結果を強く示す語
逆アセンブルや逆コンパイルは、reverse engineeringの道具になり得る。
だが、ファイル形式を観察するだけでも、通信の応答を比較するだけでも、reverse engineeringは成立する。
また、reverse engineeringをした結果、保護機構を理解しても、それを解除するとは限らない。
理解する
≠ 必ず変更する
≠ 必ず回避する
≠ 必ず複製する
この区別は重要である。
当サイトでは、観察権、理解権、変更権、再配布権を同じものとして扱わない。
reengineeringとも違う
reverse engineeringとreengineeringは、綴りも意味も似ている。
しかし、方向が違う。
reverse engineering
= 既存物から設計や理解へ戻る
reengineering
= 得られた理解を使い、作り直す・改善する
古いソフトウェアの構造を解析し、設計を復元しただけならreverse engineeringである。
その後、コードを整理し、別の言語へ移し、新しいシステムとして再構築すればreengineeringになる。
理解は、再建の前段階になり得るが、理解しただけで再建したことにはならない。
clean room――同じ機能を、別の表現で作る
互換性を目的とするreverse engineeringでは、元の実装をそのまま写さず、観察で得た仕様だけを別の開発者へ渡し、独立した実装を作る方法が使われることがある。
一般にclean-room designまたはclean-room implementationと呼ばれる。
解析する側
対象の動作から仕様を記述する
↓
境界を置く
↓
実装する側
元のコードを見ず、仕様から新しく作る
ここで復元したいのは、表現そのものではなく、外部から確認できる機能や接続条件である。
互換機、互換ソフト、ファイル読み書き、通信プロトコル、周辺機器、古いデータの救出などで重要になる。
reverse engineeringは、閉じた製品を壊すためだけでなく、閉じた製品の外に別の入口を作るためにも使われる。
セキュリティでは、攻撃と防御が同じ対象を見る
セキュリティ研究者は、プログラムや機器を解析して、脆弱性、未知の通信、隠れた機能、マルウェアの挙動を調べる。
NISTの用語集は、悪性プログラムのcode analysisについて、逆アセンブラ、デバッガ、逆コンパイラなどを用い、ソフトウェアの挙動を実装するコードを理解する行為として説明している。
一方、攻撃者も同じように解析し、保護機構や弱点を探す。
防御者
何をされ得るか知るために読む
攻撃者
何ができるか知るために読む
道具と観察対象は同じでも、権限、目的、対象への影響、得た情報の扱いが違う。
reverse engineering自体を、善または悪のどちらかへ固定することはできない。
ハードウェアでは、表面から層を剥がす
機械部品では、寸法を測り、材質を調べ、3D形状を取得し、CADモデルを作る。
電子機器では、基板、配線、部品、信号、ファームウェアを追う。
集積回路では、パッケージを開き、層を観察し、画像から回路や接続を復元することもある。
目的には、次のようなものがある。
- 製造中止部品の代替
- 古い機械の修理
- 設計資料を失った製品の保守
- 偽造部品の検出
- 知的財産侵害の確認
- 不正な回路やhardware Trojanの検出
- 互換部品の開発
- 競合製品の調査
ハードウェアreverse engineeringは、設計を盗む手段にも、設計が盗まれていないか調べる手段にもなる。
内部を読む技術は、信頼を破るためにも、信頼を作り直すためにも使われる。
合法か違法か、という単純な二択ではない
reverse engineeringは、それ自体が常に違法な行為ではない。
ただし、対象、入手方法、利用許諾、契約、著作権、技術的保護手段、営業秘密、アクセス権限、解析結果の利用方法によって扱いは変わる。
日本では、2018年の著作権法改正について文化庁が示した説明で、プログラムの調査解析を目的とする利用、いわゆるreverse engineeringが、著作物に表現された思想・感情の享受を目的としない利用の例として挙げられている。
EUのコンピュータ・プログラム指令は、合法的な利用者による観察・研究・試験や、一定条件下で相互運用性に必要な逆コンパイルを認めている。
米国著作権法のDMCAにも、合法的に取得したプログラムについて、独立したプログラムとの相互運用性に必要な要素を分析する目的のreverse engineeringに関する限定的な規定がある。
しかし、これらは「何をしてもよい」という一般許可ではない。
対象を理解すること
解析のために複製すること
技術的保護を回避すること
解析結果を公開すること
互換品を作ること
元の表現を複製すること
無許可でシステムへアクセスすること
それぞれ別の行為であり、同じ法的・倫理的評価にはならない。
作った側より深く理解すること
設計者は、全体を完全に理解しているとは限らない。
大規模な製品やシステムは、多数の人、部品、委託先、古いコード、偶然の互換性によって成立している。
開発者が退職し、仕様書が失われ、製造元が消えた後も、物だけが残ることがある。
reverse engineerは、その残った物から、現在実際に動いている設計を読む。
設計書に書かれた理想ではなく、製品に沈殿した現実を読む。
作る側が意図した仕様
と
実際に出来上がった挙動
は
必ずしも同じではない
このとき、作った者より、後から解析した者の方が、特定部分を深く理解することがある。
所有と理解が一致しないように、作者と最良の読者も一致しない。
当サイトにおける位置
当サイトの標本は、多くがreverse engineeringの周囲にある。
- phreakingは、電話網の応答から内部を読む
- crackingは、保護機構が何を信用しているか読む
- modchipは、ゲーム機の起動判定へ別の答えを返す
- バッ活は、媒体とコピー防止の構造を紙面へ展開する
- 危険文書は、解析結果や解除知識をファイルとして再流通させる
- Flipper ZeroやHackRF Oneは、見えない信号を観察可能にする
これらを一つにするのは、違法性ではない。
完成した物を、説明書どおりに使うだけでは終わらず、その物が何を根拠に動いているかを逆向きに読むこと。
reverse engineeringは、当サイトの複数の棚をつなぐ中心語になり得る。
この標本が示す境界
reverse engineeringが問い直すのは、技術だけではない。
- 購入した物を、どこまで観察してよいのか
- 使用権は、理解する権利を含むのか
- 互換性のための解析と、模倣のための解析はどこで分かれるか
- セキュリティ研究と無許可の侵害はどこで分かれるか
- 失われた仕様を復元した者は、その知識を誰と共有できるか
- メーカーが消えた後、製品を維持する権利は誰に残るか
- ブラックボックスが応答として漏らした情報は、誰のものか
reverse engineeringは、前へ進む技術ではないように見える。
だが、過去へ戻っているわけでもない。
すでに存在する物の中から、まだ書かれていない設計図を取り出し、次に作れるものを増やす技術である。
関連標本
- hack / hacking――切ることから、システムの別の可能性を引き出すことへ
- crack / cracking――防壁を破ったことを示す語
- phreak――実践のあとから現れた名前
- phreakingと最初の巨大ブラックボックス――受話器から世界最大の機械を逆向きに読む
- バックアップ活用テクニック――コピーの名で機械を開いた雑誌
- 危険文書――BBSと初期インターネットを流通した禁制知識のパック
- PlayStation modchip――コピーCDを読ませた小さなIC
- Flipper Zero
- HackRF One
- clean-room design
- disassembly
- decompilation
- program comprehension
- design recovery
- interoperability
資料・出典
- IEEE Technology Navigator|Reverse engineering
- Elliot J. Chikofsky and James H. Cross II|Reverse Engineering and Design Recovery: A Taxonomy
- NIST CSRC Glossary|code analysis
- ASME|The Rise of Reverse Engineering
- 文化庁|著作権法の一部を改正する法律(平成30年法律第30号)について
- EUR-Lex|Directive 2009/24/EC on the legal protection of computer programs
- U.S. Copyright Office|17 U.S.C. Chapter 12, Section 1201(f)
- Marc Fyrbiakほか|Hardware Reverse Engineering: Overview and Open Challenges