
Um C2/teamserver multiplataforma que suporta múltiplos protocolos de transporte, escrito em Go.
Um C2/teamserver multiplataforma com suporte a múltiplos protocolos de transporte, escrito em Go.
Nota: Isto está em desenvolvimento e, como tal, não é exatamente estável. A documentação também é escassa, mas será melhorada gradualmente ao longo do tempo.
O sistema Meteor é dividido em várias partes:
Clone o repositório e construa as imagens compose necessárias:
$ git clone https://github.com/degenerat3/meteor
$ cd meteor
$ docker-compose build
<aguarde pacientemente enquanto Golang e coisas do docker acontecem>
$ docker-compose up
O Meteor já está no ar! Note que você pode remover contêineres do arquivo compose se não for usá-los, então se você quiser apenas usar o transporte web, não há necessidade de também construir e executar Petrie/Cera. Assim que seus contêineres estiverem em execução, faça curl em localhost:8888 para garantir que o core está funcionando.
Neste ponto, um cliente Daddy Tops deve ter sido construído, então siga as instruções em meteor/docs/daddy_tops.md para baixar o cliente e começar a construir agents!
Quase toda comunicação no sistema Meteor é feita com buffers de protocolo. O Padrão de Comunicação Meteor (MCS) define como formatar dados para o Core processá-los. Os listeners e agents também utilizam MCS para transferência de ações e resultados, e o Daddy Tops utiliza MCS para tudo, desde autenticação até registro de bots e grupos. O arquivo proto do MCS pode ser encontrado em meteor/pbuf/mcs.proto.
Os pares agente/listener atuais estão implementados, com planos para mais no futuro:
Desenvolver listeners adicionais deve ser simples o suficiente se você desejar, já que a maior parte da funcionalidade real do Meteor é abstraída para utilitários de Agent e Listener. Na maioria dos casos, a única coisa necessária para a criação de um novo listener é uma maneira confiável de enviar e receber uma sequência de bytes. A partir daí, os utilitários do listener podem rotear os dados para o endpoint apropriado da API do Core, e os utilitários do agent podem executar as ações e construir as cargas MCS adequadas. Ainda há muito a melhorar nesse aspecto, pois há um pouco de lógica e análise de protobuf feita fora dos utilitários nas funções principais.
O Nest é usado para construir e compilar código Meteor (atualmente apenas agents), para que você não precise. Você pode usar o Daddy Tops (ou algo personalizado) para enviar os parâmetros necessários. Ao contrário do resto do projeto, a API do Nest é composta por endpoints JSON em vez de protobuf. Isso é para que os binários possam ser construídos e baixados com alguns simples comandos curl, em vez de exigir o uso de protobuf e código mais complicado.
A documentação é bastante limitada no momento, mas será melhorada com o tempo. Alguns documentos para as APIs do Core e do Nest, bem como instruções para o Daddy Tops, podem ser encontrados em meteor/docs.
AVISO: Esta ferramenta é apenas para fins educacionais. Não mexa em máquinas que não são suas. Os autores não são responsáveis por quaisquer usos ilícitos deste código-base.