
Goで書かれた、複数のトランスポートプロトコルをサポートするクロスプラットフォームのC2/チームサーバー。
Goで書かれた、複数のトランスポートプロトコルをサポートするクロスプラットフォームなC2/チームサーバーです。
注記: これは開発中であり、完全に安定しているわけではありません。ドキュメントも不足していますが、時間をかけて徐々に改善される予定です。
Meteorシステムはいくつかの部分に分かれています:
リポジトリをクローンし、必要なcomposeイメージをビルドします:
$ git clone https://github.com/degenerat3/meteor
$ cd meteor
$ docker-compose build
<wait patiently as Golang and docker stuff happens>
$ docker-compose up
Meteorが起動しました! 使用しないコンテナはcomposeファイルから削除できることに注意してください。たとえばwebトランスポートのみを使用する場合、Petrie/Ceraをビルドして実行する必要はありません。コンテナが実行されたら、localhost:8888 をcurlしてCoreが実行されていることを確認してください。
この時点でDaddy Topsクライアントがビルドされているはずなので、meteor/docs/daddy_tops.md の手順に従ってクライアントをダウンロードし、エージェントのビルドを開始してください!
ほぼすべての Meteorシステム内の通信は、protocol buffersを使用して行われます。Meteor Communication Standard (MCS) は、Coreが処理するためのデータのフォーマット方法を定義します。リスナーとエージェントもアクションと結果の転送にMCSを利用し、Daddy Topsは認証からボット・グループ登録に至るまでMCSを利用します。MCSのprotoファイルは meteor/pbuf/mcs.proto にあります。
現在のエージェント/リスナーのペアは実装されており、将来さらに追加される予定です:
追加のリスナーを開発することは、あなたが望めば十分に簡単でしょう。実際のMeteor機能のほとんどはAgent utilとListener utilに抽象化されているためです。ほとんどの場合、新しいリスナーを作成するために必要なのは、バイト文字列を確実に送受信できることだけです。そこから、リスナーutilはデータを適切なCore APIエンドポイントにルーティングし、エージェントutilはアクションを実行して適切なMCSペイロードを構築できます。この点に関してはまだ改善の余地が多くあります。main関数内でutilの外で行われているロジックとprotobufパースがいくらかあるためです。
NestはMeteorコード(現在はエージェントのみ)のビルドとコンパイルに使用されるので、自分で行う必要はありません。Daddy Tops(またはカスタムツール)を使用して必要なパラメータを送信できます。プロジェクトの他の部分とは異なり、Nest APIはprotobufではなくJSONエンドポイントで構成されています。これは、protbufやより複雑なコードを使用せずに、いくつかの簡単なcurlコマンドでバイナリをビルドしてダウンロードできるようにするためです。
現在ドキュメントはかなり限られていますが、時間とともに改善される予定です。Core APIとNest APIのドキュメントや、Daddy Topsの手順は meteor/docs にあります。
免責事項: このツールは教育目的のみです。自分が所有していないマシンをいじらないでください。作成者は、このコードベースの不正使用について一切責任を負いません。