Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
AV-Chaos-Monkey — Caos Monkey, mas para teste de áudio e vídeo (webRTC e UDP) | Kitploit
Ferramentas/GitHubGitHub/mdsadiqmd/av-chaos-monkey
Segurança WebSegurança de RedeTestes de PenetraçãoSegurança na NuvemDevSecOpsEngenharia do Caos
GitHubmdsadiqmd/av-chaos-monkey

AV-Chaos-Monkey

Caos Monkey, mas para teste de áudio e vídeo (webRTC e UDP)

Ver Repositório
526há 6 mesesRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

AV Chaos Monkey

Plataforma de engenharia do caos distribuída para teste de carga em sistemas de videoconferência. Simula mais de 1500 participantes WebRTC com streams H.264/Opus e injeta picos de caos na rede para validar a resiliência do sistema sob condições degradadas.

Arquitetura

image
  1. Pipeline de Processamento de Mídia:

    • FFmpeg converte vídeo de entrada para H.264 Annex-B e Ogg/Opus na inicialização
    • NAL Reader analisa o stream H.264 (SPS/PPS/IDR/Slices)
    • Opus Reader extrai quadros de áudio de 20ms do container Ogg
    • Quadros armazenados em cache na memória, compartilhados entre todos os participantes (cópia zero)
    • Reduz a CPU em ~90% vs. codificação por participante
  2. Plano de Controle:

    • Servidor HTTP (:8080) gerencia o ciclo de vida do teste via API REST
    • Spike Scheduler distribui eventos de caos (par/aleatório/frente/trás/legado)
    • Network Degrader aplica caos: perda de pacotes (1-25%), jitter (10-50ms), redução de bitrate (30-80%), queda de quadros (10-60%)
    • Configuração de caos carregada aplicada ao pool de participantes
  3. Pool de Participantes:

    • Particionamento automático entre pods usando: participant_id % total_partitions = partition_id
    • Cada participante gera streams RTP (PT=96 vídeo, PT=111 áudio)
    • ID do participante embutido no cabeçalho de extensão RTP (ID=1)
    • Tamanho do pool: 1-100 (local), 100-500 (Docker), 500-1500 (Kubernetes)
  • Auto-Configuração Kubernetes:

    • Pods detectam automaticamente o ID da partição pelo nome do pod: orchestrator-3 → PARTITION_ID=3
    • Alocação de porta: base_port + (partition_id × 10000) + participant_index
    • Exemplo: Partição 0 usa 5000-14999, Partição 1 usa 15000-24999
    • StatefulSet com 10 réplicas, cada uma lidando com ~150 participantes
    • Recursos: 1-4 CPU, 2-4Gi de memória por pod
    • Configuração automática baseada nas especificações da máquina host
  • Cadeia de Relé UDP (apenas Kubernetes):

    root@kitploit:~
    Pods Orchestrator (10×) → UDP :5000 → Pod udp-relay (Python)
    → TCP com prefixo de comprimento :5001 → kubectl port-forward 15001:5001
    → tools/udp-relay (Go) → UDP :5002 → Seu Receptor
    
    • Por quê: kubectl port-forward só suporta TCP, não UDP
    • Relé no cluster: Script Python agrega UDP de todos os pods, transmite como TCP com prefixo de 2 bytes de comprimento
    • Relé local: Ferramenta Go converte o stream TCP de volta para pacotes UDP
    • Agrega 1500 streams de participantes em uma única conexão
  • Infraestrutura WebRTC:

    • Coturn StatefulSet: 3 réplicas iniciais, HPA escala de 1 a 10 com base na carga (~500 participantes/réplica)
    • coturn-lb Service: Balanceia o tráfego TURN entre as réplicas
    • webrtc-connector: Camada de proxy opcional (Deployment + HPA 2-10 réplicas), lida com sinalização SDP
    • Modo Docker: Container Coturn único para testes locais
    • Portas: 3478 (TURN), 49152-65535 (faixa de relé)
    • Credenciais: webrtc/webrtc123
  • Integração com Cliente:

    • Receptor UDP: Recebe o stream RTP agregado de todos os participantes via cadeia de relé
    • Receptor WebRTC: Estabelece conexões WebRTC 1:1 via troca de SDP através de servidores TURN
    • Ambos encaminham para seu sistema de videochamada em teste (SFU/MCU/Mesh)
  • Pilha de Observabilidade (Opcional):

    • Prometheus: Coleta o endpoint /metrics de todos os pods do orchestrator a cada 5s
    • Grafana: Visualiza métricas via painel pré-configurado (admin/admin)
    • Métricas expostas: contagem de participantes, pacotes enviados, bytes enviados, picos ativos, % de perda de pacotes, jitter, pontuação MOS
    • Acesso: Prometheus em :30090, Grafana em :30030 (NodePort)
    • Pods do orchestrator anotados para descoberta automática: prometheus.io/scrape: "true"
  • Conceitos Principais

    Simulação de Participante

    Cada participante virtual gera streams de mídia reais:

    • Vídeo: Unidades NAL H.264 de arquivos de vídeo reais, empacotadas conforme RFC 6184
    • Áudio: Quadros Opus de containers Ogg, empacotados conforme RFC 7587
    • RTP: Cabeçalhos compatíveis com padrões com extensões de ID do participante
    • Temporização: Temporização precisa de quadros (30fps vídeo, pacotes de áudio de 20ms)

    Injeção de Caos

    Cinco tipos de pico simulam condições reais de rede:

    • Perda de Pacotes: Descarta pacotes RTP na camada de aplicação (1-100%)
    • Jitter de Rede: Adiciona variação de latência (latência base + jitter gaussiano)
    • Redução de Bitrate: Limita a codificação de vídeo (30-80% de redução)
    • Queda de Quadros: Pula quadros de vídeo (10-60% de taxa de queda)
    • Limitação de Banda: Limita a taxa total de transferência

    Estratégias de Distribuição

    Os picos são distribuídos ao longo da duração do teste usando estratégias configuráveis:

    • Uniforme: Espaçamento uniforme com jitter (carga previsível)
    • Aleatório: Temporização imprevisível (caos realista)
    • Concentrado no Início: Picos densos no início (teste de recuperação)
    • Concentrado no Fim: Linha de base seguida de caos (teste de comparação)
    • Legado: Temporizador de intervalo fixo (injeção em tempo de execução)

    Particionamento

    Implantações Kubernetes usam particionamento de participantes para escalonamento horizontal:

    • Cada pod lida com participant_id % total_partitions == partition_id
    • Alocação de porta: base_port + (partition_id * 10000) + participant_index
    • Distribuição automática de carga entre 1-10 pods
    • Escala para mais de 1500 participantes (150 por pod)

    Executando o Sistema

    1. Desenvolvimento Local (Go Nativo)

    Melhor para: Desenvolvimento, depuração, testes de pequena escala (1-100 participantes)

    root@kitploit:~
    # Iniciar orchestrator
    go run cmd/main.go
    
    # Em outro terminal: Iniciar receptor UDP
    go run examples/go/udp_receiver.go 5002
    
    # Editar config/config.json para definir num_participants: 10
    # Executar teste de caos
    go run tools/chaos-test/main.go -config config/config.json
    

    O que acontece:

    • Processo orchestrator único em :8080
    • Participantes enviam UDP para 127.0.0.1:5002
    • Picos de caos injetados via API HTTP
    • Métricas em tempo real exibidas a cada 2s

    Configuração (config/config.json):

    root@kitploit:~
    {
      "base_url": "http://localhost:8080",
      "media_path": "public/rick-roll.mp4",
      "num_participants": 10,
      "duration_seconds": 300,
      "spikes": {
        "count": 20,
        "interval_seconds": 5,
        "types": { "rtp_packet_loss": {...}, "network_jitter": {...} }
      },
      "spike_distribution": {
        "strategy": "random",
        "min_spacing_seconds": 5,
        "jitter_percent": 15
      }
    }
    

    2. Docker Compose (Containerizado)

    Melhor para: Testes isolados, CI/CD, testes de médio porte (100-500 participantes)

    Pré-requisitos:

    • Docker Desktop com alocação de memória de 8-16GB
    • docker-compose instalado
    root@kitploit:~
    # Construir e iniciar container orchestrator
    ./scripts/start_everything.sh build
    
    # Em outro terminal: Iniciar receptor UDP
    go run examples/go/udp_receiver.go 5002
    
    # Editar config/config.json para definir num_participants: 100
    # Executar teste de caos (direcionado ao container)
    go run tools/chaos-test/main.go -config config/config.json
    

    Limites de Recursos (editar docker-compose.yaml):

    root@kitploit:~
    services:
      orchestrator:
        deploy:
          resources:
            limits:
              cpus: "14.0"
              memory: 6G  # Aumentar para mais participantes
    

    Guia de Dimensionamento:

    Memória DockerMáx. ParticipantesNúcleos CPU
    8 GB~1004
    16 GB~2508
    24 GB~40012
    32 GB~50014

    3. Kubernetes com Nix (Escala de Produção)

    Melhor para: Testes de grande escala (500-1500 participantes), escalonamento horizontal, validação de produção

    Pré-requisitos:

    • Nix com flakes habilitado
    • Docker Desktop ou cluster kind
    • kubectl configurado

    Passo 1: Entrar no Ambiente Nix

    root@kitploit:~
    # Nix fornece: Go, Docker, kubectl, kind, ffmpeg
    nix develop
    
    # Ou usar direnv para ativação automática
    echo "use flake" > .envrc
    direnv allow
    

    Passo 2: Implantar no Kubernetes

    root@kitploit:~
    # Implantação automática com configurações ideais (detecta recursos do sistema)
    ./scripts/start_everything.sh run -config config/config.json
    
    # Ou especificar arquivos de mídia personalizados
    ./scripts/start_everything.sh run --media=path/to/video.mp4 -config config/config.json
    

    O que acontece:

    1. Constrói imagem Docker com toolchain Go fornecido pelo Nix
    2. Cria/utiliza cluster kind
    3. Implanta StatefulSet com 10 pods do orchestrator
    4. Implanta pod de relé UDP
    5. Configura kubectl port-forward para o relé UDP
    6. Inicia relé local TCP→UDP
    7. Executa teste de caos em todos os pods

    Passo 3: Receber Stream UDP Agregado

    Opção A: Receptor UDP (Recomendado para Kubernetes)

    root@kitploit:~
    # Recebe stream agregado de todos os 1500 participantes
    go run ./examples/go/udp_receiver.go 5002
    

    Opção B: Receptor WebRTC (Vários Participantes)

    root@kitploit:~
    # Conecta-se a até 150 participantes via WebRTC
    go run ./examples/go/webrtc_receiver.go http://localhost:8080 <test_id> 150
    

    Fluxo da Arquitetura:

    root@kitploit:~
    1500 Participantes em 10 pods
      → Cada pod: 150 participantes
      → Partição por participant_id % 10
      → Todos enviam UDP para udp-relay:5000
      → Relé UDP agrega → TCP :5001
      → kubectl port-forward 15001:5001
      → Relé local converte TCP → UDP :5002
      → Seu receptor obtém todos os 1500 streams
    

    Nota: O script start_everything.sh configura automaticamente:

    • kubectl port-forward (udp-relay 15001:5001)
    • Relé local TCP→UDP (tools/udp-relay)
    • Você só precisa executar o receptor

    Configuração Manual do Kubernetes

    root@kitploit:~
    # Construir e carregar imagem
    docker build -t chaos-monkey-orchestrator:latest .
    kind load docker-image chaos-monkey-orchestrator:latest
    
    # Implantar
    kubectl apply -f k8s/orchestrator/orchestrator.yaml
    kubectl apply -f k8s/udp-relay/udp-relay.yaml
    
    # Aguardar pods
    kubectl wait --for=condition=ready pod -l app=orchestrator --timeout=300s
    
    # Port-forward do relé UDP
    kubectl port-forward udp-relay 15001:5001 &
    
    # Iniciar relé local TCP→UDP
    go run tools/udp-relay/main.go &
    
    # Em outro terminal: Iniciar receptor
    go run ./examples/go/udp_receiver.go 5002
    
    # Em outro terminal: Executar teste de caos
    go run tools/chaos-test/main.go -config config/config.json
    

    Limpeza

    root@kitploit:~
    # Excluir recursos Kubernetes
    ./scripts/cleanup.sh
    
    # Ou excluir todo o cluster
    kind delete cluster --name av-chaos-monkey
    

    Compilações Multiplataforma com Nix

    root@kitploit:~
    # Compilar para Linux x86_64 (mais comum)
    nix build .#packages.x86_64-linux.av-chaos-monkey
    
    # Compilar para ARM64 (Raspberry Pi, AWS Graviton)
    nix build .#packages.aarch64-linux.av-chaos-monkey
    
    # Compilar para macOS Intel
    nix build .#packages.x86_64-darwin.av-chaos-monkey
    
    # Compilar para macOS Apple Silicon
    nix build .#packages.aarch64-darwin.av-chaos-monkey
    
    # Localização do binário
    ./result/bin/main
    

    Referência da API

    Ciclo de Vida do Teste

    root@kitploit:~
    # Criar teste
    POST /api/v1/test/create
    {
      "test_id": "optional_id",
      "num_participants": 100,
      "video": {...},
      "audio": {...},
      "duration_seconds": 600,
      "spikes": [...],
      "spike_distribution": {
        "strategy": "even",
        "min_spacing_seconds": 5,
        "jitter_percent": 15
      }
    }
    
    # Iniciar teste
    POST /api/v1/test/{test_id}/start
    
    # Obter métricas
    GET /api/v1/test/{test_id}/metrics
    
    # Parar teste
    POST /api/v1/test/{test_id}/stop
    

    Sinalização WebRTC

    root@kitploit:~
    # Obter oferta SDP
    GET /api/v1/test/{test_id}/sdp/{participant_id}
    
    # Definir resposta SDP
    POST /api/v1/test/{test_id}/sdp/{participant_id}
    {"sdp_answer": "v=0..."}
    

    Injeção de Caos

    root@kitploit:~
    # Injetar pico
    POST /api/v1/test/{test_id}/spike
    {
      "spike_id": "unique_id",
      "type": "rtp_packet_loss",
      "duration_seconds": 30,
      "participant_ids": [1001, 1002],
      "params": {"loss_percentage": "15"}
    }
    

    Configuração

    Tipos de Pico

    TipoParâmetrosEfeito
    rtp_packet_lossloss_percentage (0-100)Descarta pacotes na camada RTP
    network_jitterbase_latency_ms, jitter_std_dev_msAdiciona variação de atraso
    bitrate_reducenew_bitrate_kbpsLimita a codificação de vídeo
    frame_dropdrop_percentage (0-100)Pula quadros de vídeo
    bandwidth_limitbandwidth_kbpsLimita a taxa total de transferência

    Configuração de Distribuição

    root@kitploit:~
    {
      "spike_distribution": {
        "strategy": "even",
        "min_spacing_seconds": 5,
        "jitter_percent": 15,
        "respect_min_offset": true
      }
    }
    

    Integração com Cliente

    Receptor UDP (Go)

    root@kitploit:~
    # Receptor fornecido com análise RTP
    go run examples/go/udp_receiver.go 5002
    

    Saída:

    root@kitploit:~
    Ouvindo pacotes RTP na porta UDP 0.0.0.0:5002
    Pacote #100 de 127.0.0.1:xxxxx:
      ID do Participante: 1001
      Tipo de Payload: 96 (vídeo H.264)
      Sequência: 1234
      Timestamp: 90000
      SSRC: 1001000
      Tamanho do Payload: 1200 bytes
    
    ═══════════════════════════════════════════════════════════
                        ESTATÍSTICAS DE PACOTES
    ═══════════════════════════════════════════════════════════
    Duração: 60s
    Total de Pacotes: 180000 (3000 pkt/s)
    Total de Bytes: 450 MB (60 Mbps)
    
    Detalhamento por Tipo de Mídia:
      Vídeo (H.264): 120000 pacotes (66.7%)
      Áudio (Opus):  60000 pacotes (33.3%)
    
    Streams Únicos (SSRCs): 1500
    Participantes Únicos: 1500
    

    Receptor WebRTC (Go)

    root@kitploit:~
    # Participante único
    go run ./examples/go/webrtc_receiver.go http://localhost:8080 <test_id>
    
    # Vários participantes (até 150)
    go run ./examples/go/webrtc_receiver.go http://localhost:8080 <test_id> 150
    
    # Exemplo com ID de teste real
    go run ./examples/go/webrtc_receiver.go http://localhost:8080 chaos_test_1770831684 150
    

    Nota: WebRTC requer conexões 1:1. Para Kubernetes, use o receptor UDP que agrega todos os participantes automaticamente.

    Integração Personalizada

    Formato do Pacote RTP:

    root@kitploit:~
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |V=2|P|X|  CC   |M|     PT      |       número de sequência     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           timestamp                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           identificador de sincronização (SSRC)              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  ID de Extensão=1 | Comprimento=4 |   ID do Participante (uint32) |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Payload H.264/Opus                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    

    Tipos de Payload:

    • 96: Vídeo H.264 (RFC 6184)
    • 111: Áudio Opus (RFC 7587)

    Extração do ID do Participante:

    root@kitploit:~
    // Bit de extensão definido?
    if (packet[0] & 0x10) != 0 {
        offset := 12 + int(packet[0]&0x0F)*4  // Pular CSRC
        extID := binary.BigEndian.Uint16(packet[offset:])
        if extID == 1 {
            participantID := binary.LittleEndian.Uint32(packet[offset+4:])
        }
    }
    

    Desempenho

    Requisitos de Recursos

    ParticipantesMemóriaCPULargura de Banda
    1002GB2 núcleos250 Mbps
    5006GB8 núcleos1.2 Gbps
    100012GB16 núcleos2.5 Gbps
    150018GB24 núcleos3.7 Gbps

    Escalonamento Kubernetes

    • Auto-escalonamento: Calcula número ideal de pods com base na contagem de participantes
    • Capacidade do pod: 150 participantes por pod (configurável)
    • Máx. pods: 10 (limite do StatefulSet)
    • Faixa de portas: 10.000 portas por partição

    Throughput

    Por participante (1280x720@30fps + Opus):

    • Vídeo: ~2.5 Mbps (H.264)
    • Áudio: ~128 Kbps (Opus)
    • Total: ~2.6 Mbps
    • Pacotes: ~90 vídeo + 50 áudio = 140 pkt/s

    Monitoramento

    Métricas Prometheus

    root@kitploit:~
    # Exposto no endpoint /metrics
    av_chaos_monkey_participants_total
    av_chaos_monkey_packets_sent_total
    av_chaos_monkey_bytes_sent_total
    av_chaos_monkey_spikes_active
    av_chaos_monkey_packet_loss_percent
    av_chaos_monkey_jitter_ms
    

    Painel Grafana

    root@kitploit:~
    # Modo Docker: Iniciar pilha de monitoramento
    docker-compose --profile monitoring up
    
    # Modo Kubernetes: Implantar monitoramento
    kubectl apply -f k8s/monitoring/prometheus-rbac.yaml
    kubectl apply -f k8s/monitoring/prometheus.yaml
    kubectl apply -f k8s/monitoring/grafana.yaml
    
    # Acessar Grafana
    # Docker: http://localhost:3000
    # Kubernetes: http://localhost:30030 (NodePort)
    # Credenciais padrão: admin/admin
    
    # Acessar Prometheus
    # Docker: http://localhost:9091
    # Kubernetes: http://localhost:30090 (NodePort)
    

    Descoberta Automática Kubernetes:

    • Pods do orchestrator anotados com prometheus.io/scrape: "true"
    • Prometheus coleta /metrics de todos os pods a cada 5s
    • Grafana pré-configurado com fonte de dados Prometheus
    • Painel provisionado automaticamente na inicialização

    Estatísticas em Tempo Real

    root@kitploit:~
    # Obter métricas do teste
    curl http://localhost:8080/api/v1/test/{test_id}/metrics | jq
    
    # Saída
    {
      "aggregate": {
        "total_frames_sent": 45000,
        "total_packets_sent": 180000,
        "total_bitrate_kbps": 250000,
        "avg_jitter_ms": 12.5,
        "avg_packet_loss": 2.3,
        "avg_mos_score": 4.1
      }
    }
    

    Solução de Problemas

    Nenhum Pacote UDP Recebido

    root@kitploit:~
    # Verificar configuração do destino UDP
    kubectl logs orchestrator-0 | grep "UDP transmission enabled"
    
    # Verificar se o relé UDP está em execução
    kubectl get pod udp-relay
    
    # Verificar port-forward
    ps aux | grep "kubectl port-forward"
    
    # Testar conectividade UDP
    nc -u -z localhost 5002
    

    Falha na Conexão WebRTC

    root@kitploit:~
    # Verificar servidor TURN
    kubectl get svc coturn-lb
    
    # Verificar candidatos ICE
    kubectl logs orchestrator-0 | grep "ICE"
    
    # Testar conectividade TURN
    turnutils_uclient -v -u webrtc -w webrtc123 <turn-server>:3478
    

    Alto Uso de Memória

    root@kitploit:~
    # Verificar contagem de participantes por pod
    kubectl exec orchestrator-0 -- curl -s http://localhost:8080/api/v1/test/{test_id}/metrics | jq '.participants | length'
    
    # Reduzir participantes ou aumentar número de pods
    go run tools/k8s-start/main.go -replicas 10 -participants 1000
    
    # Aumentar memória Docker (Docker Desktop)
    # Configurações → Recursos → Memória → 16GB
    

    Perda de Pacotes no Receptor UDP

    Um único socket UDP não consegue lidar com mais de 3000 streams concorrentes sem estouro do buffer do kernel. Soluções:

    • Usar relé UDP (agrega antes de encaminhar)
    • Aumentar o buffer do socket: setsockopt(SO_RCVBUF, 8MB)
    • Aceitar a perda de linha de base como artefato de medição

    Licença

    Licença BSD 3-Clause

    Contribuição

    Contribuições são bem-vindas! Áreas principais:

    • Tipos de pico adicionais (limitação de CPU, pressão de memória)
    • Mais estratégias de distribuição (onda, rajada)
    • Métricas aprimoradas (cálculo MOS, feedback RTCP)
    • Bibliotecas cliente (Python, Rust, TypeScript)

    Referências

    • RFC 3550 - RTP: Um Protocolo de Transporte para Aplicações em Tempo Real
    • RFC 6184 - Formato de Payload RTP para Vídeo H.264
    • RFC 7587 - Formato de Payload RTP para Opus
    • Especificação WebRTC
    Baixar ferramenta