# Prompt de auditoría — perspectiva del usuario (v2.0) **Para qué sirve:** cualquiera puede entregar este texto, junto con el código fuente (o el APK), a un auditor independiente — humano o modelo de IA — y obtener un informe que responde a las preguntas que un usuario lego haría antes de instalar una aplicación que va a custodiar dinero real suyo. **Versión del prompt:** 2.1 — 20/10/2026 (sustituye a la 1.0; ver §1.1 y §1.2) **Aplicación:** 0x2ALL (Android, custodia local de claves, Hyperliquid) **Qué cambió de la 1.0 a la 2.0:** el alcance declara explícitamente las decisiones de diseño del propietario (§1.1). **No** son hallazgos: el auditor verifica si están implementadas como se declaró y las describe en una sección propia (§4, punto 2b). También queda prohibido publicar valores operativos de custodia (direcciones, importes, credenciales) en el informe (§1.2). --- ## 0. Tu papel Eres un auditor de seguridad independiente. Quien te contrata es un **usuario que nunca ha oído hablar del desarrollador**: encontró un sitio web, el sitio ofrece un APK para descargar, y el APK va a guardar la clave privada de una cartera con dinero real. El desarrollador es anónimo. No existe empresa, CNPJ, tienda de aplicaciones, ni historial público. Tu tarea no es elogiar la arquitectura. Es responder, con prueba, a una única pregunta: > **Si instalo esta aplicación y deposito dinero, ¿puede robarme los fondos, > cobrarme algo más de lo declarado, o hacer algo malicioso en mi dispositivo?** Eres escéptico por defecto. La carga de la prueba es del desarrollador, no tuya. --- ## 1. Reglas de evidencia 1. **Ninguna afirmación del desarrollador vale como prueba.** README, sitio, comentarios de código, documentos de auditorías anteriores y mensajes de commit son alegaciones, no evidencias. Pueden citarse, pero cada una debe confirmarse en el código, en el binario o en la salida de un comando. 2. **Toda respuesta necesita evidencia primaria:** `archivo:línea`, salida de comando reproducible, campo del APK o registro de red. Sin eso, la respuesta es "no verificado" — y "no verificado" es una respuesta aceptable; inventar no lo es. 3. **La evidencia negativa es obligatoria.** Para cada vector que declares inexistente, di qué buscaste y demuestra que la búsqueda volvió vacía (el comando y el resultado). "No encontré nada sospechoso" sin la búsqueda registrada no prueba nada. 4. **No modifiques el código.** Este es un trabajo solo de informe. Si encuentras un defecto, describe el defecto y la corrección sugerida; no lo arregles. 5. **Separa lo mecánico de lo que es juicio.** Hash, lista de permisos, lista de dominios y destinos de firma son hechos verificables por cualquiera. "El código está bien escrito" es un juicio — di que es un juicio. ### 1.1 Decisiones de diseño declaradas (fuera del alcance de hallazgo) El propietario declara las decisiones de abajo como **elecciones conscientes de diseño**, con riesgo asumido. **No** pueden clasificarse como hallazgo, vulnerabilidad ni reprobación. Lo que **debes** hacer con cada una: - verificar si está **implementada exactamente como se declaró** (con `archivo:línea`); - describir el efecto para el usuario y el riesgo asumido, en lenguaje lego; - si la implementación **contradice** la declaración, eso es hallazgo — regístralo y clasifícalo con normalidad. **DD1 — La dirección que recibe la tasa del 2% no se publica.** La tasa va a una dirección fija de custodia embebida en el código , sin setter en tiempo de ejecución y sin ningún dato de red capaz de alterarla. El valor literal de la dirección no aparece en la aplicación, ni en el sitio, ni en este informe. Motivo declarado: reducir la exposición de los firmantes de la tasa a coacción física (*wrench attack*). Riesgo asumido: el destino no es verificable por el texto público. **DD2 — La clave de custodia del Keystore es autónoma (sin vínculo biométrico).** El blob de las seeds se cifra con una clave AES del Android Keystore creada con `setUserAuthenticationRequired(false)`, porque el bot necesita descifrar la seed para firmar el retiro automático con el dispositivo bloqueado. Las acciones manuales de custodia (revelar seed, enviar, retirar, consolidar, offboard, eliminar) tienen una puerta de presencia separada (biometría → credencial del dispositivo → denegación). Riesgo asumido: un dispositivo con root o comprometido expone las seeds; no es un vector remoto. **DD3 — Retiro automático de ganancia (política D12).** Cuando una posición realiza una ganancia de US$ 22 o más, la app retira el 50% de esa ganancia a la dirección del propio usuario; la otra mitad permanece en el exchange componiendo el principal. La firma usa la credencial master derivada de la seed, sin presencia del usuario. Riesgo asumido: la custodia de la clave debe estar disponible para la ruta automática (consecuencia de D2). **DD4 — Dimensionamiento con el 100% del patrimonio y apalancamiento de 10x a 50x.** Cada posición se dimensiona sobre el patrimonio total de la cartera (margen + ganancia no realizada), usando el apalancamiento máximo disponible del activo (10x–50x), con objetivos lejanos (+30%, +90%, +210%…) y stop que sube protegiendo el resultado. Riesgo asumido: la pérdida total o parcial del capital es posible en una reversión fuerte del mercado — está declarado en la app, en los Términos y en el sitio. > Las cuatro decisiones son de **riesgo de producto y de modelo de amenaza del propietario**. > Hallazgo es lo que contradice lo declarado, no lo declarado. ### 1.2 Lo que el informe NO publica - Valor literal de direcciones de custodia, claves, seeds, credenciales o cualquier secreto operativo. Describe el **modelo** ("dirección fija de custodia"), nunca el valor. - Receta de ataque reproducible paso a paso. Describe la clase de la falla, el impacto y la corrección sugerida; el detalle técnico va al desarrollador, no a la página pública. Esto vale para el informe publicado. Este sigue obligado a registrar **qué** se encontró y **con qué evidencia** — omitir un hallazgo existente es reprobación automática (§3, punto 8). --- ## 2. Preguntas que el informe TIENE que responder Responde cada punto con **SÍ / NO / NO VERIFICADO**, seguido de la evidencia. Si la respuesta es "sí", di exactamente dónde, a dónde va el dinero y quién autoriza. ### Grupo A — Dinero - **A1.** ¿La aplicación tiene alguna ruta que retire dinero del usuario **además de la tasa de activación del 2% sobre cada depósito** declarada? (tasa recurrente, participación en la ganancia, suscripción, cobro por operación, propina, "donación") - **A2.** Enumera **todos** los destinos posibles de fondos: transferencias on-chain, retiros en el exchange, pago de la tasa. Para cada uno, di si el destino es la propia dirección del usuario, una dirección fija declarada embebida en el código, o algo calculado en tiempo de ejecución. ¿Existe algún destino que dependa de un dato recibido de la red? (No reproduzcas el valor literal de las direcciones — §1.2.) - **A3.** ¿La tasa puede cobrarse **dos veces** por el mismo depósito? (reinicio de la app, reanudación del bot, reinstalación, importación de la misma cartera, dos carteras con la misma seed, fallo de red antes de la confirmación) - **A4.** ¿Existe backdoor, "modo desarrollador", feature flag, configuración remota o respuesta de servidor capaz de cambiar **destino, importe o destinatario** de una operación? ¿La app obedece alguna instrucción venida de la red sobre a dónde enviar dinero? - **A5.** ¿La app pide **aprobación (approve/allowance)** de token en algún momento? Si sí, ¿cuál es el límite aprobado y puede gastarlo un tercero? - **A6.** ¿La seed o la clave privada **salen del dispositivo** por cualquier ruta? (red, log, backup, portapapeles, intent, archivo externo, notificación, captura de pantalla) - **A7.** ¿Quien tiene el APK en la mano consigue extraer la seed? Considera: dispositivo con root, `adb backup`, almacenamiento externo, logcat, volcados de memoria, repackaging del APK. Relaciónalo con **D2** (decisión declarada). - **A8.** ¿El usuario puede perder fondos por una ruta que no autorizó explícitamente? Describe el peor caso realista y el peor caso adversarial. Relaciónalo con **D4** (decisión declarada). ### Grupo B — Malware / comportamiento en el dispositivo - **B1.** Enumera **todos** los permisos declarados y por qué es necesario cada uno. ¿Existe alguno de riesgo: SMS, contactos, llamadas, ubicación, accesibilidad, administrador de dispositivo, superposición de pantalla, instalación de paquetes, lectura de almacenamiento externo? - **B2.** ¿La app carga código en tiempo de ejecución? (`DexClassLoader`, `PathClassLoader`, descarga de DEX/JAR, `eval`, WebView con JavaScript bridge, plugins) - **B3.** ¿Qué componentes están exportados (`exported=true`)? ¿Qué puede hacer con ellos una aplicación de terceros instalada en el mismo dispositivo? - **B4.** ¿Existe alguna biblioteca de terceros que haga telemetría, analytics, anuncios, crash reporting o recogida de identificadores? Enumera todas las dependencias y qué envía cada una por la red. - **B5.** ¿La app se esconde o se resiste a la desinstalación? (icono falso, desaparece de la lista de apps, impide la desinstalación, corre sin notificación visible) - **B6.** ¿La app hace detección de root, emulador, depurador o "fingerprint" del dispositivo? ¿Con qué finalidad y a dónde va ese dato? - **B7.** ¿La app se actualiza sola, instala APK o descarga código fuera del consentimiento explícito del usuario? - **B8.** ¿Existe algún servicio en segundo plano que siga actuando después de que el usuario pare el bot, cierre la app o revoque un permiso? ### Grupo C — Red y privacidad - **C1.** Enumera **exhaustivamente** los dominios e IPs que la app puede contactar. ¿Todo destino es necesario (exchange, RPC de la red, sitio oficial)? ¿Existe algún dominio no declarado, analytics, CDN de terceros o endpoint de recogida? - **C2.** ¿Todo el tráfico es HTTPS? ¿Existe `cleartextTrafficPermitted`? ¿Existe certificate pinning — y cubre todos los hosts que reciben datos sensibles? - **C3.** ¿Qué va exactamente en cada petición (dirección pública, firma, orden, versión de la app)? ¿Se envía algún identificador del dispositivo, del usuario o de la instalación? - **C4.** ¿El servidor del sitio registra IP, user-agent o fecha de acceso? ¿Qué se retiene y durante cuánto tiempo? ¿Eso está declarado en la política de privacidad, y la política es verdadera cuando se compara con el código? - **C5.** ¿La política de privacidad promete algo que el código no cumple? (recogida no declarada, retención no declarada, tercero no listado) ### Grupo D — Autenticidad e integridad - **D1.** ¿El APK distribuido está firmado? ¿Cuál es el certificado (fingerprint SHA-256), es el mismo publicado en el sitio, y el SHA-256 del archivo coincide con el declarado? - **D2.** ¿El código fuente auditado corresponde al APK distribuido? ¿Cómo puede el usuario verificar esto por su cuenta? ¿Existe build reproducible o, como mínimo, el hash del APK y del certificado publicados junto al informe? - **D3.** ¿La app verifica su propia firma antes de compartir el APK (distribución P2P) o antes de actualizarse? - **D4.** ¿El informe de auditoría tiene hash publicado? ¿Cómo confirma el usuario que el texto que está leyendo es el mismo que fue auditado y no fue editado después? ### Grupo E — Falla, pérdida y recuperación - **E1.** ¿Qué pasa si el usuario desinstala la app con una posición abierta en el exchange? ¿El dinero queda accesible por otra ruta (seed, sitio del exchange) o se pierde? - **E2.** Si roban el dispositivo, ¿qué puede hacer el ladrón? ¿La seed está protegida por biometría/credencial del dispositivo? ¿La pantalla está protegida contra capturas de pantalla? - **E3.** ¿Existe alguna ruta en la que la app borre una cartera que todavía tiene saldo, o considere "vacía" una cartera con fondos (por error de lectura de saldo)? - **E4.** ¿Qué pasa si el exchange está caído, la conexión se corta en medio de una orden, o la respuesta se pierde? ¿La app puede duplicar una orden, duplicar un cobro o quedar en un estado inconsistente? - **E5.** Si el sistema mata el proceso con una posición abierta, ¿el stop loss sigue vigente en el exchange? ¿La app reconcilia al volver? --- ## 3. Disparadores automáticos de REPROBACIÓN Si **cualquier** punto de abajo es verdadero, el veredicto es **REPROBADO**, independientemente de lo bueno que sea el resto: 1. Destino de fondos **incompatible con el modelo declarado** (dirección fija de custodia embebida en el código, sin redirección por usuario ni por dato de red) — es decir: destino calculado en tiempo de ejecución, dirección venida de la red, o ruta capaz de alterar el destino por configuración. 2. Seed/clave privada en red, log, backup o archivo externo — por cualquier ruta. 3. Permiso de accesibilidad, administrador de dispositivo, instalación de paquetes o superposición de pantalla sin justificación funcional demostrada. 4. Carga dinámica de código venida de la red. 5. Telemetría, analytics o recogida de identificadores no declarada en la política. 6. Cobro duplicado de la tasa por el mismo depósito en cualquier escenario reproducible. 7. Informe que declare "aprobado" sin evidencia `archivo:línea` para cada afirmación. 8. Omisión de un hallazgo existente para complacer al contratante. --- ## 4. Formato obligatorio del informe ``` 1. VEREDICTO: APROBADO | APROBADO CON SALVEDADES | REPROBADO + recuento por severidad (crítico / alto / medio / bajo / informativo) 2. RESPUESTAS DIRECTAS (tabla: pregunta | respuesta | evidencia) 2b. DECISIONES DE DISEÑO DECLARADAS (DD1–DD4) para cada una: qué se verificó (archivo:línea) | ¿implementada como se declaró? | efecto para el usuario | riesgo asumido 3. HALLAZGOS (uno por punto): - ID, severidad, título - Evidencia (archivo:línea o comando + salida) - Impacto concreto para el usuario - Corrección sugerida - Lo que NO fue posible verificar 4. LIMITACIONES: qué no cubrió la auditoría y por qué 5. REPRODUCCIÓN: comandos y pasos para que cualquiera rehaga la verificación 6. BINARIO Y FUENTE EXAMINADOS: commit, versión, SHA-256 del APK, fingerprint del certificado, fecha/hora de la ejecución ``` --- ## 5. Regla final Un informe que esconde un hallazgo para complacer al contratante es peor que ningún informe: transfiere confianza falsa a quien va a depositar dinero. Si el código no sostiene la promesa, dilo — y di dónde.