martyx00/collareマルチツール対応のリバースエンジニアリング共同作業ソリューション。
CollaRE は、共同リバースエンジニアリングのためのツールで、プロジェクト中に複数のツールを使う必要があるチームが、別の場所でファイルを共有しなくてもコラボレーションできるようにすることを目的としています。また、非常にシンプルなユーザー管理機能も含まれており、異なるチームが異なるプロジェクトで作業するマルチプロジェクトサーバーとしても使用できます。
このツールのバックエンドは、Docker で動作する nginx を前面に配置したシンプルな Flask app で、関連データを保持するファイルと JSON ベースのマニフェストを扱います。フロントエンドは、プロジェクトの管理と、バイナリファイルおよび対応するリバースエンジニアリングデータベースの操作を可能にするシンプルなインターフェースを備えた PyQT ベースの GUI ツールです。現時点では、このツールは Binary Ninja、Cutter (Rizin)、Ghidra、Hopper Dissassembler、IDA、JEB、Android Studio (Decompiled by JADX) をサポートしています。実装は、API の変更による問題を回避するために、これらのツールの内部動作から可能な限り抽象化されており、そのため、プラグインの形でこれらのツールに直接統合されることはありません（後述のデータ移行プラグインを除く）。この作業は、これらのツールが生成するファイル（よく知られたファイル拡張子のみに基づく）の管理と、シンプルな SVN スタイルの check-out および check-in 操作のみに基づいています。
最新のバイナリリリースをこのリポジトリから入手するか、リポジトリをクローンして Linux では sudo python3 setup.py install を実行するか、Windows ではコマンドラインを使用して python3 setup.py install を実行してください。Linux では、これによりツールが PATH にインストールされ、collare コマンドで簡単に実行できるようになります。Windows では、ファイルは C:\Users\<USERNAME>\AppData\Local\Programs\Python\<PYTHON_VERSION>\Scripts\collare.exe に配置されます（Python のインストール方法によって異なります）。
Gnome ベースのデスクトップ UI の場合は、次のデスクトップファイルを使用できます（ファイルへのパスは CollaRE と Python のバージョンによって異なる場合があります）。
[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=CollaRE
Exec=/usr/local/bin/collare
Icon=/usr/local/lib/python3.8/dist-packages/collare-1.2-py3.8.egg/collare/icons/collare.png
Terminal=false
Cutter のサポートを有効にするには、Cutter というファイルを PATH に追加します（cmd/terminal を開いたときに Cutter と入力するとアプリケーションが起動するようにします）。
Cutter (rizin) プロジェクトを保存するときは、手動で .rzdb を追加する必要があります。ファイルがすでに持っている拡張子（たとえば exe や so）は削除しないでください。
Binary Ninja のサポートを有効にするには、binaryninja というファイルを PATH に追加します（cmd/terminal を開いたときに binaryninja と入力するとアプリケーションが起動するようにします）。
Binary Ninja はデフォルトでファイル拡張子を削除しますが、このツールはそれを考慮しているため、元のファイル拡張子を手動で戻す必要はありません。プロジェクトをデフォルトのパスにそのまま保存すれば、ローカルの bndb データベースを正常にプッシュできます。
Hopper Disassembler のサポートを有効にするには、Hopper というファイルを PATH に追加します（cmd/terminal を開いたときに Hopper と入力するとアプリケーションが起動するようにします）。
Hopper はデフォルトでファイル拡張子を削除しますが、このツールはそれを考慮しているため、元のファイル拡張子を手動で戻す必要はありません。Ctrl+S でプロジェクトを保存するだけで、ローカルの hop データベースを正常にプッシュできます。
JEB のサポートを有効にするには、jeb というファイルを PATH に追加します（cmd/terminal を開いたときに jeb と入力するとアプリケーションが起動するようにします）。これは、お使いの OS 用のデフォルトのランナースクリプトファイルを jeb に名前を変更することで行えます（Windows の場合は実際には jeb.bat になります）。
IDA ツールのサポートを有効にするには、ida64 と ida というファイルを PATH に追加します（cmd/terminal を開いたときに ida64/ida と入力するとアプリケーションが起動するようにします）。
このツールのサポートを有効にするには、ghidraRun と analyzeHeadless（Windows では .bat）というファイルを PATH に追加します（cmd/terminal を開いたときに ghidraRun と入力するとアプリケーションが起動するようにします）。analyzeHeadless は Ghidra のルートディレクトリ内の support フォルダにあるため、両方のファイルが含まれるように PATH を調整してください。
Ghidra でデータベースを初期化するプロセスは少し複雑です。プロジェクトを作成せずに Ghidra がファイルを処理する方法がないためです。そのため、Ghidra データベース（ghdb と呼ばれます）をプッシュできるようにするには、自動処理が失敗するたびに（基本的には処理するファイルが ELF/PE ではない場合）、プロジェクトを手動で作成し、その後 gpr ファイルへのパスを指定するよう求められます（ご不便をおかけします）。
リバースエンジニアリングの作業中に APK ファイルや JAR ファイルはよく遭遇するため、CollaRE ツールはこれらのタイプのファイルの操作もサポートしています。これらのツールのサポートを有効にするには、android-studio と jadx の両方のファイルが PATH にあることを確認する必要があります（cmd/terminal を開いたときに android-studio/jadx と入力するとアプリケーションが起動するようにします）。JADX ツールは JAR/APK ファイルの逆コンパイルを実行するために使用され、Android Studio は結果のファイルを開くために使用されます。Android Studio の使用は任意であることに注意してください。Gradle プロジェクトを処理する他のツールを android-studio コマンドとしてエイリアス（IntelliJ IDEA など）することができます。
サーバー側を独自の readme ファイルで説明されているとおりにデプロイした後、使用する証明書ファイルをアプリケーションのすべてのユーザーに配布し、デフォルトの admin アカウントと admin パスワードを使用して、Admin タブから他のユーザーアカウントを作成する必要があります（admin ユーザーのパスワードを変更することを忘れないでください）。ユーザーが設定されると、誰でも自分のプロジェクトを作成し、ツール自体の操作を開始できます。
プロジェクトを作成するには、ユーザーはまず URL と資格情報を入力し、証明書を提供してサーバーの ID を検証することにより、リモートサーバーに認証する必要があります。その後、ステータスが Connected に変わり、既存のプロジェクトを選択または削除したり、名前（英数字と _ のみ）を入力してプロジェクトに参加するユーザーを選択するだけで新しいプロジェクトを作成したりできます（後で Admin タブで変更できます）。プロジェクトを作成するユーザーは自動的にユーザーリストに追加されるため、自分自身を選択する必要はありません。
Project View タブに移動すると、新しいフォルダー（英数字と _ のみ。すみません）を作成し、ドラッグアンドドロップでファイル（またはフォルダー）をアップロードできます。
このツールには現在、プロジェクトを保存したときに自動アップロードを可能にするプラグインやネイティブフックがないため、目的のデータベースを作成した後にローカル DB ファイルのプッシュを手動でトリガーする必要があります。これは、アップロードされたバイナリファイルを右クリックし、バイナリを処理するツールを選択することで行えます。基本的な解析はできますが、何も変更せずにファイルを保存することを強くお勧めします（Cutter での rzdb の追加と、Ghidra でのまったく異なるプロセスを除く）。パスとファイル名を変更しないでください。これを行って逆アセンブラを閉じた後、バイナリ名を右クリックして Push Local DBs オプションを選択するだけです。これによりローカルデータベースがアップロードされ、以降 DB ファイルを操作するときは Check-out を実行する必要があります。各バイナリはすべてのツールで個別に処理できますが、バイナリとツールごとに存在できる DB ファイルは 1 つだけであることに注意してください。
ファイルを検査したいだけの場合は、目的の DB ファイルを右クリックして Open File オプションを選択します（またはダブルクリックします）。ファイルが自分にチェックアウトされている場合は、ローカルファイルが開き、DB ファイルに自由に変更を加えることができます。完了したら（または変更をプッシュしたいだけの場合は）、Check-in オプションを選択できます。これにより変更がサーバーにアップロードされ、さらに変更するためにファイルをチェックアウトしたままにするかどうかを尋ねられます。ローカルの変更を破棄したい場合は、コンテキストメニューから Undo Check-out オプションを選択します。これにより変更が破棄され、サーバー上のファイルで続行できます。最初に Check-out 操作を行わずにファイルを開くと、擬似的な読み取り専用モードで開かれます（DB ファイルに変更を加えることはできますが、次回チェックアウトまたはファイルを開いたときにそれらの変更は失われます）。
このツールは、DB ファイルのバージョン管理もサポートしており、Check-in アクションのたびに DB ファイルの新しいバージョンとしてカウントされます。そのバージョンで適用された変更にコンテキストを与えるために使用されるバージョンのコメントを入力するよう求められます。その後、ファイルの以前のバージョンを開いたりチェックアウトしたりして、それらのバージョンで作業することができます。
このリポジトリ内のプラグインフォルダには、複数のツールで 1 つのバイナリを操作する場合に、ツール間でコメントと関数名を共有できるようにするための対応ツール用のプラグインが含まれています。対象のツールの標準的なプラグインインストール手順に従ってください。各プラグインは Import 機能と Export 機能を提供します。ツール間でデータを共有する予定がある場合は、他の誰かがすでに名前を変更した関数を再度変更しないように、必ず最初にデータを Import してください。プラグインに注意点がある場合は、そのプラグインの README ファイルに記載されています。プラグインは、複数人の同時コラボレーションのためではなく、他のツールへのデータ移行を目的としていることに注意してください。
