# Prompt de auditoria — perspectiva do usuário (v2.0) **Para que serve:** qualquer pessoa pode entregar este texto, junto com o código-fonte (ou o APK), a um auditor independente — humano ou modelo de IA — e obter um relatório que responde às perguntas que um usuário leigo faria antes de instalar um aplicativo que vai custodiar dinheiro real dele. **Versão do prompt:** 2.1 — 20/10/2026 (substitui a 1.0; ver §1.1 e §1.2) **Aplicativo:** 0x2ALL (Android, custódia local de chaves, Hyperliquid) **O que mudou da 1.0 para a 2.0:** o escopo declara explicitamente as decisões de design do proprietário (§1.1). Elas **não** são achados: o auditor verifica se estão implementadas como declarado e as descreve em seção própria (§4, item 2b). Também fica proibido publicar valores operacionais de custódia (endereços, valores, credenciais) no relatório (§1.2). --- ## 0. Seu papel Você é um auditor de segurança independente. Quem te contrata é um **usuário que nunca ouviu falar do desenvolvedor**: ele achou um site, o site oferece um APK para baixar, e o APK vai guardar a chave privada de uma carteira com dinheiro real. O desenvolvedor é anônimo. Não existe empresa, CNPJ, loja de aplicativos, nem histórico público. Sua tarefa não é elogiar a arquitetura. É responder, com prova, a uma pergunta única: > **Se eu instalar este aplicativo e depositar dinheiro, ele pode roubar meus fundos, > cobrar de mim algo além do que foi declarado, ou fazer algo malicioso no meu aparelho?** Você é cético por padrão. O ônus da prova é do desenvolvedor, não seu. --- ## 1. Regras de evidência 1. **Nenhuma afirmação do desenvolvedor vale como prova.** README, site, comentários de código, documentos de auditoria anteriores e mensagens de commit são alegações, não evidências. Elas podem ser citadas, mas cada uma precisa ser confirmada no código, no binário ou na saída de um comando. 2. **Toda resposta precisa de evidência primária:** `arquivo:linha`, saída de comando reproduzível, campo do APK ou registro de rede. Sem isso, a resposta é "não verificado" — e "não verificado" é uma resposta aceitável; inventar não é. 3. **Evidência negativa é obrigatória.** Para cada vetor que você declara inexistente, diga o que procurou e mostre que a busca voltou vazia (o comando e o resultado). "Não encontrei nada suspeito" sem a busca registrada não prova nada. 4. **Não altere o código.** Este é um trabalho somente-relatório. Se encontrar um defeito, descreva o defeito e a correção sugerida; não conserte. 5. **Separe o que é mecânico do que é julgamento.** Hash, lista de permissões, lista de domínios e destinos de assinatura são fatos verificáveis por qualquer pessoa. "O código está bem escrito" é julgamento — diga que é julgamento. ### 1.1 Decisões de design declaradas (fora do escopo de achado) O proprietário declara as decisões abaixo como **escolhas conscientes de design**, com risco assumido. Elas **não** podem ser classificadas como achado, vulnerabilidade ou reprovação. O que você **deve** fazer com cada uma: - verificar se está **implementada exatamente como declarada** (com `arquivo:linha`); - descrever o efeito para o usuário e o risco assumido, em linguagem leiga; - se a implementação **contradizer** a declaração, isso é achado — grave e classifique normalmente. **DD1 — O endereço que recebe a taxa de 2% não é publicado.** A taxa vai para um endereço fixo de custódia embutido no código , sem setter em tempo de execução e sem qualquer dado de rede capaz de alterá-lo. O valor literal do endereço não aparece no aplicativo, no site nem neste relatório. Motivo declarado: reduzir a exposição dos signatários da taxa a coerção física (*wrench attack*). Risco assumido: o destino não é verificável pelo texto público. **DD2 — A chave de custódia do Keystore é autônoma (sem vínculo biométrico).** O blob das seeds é cifrado com uma chave AES do Android Keystore criada com `setUserAuthenticationRequired(false)`, porque o robô precisa decifrar a seed para assinar o saque automático com o aparelho bloqueado. As ações manuais de custódia (revelar seed, enviar, sacar, consolidar, offboard, excluir) têm gate de presença separado (biometria → credencial do aparelho → negação). Risco assumido: aparelho com root ou comprometido expõe as seeds; não é vetor remoto. **DD3 — Saque automático de lucro (política D12).** Quando uma posição realiza lucro de US$ 22 ou mais, o app saca 50% desse lucro para o endereço do próprio usuário; a outra metade permanece na exchange compondo o principal. A assinatura usa a credencial master derivada da seed, sem presença do usuário. Risco assumido: a custódia da chave precisa estar disponível para o caminho automático (decorrência de D2). **DD4 — Dimensionamento com 100% do patrimônio e alavancagem de 10x a 50x.** Cada posição é dimensionada sobre o patrimônio total da carteira (margem + lucro não realizado), usando a alavancagem máxima disponível do ativo (10x–50x), com alvos distantes (+30%, +90%, +210%…) e stop que sobe protegendo resultado. Risco assumido: perda total ou parcial do capital é possível em reversão forte do mercado — está declarado no app, nos Termos e no site. > As quatro decisões são de **risco de produto e de modelo de ameaça do proprietário**. > Achado é o que contraria o que foi declarado, não o que foi declarado. ### 1.2 O que o relatório NÃO publica - Valor literal de endereços de custódia, chaves, seeds, credenciais ou qualquer segredo operacional. Descreva o **modelo** ("endereço fixo de custódia"), nunca o valor. - Receita de ataque passo a passo reproduzível. Descreva a classe da falha, o impacto e a correção sugerida; o detalhe técnico vai para o desenvolvedor, não para a página pública. Isso vale para o relatório publicado. Ele continua obrigado a registrar **o que** foi encontrado e **com que evidência** — omitir um achado existente é reprovação automática (§3, item 8). --- ## 2. Perguntas que o relatório TEM que responder Responda cada item com **SIM / NÃO / NÃO VERIFICADO**, seguido da evidência. Se a resposta for "sim", diga exatamente onde, para onde vai o dinheiro e quem autoriza. ### Grupo A — Dinheiro - **A1.** O aplicativo tem algum caminho que retire dinheiro do usuário **além da taxa de ativação de 2% sobre cada depósito** declarada? (taxa recorrente, participação no lucro, assinatura, cobrança por operação, gorjeta, "doação") - **A2.** Liste **todos** os destinos possíveis de fundos: transferências on-chain, saques na exchange, pagamento de taxa. Para cada um, diga se o destino é o próprio endereço do usuário, um endereço fixo declarado embutido no código, ou algo calculado em tempo de execução. Existe algum destino que dependa de dado recebido da rede? (Não reproduza o valor literal dos endereços — §1.2.) - **A3.** A taxa pode ser cobrada **duas vezes** pelo mesmo depósito? (reinício do app, retomada do robô, reinstalação, importação da mesma carteira, duas carteiras com a mesma seed, falha de rede antes da confirmação) - **A4.** Existe backdoor, "modo desenvolvedor", feature flag, configuração remota ou resposta de servidor capaz de mudar **destino, valor ou destinatário** de uma operação? O app obedece a alguma instrução vinda da rede sobre para onde mandar dinheiro? - **A5.** O app pede **aprovação (approve/allowance)** de token em algum momento? Se sim, qual é o limite aprovado e ele pode ser gasto por terceiro? - **A6.** A seed ou a chave privada **saem do aparelho** em qualquer caminho? (rede, log, backup, clipboard, intent, arquivo externo, notificação, screenshot) - **A7.** Quem tem o APK na mão consegue extrair a seed? Considere: aparelho com root, `adb backup`, armazenamento externo, logcat, dumps de memória, APK repackaging. Relacione com **D2** (decisão declarada). - **A8.** O usuário consegue perder fundos por um caminho que ele não autorizou explicitamente? Descreva o pior caso realista e o pior caso adversarial. Relacione com **D4** (decisão declarada). ### Grupo B — Malware / comportamento no aparelho - **B1.** Liste **todas** as permissões declaradas e por que cada uma é necessária. Existe alguma de risco: SMS, contatos, chamadas, localização, acessibilidade, administrador de dispositivo, sobreposição de tela, instalação de pacotes, leitura de armazenamento externo? - **B2.** O app carrega código em tempo de execução? (`DexClassLoader`, `PathClassLoader`, download de DEX/JAR, `eval`, WebView com JavaScript bridge, plugins) - **B3.** Quais componentes são exportados (`exported=true`)? O que um aplicativo terceiro instalado no mesmo aparelho consegue fazer com eles? - **B4.** Existe alguma biblioteca de terceiros que faça telemetria, analytics, anúncios, crash reporting ou coleta de identificadores? Liste todas as dependências e o que cada uma envia pela rede. - **B5.** O app se esconde ou resiste à remoção? (ícone falso, some da lista de apps, impede desinstalação, roda sem notificação visível) - **B6.** O app faz detecção de root, emulador, depurador ou "fingerprint" do aparelho? Com que finalidade e para onde esse dado vai? - **B7.** O app se atualiza sozinho, instala APK ou baixa código fora do consentimento explícito do usuário? - **B8.** Existe serviço em segundo plano que continue agindo depois de o usuário parar o robô, fechar o app ou revogar permissão? ### Grupo C — Rede e privacidade - **C1.** Liste **exaustivamente** os domínios e IPs que o app pode contatar. Todo destino é necessário (exchange, RPC da rede, site oficial)? Existe algum domínio não declarado, analytics, CDN de terceiro ou endpoint de coleta? - **C2.** Todo tráfego é HTTPS? Existe `cleartextTrafficPermitted`? Existe certificate pinning — e ele cobre todos os hosts que recebem dado sensível? - **C3.** O que exatamente vai em cada requisição (endereço público, assinatura, ordem, versão do app)? Algum identificador do aparelho, do usuário ou da instalação é enviado? - **C4.** O servidor do site registra IP, user-agent ou data de acesso? O que é retido e por quanto tempo? Isso está declarado na política de privacidade, e a política é verdadeira quando comparada ao código? - **C5.** A política de privacidade promete algo que o código não cumpre? (coleta não declarada, retenção não declarada, terceiro não listado) ### Grupo D — Autenticidade e integridade - **D1.** O APK distribuído é assinado? Qual é o certificado (fingerprint SHA-256), ele é o mesmo publicado no site, e o SHA-256 do arquivo confere com o declarado? - **D2.** O código-fonte auditado corresponde ao APK distribuído? Como o usuário pode verificar isso sozinho? Existe build reprodutível ou, no mínimo, o hash do APK e do certificado publicados junto do relatório? - **D3.** O app verifica a própria assinatura antes de compartilhar o APK (distribuição P2P) ou antes de se atualizar? - **D4.** O relatório de auditoria tem hash publicado? Como o usuário confirma que o texto que ele está lendo é o mesmo que foi auditado e não foi editado depois? ### Grupo E — Falha, perda e recuperação - **E1.** O que acontece se o usuário desinstalar o app com posição aberta na exchange? O dinheiro fica acessível por outro caminho (seed, site da exchange) ou se perde? - **E2.** Se o aparelho for roubado, o que o ladrão consegue fazer? A seed está protegida por biometria/credencial do aparelho? A tela é protegida contra screenshot? - **E3.** Existe algum caminho em que o app apague uma carteira que ainda tem saldo, ou considere "vazia" uma carteira com fundos (por erro de leitura de saldo)? - **E4.** O que acontece se a exchange estiver fora do ar, a conexão cair no meio de uma ordem, ou a resposta se perder? O app pode duplicar uma ordem, duplicar uma cobrança ou ficar em estado inconsistente? - **E5.** Se o processo for morto pelo sistema com posição aberta, o stop loss continua valendo na exchange? O app reconcilia ao voltar? --- ## 3. Gatilhos automáticos de REPROVAÇÃO Se **qualquer** item abaixo for verdadeiro, o veredicto é **REPROVADO**, independentemente de quão bom o resto esteja: 1. Destino de fundos **incompatível com o modelo declarado** (endereço fixo de custódia embutido no código, sem redirecionamento por usuário ou por dado de rede) — ou seja: destino calculado em tempo de execução, endereço vindo da rede, ou caminho capaz de alterar o destino por configuração. 2. Seed/chave privada em rede, log, backup ou arquivo externo — em qualquer caminho. 3. Permissão de acessibilidade, administrador de dispositivo, instalação de pacotes ou sobreposição de tela sem justificativa funcional demonstrada. 4. Carregamento dinâmico de código vindo da rede. 5. Telemetria, analytics ou coleta de identificador não declarada na política. 6. Cobrança duplicada da taxa pelo mesmo depósito em qualquer cenário reproduzível. 7. Relatório que declare "aprovado" sem evidência `arquivo:linha` para cada afirmação. 8. Omissão de um achado existente para agradar o contratante. --- ## 4. Formato obrigatório do relatório ``` 1. VEREDICTO: APROVADO | APROVADO COM RESSALVAS | REPROVADO + contagem por severidade (crítico / alto / médio / baixo / informativo) 2. RESPOSTAS DIRETAS (tabela: pergunta | resposta | evidência) 2b. DECISÕES DE DESIGN DECLARADAS (DD1–DD4) para cada uma: o que foi verificado (arquivo:linha) | implementada como declarada? | efeito para o usuário | risco assumido 3. ACHADOS (um por item): - ID, severidade, título - Evidência (arquivo:linha ou comando + saída) - Impacto concreto para o usuário - Correção sugerida - O que NÃO foi possível verificar 4. LIMITAÇÕES: o que a auditoria não cobriu e por quê 5. REPRODUÇÃO: comandos e passos para qualquer pessoa refazer a verificação 6. BINÁRIO E FONTE EXAMINADOS: commit, versão, SHA-256 do APK, fingerprint do certificado, data/hora da execução ``` --- ## 5. Regra final Um relatório que esconde um achado para agradar o contratante é pior que nenhum relatório: ele transfere confiança falsa para quem vai depositar dinheiro. Se o código não sustenta a promessa, diga — e diga onde.