リバースエンジニアリング

ツポレフTu-4は、捕獲したボーイングB-29スーパーフォートレスをリバースエンジニアリングして製造されたソ連の爆撃機である。

リバースエンジニアリング（後方エンジニアリング、バックエンジニアリングとも呼ばれる）とは、以前に作られたデバイス、プロセス、システム、またはソフトウェアが、どのようにタスクを達成するかを、演繹的推論によって理解しようとするプロセスまたは手法である。その具体的な方法についてはほとんど（あるいは全く）理解していない。対象とするシステムと採用されている技術に応じて、リバースエンジニアリング中に得られる知識は、廃止されたオブジェクトの再利用、セキュリティ分析、あるいは何かの仕組みの理解に役立つ可能性がある。[ 1 ] [ 2 ] [ 3 ]

プロセスは実行されるオブジェクトに固有のものですが、すべてのリバースエンジニアリングのプロセスは、情報抽出、モデリング、レビューという3つの基本的なステップで構成されます。情報抽出は、操作を実行するために必要なすべての情報を収集する行為です。モデリングは、収集された情報を抽象モデルに結合する行為で、新しいオブジェクトまたはシステムを設計するためのガイドとして使用できます。レビューは、選択された抽象の妥当性を確認するためにモデルをテストします。[ 4 ]リバースエンジニアリングは、コンピュータ工学、機械工学、設計、電気電子工学、土木工学、原子力工学、航空宇宙工学、ソフトウェア工学、化学工学、[ 5 ]システム生物学[ 6 ]などの分野に 適用できます。

概要

リバースエンジニアリングを行う理由は、様々な分野に存在します。リバースエンジニアリングは、商業的または軍事的利益のためにハードウェアを分析することに起源を持ちます。[ 7 ]：13 しかし、リバースエンジニアリングのプロセスは、必ずしも複製を作成したり、何らかの形で成果物を変更したりすることではありません。製品の元の製造手順に関する追加情報をほとんど、あるいは全く必要とせずに、分析の一環として設計上の特徴を推測するために使用される場合もあります。[ 7 ]：15

場合によっては、リバースエンジニアリングプロセスの目的は、レガシーシステムの再文書化に過ぎないこともあります。[ 7 ] : 15 [ 8 ]リバースエンジニアリングされた製品が競合他社の製品であっても、その目的はそれをコピーすることではなく、競合他社の分析を行うことである場合があります。[ 9 ]リバースエンジニアリングは相互運用可能な製品を作成するために使用される場合もあり、米国と欧州連合の法律が厳密に適合しているにもかかわらず、その目的で特定のリバースエンジニアリング技術を使用することの合法性は、20年以上にわたって世界中の法廷で激しく争われてきました。[ 10 ]

ソフトウェアのリバースエンジニアリングは、ソフトウェアの保守と改良のために、基礎となるソースコードの理解を深めるのに役立ちます。関連情報を抽出してソフトウェア開発の意思決定を行うことができ、コードのグラフィカルな表現はソースコードに関する別の見方を提供し、ソフトウェアのバグや脆弱性の検出と修正に役立ちます。ソフトウェアは開発の過程で設計情報や改良点が失われることがよくありますが、リバースエンジニアリングによって失われた情報は通常復元できます。このプロセスはソースコードの理解に必要な時間を短縮し、ソフトウェア開発の全体的なコストを削減するのにも役立ちます。[ 11 ]リバースエンジニアリングは、より優れたコード検出器を使用して、ソフトウェアに書き込まれた悪意のあるコードを検出して排除するのにも役立ちます。ソースコードをリバースエンジニアリングすることで、意図しない場所でのソースコードの無許可の複製を検出したり、競合他社の製品の製造方法を明らかにしたりするなど、ソースコードの別の用途を見つけることができます。[ 12 ]このプロセスは、ソフトウェアやメディアを「クラッキング」してコピー保護を解除したり、[ 12 ] : 7 、競合他社やハッカーの目的である、改良されたコピーや模造品を作成したりするためによく使用されます。[ 12 ] : 8

マルウェア開発者は、オペレーティングシステムの脆弱性を見つけ、システムの脆弱性を悪用できるコンピュータウイルスを作成するために、リバースエンジニアリング技術をよく使用します。 [ 12 ] : 5 リバースエンジニアリングは、置換暗号、対称鍵アルゴリズム、公開鍵暗号の脆弱性を見つけるために暗号解読にも使用されています。[ 12 ] : 6

リバース エンジニアリングには他の用途もあります。

  • ゲーム。ゲームやゲームエンジンにおけるリバースエンジニアリングは、基盤となるメカニズム、データ構造、独自プロトコルを理解するためによく使用され、開発者はMODやカスタムツールを作成したり、互換性を高めたりすることができます。この手法は、既存のシステムとインターフェースを取り、異なるゲームコンポーネント、エンジン、プラットフォーム間の相互運用性を向上させる場合に特に役立ちます。ResHax [ 13 ]のようなプラットフォームは、ゲームバイナリの解析やゲームエンジンの動作の分析を支援するツールやリソースを提供しており、ゲーム技術へのより深い理解とコミュニティ主導の機能強化に貢献しています。
  • インターフェース。リバースエンジニアリングは、あるシステムを別のシステムとインターフェースする必要があり、両システム間のネゴシエーション方法を確立する必要がある場合に使用できます。このような要件は、通常、相互運用性のために存在します。
  • 軍事または商業スパイ活動。試作品を盗んだり、捕獲したり、解体したりすることで敵や競合相手の最新の研究を知ることは、類似製品の開発や、それに対するより良い対抗策につながる可能性があります。
  • 陳腐化。集積回路は多くの場合、独自のシステムで設計され、生産ラインで製造されますが、これらの生産ラインはわずか数年で陳腐化します。部品の生産が中止され、それらの部品を使用しているシステムが維持できなくなった場合、その機能を新しい技術に組み込む唯一の方法は、既存のチップをリバースエンジニアリングし、得られた知見を参考にして新しいツールを用いて再設計することです。リバースエンジニアリングによって解決できる、陳腐化に起因するもう一つの問題は、製造元によるサポートが終了した既存のレガシーデバイスのサポート（継続的な運用のための保守と供給）の必要性です。この問題は、特に軍事作戦において深刻です。
  • 製品セキュリティ分析。これは、製品のコンポーネントの仕様を特定し、コストを推定することで製品の仕組みを検証し、潜在的な特許侵害を特定します。また、製品セキュリティ分析には、システムコンポーネントの設計を分解・分析することで機密データを取得することも含まれます。[ 14 ]コピープロテクションの解除やアクセス制限の回避も目的としています。
  • 競争技術情報。競合他社が何をしているかではなく、実際に何をしているかを理解することです。
  • お金を節約。電子機器の機能を知ることで、ユーザーは別の製品を購入する必要がなくなるかもしれません。
  • 再利用。古くなったオブジェクトは、別の、しかし有用な方法で再利用されます。
  • デザイン。製造・デザイン企業は、リバースエンジニアリングを実際の工芸品製造プロセスに適用しました。これらの企業は、3Dスキャン、3Dリモデリング、そして再設計を通じて、「歴史的な」製造コレクションに取り組むことができます。2013年には、イタリアの製造企業であるBaldi社とSavio Firmino社がフィレンツェ大学と共同で、イノベーション、デザイン、そして製造プロセスの最適化を行いました。 [ 15 ]

一般的な用途

機械

コンピュータ支援設計（CAD）の普及に伴い、リバースエンジニアリングは、3D CAD、CAM、CAE、またはその他のソフトウェアで使用するために、既存の物理部品の3D仮想モデルを作成するための現実的な方法となっています。[ 16 ]リバースエンジニアリングのプロセスでは、物体を測定し、それを3Dモデルとして再構築します。物体は、 CMM、レーザースキャナー、構造化光デジタイザー、産業用CTスキャン（コンピュータ断層撮影）などの3Dスキャン技術を使用して測定できます。通常、点群として表される測定データだけでは、位相情報と設計意図が欠けています。位相情報は、点群を三角形の面を持つメッシュに変換することで回復できます。リバースエンジニアリングは、そのようなメッシュの作成にとどまらず、必要に応じて単純な解析面（平面、円柱など）や、場合によってはNURBS面を用いて設計意図を回復し、境界表現CADモデルを作成することを目的としていますこのようなモデルを復元すると、新しい要件を満たすように設計を変更したり、製造計画を生成したりできるようになります。

ハイブリッドモデリングとは、NURBSとパラメトリックモデリングを併用する際によく使われる用語です。幾何形状と自由形状面を組み合わせることで、3Dモデリングの強力な手法を実現できます。自由形状データ領域を正確な幾何形状面と組み合わせることで、ハイブリッドモデルを作成できます。その典型的な例としては、ウォータージャケットや高精度加工領域などの自由形状鋳造フィーチャを含むシリンダーヘッドのリバースエンジニアリングが挙げられます。[ 17 ]

リバースエンジニアリングは、既存の物理ジオメトリをデジタル製品開発環境に取り込む、自社製品のデジタル3D記録を作成する、競合他社の製品を評価するために企業でも利用されています。製品の仕組み、機能、構成部品の分析、コストの見積もり、潜在的な特許侵害の特定などに活用されています。

バリューエンジニアリングは、企業でも活用される関連活動であり、製品の分解と分析を伴います。ただし、その目的はコスト削減の機会を見つけることです。

プリント基板

プリント基板のリバースエンジニアリングでは、特定の基板の製造データを再現します。これは主に設計を特定し、その機能的および構造的特性を把握するために行われます。また、特に設計情報が容易に入手できない場合、製品の背後にある設計原理を発見することも可能になります

古くなったPCBは、特に機械やその他の電子部品への電力供給など、極めて重要な機能を果たす場合、リバースエンジニアリングの対象となることがよくあります。これらの古い部品をリバースエンジニアリングすることで、PCBが重要な機能を果たしている場合、PCBを再構築できるだけでなく、同じ機能を提供する代替品を見つけたり、古いPCBをアップグレードしたりすることも可能です。[ 18 ]

PCBのリバースエンジニアリングは、基本的に同じ一連の手順を踏みます。まず、PCBの図面、スキャン、または写真撮影によって画像を作成します。次に、これらの画像を適切なリバースエンジニアリングソフトウェアに移植し、新しいPCBの基本設計を作成します。適切なリバースエンジニアリングに必要な画像の品質は、PCB自体の複雑さに比例します。複雑なPCBでは、暗い背景に明るい光が当たる写真が必要になりますが、比較的シンプルなPCBであれば、基本的な寸法を測るだけで再現できます。PCBの各層は、最終設計が初期設計にできるだけ近づくように、ソフトウェアで慎重に再現されます。最後に、適切なツールを使用して回路図が生成されます。[ 19 ]

ソフトウェア

1990年、電気電子学会（IEEE）は、（ソフトウェア）リバースエンジニアリング（SRE）を「対象システムを分析し、システムの構成要素とそれらの相互関係を特定し、別の形式またはより高い抽象レベルでシステムの表現を作成するプロセス」と定義しました。ここで「対象システム」とは、ソフトウェア開発の最終成果物です。リバースエンジニアリングは検査のみのプロセスであり、検討対象のソフトウェアシステムに変更を加えることはありません。変更を加えると、リエンジニアリングや再構築が必要になります。リバースエンジニアリングは、必ずしも機能的な最終製品からではなく、製品サイクルのどの段階でも実行できます。[ 11 ]

リバースエンジニアリングには、再文書化と設計回復という2つの要素があります。再文書化とは、コンピュータコードの新しい表現を作成し、理解しやすくすることです。一方、設計回復とは、製品の機能を完全に理解するために、製品に関する一般的な知識や個人的な経験から演繹や推論を用いることです。[ 11 ]これは「開発サイクルを逆戻りする」とも捉えられます。[ 20 ]このモデルでは、実装フェーズの出力（ソースコード形式）を分析フェーズにリバースエンジニアリングし、従来のウォーターフォールモデルを逆転させます。この手法はプログラム理解とも呼ばれます。[ 8 ]リバースエンジニアリングに関するワーキングカンファレンス（WCRE）は、リバースエンジニアリングの手法を探求・拡張するために毎年開催されています。[ 12 ] [ 21 ]コンピュータ支援ソフトウェアエンジニアリング（CASE）と自動コード生成は、リバースエンジニアリングの分野に大きく貢献してきました。[ 12 ]

難読化などのソフトウェア改ざん防止技術は、プロプライエタリソフトウェアやソフトウェア駆動型システムのリバースエンジニアリングとリエンジニアリングの両方を阻止するために使用されます。実際には、リバースエンジニアリングには主に2つの種類があります。1つ目のケースでは、ソフトウェアのソースコードは既に入手可能ですが、プログラムの高レベルな側面（おそらく文書化が不十分、または文書化されているものの有効ではなくなったもの）が発見されます。2つ目のケースでは、ソフトウェアのソースコードは入手できず、ソフトウェアの可能性のあるソースコードを発見するためのあらゆる取り組みがリバースエンジニアリングとみなされます。後者の用法の方が、ほとんどの人にとって馴染み深いものです。ソフトウェアのリバースエンジニアリングでは、著作権侵害を回避するためにクリーンルーム設計手法を活用できます。

関連する点として、ソフトウェアエンジニアリングにおけるブラックボックステストはリバースエンジニアリングと多くの共通点があります。テスターは通常APIを所有していますが、製品の外部からテストを行うことでバグや未文書化の機能を見つけることが目的です。[ 22 ]

リバースエンジニアリングのその他の目的としては、セキュリティ監査、コピー保護の解除（「クラッキング」）、民生用電子機器によくあるアクセス制限の回避、組み込みシステムのカスタマイズ（エンジン管理システムなど）、社内修理または改造、低価格の「機能不全」ハードウェア（一部のグラフィックカードのチップセットなど）の追加機能の有効化、あるいは単なる好奇心の満足などがあります。

バイナリソフトウェア

バイナリリバースエンジニアリングは、ソフトウェアのソースコードが入手できない場合に実行されます。[ 12 ]このプロセスは、リバースコードエンジニアリング、またはRCEと呼ばれることもあります。[ 23 ]たとえば、Javaプラットフォームのバイナリの逆コンパイルは、Jadを使用して実行できます。リバースエンジニアリングの有名な事例の1つは、PC BIOSの最初の非IBM実装であり、長年にわたり圧倒的な支配力を持つコンピュータハードウェアプラットフォームである歴史的なIBM PC互換機業界の幕開けとなりました。ソフトウェアのリバースエンジニアリングは、米国では著作権法のフェアユース例外によって保護されています。[ 24 ] Microsoft Windowsシステムを実行していないシステムが、それを実行するシステムとファイルを共有できるようにするSambaソフトウェアは、ソフトウェアリバースエンジニアリングの典型的な例です。[ 25 ] Sambaプロジェクトは、Windowsファイル共有の仕組みに関する未公開情報をリバースエンジニアリングし、Windows以外のコンピュータでエミュレートできるようにしなければならなかったためです。WineプロジェクトはWindows APIに対して同じことを行っており、OpenOffice.orgはMicrosoft Officeファイル形式に対してこれを行っている団体の1つですReactOSプロジェクトは、NT ブランチの現在の Windows オペレーティング システムとのバイナリ (ABI および API) 互換性を提供することを目指しており、その目標はさらに野心的です。これにより、Windows 用に作成されたソフトウェアとドライバーを、クリーン ルーム リバース エンジニアリングされたフリー ソフトウェア (GPL) 版で実行できるようになります。

バイナリソフトウェア技術

ソフトウェアのリバースエンジニアリングは様々な方法で行うことができます。ソフトウェアリバースエンジニアリングの主な3つのグループは次のとおりです。

  1. 情報交換の観察による分析。プロトコルリバースエンジニアリングで最も普及している手法で、バスアナライザやパケットスニファなどを使用してコンピュータバスやコンピュータネットワーク接続にアクセスし、そこに含まれるトラフィックデータを明らかにします。その後、バスまたはネットワークの動作を分析して、その動作を模倣するスタンドアロン実装を作成できます。これは、デバイスドライバのリバースエンジニアリングに特に役立ちます。組み込みシステムのリバースエンジニアリングでは、 JTAGポートやその他のデバッグ手段など、メーカーが意図的に導入したツールが大きな助けとなる場合があります。Microsoft Windowsでは、 SoftICEなどの低レベルデバッガが人気です。
  2. 逆アセンブラを用いた逆アセンブルとは、プログラムの生の機械語を、機械語ニーモニックの助けを借りて、その言葉通りに読み解くことを意味します。これはあらゆるコンピュータプログラムで実行可能ですが、特に機械語に慣れていない人にとってはかなりの時間がかかります。インタラクティブ・ディスアセンブラは特に人気のあるツールです。
  3. デコンパイラを使用した逆コンパイル。マシン コードまたはバイトコードでのみ使用可能なプログラムのソース コードを何らかの高水準言語で再作成しようとするプロセスで、結果はさまざまです。

ソフトウェア分類

ソフトウェア分類とは、異なるソフトウェアバイナリ（同じバイナリの2つの異なるバージョンなど）間の類似性を識別するプロセスであり、ソフトウェアサンプル間のコード関係を検出するために使用されます。このタスクは、従来、脆弱性検出や著作権侵害のためのパッチ分析など、いくつかの理由から手動で行われていましたが、現在では大量のサンプルに対してある程度自動的に実行できます

この手法は、主に長時間にわたる徹底的なリバースエンジニアリングタスク（複雑なアルゴリズムや大規模なソフトウェアの完全な分析）に使用されています。一般的に、統計的分類は難しい問題と考えられており、ソフトウェア分類も同様です。そのため、このタスクを適切に処理できるソリューションやツールはほとんどありません。

ソースコード

多くのUMLツールでは、 ソースコードをインポートして分析し、UMLダイアグラムを生成するプロセスを「リバースエンジニアリング」と呼んでいます

UMLは「リバースエンジニアリング」を提供する一つのアプローチですが、近年の国際標準化活動の進歩により、知識発見メタモデル（KDM）が開発されました。この標準は、プログラミング言語構成要素とその相互関係の中間（または抽象化）表現のためのオントロジーを提供します。オブジェクト管理グループの標準であり（ISO標準にもなりつつあります）、KDMはソースコード、バイナリコード、バイトコードの抽出と分析を可能にするツールと分析環境の開発により、産業界に定着し始めています。ソースコード分析においては、KDMの粒度の高い標準アーキテクチャにより、ソフトウェアシステムフロー（データ、制御、呼び出しマップ）、アーキテクチャ、ビジネス層の知識（ルール、用語、プロセス）の抽出が可能です。この標準により、共通データ形式（XMI）の使用が可能になり、システム知識の様々な層の相関関係を詳細分析（根本原因、影響など）または派生分析（ビジネスプロセスの抽出など）に活用できるようになります。言語構造を表現するための取り組みは、言語の数、ソフトウェア言語の継続的な進化、そして新しい言語の開発によって終わりのないものになりかねませんが、この標準では、幅広い言語セットとその進化をサポートするための拡張機能の使用が認められています。KDMはUML、BPMN、RDFなどの標準と互換性があり、他の環境への移行を可能にし、ソフトウェアシステムの変革やエンタープライズビジネスレイヤー分析などの取り組みにおいてシステム知識を活用できます。

プロトコル

プロトコルとは、メッセージの形式と交換方法を記述する一連の規則、つまりプロトコルステートマシンです。したがって、プロトコルリバースエンジニアリングの問題は、メッセージ形式とステートマシンリバースエンジニアリングという2つのサブ問題に分割できます

メッセージ形式は、従来、プロトコル実装がメッセージを処理する方法を分析する面倒な手動プロセスによってリバースエンジニアリングされてきましたが、最近の研究では、いくつかの自動ソリューションが提案されています。[ 26 ] [ 27 ] [ 28 ]通常、自動アプローチでは、さまざまなクラスタリング分析を使用してメッセージをクラスターにグループ化するか、メッセージ処理をトレースするプロトコル実装をエミュレートします。

プロトコルのステートマシンのリバースエンジニアリングに関する研究は少ない。一般的に、プロトコルのステートマシンは、通信を受動的に観察し、観察されたすべてのメッセージシーケンスを受け入れる最も一般的なステートマシンを構築しようとするオフライン学習プロセスと、メッセージのプローブシーケンスを対話的に生成し、それらのプローブシーケンスへの応答をリッスンするオンライン学習プロセスのいずれかを通じて学習できる。一般的に、小規模なステートマシンのオフライン学習はNP完全であることが知られているが[ 29 ]、オンライン学習は多項式時間で実行できる。[ 30 ]自動オフラインアプローチはComparettiらによって実証されている[ 28 ] 。また、オンラインアプローチはChoらによって実証されている[ 31 ]。

暗号化やハッシュ関数といった典型的なプロトコルの他の構成要素も、自動的にリバースエンジニアリングできます。典型的には、自動的なアプローチでは、プロトコル実装の実行をトレースし、暗号化されていないパケットを保持するメモリ内のバッファを検出しようとします。[ 32 ]

集積回路／スマートカード

リバースエンジニアリングは、スマートカードを分析する侵襲的かつ破壊的な方法です。攻撃者は化学物質を使用してスマートカードの層を一つ一つエッチングし、走査型電子顕微鏡（SEM）で写真を撮影します。この技術により、スマートカードのハードウェアとソフトウェア部分を完全に明らかにすることができます。攻撃者にとっての主な問題は、すべてを正しく並べ、どのように動作するかを調べることです。カードメーカーは、バススクランブルなど、メモリの位置を混ぜることで、キーと操作を隠そうとします。[ 33 ] [ 34 ]

場合によっては、スマートカードが動作している間にプローブを接続して電圧を測定することさえ可能です。カードメーカーは、このような攻撃を検知・防止するためのセンサーを採用しています。[ 35 ]この攻撃は、大規模な投資と、通常は大手チップメーカーしか入手できない特殊な機器が必要となるため、それほど一般的ではありません。さらに、シャドーアカウントなどの他のセキュリティ手法が使用されることが多いため、この攻撃による利益は小さいです。チップ＆PINカードに対して暗号化データを複製し、PINを解読する攻撃が、多要素認証に対する費用対効果の高い攻撃となるかどうかは依然として不透明です。

完全なリバース エンジニアリングはいくつかの主要なステップで進行します。

SEMで画像を撮影した後の最初のステップは、画像をつなぎ合わせることです。これは、各層を1回の撮影で捉えることができないために必要です。SEMは回路領域を走査し、層全体を網羅するために数百枚の画像を撮影する必要があります。画像つなぎ合わせは、数百枚の画像を入力として受け取り、層全体の適切に重ね合わせた1枚の画像を出力します。

次に、ステッチングされたレイヤーを位置合わせする必要があります。エッチング後のサンプルは、SEMに対して毎回正確に同じ位置に置くことができないためです。そのため、ステッチングされたバージョンは、実際の回路のように正しく重なり合うことはありません。通常は、対応する3つの点を選択し、それに基づいて変換を適用します。

回路構造を抽出するには、位置合わせしてつなぎ合わせた画像を分割し、重要な回路を強調表示して、興味のない背景や絶縁材料から分離する必要があります。

最後に、配線をある層から次の層まで追跡し、回路のすべての情報を含む回路のネットリストを再構築できます。

軍事用途

リバースエンジニアリングは、戦場での正規軍や諜報活動によって入手された他国の技術、装置、または情報を模倣するためによく用いられます。第二次世界大戦と冷戦期には、しばしばリバースエンジニアリングが用いられました。以下は、第二次世界大戦およびその後のよく知られた例です。

遺伝子ネットワーク

リバースエンジニアリングの概念は生物学にも応用されており、特に遺伝子制御ネットワークの構造と機能の理解に役立っています。遺伝子制御ネットワークは生物学的行動のほぼすべての側面を制御し、細胞が生理学的プロセスや摂動への反応を実行できるようにします。したがって、遺伝子ネットワークの構造と動的挙動を理解することは、システム生物学の最も重要な課題の1つであり、基礎研究を超えたいくつかの応用において、すぐに実用的な影響をもたらします。[ 43 ]

分子生物学とデータサイエンスの手法を用いて遺伝子制御ネットワークをリバースエンジニアリングする方法はいくつかある。それらは一般的に6つのクラスに分類される。[ 44 ]

[ 44 ]によると、遺伝子ネットワーク推論法の6つのクラスは、
  • 共発現法は、2 つの遺伝子が類似した発現プロファイルを示す場合、共発現から単純に因果関係を推測することはできないが、それらの遺伝子は関連している可能性があるという考えに基づいています。
  • 配列モチーフ法は、遺伝子プロモーターを解析し、特定の転写因子結合ドメインを見つけます。転写因子が特定の遺伝子のプロモーターに結合すると予測される場合、制御的なつながりが仮説として考えられます。
  • クロマチン免疫沈降(ChIP) 法は、選択された転写因子のDNA 結合のゲノム全体のプロファイルを調査して、下流の遺伝子ネットワークを推測します。
  • オーソロジー法は、遺伝子ネットワークの知識をある種から別の種に転送します。
  • 文献法では、テキスト マイニングと手動調査を実施して、推定または実験的に証明された遺伝子ネットワーク接続を特定します。
  • 転写複合体法は、転写因子間のタンパク質間相互作用に関する情報を活用し、遺伝子ネットワークの概念を転写制御複合体にまで拡張します。

遺伝子ネットワークの信頼性は、多くの場合、遺伝子摂動実験とそれに続く動的モデリングによってテストされます。これは、ネットワークノードを1つ削除すると、ネットワークの残りのノードの機能に予測可能な影響があるという原理に基づいています。[ 45 ] 遺伝子ネットワークのリバースエンジニアリングの応用は、植物生理学のメカニズムの理解から[ 46 ]抗癌治療の新たなターゲットの発見まで多岐にわたります。[ 47 ]

特許法との重複

リバース エンジニアリングは、主に、作成者によってその構築、使用、または内部プロセスの方法が明らかにされていないプロセスまたは成果物を理解することに適用されます。

特許取得済みの製品については、必ずしもリバースエンジニアリングして研究する必要はありません。特許の本質は、発明者が自ら詳細な情報開示を行い、その見返りとして、関連する発明の法的保護を受けることにあるからです。しかし、1つ以上の特許に基づいて製造された製品には、特許取得も開示もされていない他の技術が含まれている可能性があります。実際、リバースエンジニアリングの一般的な目的の一つは、競合他社の製品に特許侵害または著作権侵害が含まれているかどうかを判断することです。

合法性

アメリカ合衆国

アメリカ合衆国では、たとえ成果物やプロセスが企業秘密によって保護されていたとしても、合法的に取得された場合、その成果物やプロセスのリバースエンジニアリングは多くの場合合法です。[ 48 ]

法的分析によれば、リバースエンジニアリングは、著作権が再配布されないことを前提として、システムの機能の研究やセキュリティ研究を目的とした場合、フェアユースとして認められる可能性があることが示されている[ 49 ]。さらに、*Sega Enterprises Ltd. v. Accolade, Inc.*などの裁判所の判決は、ソフトウェアの保護されていない機能要素にアクセスするためのリバースエンジニアリングは、米国の著作権法理の下では合法となり得ることを明確にしている。 [ 50 ]

コンピュータソフトウェアのリバースエンジニアリングは、契約違反として契約法に抵触するだけでなく、その他の関連法規にも抵触することが多い。これは、ほとんどのエンドユーザーライセンス契約で明確に禁止されており、米国の裁判所は、そのような条項が存在する場合、明示的に許可している著作権法よりも優先すると判決を下しているからである（Bowers v. Baystate Technologies [ 51 ] [ 52 ]参照）。デジタルミレニアム著作権法第103条(f)項（17 USC § 1201 (f) ）によれば、プログラムを合法的に保有する者は、「相互運用性」を達成するために必要な場合、リバースエンジニアリングを行い、その保護を回避することができる。「相互運用性」とは、プログラムと相互作用し、プログラムを利用し、有用な方法でデータを使用し、プログラムとの間でデータを転送できる他のデバイスやプログラムを広くカバーする用語である。こうして得られた知識を共有し、相互運用性の目的で利用することを許可する限定的な例外が存在する。[ a ]

欧州連合

コンピュータプログラムの法的保護に関するEU指令2009/24は、以前の（1991年の）指令に取って代わり、欧州連合諸国におけるリバースエンジニアリングを規制しています。[ 53 ] [ 54 ] [ b ]

参照

注記

  1. ^この条項は次のように規定している:(f) リバースエンジニアリング.—(1) サブセクション (a)(1)(A) の規定にかかわらず、コンピュータプログラムのコピーを使用する権利を合法的に取得した者は、独立して作成されたコンピュータプログラムと他のプログラムとの相互運用性を実現するために必要であり、かつ、回避を行う者がこれまで容易に入手できなかったプログラムの要素を識別および分析する目的のみで、そのプログラムの特定部分へのアクセスを効果的に制御する技術的手段を回避することができる。ただし、そのような識別および分析行為が本章の下では侵害を構成しない範囲とする。(2) (a)(2)項および(b)項の規定にかかわらず、(1)項の識別および分析を可能にするため、または独自に作成されたコンピュータプログラムと他のプログラムとの相互運用性を可能にする目的で、当該手段が相互運用性を達成するために必要な場合、人は技術的手段を回避するため、または技術的手段によって与えられる保護を回避するために技術的手段を開発および使用することができる。ただし、これを行うことが本法の下で侵害を構成しない範囲とする。(3) (1)項の下で許可された行為によって取得された情報、および第2項の下で許可された手段は、(1)項または(2)項で言及される人が、独自に作成されたコンピュータプログラムと他のプログラムとの相互運用性を可能にすることのみを目的として、当該情報または手段を提供する場合に限り、他者に提供することができる。ただし、これを行うことが本法の下で侵害を構成しないか、または本条以外の適用法に違反しない範囲とする。（４）この項において、「相互運用性」とは、コンピュータプログラムが情報を交換する能力、及びそのようなプログラムが交換された情報を相互に利用する能力を意味する。
  2. ^指令では次のように述べられている。

    コンピュータ・プログラムのコピーが利用可能となっているコードの形式を無許可で複製、翻訳、翻案または変換することは、著作者の排他的権利の侵害に当たる。しかしながら、独自に作成されたプログラムと他のプログラムとの相互運用性を実現するために必要な情報を得るために、コードの複製およびその形式の翻訳が不可欠な状況も存在する可能性がある。したがって、このような限定された状況においてのみ、プログラムのコピーを使用する権利を有する者またはその代理人による複製および翻訳行為の遂行は正当であり、公正な慣行に適合するものであり、したがって権利者の許可を必要としないとみなされるべきである。この例外の目的は、異なるメーカーのものも含め、コンピュータ・システムのすべてのコンポーネントを接続し、それらが連携して動作できるようにすることである。このような著作者の排他的権利の例外は、権利者の正当な利益を害する方法、またはプログラムの通常の利用と抵触する方法で使用してはならない。

参考文献

  1. ^ 「リバースエンジニアリングとは何か？どのように機能するのか？」 SearchSoftwareQuality 。 2022年7月27日閲覧
  2. ^ 「リバースエンジニアリング」ethics.csc.ncsu.edu . 2022年7月27日閲覧。
  3. ^ Garcia, Jorge (2015年12月). 「アンビルディングブロック：リバースエンジニアリングと適用可能なヒューリスティックスのモデル」(PDF) . Core.ac.uk. 2023年6月4日閲覧。
  4. ^引用エラー: 名前付き参照が呼び出されましたが、定義されていません (ヘルプ ページを参照してください)。:1
  5. ^ Thayer, Ken. 「リバースエンジニアリングはどのように機能するのか？」 globalspec IEEE Global Spec 2018年2月26日閲覧。
  6. ^ Villaverde, Alejandro F.; Banga, Julio R. (2014年2月6日). 「システム生物学におけるリバースエンジニアリングと同定：戦略、展望、そして課題」 . Journal of the Royal Society Interface . 11 (91) 20130505. doi : 10.1098/rsif.2013.0505 . PMC 3869153. PMID 24307566 .  
  7. ^ a b c Chikofsky, EJ & Cross, JH II (1990). 「リバースエンジニアリングと設計リカバリ：分類法」. IEEE Software . 7 (1): 13– 17. Bibcode : 1990ISoft...7a..13C . doi : 10.1109/52.43044 . S2CID 16266661 . 
  8. ^ a bリバースエンジニアリングとプログラム理解の概説。マイケル・L・ネルソン、1996年4月19日、ODU CS 551 – ソフトウェアエンジニアリング概説。arXiv : cs /0503068v1
  9. ^ Vinesh Raja、Kiran J. Fernandes (2007).リバースエンジニアリング：産業的視点. Springer Science & Business Media. p. 3. ISBN 978-1-84628-856-2。
  10. ^ジョナサン・バンド、加藤正信 (2011). 『Interfaces on Trial 2.0』 MIT Press. 136ページ. ISBN 978-0-262-29446-1。
  11. ^ a b c Chikofsky, EJ; Cross, JH (1990年1月). 「リバースエンジニアリングと設計回復：分類法」(PDF) . IEEE Software . 7 (1): 13– 17. Bibcode : 1990ISoft...7a..13C . doi : 10.1109/52.43044 . S2CID 16266661. 2018年4月17日時点のオリジナル(PDF)からアーカイブ。2012年7月2日閲覧 
  12. ^ a b c d e f g hエイラム、エルダド (2005)。リバース: リバースエンジニアリングの秘密。ジョン・ワイリー＆サンズ。ISBN 978-0-7645-7481-8。
  13. ^ 「ResHax」 . ResHax . 2025年11月12日. 2025年11月19日閲覧
  14. ^インターネット技術タスクフォース RFC 2828 インターネットセキュリティ用語集
  15. ^ Karwowski, Waldemar; Trzcielinski, Stefan; Mrugalsk, Beata; DiNicolantonio, Massimo; Rossi, Emilio (2018).製造業、生産管理、プロセス制御の進歩. pp.  287– 288.
  16. ^ Varady, T; Martin, R; Cox, J (1997). 「形状モデルのリバースエンジニアリング入門」. Computer-Aided Design . 29 (4): 255– 268. Bibcode : 1997CAD....29..255V . doi : 10.1016/S0010-4485(96)00054-1 .
  17. ^ 「リバースエンジニアリング」。フィジカルデジタル。
  18. ^ Patel, Suresh (2022年8月25日). 「プリント回路基板のリバースエンジニアリング」 . Electronic Design . 2024年2月1日閲覧。
  19. ^ Patel, Suresh (2022年8月25日). 「プリント回路基板のリバースエンジニアリング」 . Electronic Design . 2024年2月1日閲覧。
  20. ^ Warden, R. (1992).ソフトウェアの再利用とリバースエンジニアリングの実践. ロンドン、イギリス: Chapman & Hall. pp.  283– 305.
  21. ^ 「リバースエンジニアリングに関するワーキングカンファレンス（WCRE）」 uni-trier.deコンピュータサイエンス文献。2017年3月14日時点のオリジナルよりアーカイブ。2018年2月22日閲覧。
  22. ^ Shahbaz, Muzammil (2012).ブラックボックスソフトウェアコンポーネントのリバースエンジニアリングとテスト：文法推論技術による. LAP LAMBERT Academic Publishing. ISBN 978-3-659-14073-0。
  23. ^アントン・チュヴァキン、サイラス・ペイカリ（2004年1月）。『セキュリティ・ウォリアー』（第1版）。オライリー。2006年5月22日時点のオリジナルよりアーカイブ。 2006年5月25日閲覧
  24. ^ Samuelson, Pamela & Scotchmer, Suzanne (2002). 「リバースエンジニアリングの法と経済学」 . Yale Law Journal . 111 (7): 1575– 1663. doi : 10.2307/797533 . JSTOR 797533. 2010年7月15日時点のオリジナルよりアーカイブ。 2011年10月31日閲覧。 
  25. ^ 「Samba: 入門」 2001年11月27日. 2009年5月7日閲覧。
  26. ^ W. Cui、J. Kannan、HJ Wang. 「Discoverer：ネットワークトレースからの自動プロトコルリバースエンジニアリング」第16回USENIXセキュリティシンポジウム議事録、1～14ページ。
  27. ^ W. Cui, M. Peinado, K. Chen, HJ Wang, L. Irún-Briz. Tupni: 入力形式の自動リバースエンジニアリング. 第15回ACMコンピュータおよび通信セキュリティ会議論文集, pp. 391–402. ACM, 2008年10月.
  28. ^ a b P. M. Comparetti、G. Wondracek、C. Kruegel、E. Kirda. Prospex: プロトコル仕様抽出. 2009年第30回IEEEセキュリティとプライバシーシンポジウム議事録、pp. 110–125、ワシントン、2009年. IEEEコンピュータソサエティ.
  29. ^ Gold, E (1978). 「与えられたデータからのオートマトン識別の複雑性」 .情報制御. 37 (3): 302– 320. doi : 10.1016/S0019-9958(78)90562-4 .
  30. ^ D. Angluin (1987). 「クエリと反例からの正規集合の学習」 .情報と計算. 75 (2): 87–106 . doi : 10.1016/0890-5401(87)90052-6 .
  31. ^ CY Cho、D. Babic、R. Shin、D. Song.ボットネットコマンドアンドコントロールプロトコルの形式モデルの推論と分析、2010 ACM Conference on Computer and Communications Security.
  32. ^ポリグロット：動的バイナリ解析を用いたプロトコルメッセージ形式の自動抽出。J. Caballero、H. Yin、Z. Liang、D. Song。第14回ACMコンピュータおよび通信セキュリティ会議議事録、317～329ページ。
  33. ^ Wolfgang Rankl、Wolfgang Effing著『スマートカードハンドブック』（2004年）
  34. ^ T. Welz:スマートカードによる支払い方法(2008)、ボーフム大学ITSセキュリティセミナー
  35. ^ David C. Musker:エレクトロニクスにおける知的財産の保護と活用Archived 2011-07-09 at the Wayback Machine、IBC Conferences、1998年6月10日
  36. ^フランシロン、ルネ・J. (1988) [1979].マクドネル・ダグラス航空機 1920年以降. 第1巻（第2版）. アナポリス、メリーランド州: 海軍研究所出版. pp.  265– 268. ISBN 0-87021-428-4。
  37. ^ウェステル、フリーマン（1999年11月）「巨大な鉄、巨大なエンジン、そしてさらに大きな頭痛：最初の実験的戦略爆撃機の建造」エアパワー29 ( 6): 18,49–50
  38. ^アンジェルッチ、エンツォ、マトリカルディ、パオロ (1978). 『第二次世界大戦の飛行機：第2巻』 シカゴ：ランドマクナリー社. p. 127. ISBN 0-528-88171-X。
  39. ^イェーム・ゴードン、ウラジミール・リグマント著『ツポレフTu-4：ソビエトの超大型要塞』（英国ヒンクリー：ミッドランド、2002年）。
  40. ^ 「レッドストーンロケット」 centennialofflight.net . 2010年4月27日閲覧。
  41. ^「中国空軍：進化する概念、役割、能力」、中国軍事研究センター（米国）、国防大学出版局、277ページ
  42. ^ Chandrashekar, S., R. Nagappa, L. Sundaresan, N. Ramani. 2011. 「中国における技術とイノベーション：航空機タービンブレード向け単結晶超合金開発のケーススタディ」R4–11. ISSSP インド国立高等研究所、バンガロール。http ://isssp.in/wp-content/uploads/2013/01/Technology-and-Innovation-in-China-A-case-Study-of-Single-Crystal4.pdf ;ディロン・チョウ、「中国のJ-15戦闘機：中国当局は新型戦闘機を中国製と擁護するが、疑問は残る」Mic、2012年12月16日、 https://mic.com/articles/20270/china-j-15-fighter-jet-chinese-officials-defend-new-fighter- as-chinese-original-but-questions-remain
  43. ^ Giorgi, Federico M. (2020). 「遺伝子ネットワークリバースエンジニアリング：次世代」. Biochimica et Biophysica Acta (BBA) - 遺伝子制御メカニズム. 1863 ( 6) 194523. doi : 10.1016/j.bbagrm.2020.194523 . hdl : 11585/753853 . ISSN 1874-9399 . PMID 32145356. S2CID 212629142 .   
  44. ^ a b Mercatelli, Daniele; Scalambra, Laura; Triboli, Luca; Ray, Forest; Giorgi, Federico M. (2020). 「遺伝子調節ネットワーク推論リソース：実践的概要」. Biochimica et Biophysica Acta (BBA) - 遺伝子調節メカニズム. 1863 (6) 194430. doi : 10.1016/j.bbagrm.2019.194430 . ISSN 1874-9399 . PMID 31678629. S2CID 207895066 .   
  45. ^ Tegner, J.; Yeung, MKS; Hasty, J.; Collins, JJ (2003). 「遺伝子ネットワークのリバースエンジニアリング：遺伝的摂動と動的モデリングの統合」 . Proceedings of the National Academy of Sciences . 100 (10): 5944– 5949. Bibcode : 2003PNAS..100.5944T . doi : 10.1073/pnas.0933416100 . ISSN 0027-8424 . PMC 156306. PMID 12730377 .   
  46. ^ Friedel, Swetlana; Usadel, Björn; von Wirén, Nicolaus; Sreenivasulu, Nese (2012). 「リバースエンジニアリング：地球規模の非生物的ストレス相互作用を解明するためのシステム生物学の主要構成要素」 . Frontiers in Plant Science . 3 : 294. Bibcode : 2012FrPS....3..294F . doi : 10.3389/fpls.2012.00294 . ISSN 1664-462X . PMC 3533172. PMID 23293646 .   
  47. ^ Lefebvre, Celine; Rieckhof, Gabrielle; Califano, Andrea (2012). 「ヒト調節ネットワークのリバースエンジニアリング」 . Wiley Interdisciplinary Reviews: Systems Biology and Medicine . 4 (4): 311– 325. doi : 10.1002/wsbm.1159 . ISSN 1939-5094 . PMC 4128340. PMID 22246697 .   
  48. ^「Trade Secrets 101」特集記事、2011年3月。ASME。2013年10月31日閲覧。
  49. ^サミュエルソン、P. (2003). 「著作権法下におけるリバースエンジニアリング」 Communications of the ACM, 46(8), 15–20.
  50. ^ Sega Enterprises Ltd. v. Accolade, Inc. , 977 F.2d 1510 (米国第9巡回区控訴裁判所 1992年)。
  51. ^ Baystate v. Bowers 討論. Utsystem.edu. 2011年5月29日閲覧。
  52. ^ Gross, Grant. (2003-06-26)契約訴訟はリバースエンジニアリングに悪影響を及ぼす可能性がある | Developer World . InfoWorld. 2011-05-29閲覧。
  53. ^ 1991年5月14日のコンピュータプログラムの法的保護に関する理事会指令91/250/EEC
  54. ^ 2009年4月23日の欧州議会及び理事会のコンピュータプログラムの法的保護に関する指令2009/24/EC（成文化版）

出典

「 https://en.wikipedia.org/w/index.php?title=リバースエンジニアリング&oldid=1325676714 #ソフトウェア」より取得