Prompt appliqué : AUDIT_PROMPT_USER_pt-BR.md v2.1 (public, reproductible) — inchangé Date
d'exécution : 21 octobre 2026 Auditeur : DeepSeek v4.1 Flash (1017) — revue en quatre axes
(argent, malware, réseau, conservation) avec vérification manuelle des points qui modifient le verdict
Code audité : commit 9f69edc — v1.0.21 (code 21). L'arborescence de fichiers ayant produit l'APK
est celle de ce commit ; 73fe94d et 19209cf sont de la documentation et du site, avec la même
arborescence d'application Binaire examiné : 0x2ALL-1.0.21-9f69edc-release.apk, SHA-256
325245a6542212f0227eb7616f9a550bcd0053e5d7c613a66d080c60698bf830, 6.677.553 octets, certificat
53dac6cbe7edd6894b9377c4bbdc302a883abbe18a01ad2bd87d0a0fafa142c1 Remplace : édition v8.0
(1.0.20, 6814b8b) Périmètre : prompt v2.1 — les décisions de conception déclarées au §2b sont
hors du périmètre de constat, mais elles ont été vérifiées une par une.
Il s'agit du réaudit du binaire 1.0.21. Le delta depuis l'édition v8.0 (1.0.20, 6814b8b)
comporte un changement fonctionnel et une correction de texte :
security/DeviceIntegrity.kt évalue les signaux de root ou
de bootloader déverrouillé sur l'appareil lui-même, une fois par processus, et l'application réagit
en trois points : un avertissement bloquant à chaque ouverture (avant tout écran de contenu), une
carte « Intégrité de l'appareil » sur l'écran Sécurité et le blocage de nouvelle conservation —
créer un portefeuille, importer, on-ramp et déposer. La sortie de fonds (retirer, envoyer,
consolider, offboard, panique et révéler la phrase) reste autorisée.app/build.gradle.kts — bump 1.0.20 → 1.0.21 (code 21).Ce qui change pour l'utilisateur, en langage simple. Si le téléphone est rooté ou si le bootloader est déverrouillé, l'application avertit désormais au lieu de prétendre que tout va bien — et elle ne le laisse plus placer de l'argent neuf sur un appareil où la phrase de récupération peut être lue par n'importe quelle application disposant de root. Celui qui a déjà des fonds dessus peut toujours retirer, envoyer et voir la phrase : l'application informe et bloque l'entrée, jamais la sortie.
Pourquoi cela ne relâche aucune protection. La vérification est locale — rien n'est envoyé, rien
n'est persisté et aucun identifiant de l'appareil n'est lu. Il n'y a ni endpoint, ni permission, ni
destination de fonds nouvelle : le <queries> du manifeste rend seulement visible si un gestionnaire
de root est installé. Les permissions (13), les hôtes (12) et les adresses 0x (7) restent
identiques à celles de la 1.0.20.
Limite déclarée. La détection est heuristique : Magisk DenyList/Shamiko, un APK repatché et un hook (Frida) la déjouent. Elle sert l'utilisateur honnête et le moment qui précède le premier dépôt — pas l'attaquant. L'application n'affirme nulle part que « sans avertissement = sûr ».
Réaudit. Les 30 réponses ont été revérifiées contre la nouvelle arborescence et le nouveau
binaire. Preuve que le code audité est celui qui a été signé : 83 nouvelles classes dans le DEX,
dont celles de domaine DeviceIntegrity, DeviceIntegrity$Finding et
MainActivityKt$DeviceIntegrityGate* (le reste sont des lambdas Compose renumérotées, 66 anciennes
classes équivalentes ont disparu) ; les chaînes androidboot.verifiedbootstate (4 occurrences),
androidboot.flash.locked, test-keys, kernelsu et /system/xbin/su présentes dans classes.dex
; et les 10 nouvelles clés d'avertissement/état dans chacune des 6 locales du resources.arsc.
Tailles : classes.dex +1.456 octets, classes3.dex +12.196, resources.arsc +16.972.
| Critère | Résultat |
|---|---|
| Verdict | APPROUVÉ — 0 constat ouvert |
| Critique | 0 |
| Élevé | 0 |
| Moyen | 0 |
| Faible | 0 |
| Informatif | 5 (distribution, domaine, correction de registre et la nouvelle détection de root, §3) |
| # | Question | Réponse | Preuve |
|---|---|---|---|
| A1 | L'application comporte-t-elle un chemin qui retire de l'argent à l'utilisateur au-delà des frais d'activation de 2 % sur chaque dépôt déclarés ? (frais récurrents, participation aux bénéfices, abonnement, facturation par opération, pourboire, « don ») | NON. Le seul prélèvement est de 2 % sur chaque dépôt, effectué avant le crédit sur l'exchange. Il n'existe pas de frais sur le profit, par opération, sur le retrait, d'abonnement ou de pourboire | PaymentManager.kt:109-111 (2 %), :127-138 (prélèvement avant le dépôt), :114-121 (ordre du flux) ; recherche « performance fee/profit share/management fee » : 0 occurrence dans app/src/main |
| A2 | Listez toutes les destinations possibles des fonds : transferts on-chain, retraits sur l'exchange, paiement des frais. Pour chacune, indiquez si la destination est la propre adresse de l'utilisateur, une adresse fixe déclarée et codée en dur, 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.) | 3 destinations. (i) frais → adresse fixe de conservation codée en dur ; (ii) dépôt → contrat Bridge2 de Hyperliquid ; (iii) retrait withdraw3 → toujours la propre adresse qui signe. Aucune destination ne vient du réseau |
AppConfiguration.kt:32 (constante immuable), PaymentManager.kt:100-101 ; WalletManager.kt:92 (Bridge2) ; HyperliquidAPI.kt:1716 (destination = masterCredentials.address) et :1727 |
| A3 | Les frais peuvent-ils être prélevés deux fois pour le même dépôt ? (redémarrage de l'application, reprise du bot, réinstallation, importation du même portefeuille, deux portefeuilles avec la même seed, échec réseau avant la confirmation) | NON pour le même dépôt. Journal durable avec identité <depósito>:fee ; un état indéterminé ne devient pas une annulation et l'opération est reprise avec la même identité. Les dépôts nouveaux paient 2 % à nouveau — c'est déclaré |
PaymentOperationStore.kt:24-34 ; PaymentManager.kt:70-76, :198 |
| A4 | Existe-t-il une backdoor, un « mode développeur », un feature flag, une configuration distante ou une réponse de serveur capable de modifier la destination, le montant ou le destinataire d'une opération ? L'application obéit-elle à une instruction venue du réseau sur l'endroit où envoyer l'argent ? | NON. L'URL de base est une constante de code ; il n'existe ni configuration distante, ni feature flag, ni « mode dev », ni réponse HTTP capable de définir une destination | HyperliquidSigner.kt:38 (MAINNET_URL constante) ; recherche remote config/flags : aucun chemin ne modifie la destination |
| A5 | L'application demande-t-elle une approbation (approve/allowance) de token à un moment quelconque ? Si oui, quel est le plafond approuvé et peut-il être dépensé par un tiers ? | NON. Aucun approve/allowance n'est demandé. Le contrat ERC-20 n'est utilisé que pour balanceOf et pour construire le transfert d'USDC |
ERC20Contract.kt:31 ; recherche « approve(/allowance » : 0 occurrence |
| A6 | La seed ou la clé privée sortent-elles de l'appareil par un chemin quelconque ? (réseau, log, sauvegarde, presse-papiers, intent, fichier externe, notification, capture d'écran) | NON. La seed ne sort ni par le réseau, ni par les logs, la sauvegarde, le presse-papiers ou un intent ; elle n'apparaît qu'à l'écran, sous contrôle de présence | recherche de log de seed : 0 occurrence ; MultiWalletManager.kt:422 ; MainActivity.kt:68-71 (FLAG_SECURE sur toute l'application) ; allowBackup=false |
| A7 | Quelqu'un qui a l'APK en main peut-il extraire la seed ? Considérez : appareil rooté, adb backup, stockage externe, logcat, dumps mémoire, repackaging de l'APK. Reliez à D2 (décision déclarée). |
Avec root, oui — décision déclarée DD2 : la clé du Keystore est autonome pour que le bot fonctionne 24 h. adb backup non (allowBackup=false) ; logcat non ; le repackaging de l'APK peut remplacer la constante des frais, c'est pourquoi le certificat est publié et vérifié |
MultiWalletManager.kt:422 ; AndroidManifest.xml:55-57 ; ShareAppHelper.kt:33,42 |
| 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 adverse. Reliez à D4 (décision déclarée). | Réaliste : perte due à la stratégie (D4 — levier 10–50x, sizing 100 %). Adverse : appareil compromis → seed → tous les portefeuilles ; APK re-signé hors de la distribution officielle | TradingBot.kt:1257,1282-1285,1338 ; MainActivity.kt:68-71 |
| # | Question | Réponse | Preuve |
|---|---|---|---|
| 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 ? | 13 dans l'APK, toutes fonctionnelles. 11 déclarées dans le manifest (internet, réseau, biométrie, notifications, vibration, foreground service, data sync du service, wake lock, optimisation de batterie, boot, alarme exacte) + USE_FINGERPRINT (alias hérité de l'API de biométrie) + une permission interne de signature d'AndroidX pour les receivers dynamiques. Aucune à risque : pas de SMS, contacts, localisation, accessibilité, admin, overlay ni installation de paquets |
AndroidManifest.xml:6-31 ; vérifié dans l'APK avec aapt2 dump badging |
| B2 | L'application charge-t-elle du code à l'exécution ? (DexClassLoader, PathClassLoader, téléchargement de DEX/JAR, eval, WebView avec JavaScript bridge, plugins) |
NON. Zéro DexClassLoader, PathClassLoader, WebView, eval ou plugin ; zéro bibliothèque native (.so) dans l'APK |
recherche dans app/src/main : 0 occurrence ; find de .so : 0 |
| B3 | Quels composants sont exportés (exported=true) ? Que peut faire une application tierce installée sur le même appareil avec eux ? |
MainActivity (ouvre seulement l'application ; ne lit pas l'Intent) et BootReceiver (rejette action ≠ BOOT_COMPLETED). Les autres composants sont exported=false |
AndroidManifest.xml:46-93 |
| 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 par le réseau. | NON. Sans télémétrie, analytics, publicité, crash reporting ni collecte d'identifiant | recherche firebase/crashlytics/analytics/sentry : 0 occurrence |
| B5 | L'application se cache-t-elle ou résiste-t-elle à la désinstallation ? (icône factice, disparition de la liste des applications, blocage de la désinstallation, exécution sans notification visible) | NON. Icône normale, désinstallation normale, notification du service toujours visible | AndroidManifest.xml ; service en foreground |
| B6 | L'application fait-elle de la détection de root, d'émulateur, de débogueur ou une « empreinte » de l'appareil ? Dans quel but et où va cette donnée ? | OUI, locale (nouveau en 1.0.21). Elle détecte le root et le bootloader déverrouillé pour avertir l'utilisateur et bloquer la nouvelle conservation. Elle ne détecte ni émulateur ni débogueur, ne lit aucun identifiant de l'appareil et n'envoie rien | DeviceIntegrity.kt (signaux au §0) ; <queries> dans AndroidManifest.xml:31-51 (sans permission) |
| B7 | L'application se met-elle à jour toute seule, installe-t-elle un APK ou télécharge-t-elle du code sans consentement explicite de l'utilisateur ? | NON. Elle ne consulte aucune version, ne télécharge aucun APK, n'installe rien ; la mise à jour se fait par téléchargement manuel sur le site. La nouvelle carte du site officiel n'ouvre le navigateur de l'utilisateur que lorsqu'il touche — aucun octet de l'APK n'est téléchargé par l'application | recherche UpdateChecker/UPDATE_CHECK_URL : 0 occurrence ; SecurityScreen.kt:191-226 (uniquement ACTION_VIEW) ; DEX sans téléchargement natif |
| B8 | Existe-t-il un service en arrière-plan qui continue d'agir après que l'utilisateur a arrêté le bot, fermé l'application ou révoqué une permission ? | Le service en foreground n'agit que tant que le bot est actif et s'arrête quand l'utilisateur l'arrête ; la notification est permanente et non retirable sans arrêter le service | TradingBotService (foreground, canal visible) |
| # | Question | Réponse | Preuve |
|---|---|---|---|
| C1 | Listez exhaustivement les domaines et IP que l'application peut contacter. Chaque 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 ? | 4 hôtes d'exploitation : api.hyperliquid.xyz, rpc.hyperliquid.xyz, arb1.arbitrum.io et https://0x2all.xyz (introduit en 1.0.14, inchangé ici), qui existe dans l'APK uniquement comme texte (carte Sécurité et lien de la politique de confidentialité, ouvert dans le navigateur) et n'est jamais cible de requête : le toucher ouvre le navigateur via Intent.ACTION_VIEW, pas une connexion de l'application. Deux autres hôtes de contenu (documentation de Hyperliquid et une recherche Google lancée par l'utilisateur lui-même). Aucun domaine d'analytics/CDN de collecte |
balayage des URL dans app/src/main et réconciliation du DEX : 12 hôtes, ensemble identique à celui de la 1.0.16 — aucun nouveau, aucun supprimé ; SecurityScreen.kt:39,196 ; HistoryScreen.kt:149 |
| 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 ? |
OUI, tout est en HTTPS. cleartextTrafficPermitted=false dans la configuration réseau ; pinning de CA sur Hyperliquid et sur le RPC d'Arbitrum |
res/xml/network_security_config.xml:3 ; HyperliquidAPI.kt:460-461 ; ArbitrumRpc.kt:10 |
| C3 | Que contient exactement chaque requête (adresse publique, signature, ordre, version de l'application) ? Un identifiant de l'appareil, de l'utilisateur ou de l'installation est-il envoyé ? | Adresse publique, signature et payload de l'ordre ; aucun identifiant d'appareil, d'utilisateur ou d'installation | HyperliquidAPI.kt (payloads) ; recherche ANDROID_ID/AdvertisingId : 0 |
| C4 | Le serveur du site enregistre-t-il l'IP, le user-agent ou la date d'accès ? Que conserve-t-il et pendant combien de temps ? Est-ce déclaré dans la politique de confidentialité, et cette politique est-elle vraie comparée au code ? | Le site enregistre uniquement les blocages (événement, pays, région, route, horaire ; sans IP) et est servi par Cloudflare. La politique le déclare depuis la v7 : la version 6 affirmait le contraire et a été corrigée dans cette édition — une politique qui contredit le code est un constat, pas un détail de rédaction | website/src/worker.js:15-17 ; privacy.html §4 (v7) |
| C5 | La politique de confidentialité promet-elle quelque chose que le code ne respecte pas ? (collecte non déclarée, rétention non déclarée, tiers non listé) | NON (revérifié après la correction de la v7). Politique et code coïncident sur les points vérifiables : données sur l'appareil, pas de compte, pas d'analytics, journal de blocage sans IP, aucun tiers au-delà de Hyperliquid/Arbitrum/Cloudflare | privacy.html v7 ; code cité en C1–C4 |
| # | Question | Réponse | Preuve |
|---|---|---|---|
| D1 | L'APK distribué est-il signé ? Quel est le certificat (empreinte SHA-256), est-ce le même que celui publié sur le site, et le SHA-256 du fichier correspond-il à celui déclaré ? | OUI. APK signé en v2+v3, RSA-4096, certificat 53dac6cb…42c1 — le même que celui publié sur le site ; le SHA-256 du fichier correspond |
apksigner verify --print-certs ; sha256sum |
| D2 | Le code source audité correspond-il à l'APK distribué ? Comment l'utilisateur peut-il le vérifier seul ? Existe-t-il un build reproductible ou, au minimum, le hash de l'APK et du certificat publiés avec le rapport ? | Correspondance source↔APK vérifiée par inspection du binaire (version, permissions, classes, hôtes et adresses de contrat) — ce n'est pas un build reproductible, et cela est déclaré dans les limites | aapt2 dump badging ; réconciliation de DEX |
| D3 | L'application vérifie-t-elle sa propre signature avant de partager l'APK (distribution P2P) ou avant de se mettre à jour ? | OUI. Le partage P2P s'interrompt si le certificat n'est pas celui attendu | ShareAppHelper.kt:33,42 |
| D4 | Le rapport d'audit a-t-il un hash publié ? Comment l'utilisateur confirme-t-il que le texte qu'il lit est celui qui a été audité et n'a pas été modifié ensuite ? | OUI. Chaque fichier a un SHA-256 publié et une preuve de date OpenTimestamps | audit.json ; fichiers .ots |
| # | Question | Réponse | Preuve |
|---|---|---|---|
| E1 | Que se passe-t-il si l'utilisateur désinstalle l'application 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 ? | L'argent reste accessible par la seed (autre portefeuille ou importation dans l'application) et par l'exchange lui-même ; les positions vivantes sont lues depuis l'exchange à la réinstallation | réconciliation des fills/positions ; MultiWalletManager |
| E2 | Si l'appareil est volé, que peut faire le voleur ? La seed est-elle protégée par biométrie/identifiant de l'appareil ? L'écran est-il protégé contre les captures d'écran ? | Seed chiffrée par le Keystore, écran protégé contre la capture ; les actions de conservation exigent une présence. Root expose la seed (D2) — depuis la 1.0.21, l'application avertit à l'ouverture et bloque le dépôt sur un appareil signalé | MainActivity.kt:68-71 ; DeviceIntegrityGate dans MainActivity.kt:159-181 ; AppLockManager.requirePresence dans DashboardScreen.kt:586-696 |
| E3 | Existe-t-il un chemin où l'application supprime un portefeuille qui a encore un solde, ou considère « vide » un portefeuille avec des fonds (par erreur de lecture du solde) ? | La suppression et l'offboard valident le solde à toutes les couches (USDC on-chain, ETH et solde sur l'exchange) avant toute action destructive ; sans solde = seule la poussière est supprimable avec acceptation | RageQuitController ; vérifications cross-layer |
| E4 | Que se passe-t-il si l'exchange est hors ligne, si la connexion tombe au milieu d'un ordre ou si la réponse se perd ? L'application peut-elle dupliquer un ordre, dupliquer un prélèvement ou rester dans un état incohérent ? | Les opérations ont un journal durable et une identité idempotente ; un état indéterminé ne duplique ni prélèvement ni retrait | PaymentOperationStore.kt ; HyperliquidOperationStore ; PaymentManager.kt:70-76,198 |
| E5 | Si le processus est tué par le système avec une position ouverte, le stop loss reste-t-il valide sur l'exchange ? L'application réconcilie-t-elle au retour ? | Les stops vivent sur l'exchange et restent valides avec l'application morte ; l'application réconcilie et recrée le stop absent au retour | reconcileStopWithExchange (checkPositions, cycle de 2 min) |
| ID | Déclaration | Vérifiée ? | Effet pour l'utilisateur | Risque assumé |
|---|---|---|---|---|
| DD1 | Adresse des frais non publiée | OUI — constante immuable (AppConfiguration.kt:32), sans setter ; valeur absente de l'application et du site (recherche = 0) |
La destination n'est pas vérifiable par le texte public | Destination non vérifiable par lecture |
| DD2 | Clé du Keystore autonome | OUI — setUserAuthenticationRequired(false) (MultiWalletManager.kt:422) avec contrôle de présence sur les actions manuelles |
Le bot fonctionne avec l'appareil verrouillé ; les actions manuelles exigent une présence | Un appareil rooté expose les seeds ; ce n'est pas un vecteur distant |
| DD3 | Retrait automatique du profit (D12) | OUI — déclencheur 22 USD par événement (ProfitTracker.kt:46) et fraction de 50 % (:52) |
Le profit réalisé au-delà du déclencheur est partiellement retiré vers l'utilisateur lui-même | Dépend de la conservation autonome (D2) |
| DD4 | Sizing 100 % du patrimoine, levier 10–50x | OUI — patrimoine lu en fail-closed (TradingBot.kt:1252-1258), position de 100 % (:1270), levier maximal de l'actif (:1192-1202) |
Positions importantes avec des cibles lointaines ; perte totale possible en cas de retournement violent | Perte totale ou partielle du capital |
Aucune des quatre n'a été classée comme constat, conformément au périmètre. Ce qui a été vérifié, c'est que chacune est implémentée telle que déclarée ; celle qui ne le serait pas serait un constat.
0 constat ouvert (critique, élevé, moyen ou faible).
Notes informatives, sans action obligatoire :
0x2all.xyz est enregistré et en ligne depuis le
20/10/2026 ; le lien de la politique et la carte d'authenticité ouvrent une destination réelle,
et la page publie l'empreinte du certificat et le SHA-256 de l'APK.stillOpen. Revérifié
dans l'arborescence 1.0.19 (0c96c95) et dans celle de la 1.0.20 (6814b8b) : il y a une
seule occurrence (TradingBot.kt:2121-2123), déjà ainsi dans l'édition précédente. La
duplication avait été supprimée avant la 1.0.19 et la note est retirée — aucun effet pour
l'utilisateur.DeviceIntegrity) est heuristique et s'exécute sur l'appareil : Magisk DenyList/Shamiko, un
APK re-signé ou un hook (Frida) renvoient le résultat voulu par l'attaquant. Il vaut pour
l'utilisateur honnête et pour le moment avant le premier dépôt ; il ne remplace pas un appareil
dédié, sans root, avec verrouillage d'écran. Aucune donnée ne quitte l'appareil et aucun
identifiant n'est lu.version.json)./audit/prompt-pt.md ou prompt-en.md) et appliquez-le à l'APK signé :
apksigner verify --print-certs, aapt2 dump badging/xmltree, décompilation du DEX (jadx
ou baksmali) et balayage des hôtes et des adresses 0x dans les DEX.audit.json.ots verify sur les fichiers .ots.fichier:ligne renvoient au source du
commit cité ; en auditant seulement l'APK, on vérifie le comportement et les chaînes du DEX.| Élément | Valeur |
|---|---|
| Commit | 9f69edc (73fe94d et 19209cf = docs/site, même arborescence d'application) |
| Version | 1.0.21 (code 21) |
| APK examiné | 0x2ALL-1.0.21-9f69edc-release.apk |
| SHA-256 de l'APK | 325245a6542212f0227eb7616f9a550bcd0053e5d7c613a66d080c60698bf830 |
| Taille | 6.677.553 octets |
| Certificat (SHA-256) | 53dac6cbe7edd6894b9377c4bbdc302a883abbe18a01ad2bd87d0a0fafa142c1 |
| Signature | v2 + v3, RSA-4096, CN=0x2ALL |
| Permissions | 13 dans l'APK, identiques à celles de la 1.0.20 (diff vide) |
| Hôtes dans le DEX | 12, ensemble identique à celui de la 1.0.20 (diff vide) |
Adresses 0x… dans le DEX |
7, identiques à celles de la 1.0.20 (diff vide) |
| Nouvelles classes dans le DEX | 83 au total ; de domaine : DeviceIntegrity, DeviceIntegrity$Finding, MainActivityKt$DeviceIntegrityGate* — le reste sont des lambdas Compose renumérotées (66 anciennes classes équivalentes ont disparu) |
| Date d'exécution | 21/10/2026 |