
Un C2/teamserver multiplateforme prenant en charge plusieurs protocoles de transport, écrit en Go.
Un C2/teamserver multiplateforme prenant en charge plusieurs protocoles de transport, écrit en Go.
Note : Ceci est en développement et n'est donc pas exactement stable. La documentation est également incomplète, mais elle sera améliorée progressivement au fil du temps.
Le système Meteor est divisé en plusieurs parties :
Clonez le dépôt et construisez les images compose requises :
$ git clone https://github.com/degenerat3/meteor
$ cd meteor
$ docker-compose build
<wait patiently as Golang and docker stuff happens>
$ docker-compose up
Meteor est maintenant opérationnel ! Notez que vous pouvez supprimer les conteneurs du fichier compose si vous ne les utilisez pas. Ainsi, si vous ne voulez utiliser que le transport web, il n'est pas nécessaire de construire et d'exécuter aussi Petrie/Cera. Une fois vos conteneurs en cours d'exécution, faites un curl localhost:8888 pour vérifier que le core fonctionne.
À ce stade, un client Daddy Tops devrait être construit. Suivez donc les instructions dans meteor/docs/daddy_tops.md pour télécharger le client et commencer à créer des agents !
Presque toutes les communications dans le système Meteor sont effectuées avec des protocol buffers. Le Meteor Communication Standard (MCS) définit comment formater les données pour que le Core puisse les traiter. Les listeners et les agents utilisent également MCS pour le transfert des actions et des résultats, et Daddy Tops utilise MCS pour tout, de l'authentification à l'enregistrement des bots et des groupes. Le fichier proto MCS se trouve à meteor/pbuf/mcs.proto.
Les paires agent/listener actuelles sont implémentées, avec des projets pour plus à l'avenir :
Le développement de listeners supplémentaires devrait être assez simple si vous le souhaitez, car la plupart des fonctionnalités réelles de Meteor sont abstraites dans les utils Agent et Listener. Pour l'essentiel, la seule chose requise pour créer un nouveau listener est un moyen fiable d'envoyer et de recevoir une chaîne d'octets. À partir de là, les utils listener peuvent router les données vers le endpoint API approprié du Core, et les utils agent peuvent exécuter les actions et construire les payloads MCS appropriés. Il reste encore beaucoup d'améliorations à faire à cet égard, car une partie de la logique et de l'analyse protobuf est effectuée en dehors des utils dans les fonctions principales.
Le Nest est utilisé pour construire et compiler le code de Meteor (actuellement uniquement les agents), afin que vous n'ayez pas à le faire. Vous pouvez utiliser Daddy Tops (ou un outil personnalisé) pour envoyer les paramètres requis. Contrairement au reste du projet, l'API Nest est composée d'endpoints JSON plutôt que de protobuf. Cela permet de construire et de télécharger les binaires avec quelques simples commandes curl, plutôt que d'exiger l'utilisation de protobuf et de code plus compliqué.
La documentation est assez limitée pour le moment, mais elle s'améliorera avec le temps. Certains documents pour les API Core et Nest, ainsi que des instructions pour Daddy Tops, sont disponibles dans meteor/docs.
AVERTISSEMENT : Cet outil est uniquement à des fins éducatives. Ne touchez pas aux machines qui ne vous appartiennent pas. Les auteurs ne sont pas responsables des utilisations illicites de cette base de code.