Documento técnico — amostra maliciosa. Este relatório descreve um kit de relay NFC/EMV com captura de PIN. Não execute o APK, não distribua os binários e não reutilize os domínios citados. SHA-256 da amostra: 21ccef318fed2f2013fda52603a0d3473aba1b75b8dcf0ce46f98460de98d205

limitacoes.md — lacunas, o que não pôde ser analisado e pendências

1. Escopo não executado (por decisão explícita)

Item	Situação	Motivo
Execução do APK	não executado	a autorização do pedido é condicional ("somente se houver ambiente isolado e autorização específica"). Esta máquina tem dois AVDs configurados para outro projeto, mas não há ambiente isolado dedicado provisionado para esta amostra, e a amostra é de fraude de cartão — executá-la exigiria snapshot descartável + rede isolada + autorização explícita
Chamadas aos endpoints (`dashboard.gripe`, `cupworldcup.site`)	não realizadas	proibido pelo pedido e desnecessário para o contrato observado
Uso de qualquer credencial do APK	não aplicável	nenhuma credencial existe no APK
Análise dinâmica (Frida, logcat, tráfego)	não realizada	depende de execução
Análise do painel/backend	não realizada	fora do escopo; o backend não foi recuperado

Consequência: tudo que depende de comportamento em tempo real (por exemplo, se o servidor realmente envia GENERATE AC, se o PIN é aceito, se o cartão autoriza) permanece não verificado. O contrato descrito é o que o cliente implementa.

2. Lacunas técnicas na análise estática

Lacuna	Impacto	Evidência do bloqueio
7 classes não decompiladas pelo JADX	trechos de código de biblioteca ficam só em smali	`evidencias/jadx-decompile.log` → `ERROR - finished with errors, count: 7`; o processo `JadxCLI` terminou com exit code 3 (o log não nomeia as classes; não foi possível extrair a lista)
Divergência de contagem de classes: DEX `class_defs_size = 3287` × JADX `3028 .java` × REA `class_count 3036`	não se sabe exatamente quais classes o JADX descartou (provável: entradas duplicadas/ inválidas ou sintéticas)	cabeçalho DEX × `rea-inspect-android-package.json` × `find -name '*.java' \| wc -l`
2.608 classes em pacote default ofuscadas	não é possível atribuir com segurança qual classe pertence ao app × a qual biblioteca, exceto pelos pontos de contato do framework	`estrutura.md` §2, `dependencias.md` §4
`assets/nfc_config.dat` (25.422 B) e `card_resources.bin` (15.064 B) não decifrados	conteúdo desconhecido	entropia 7,99 bit/byte; nenhuma chave/rotina de decifra no APK
Versões exatas de AndroidX/Material desconhecidas	impede reprodução fiel de dependências	R8 removeu metadados; sem `pom.properties` no APK
Plano de controle de fluxo/strings de `MainActivity`	é código morto; analisado, mas sem confirmação de que já foi ativo	nenhum `startActivity` para `MainActivity`

3. Ferramentas — o que existia e o que faltava

Presentes no host

Ferramenta	Versão/local
Java (JDK)	Microsoft JDK 25.0.5.21 (`C:\Program Files\Microsoft\jdk-25.0.5.21-hotspot`)
Python	3.14.7 (Hermes)
Android SDK build-tools	34.0.0, 35.0.0, 36.0.0, 36.1.0 (aapt, aapt2, apksigner, zipalign, d8, dexdump)
Ghidra	12.1.4 (`C:\tools\ghidra_12.1.4_PUBLIC`)
unzip, curl, openssl, keytool	presentes
REA	`rea-agents@6.8.0` + `jadx-headless-mcp 0.7.1`

Ausentes no PATH (limitação registrada; contornada)

Ferramenta	Situação	Contorno
`jadx` / `jadx-gui`	ausente	instalado 1.5.6 durante a análise
`apktool`	ausente	instalado 3.0.3 durante a análise
`aapt` / `aapt2` / `apkanalyzer` / `dexdump`	fora do PATH (`apkanalyzer` não existe: `cmdline-tools` não instalado)	usados por caminho absoluto em `…\Sdk\build-tools\36.1.0\`; `apkanalyzer` não disponível
`rz-bin` / `rabin2` / `rizin`	ausentes	sem uso (não há código nativo)
`strings` / `readelf` / `nm` / `objdump`	ausentes	substituídos por extração de strings em Python
`jq`	ausente	parsing de JSON em Python

Limitações de suporte a proxy

Nenhuma ferramenta que precisou de rede deixou de suportá-lo: curl (downloads) e npx (REA) funcionaram via proxy. npx/npm foi configurado por variáveis de ambiente temporárias. Nenhuma ferramenta fez conexão direta.

Ferramentas do REA — situação real (importante)

As ferramentas MCP do REA disponíveis nesta sessão (inspect_android_package, inspect_apk_signature, decode_android_resources, search_android_classes, inspect_android_class) falharam inicialmente com capability_unavailable, porque o servidor MCP em execução não tinha REA_JADX_MCP_JAR no ambiente de spawn ({"diagnostics":{"jar_configured":false,"failure_kind":"jar"}}).
Contorno adotado: execução do CLI oficial do REA (npx -y rea-agents@6.8.0 <comando> --json) com as variáveis REA_JADX_MCP_JAR e REA_APKTOOL_COMMAND definidas — obtendo as mesmas análises do REA, registradas em evidencias/rea-*.json.
O JAR do motor foi baixado e verificado por SHA-256 (6e5eacf5…ff75, conforme o guia oficial) para C:\Users\ADM\.local\share\rea\android\jadx-headless-mcp-0.7.1-all.jar.
Para sessões futuras, mcp_servers.rea.env.REA_JADX_MCP_JAR foi apontado no config.yaml do Hermes; o servidor MCP já iniciado nesta sessão continua sem a variável (seria necessário reiniciar o gateway/sessão).

4. Projeto compilável — avaliação e bloqueios

Conclusão: um projeto Android/Gradle fiel e compilável NÃO é recuperável a partir deste APK. Motivos concretos:

Não existe código-fonte: só há DEX. O JADX reconstruiu 3.028 arquivos .java, mas saída de decompilador não é código-fonte original — contém /* JADX INFO: loaded from: classes.dex */, campos sintéticos, lambda$…$N reconstruídos, e referências a classes em pacote default que não compilam sem renomeação prévia.
Não há metadados de build: build.gradle, settings.gradle, versões de AGP, dependencies {}, flavors, proguard-rules.pro — nada disso é empacotado em um APK. As versões de AndroidX/Material são desconhecidas.
Bibliotecas estão como bytecode ofuscado, não como dependências: OkHttp, Okio, Guava, Kotlin stdlib e Material estão no DEX, com metade renomeada para o pacote default e sem kotlin.Metadata. Reintegrá-las como dependências exigiria descobrir as versões e desfazer a renomeação (2.608 classes) — trabalho de engenharia reversa, não de reconstrução automática.
R.java e recursos: os recursos são recuperáveis (é o que foi feito), mas o R gerado pelo apktool difere do R do build original (nomes preservados via public.xml, ids podem variar).

O que foi produzido (verificado, não prometido)

projeto-reconstruido/ contém a recompilação do material recuperado (smali + recursos), não um projeto Gradle:

Arquivo	Origem	Verificação
`NFCLocator-rebuilt-unsigned.apk` (3.668.797 B)	`apktool b decompilado/apktool`	build sem erro (Apktool 3.0.3, aapt2)
`NFCLocator-rebuilt-signed.apk`	assinado com chave gerada localmente (`analysis.keystore`, PKCS12, RSA-2048)	`apksigner verify` → OK (`CN=Analysis Only`)
`analysis.keystore`	gerado nesta análise	não é chave do autor; serve só para instalar/testar

Fidelidade medida (ver README.md §5): resources.arsc byte-idêntico; DEX com mesmo número de classes (3.287), métodos (27.619), strings (21.858) e tipos (4.229), mas bytes diferentes (SHA-256 diverge — re-encodamento smali→dex); manifest binário com mesmo tamanho e conteúdo não byte-idêntico.

O que faltaria para um projeto Gradle compilável: - (a) versões de AndroidX/Material/OkHttp/Guava — reconstruir por tentativa e erro; - (b) renomear 2.608 classes + membros de volta a namespaces plausíveis (ou aceitar tudo em defpackage); - (c) reescrever os pontos onde o R8 gerou synthetic accessors e lambda bridges; - (d) AndroidManifest.xml + build.gradle escritos à mão a partir do manifest decodificado; - (e) validação funcional — impossível sem executar, e executar é justamente o que este relatório não faz.

5. Ameaças à validade

Falsos positivos de atribuição: qualquer conclusão "esta classe é do app" baseada só em nome de pacote é segura; baseada em grafo de referências, não (ver estrutura.md §5).
Ofuscação: se parte da lógica de decisão estiver no servidor (é o que parece), o que o APK faz localmente é só transporte — o impacto real depende do backend, que não foi analisado.
Versão: todas as conclusões valem para SHA-256 21ccef31…d205. O kit tem indícios de versionamento (# build 2363b211bfb1 em aids.txt, cupworldcup.site legado), logo outras amostras podem diferir.
Sem execução: nenhuma afirmação de comportamento em runtime é feita sem a marcação [inferido].

6. Pendências sugeridas (se houver autorização)

Provisionar AVD descartável + rede isolada e executar a amostra capturando logcat/Frida para confirmar os APDUs enviados pelo servidor (passaria de inferido a comprovado).
Correlacionar dashboard.gripe / cupworldcup.site com outras amostras do mesmo kit (CN=Android, O=Local e o esquema base64+XOR {42,31,55,13} são assinaturas reutilizáveis para hunting).
Tentar decifrar nfc_config.dat / card_resources.bin com chaves derivadas de # config e69ea27c e # build 2363b211bfb1 (hipótese: identificadores de versão, não chaves).
Reportar a infraestrutura (domínios, certificado) ao CERT.br / provedores, se o contexto for de incidente real.

Análise estática · amostra não executada · gerado a partir de analise-apk/