
크로스 플랫폼 C2/팀서버로, Go로 작성되었으며 다중 전송 프로토콜을 지원합니다.
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 파일에서 제거할 수 있으므로, 웹 전송만 사용하려면 Petrie/Cera를 굳이 빌드하고 실행할 필요는 없습니다. 컨테이너가 실행되면 localhost:8888을 curl로 확인하여 Core가 실행 중인지 확인하세요.
이제 Daddy Tops 클라이언트가 빌드되어 있을 것이므로, meteor/docs/daddy_tops.md의 지침에 따라 클라이언트를 다운로드하고 에이전트 빌드를 시작하세요!
Meteor 시스템의 거의 모든 통신은 프로토콜 버퍼로 이루어집니다. Meteor 통신 표준(MCS)은 Core가 처리할 데이터 형식을 정의합니다. 리스너와 에이전트는 작업 및 결과 전송에도 MCS를 사용하며, Daddy Tops는 인증부터 봇/그룹 등록까지 모든 것에 MCS를 사용합니다. MCS proto 파일은 meteor/pbuf/mcs.proto에서 찾을 수 있습니다.
현재 에이전트/리스너 쌍은 다음과 같이 구현되어 있으며, 향후 더 많은 프로토콜이 추가될 예정입니다:
원한다면 추가 리스너를 개발하는 것은 충분히 간단합니다. 대부분의 실제 Meteor 기능은 Agent 및 Listener 유틸리티로 추상화되어 있기 때문입니다. 대부분의 경우 새 리스너를 만드는 데 필요한 것은 바이트 문자열을 안정적으로 보내고 받는 방법뿐입니다. 그 이후에는 리스너 유틸리티가 데이터를 적절한 Core API 엔드포인트로 라우팅하고, 에이전트 유틸리티가 작업을 실행하고 올바른 MCS 페이로드를 구성할 수 있습니다. 이와 관련해서는 아직 개선할 여지가 많습니다. 일부 로직 및 protobuf 파싱이 유틸리티 외부의 main 함수에서 수행되기 때문입니다.
Nest는 Meteor 코드(현재는 에이전트만 해당)를 빌드하고 컴파일하는 데 사용되므로 직접 빌드할 필요가 없습니다. Daddy Tops(또는 사용자 지정 도구)를 사용하여 필요한 매개변수를 보낼 수 있습니다. 프로젝트의 나머지 부분과 달리 Nest API는 protobuf가 아닌 JSON 엔드포인트로 구성됩니다. 이는 몇 가지 간단한 curl 명령으로 바이너리를 빌드하고 다운로드할 수 있도록 하기 위함이며, protobuf와 더 복잡한 코드를 사용할 필요가 없게 하기 위함입니다.
현재 문서는 상당히 제한적이지만 시간이 지나면서 개선될 예정입니다. Core 및 Nest API에 대한 문서와 Daddy Tops 사용 지침은 meteor/docs에서 찾을 수 있습니다.
고지 사항: 이 도구는 교육 목적으로만 제공됩니다. 다른 사람의 기기를 무단으로 조작하지 마세요. 작성자는 이 코드베이스의 불법적인 사용에 대해 책임을 지지 않습니다.