Como o Moatgator funciona

O Moatgator é um RASP móvel (autoproteção do app em tempo de execução) feito para apps que movimentam dinheiro. Ele observa o aparelho de dentro do seu app, reporta o que vê a um backend que é seu, e deixa você decidir — por detecção — se apenas observa, avisa o usuário, bloqueia a ação sensível ou encerra a sessão.

O que roda no aparelho

O SDK de runtime (Kotlin + C/JNI no Android, Swift + C no iOS) adiciona várias camadas independentes. Nenhuma delas muda o comportamento do app sozinha — a detecção é separada da resposta que você escolhe.

• Detecções de runtime. Dezenas de sinais agrupados em detecções, cada uma com uma nota de confiança. Sinais fracos sozinhos ficam suspeitos; um forte, ou vários fracos juntos, viram comprometido.
• Checagens nativas. As checagens de maior valor (root, montagens de root escondido, threads do Frida) rodam em C por syscalls diretas, então trocar uma função Java ou da libc em runtime não esconde o resultado.
• Anti-análise / ofuscação. Um plugin Gradle (com.moatgator.protect) endurece a build de release para que strings, grep e decompiladores não entreguem a lógica de detecção (veja abaixo).
• Anti-dump / anti-debug. prctl(PR_SET_DUMPABLE, 0) e o Yama impedem outro processo de ler a memória do app ou anexar um depurador — a mesma proteção que apps bancários usam para blindar chaves e tokens na heap.
• Certificate pinning (SPKI SHA-256) no canal de telemetria, Attest (Play Integrity + App Attest reunidos num veredito único assinado) e Pix Shield para telas de pagamento.

O que o Moatgator detecta

Uma detecção é um sinal para o qual você escolhe uma resposta. As cinco detecções básicas estão em todos os planos; as de tela de pagamento, antifraude e instrumentação começam no plano Scale.

Categoria	Detecções	O que pega
Integridade do aparelho	root / jailbreak, emulator, tamper	Aparelhos com root/jailbreak (inclui Magisk + montagens de root escondido pela camada nativa), emuladores e fazendas de fraude, apps reempacotados ou reassinados.
Análise dinâmica	debugger, hooking, instrumentation	Depuradores anexados, frameworks de hooking (Xposed/LSPosed/Substrate) e instrumentação dinâmica (Frida) — detectada por maps, portas abertas e nomes de thread, então uma .so escondida ainda aparece.
Tela de pagamento (Pix Shield)	overlay, accessibility_abuse, screen_capture, remote_access	O roteiro do trojan bancário brasileiro: sobreposição roubando toques, serviço de acessibilidade abusado, gravação/espelhamento de tela e ferramentas de controle remoto durante um pagamento.
Antifraude	mock_location, memory_editor, app_clone, camera_injection, vpn_proxy	GPS falso, editores de memória (GameGuardian), apps clonados/dual-space, câmeras virtuais/injetadas que burlam liveness e KYC, e VPN/proxy mascarando a origem da conexão.

São 15 detecções hoje, cada uma documentada com seus falsos positivos típicos e como liberá-la aos poucos na referência de detecções. Uma detecção é um sinal, não prova de fraude — use-a junto com o seu motor antifraude, nunca no lugar dele.

Como o app é endurecido contra engenharia reversa

O plugin Gradle com.moatgator.protect roda depois do javac/kotlinc e antes do R8, e encadeia várias transformações para que um atacante não leia a lógica de detecção direto do .dex ou da .so:

• Cifra de strings — URLs, flags e palavras-chave de detecção são decifradas em runtime, não viajam em claro.
• Ofuscação de constantes numéricas — magic numbers viram chamadas de runtime que sobrevivem ao constant-folding do R8.
• Ofuscação de fluxo de controle — predicados opacos que o otimizador não consegue dobrar.
• API hiding — chamadas a APIs delatoras do framework (PackageManager, Debug, AppOps) passam por wrappers de reflexão, e os próprios nomes dos métodos são cifrados.
• Renomeação agressiva — dicionário confuso do R8 mais achatamento de pacotes.
• Ofuscação de strings nativas — os caminhos /proc, paths de su e nomes de sinal da camada C são XOR-ofuscados, então strings libmoatgator.so não revela nada.
• Cofre de segredos criptografado — valores de moatgator-secrets.properties são cifrados num asset e lidos em runtime com Moatgator.secret(), fora do texto puro do APK.

Nada disso é segredo criptográfico — as chaves viajam no binário, como em toda ofuscação. O objetivo é elevar o custo para o atacante, não prometer proteção perfeita.

O que sai do aparelho

Quando uma detecção dispara, o SDK envia uma mensagem compacta event.v1 — o tipo da detecção, uma nota de confiança, nomes curtos de sinal (sem dado pessoal), a versão do app e um hash de aparelho anônimo e rotativo — por TLS com pinning. Com o Attest ligado, os sinais são reunidos num único veredito assinado que o seu backend verifica offline.

A política vai no sentido contrário: você a edita no console ou como arquivo moatgator.yml, ela é assinada, e o SDK pega as novas respostas na próxima sincronização — sem precisar de um novo release. Um kill switch desliga na hora uma política problemática.

Você decide a resposta

Toda detecção mapeia para uma resposta: monitor (só registra), warn (avisa o usuário), block (barra a ação sensível) ou terminate (encerra a sessão). Tudo o que você não listar fica em monitor, então adotar uma versão mais nova do Moatgator nunca começa a bloquear usuários por conta própria. A liberação recomendada é monitor → warn → block, uma detecção por vez.

A partir da sua CI

A CLI, a GitHub Action e o GitHub App registram e escaneiam estaticamente cada build de release — no GitHub Actions por OIDC, então não há chave de longa duração nos seus secrets. O Scan estático dá uma nota ao pacote (manifesto, permissões, config de rede, segredos, proteções) de forma independente do SDK de runtime.

Limites honestos

O motor de proteção está em prévia e algumas peças ainda não estão publicadas. Antes de planejar em cima do Moatgator, leia limites e garantias.