Caso de uso

Inspecione o tráfego. Saiba o que você não consegue ver.

Limite a descriptografia exatamente aos hosts que você está testando, rode regras de bloquear/simular/descartar na rede, e obtenha uma resposta honesta sobre o que o certificate pinning ainda esconde de você.

A vertical trust stack threaded by one line: a write-only vault door with an inbound arrow and a blocked outbound arrow, an append-only audit ledger of timestamped rows, a least-privilege role matrix, and at the base a database wrapped in a row-level-security shield. write-only audit_log 12:04:31 12:04:32 12:04:40 least privilege rls

O problema

A maioria das ferramentas MITM exagera o que conseguem ver

Uma ferramenta que silenciosamente não menciona o certificate pinning desperdiça uma sessão de pesquisa em um alvo que nunca conseguiria descriptografar.

Para pesquisadores de segurança e testadores de apps auditando o que um app ou dispositivo realmente envia — SDKs de terceiros, endpoints não documentados, se um app degrada com segurança quando uma requisição é bloqueada ou corrompida.

A Busymate limita a descriptografia a uma lista SSL por dispositivo que você controla, roda o mesmo motor de regras de bloquear/simular/descartar na rede em iOS, Android e no proxy, e registra cada ação — incluindo acesso direto ao banco de dados — em uma trilha de auditoria somente de acréscimo. E é honesta sobre a única coisa que não consegue fazer: um app com certificate pinning próprio não descriptografará pela lista SSL, em nenhuma plataforma.

Como resolve isso

Descriptografia limitada, regras em nível de rede, um log de auditoria real

Cada afirmação abaixo é verificável — nada aqui é uma caixa-preta.

Bloqueie, simule e descarte na rede

O mesmo motor de regras em sandbox roda inline em iOS, Android e no proxy — um único conjunto de regras, aplicado de forma idêntica em todo lugar por onde o tráfego do alvo passa.

Cada ação, auditada

Uma trilha de auditoria somente de acréscimo registra cada ação em cada superfície, incluindo acesso direto ao banco de dados. Acompanhe ao vivo, filtre, ou compartilhe um link permanente para o evento exato.

Honestos sobre certificate pinning

Um app que fixa seu próprio certificado não será descriptografado pela lista SSL em iOS, Android ou no proxy — isso é uma limitação real, não um bug. Para tráfego já dentro de um navegador Chromium, a captura baseada em CDP (bmc) lê pós-descriptografia e não é afetada pelo pinning, porque nunca toca a conexão TLS.

Superfícies envolvidas
  • Proxy
  • iOS
  • Android
  • CLI
  • Security & audit

Passo a passo

De um host alvo a um achado documentado

Com um registro real no final.

  1. 01

    Delimite a lista SSL

    Adicione apenas os hosts que você está testando à lista SSL do dispositivo ou proxy, e confie na CA gerada naquele dispositivo. Todo o resto passa intocado.

  2. 02

    Sonde com regras

    Escreva uma regra de bloquear, simular ou descartar — ou um script JS em sandbox — para ver como o alvo se comporta sob uma resposta corrompida, atrasada ou ausente.

  3. 03

    Acompanhe a trilha de auditoria

    Revise exatamente o que mudou e quando — cada regra que você disparou, cada host descriptografado — como um registro com link permanente e somente de acréscimo que você pode anexar a um relatório.

No alvo

Como funciona contra um app real

Três passos, e um registro de cada um.

  1. 01

    Restrinja a descriptografia aos hosts que você está testando

    No dispositivo ou no proxy, adicione só os hosts do alvo à lista SSL e confie ali na autoridade certificadora gerada. Tudo fora dessa lista permanece criptografado de ponta a ponta, então uma sessão contra um app nunca abre o resto do tráfego do celular.

  2. 02

    Sonde com regras e scripts

    Escreva uma regra de bloqueio, simulação ou descarte para um endpoint do alvo, ou uma regra JavaScript em sandbox que reescreva uma requisição ou resposta no caminho. Veja como o app se comporta quando o backend responde devagar, errado ou nunca — o motor de regras roda igual no iOS, no Android e no proxy.

  3. 03

    Leve o registro com você

    Cada regra que você disparou, cada host que descriptografou e cada entrada que inspecionou vai para a trilha de auditoria somente de acréscimo. Filtre pela sessão, abra o permalink do evento exato e anexe ao relatório junto com a exportação HAR do próprio tráfego.

FAQ

Antes de iniciar uma sessão, as perguntas de sempre

Ele vai descriptografar um app que fixa o certificado?

Não. O pinning vence a lista SSL no iOS, no Android e no proxy — você vê que a conexão aconteceu, não o que havia nela. O tráfego que já está dentro de um navegador Chromium é diferente: a captura do navegador o lê depois que o Chrome descriptografou, então o pinning não se aplica ali.

A captura é limitada a apps meus?

As ferramentas funcionam com qualquer tráfego que chegue ao dispositivo ou ao proxy, e os termos exigem que o app seja seu ou que você esteja autorizado a testá-lo. A captura é opcional em todas as plataformas e pode ser parada e removida a qualquer momento.

Para onde vão os dados capturados?

A descriptografia acontece no dispositivo ou no seu proxy. As entradas que você escolhe sincronizar ficam na sua própria conta pela janela de retenção de toda a plataforma e podem ser apagadas quando quiser; tokens e credenciais podem aparecer nos corpos, então restrinja bem a lista SSL.

Posso provar o que fiz durante uma sessão?

Sim. A trilha de auditoria é somente de acréscimo e registra cada ação em cada superfície — dashboard, API e agentes de IA igualmente. Cada evento tem um permalink, então um achado pode citar o momento exato em que uma regra foi aplicada.

Verifique você mesmo — não confie apenas na nossa palavra

O modelo de segurança é uma página, não uma alegação — leia exatamente o que é aplicado e onde.

Ask your mate