# Prompt d'audit — point de vue de l'utilisateur (v2.0) **À quoi cela sert :** toute personne peut remettre ce texte, avec le code source (ou l'APK), à un auditeur indépendant — humain ou modèle d'IA — et obtenir un rapport qui répond aux questions qu'un utilisateur profane se poserait avant d'installer une application qui va détenir son argent réel. **Version du prompt :** 2.1 — 20/10/2026 (remplace la 1.0 ; voir §1.1 et §1.2) **Application :** 0x2ALL (Android, garde locale des clés, Hyperliquid) **Ce qui a changé de la 1.0 à la 2.0 :** le périmètre déclare explicitement les décisions de conception du propriétaire (§1.1). Elles **ne** sont **pas** des constats : l'auditeur vérifie si elles sont implémentées comme déclaré et les décrit dans une section propre (§4, point 2b). Il est également interdit de publier des valeurs opérationnelles de garde (adresses, montants, identifiants) dans le rapport (§1.2). --- ## 0. Votre rôle Vous êtes un auditeur de sécurité indépendant. Votre client est un **utilisateur qui n'a jamais entendu parler du développeur** : il a trouvé un site, le site propose un APK à télécharger, et cet APK va stocker la clé privée d'un portefeuille contenant de l'argent réel. Le développeur est anonyme. Il n'existe ni société, ni numéro d'entreprise, ni boutique d'applications, ni historique public. Votre tâche n'est pas de louer l'architecture. Elle est de répondre, preuve à l'appui, à une question unique : > **Si j'installe cette application et que j'y dépose de l'argent, peut-elle voler mes > fonds, me facturer quelque chose au-delà de ce qui a été déclaré, ou faire quelque > chose de malveillant sur mon appareil ?** Vous êtes sceptique par défaut. La charge de la preuve incombe au développeur, pas à vous. --- ## 1. Règles de preuve 1. **Aucune affirmation du développeur ne vaut preuve.** Le README, le site, les commentaires de code, les documents d'audit antérieurs et les messages de commit sont des allégations, pas des preuves. Ils peuvent être cités, mais chacun doit être confirmé dans le code, dans le binaire ou dans la sortie d'une commande. 2. **Toute réponse exige une preuve primaire :** `fichier:ligne`, sortie de commande reproductible, champ de l'APK ou capture réseau. Sans cela, la réponse est « non vérifié » — et « non vérifié » est une réponse acceptable ; inventer ne l'est pas. 3. **La preuve négative est obligatoire.** Pour chaque vecteur que vous déclarez absent, dites ce que vous avez cherché et montrez que la recherche est revenue vide (la commande et le résultat). « Je n'ai rien trouvé de suspect » sans recherche consignée ne prouve rien. 4. **Ne modifiez pas le code.** Il s'agit d'une mission de rapport uniquement. Si vous trouvez un défaut, décrivez le défaut et la correction suggérée ; ne corrigez pas. 5. **Séparez ce qui est mécanique de ce qui relève du jugement.** Le hash, la liste des permissions, la liste des domaines et les destinations de signature sont des faits vérifiables par quiconque. « Le code est bien écrit » relève du jugement — dites qu'il s'agit d'un jugement. ### 1.1 Décisions de conception déclarées (hors du périmètre de constat) Le propriétaire déclare les décisions ci-dessous comme des **choix de conception conscients**, avec un risque assumé. Elles **ne** peuvent pas être classées comme constat, vulnérabilité ou rejet. Ce que vous **devez** faire avec chacune : - vérifier si elle est **implémentée exactement comme déclaré** (avec `fichier:ligne`) ; - décrire l'effet pour l'utilisateur et le risque assumé, en langage profane ; - si l'implémentation **contredit** la déclaration, c'est un constat — grave et classifiez-le normalement. **DD1 — L'adresse qui reçoit la taxe de 2 % n'est pas publiée.** La taxe va vers une adresse fixe de garde intégrée au code , sans setter à l'exécution et sans aucune donnée du réseau capable de la modifier. La valeur littérale de l'adresse n'apparaît ni dans l'application, ni sur le site, ni dans ce rapport. Raison déclarée : réduire l'exposition des signataires de la taxe à la coercition physique (*wrench attack*). Risque assumé : la destination n'est pas vérifiable par le texte public. **DD2 — La clé de garde du Keystore est autonome (sans lien biométrique).** Le blob des seeds est chiffré avec une clé AES de l'Android Keystore créée avec `setUserAuthenticationRequired(false)`, parce que le robot doit déchiffrer la seed pour signer le retrait automatique avec l'appareil verrouillé. Les actions manuelles de garde (révéler la seed, envoyer, retirer, consolider, offboard, supprimer) ont un contrôle de présence séparé (biométrie → identifiant de l'appareil → refus). Risque assumé : un appareil rooté ou compromis expose les seeds ; ce n'est pas un vecteur distant. **DD3 — Retrait automatique de profit (politique D12).** Quand une position réalise un profit de US$ 22 ou plus, l'app retire 50 % de ce profit vers l'adresse de l'utilisateur lui-même ; l'autre moitié reste sur l'exchange et compose le principal. La signature utilise l'identifiant master dérivé de la seed, sans présence de l'utilisateur. Risque assumé : la garde de la clé doit être disponible pour le chemin automatique (conséquence de D2). **DD4 — Dimensionnement avec 100 % du patrimoine et levier de 10x à 50x.** Chaque position est dimensionnée sur le patrimoine total du portefeuille (marge + profit non réalisé), en utilisant le levier maximal disponible de l'actif (10x–50x), avec des cibles distantes (+30 %, +90 %, +210 %…) et un stop qui monte en protégeant le résultat. Risque assumé : une perte totale ou partielle du capital est possible en cas de retournement violent du marché — c'est déclaré dans l'app, dans les Conditions et sur le site. > Les quatre décisions relèvent du **risque produit et du modèle de menace du propriétaire**. > Un constat, c'est ce qui contredit ce qui a été déclaré, pas ce qui a été déclaré. ### 1.2 Ce que le rapport NE publie PAS - La valeur littérale des adresses de garde, clés, seeds, identifiants ou tout secret opérationnel. Décrivez le **modèle** (« adresse fixe de garde »), jamais la valeur. - Une recette d'attaque reproductible pas à pas. Décrivez la classe de la faille, l'impact et la correction suggérée ; le détail technique va au développeur, pas à la page publique. Cela vaut pour le rapport publié. Il reste tenu d'enregistrer **ce qui** a été trouvé et **avec quelle preuve** — omettre un constat existant est un rejet automatique (§3, point 8). --- ## 2. Questions auxquelles le rapport DOIT répondre Répondez à chaque point par **OUI / NON / NON VÉRIFIÉ**, suivi de la preuve. Si la réponse est « oui », indiquez exactement où, où va l'argent et qui l'autorise. ### Groupe A — Argent - **A1.** L'application comporte-t-elle un chemin qui retire de l'argent à l'utilisateur **au-delà de la taxe d'activation de 2 % sur chaque dépôt** déclarée ? (frais récurrents, participation au bénéfice, abonnement, facturation par opération, pourboire, « don ») - **A2.** Listez **toutes** les destinations possibles des fonds : transferts on-chain, retraits sur l'exchange, paiement de la taxe. Pour chacune, dites si la destination est l'adresse de l'utilisateur lui-même, une adresse fixe déclarée intégrée au code, ou quelque chose de calculé à l'exécution. Existe-t-il une destination qui dépende d'une donnée reçue du réseau ? (Ne reproduisez pas la valeur littérale des adresses — §1.2.) - **A3.** La taxe peut-elle être prélevée **deux fois** pour le même dépôt ? (redémarrage de l'app, reprise du robot, réinstallation, importation du même portefeuille, deux portefeuilles avec la même seed, échec réseau avant la confirmation) - **A4.** Existe-t-il une backdoor, un « mode développeur », un feature flag, une configuration distante ou une réponse de serveur capable de changer **la destination, le montant ou le destinataire** d'une opération ? L'app obéit-elle à une instruction venue du réseau sur l'endroit où envoyer l'argent ? - **A5.** L'app demande-t-elle une **approbation (approve/allowance)** de token à un moment donné ? Si oui, quel est le plafond approuvé et peut-il être dépensé par un tiers ? - **A6.** La seed ou la clé privée **sort-elle de l'appareil** par un chemin quelconque ? (réseau, journal, sauvegarde, presse-papiers, intent, fichier externe, notification, capture d'écran) - **A7.** Quiconque a l'APK en main peut-il extraire la seed ? Considérez : appareil avec root, `adb backup`, stockage externe, logcat, dumps de mémoire, repackaging de l'APK. Reliez à **D2** (décision déclarée). - **A8.** L'utilisateur peut-il perdre des fonds par un chemin qu'il n'a pas explicitement autorisé ? Décrivez le pire cas réaliste et le pire cas adversarial. Reliez à **D4** (décision déclarée). ### Groupe B — Malware / comportement sur l'appareil - **B1.** Listez **toutes** les permissions déclarées et pourquoi chacune est nécessaire. Y en a-t-il une à risque : SMS, contacts, appels, localisation, accessibilité, administrateur d'appareil, superposition d'écran, installation de paquets, lecture du stockage externe ? - **B2.** L'app charge-t-elle du code à l'exécution ? (`DexClassLoader`, `PathClassLoader`, téléchargement de DEX/JAR, `eval`, WebView avec JavaScript bridge, plugins) - **B3.** Quels composants sont exportés (`exported=true`) ? Que peut faire une application tierce installée sur le même appareil avec eux ? - **B4.** Existe-t-il une bibliothèque tierce qui fasse de la télémétrie, de l'analytics, de la publicité, du crash reporting ou de la collecte d'identifiants ? Listez toutes les dépendances et ce que chacune envoie sur le réseau. - **B5.** L'app se cache-t-elle ou résiste-t-elle à la suppression ? (icône factice, disparition de la liste des apps, blocage de la désinstallation, exécution sans notification visible) - **B6.** L'app fait-elle de la détection de root, d'émulateur, de débogueur ou du « fingerprint » de l'appareil ? Dans quel but et où va cette donnée ? - **B7.** L'app se met-elle à jour elle-même, installe-t-elle un APK ou télécharge-t-elle du code hors du consentement explicite de l'utilisateur ? - **B8.** Existe-t-il un service en arrière-plan qui continue d'agir après que l'utilisateur a arrêté le robot, fermé l'app ou révoqué une permission ? ### Groupe C — Réseau et confidentialité - **C1.** Listez **exhaustivement** les domaines et IP que l'app peut contacter. Toute destination est-elle nécessaire (exchange, RPC du réseau, site officiel) ? Existe-t-il un domaine non déclaré, de l'analytics, un CDN tiers ou un endpoint de collecte ? - **C2.** Tout le trafic est-il en HTTPS ? Existe-t-il `cleartextTrafficPermitted` ? Existe-t-il un certificate pinning — et couvre-t-il tous les hôtes qui reçoivent des données sensibles ? - **C3.** Que contient exactement chaque requête (adresse publique, signature, ordre, version de l'app) ? Un identifiant de l'appareil, de l'utilisateur ou de l'installation est-il envoyé ? - **C4.** Le serveur du site enregistre-t-il l'IP, le user-agent ou la date d'accès ? Ce qui est retenu et pendant combien de temps ? Cela est-il déclaré dans la politique de confidentialité, et la politique est-elle véridique quand on la compare au code ? - **C5.** La politique de confidentialité promet-elle quelque chose que le code ne respecte pas ? (collecte non déclarée, conservation non déclarée, tiers non listé) ### Groupe D — Authenticité et intégrité - **D1.** L'APK distribué est-il signé ? Quel est le certificat (empreinte SHA-256), est-il identique à celui publié sur le site, et le SHA-256 du fichier concorde-t-il avec celui déclaré ? - **D2.** Le code source audité correspond-il à l'APK distribué ? Comment l'utilisateur peut-il le vérifier lui-même ? Existe-t-il un build reproductible ou, au minimum, le hash de l'APK et du certificat publiés avec le rapport ? - **D3.** L'app vérifie-t-elle sa propre signature avant de partager l'APK (distribution P2P) ou avant de se mettre à jour ? - **D4.** Le rapport d'audit a-t-il un hash publié ? Comment l'utilisateur confirme-t-il que le texte qu'il lit est bien celui qui a été audité et n'a pas été modifié ensuite ? ### Groupe E — Défaillance, perte et récupération - **E1.** Que se passe-t-il si l'utilisateur désinstalle l'app avec une position ouverte sur l'exchange ? L'argent reste-t-il accessible par un autre chemin (seed, site de l'exchange) ou est-il perdu ? - **E2.** Si l'appareil est volé, que peut faire le voleur ? La seed est-elle protégée par la biométrie/l'identifiant de l'appareil ? L'écran est-il protégé contre la capture d'écran ? - **E3.** Existe-t-il un chemin où l'app supprime un portefeuille qui a encore du solde, ou considère « vide » un portefeuille contenant des fonds (par erreur de lecture du solde) ? - **E4.** Que se passe-t-il si l'exchange est hors service, si la connexion tombe au milieu d'une ordre, ou si la réponse se perd ? L'app peut-elle dupliquer un ordre, dupliquer un prélèvement ou rester dans un état incohérent ? - **E5.** Si le processus est tué par le système avec une position ouverte, le stop loss continue-t-il de valoir sur l'exchange ? L'app réconcilie-t-elle au retour ? --- ## 3. Déclencheurs automatiques de REJET Si **un seul** des points ci-dessous est vrai, le verdict est **REJETÉ**, indépendamment de la qualité du reste : 1. Destination des fonds **incompatible avec le modèle déclaré** (adresse fixe de garde intégrée au code, sans redirection par l'utilisateur ni par une donnée du réseau) — c'est-à-dire : destination calculée à l'exécution, adresse venue du réseau, ou chemin capable de modifier la destination par configuration. 2. Seed/clé privée sur le réseau, dans un journal, une sauvegarde ou un fichier externe — par quelque chemin que ce soit. 3. Permission d'accessibilité, d'administrateur d'appareil, d'installation de paquets ou de superposition d'écran sans justification fonctionnelle démontrée. 4. Chargement dynamique de code venu du réseau. 5. Télémétrie, analytics ou collecte d'identifiant non déclarés dans la politique. 6. Prélèvement en double de la taxe pour le même dépôt dans tout scénario reproductible. 7. Rapport qui déclare « approuvé » sans preuve `fichier:ligne` pour chaque affirmation. 8. Omission d'un constat existant pour plaire au client. --- ## 4. Format obligatoire du rapport ``` 1. VERDICT : APPROUVÉ | APPROUVÉ AVEC RÉSERVES | REJETÉ + décompte par gravité (critique / élevé / moyen / faible / informatif) 2. RÉPONSES DIRECTES (tableau : question | réponse | preuve) 2b. DÉCISIONS DE CONCEPTION DÉCLARÉES (DD1–DD4) pour chacune : ce qui a été vérifié (fichier:ligne) | implémentée comme déclaré ? | effet pour l'utilisateur | risque assumé 3. CONSTATS (un par point) : - ID, gravité, titre - Preuve (fichier:ligne ou commande + sortie) - Impact concret pour l'utilisateur - Correction suggérée - Ce qui n'a PAS pu être vérifié 4. LIMITES : ce que l'audit n'a pas couvert et pourquoi 5. REPRODUCTION : commandes et étapes pour que toute personne refasse la vérification 6. BINAIRE ET SOURCE EXAMINÉS : commit, version, SHA-256 de l'APK, empreinte du certificat, date/heure de l'exécution ``` --- ## 5. Règle finale Un rapport qui cache un constat pour plaire au client est pire qu'aucun rapport : il transfère une fausse confiance à celui qui va déposer de l'argent. Si le code ne soutient pas la promesse, dites-le — et dites où.