demining/pixnapping-attack-on-androidAttaque Pixnapping : compromettre les clés privées et les phrases de récupération via la vulnérabilité CVE-2025-48561 représente une nouvelle menace critique pour le réseau Bitcoin et l'infrastructure Android.
Cet article examine l'évolution des menaces de sécurité dans le domaine du stockage de cryptomonnaies, en se concentrant sur les méthodes modernes de compromission des clés privées et des phrases de récupération, qui sécurisent les portefeuilles numériques. L'écosystème moderne des cryptomonnaies est confronté à une menace croissante de cyberattaques visant à compromettre les clés privées et les phrases de récupération, qui constituent le fondement de la sécurité des portefeuilles numériques. La complexité et la sophistication des attaques, exploitant non seulement le logiciel mais aussi le matériel des appareils mobiles modernes, augmentent chaque année. Parallèlement aux menaces traditionnelles telles que le détournement de presse-papiers, l'enregistrement de frappe, l'usurpation de codes QR et l'exploitation de vulnérabilités dans les implémentations de portefeuilles BIP32/BIP39, les chercheurs identifient de plus en plus de nouvelles façons de compromettre les données cryptographiques stockées sur les smartphones.
Au début d'octobre 2025, des chercheurs de l'Université Carnegie Mellon et de plusieurs universités américaines ont présenté les résultats d'une étude qui a fait sensation dans les communautés scientifiques et cryptographiques. Ils ont découvert une vulnérabilité critique dans le système d'exploitation Android, surnommée « Pixnapping » et enregistrée sous l'identifiant CVE-2025-48561. Cette vulnérabilité permet aux attaquants de reconstruire étape par étape le contenu de l'écran des appareils Android, extrayant ainsi des informations visuelles sensibles, notamment les clés privées, les phrases de récupération , et les codes d'authentification 2FA à usage unique d'applications comme Google Authenticator.
La menace identifiée par les chercheurs repose sur l'interaction profonde entre les couches logicielles et matérielles d'Android—des API système au moteur de compression graphique du GPU. Pixnapping combine les techniques de canal auxiliaire GPU.zip avec l'utilisation légitime des Intents Android et de l'API de flou de fenêtre, permettant une reconstruction furtive pixel par pixel de l'écran. Cette approche transforme un smartphone standard en une source de fuite potentielle d'informations clés utilisées pour gérer les actifs numériques, notamment Bitcoin (BTC), Ethereum (ETH), Litecoin (LTC), XRP et d'autres cryptomonnaies.
Le danger réside dans le fait que l'utilisateur n'a pas besoin d'accorder d'autorisations à l'attaquant—l'application malveillante peut s'exécuter en arrière-plan, restant invisible pour le système de sécurité Android. En conséquence, l'attaquant peut obtenir un accès visuel aux phrases de récupération lors des sauvegardes ou des retraits de portefeuille, ce qui équivaut à un contrôle total sur les actifs cryptographiques de la victime.
La combinaison de telles menaces—des attaques Pixnapping aux fuites matérielles via Rowhammer, Spectre, Meltdown et autres méthodes de canal auxiliaire connexes—souligne la nécessité de repenser les stratégies de sécurité à l'intersection des systèmes d'exploitation mobiles et des technologies financières. Chaque nouvelle vulnérabilité comme CVE-2025-48561 démontre à quel point l'équilibre peut être fragile entre la commodité de l'accès mobile aux cryptomonnaies et la garantie d'une sécurité cryptographique fondamentale.
La transaction décodée 816760531f334651d711909a93a5959e74b3dbe126f50dbb6efb3e7d61f224ba représente une preuve documentée des travaux de recherche, enregistrée dans le registre immuable de la blockchain Bitcoin. Une analyse structurelle de RawTX révèle l'architecture classique d'une transaction Bitcoin version 1, contenant un élément critique—le champ OP_RETURN avec une URL intégrée pointant vers la recherche sur l'attaque Pixnapping.
https://github.com/zoeir/Bitcoin-Message-Transaction
Décomposition de la structure de la transaction :
La transaction utilise une seule entrée (UTXO) provenant de la transaction précédente et crée trois sorties : la première sortie, d'une valeur nulle, contient le message OP_RETURN (77 octets de données), la deuxième sortie transfère 1000 satoshis (0,00001 BTC) à l'adresse du destinataire 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr , et la troisième sortie retourne la monnaie de 22 500 satoshis à l'adresse de l'expéditeur 1G84gkhBsBM9B5Xsqw2s9b6H1oqg4nPEiW . Les frais de transaction sont de 1000 satoshis, ce qui garantit un traitement prioritaire par les mineurs du réseau.
010000000147ac1bf5cff92293f1244c141103dd1ec46ce260f117a8f8df00e6ad0cd4d15a000000008a47304402204f0c3c52b5941993d92e85bda70f93d15b76ad3af6ceab4a1bbb9b33f5432f38022079458bd4071e7c9ab7a3a9d6872083218becb935dbe8eba7862cc30d59db1da10141049a296066ca26625e22c5759a0ed00120e0183b52454b4e6155cd3855bd689f5231497de3552b9a7b976933a803b76632f6f2ac1134acf9af248e697d19a15abbffffffff0300000000000000004d6a4b7777772e626974636f696e6d6573736167652e72752f536f757263655f436f64652f5069786e617070696e675f41747461636b5f746f5f457874726163745f507269766174655f4b657973e8030000000000001976a91412d5a845f2b212ce0c3bd65a4035881d9219090e88ace4570000000000001976a914a5dfdff9f85277310a40d2978fb7040f7af8ca4b88ac00000000
Signature cryptographique et authentification :
Le champ ScriptSig de 138 octets contient une signature ECDSA basée sur la courbe secp256k1, confirmant la possession de la clé privée de l'expéditeur. Cela vérifie la légitimité de la transaction et empêche les dépenses non autorisées. Le message décodé dans OP_RETURN : « www.bitcoinmessage.ru/Source_Code/Pixnapping_Attack_to_Extract_Private_Keys » sert de marqueur permanent sur la blockchain, reliant la transaction à la recherche scientifique sur la vulnérabilité critique.
CVE-2025-48561 est une vulnérabilité critique de haute gravité découverte par une équipe de recherche de l'Université de Californie à Berkeley, de l'UC San Diego, de l'Université de Washington et de l'Université Carnegie Mellon en février 2025. L'attaque Pixnapping démontre une violation fondamentale du modèle de sécurité Android, permettant à une application arbitraire, sans aucune autorisation spéciale, d'effectuer une reconstruction bit à bit du contenu visuel d'autres applications.
Un schéma des trois étapes d'une attaque Pixnapping sur les appareils Android.Pixnapping utilise une combinaison d'API Android et d'un canal auxiliaire matériel GPU (zip) pour extraire des informations visuelles des écrans d'appareils. L'attaque exploite trois mécanismes clés d'Android : la capacité d'envoyer les activités d'autres applications au pipeline de rendu via les Intents Android, l'exécution d'opérations graphiques (flou) sur les pixels d'autres applications, et la mesure des effets secondaires de ces opérations, qui dépendent de la couleur des pixels. cylab.cmu+ 2
Pixnapping est basé sur la vulnérabilité GPU.zip, découverte par le même groupe de recherche en 2023. Cette attaque exploite la compression matérielle des données graphiques dans les GPU modernes, qui dépend des données, est transparente pour le logiciel et présente dans presque tous les GPU modernes. cylab.cmu+ 2
La compression des données graphiques est une optimisation des GPU intégrés (iGPU) qui économise la bande passante mémoire et améliore les performances de rendu des images. L'attaque GPU.zip permet à un site Web malveillant d'extraire des pixels d'iframes dans la dernière version de Google Chrome, violant le modèle de sécurité du navigateur. hertzbleed+ 1
Pixnapping exploite SurfaceFlinger, un processus système Android responsable de l'affichage et de l'agencement des éléments graphiques. L'application malveillante utilise les Intents Android pour lancer des applications ciblées, les amenant à afficher des informations sensibles à l'écran. Une « activité de masquage » est ensuite créée—une superposition translucide qui masque l'application ciblée, ne laissant qu'un seul pixel sélectionné transparent. bleepingcomputer+ 1
L'attaque Pixnapping est réalisée en trois étapes principales, chacune utilisant des API Android et des appels système spécifiques : pixnapping+ 1
Étape 1 : Invocation de l'application cible :
L'application malveillante utilise les Intents Android pour invoquer les activités exportées des applications cibles, telles que Google Authenticator ou Signal. Ce processus amène les informations sensibles (codes 2FA, graines) à s'afficher à l'écran et à être transmises au pipeline de rendu SurfaceFlinger. bleepingcomputer+ 1
Étape 2 : Induction d'opérations graphiques
: Cette étape crée une pile d'activités Android translucides qui utilisent des techniques de masquage, d'augmentation et d'encodage pour manipuler des pixels individuels de la victime. L'attaque utilise l'API de flou de fenêtre Android pour effectuer des opérations graphiques sur les pixels et les rappels VSync pour mesurer les temps de rendu avec une précision suffisante afin d'extraire des valeurs de pixels individuelles. theregister+ 2
Étape 3 : Extraction par canal auxiliaire.
L'étape finale utilise le canal auxiliaire GPU.zip pour voler les pixels traités à l'étape 2, un pixel à la fois. En mesurant les différences de temps de rendu causées par les optimisations GPU dépendantes des motifs, telles que la compression des données d'image, l'attaque peut déterminer les informations de couleur des pixels. gbhackers+ 1
L'API de flou de fenêtre Android, disponible depuis Android 12, offre des capacités pour implémenter des effets de flou de fenêtre. Il existe deux types de flou de fenêtre : le flou d'arrière-plan (crée un effet de verre dépoli) et le flou derrière (floute tout l'écran derrière la fenêtre). source.android
Pixnapping abuse de ces API de la manière suivante :
// Exemple de code utilisé dans l'attaque (conceptuel)
window.setBackgroundBlurRadius(blurRadius);
window.addFlags(WindowManager.LayoutParams.FLAG_BLUR_BEHIND);
WindowManager.LayoutParams.setBlurBehindRadius(blurRadius);
L'attaque crée des activités translucides en utilisant windowIsTranslucent et manipule le canal alpha d'un drawable d'arrière-plan pour isoler des pixels individuels. source.android
Pour mesurer avec précision les temps de rendu, Pixnapping utilise les rappels VSync. VSync (synchronisation verticale) est un signal qui synchronise le taux de trames avec le taux de rafraîchissement de l'écran. Sur Android, cela est implémenté via Choreographer.VsyncCallback. blurbusters+ 1
// Exemple conceptuel d'utilisation des rappels VSync
Choreographer.getInstance().postVsyncCallback(new Choreographer.VsyncCallback() {
@Override
public void onVsync(long frameTimeNanos) {
// Mesure du temps pour extraire la couleur du pixel
measureRenderingTime(frameTimeNanos);
}
});
Les chercheurs ont testé Pixnapping sur cinq appareils fonctionnant sous Android 13-16 : cylab.cmu+ 1
Résultats des tests de vulnérabilité Pixnapping sur divers appareils Android
L'attaque a été la plus efficace sur le Google Pixel 6, avec un taux de réussite de 73 % pour la récupération des codes 2FA. Le Samsung Galaxy S25 a démontré une résistance à l'attaque en raison d'un « bruit important » dans le signal. bleepingcomputer+ 1
Une version optimisée de l'attaque est capable d'extraire les codes 2FA à 6 chiffres de Google Authenticator en moins de 30 secondes. Cette durée s'inscrit dans la période de validité standard de 30 secondes des codes TOTP, ce qui rend l'attaque pratique. cylab.cmu+ 2
Les données plus complexes prennent plus de temps à extraire :
Pixnapping constitue une menace particulière pour les utilisateurs de cryptomonnaies. Les phrases de récupération des portefeuilles restent visibles à l'écran plus longtemps que les codes 2FA temporaires, ce qui les rend vulnérables au balayage de pixels. Bien que la récupération complète de la phrase de récupération de 12 mots prenne un temps considérable, l'attaque reste viable si l'utilisateur laisse la phrase visible à l'écran lorsqu'il la note. currently.att.yahoo+3
Les chercheurs ont fourni plusieurs vidéos démontrant l'attaque Pixnapping :
1. Démo de base Pixnapping
2. Démo technique de Tweakers
Les résultats de la recherche ont été officiellement présentés à la 32e conférence ACM sur la sécurité informatique et des communications (ACM CCS 2025) à Taipei, Taïwan, du 13 au 17 octobre 2025. La présentation comprenait une analyse détaillée des aspects techniques de l'attaque et une démonstration d'exemples pratiques. cylab.cmu+ 2
En date d'octobre 2025, Google et les chercheurs n'ont trouvé aucune preuve d'exploitation de la vulnérabilité Pixnapping dans la nature. Google a déclaré : « Nous n'avons vu aucune preuve d'exploitation dans la nature. » Cependant, cela n'exclut pas la possibilité d'une utilisation clandestine par des attaquants. bleepingcomputer+ 1
Les chercheurs ont identifié plusieurs scénarios potentiels d'exploitation de la vulnérabilité :
1. Vol des codes 2FA.
Le scénario le plus courant consiste à voler les codes d'authentification temporaires de Google Authenticator, Authy et d'autres applications 2FA. Un attaquant peut utiliser les codes volés pour contourner l'authentification à deux facteurs et obtenir un accès non autorisé aux comptes de la victime. cylab.cmu+ 1
2. Compromission des portefeuilles de cryptomonnaies.
Un scénario particulièrement dangereux est le vol des phrases de récupération des portefeuilles Bitcoin et autres cryptomonnaies. Si un utilisateur affiche sa phrase de récupération à l'écran pour l'enregistrer ou la vérifier, une application malveillante peut progressivement extraire la phrase entière, obtenant ainsi un contrôle total du portefeuille. currently.att.yahoo+ 2
3. Interception de la correspondance privée.
L'attaque peut être utilisée pour extraire des messages d'applications de messagerie chiffrée comme Signal, même avec la sécurité d'écran activée. Cela constitue une menace sérieuse pour les utilisateurs qui comptent sur la sécurité du chiffrement de bout en bout. bleepingcomputer+ 1
Bien qu'aucun échantillon de malware spécifique utilisant Pixnapping n'ait été détecté, la technique pourrait être intégrée aux familles de chevaux de Troie Android existantes. Par exemple, la famille de malwares SpyAgent utilise déjà la reconnaissance d'images pour voler les clés mnémoniques, et l'ajout des capacités de Pixnapping pourrait considérablement étendre ses fonctionnalités. currently.att.yahoo+ 1
Une application malveillante effectuant Pixnapping ne nécessite aucune permission à déclarer dans son fichier manifeste Android. Cela la rend impossible à distinguer des applications bénignes lors des contrôles de sécurité des magasins d'applications. pixnapping+ 1
Structure de base du manifeste :
xml:
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
<application>
<activity android:name=".MaliciousActivity">
<!-- Sans déclaration d'aucune permission -->
</activity>
</application>
</manifest>
Un composant clé de l'attaque est l'utilisation des Intents Android pour lancer les applications cibles :
java:
// Exemple conceptuel du code d'activation de l'application cible
Intent intent = new Intent();
intent.setAction("com.google.android.apps.authenticator2.AUTHENTICATE");
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
Les chercheurs ont analysé près de 100 000 applications du Google Play Store et ont trouvé des centaines de milliers d'actions invoquées via les Intents Android, ce qui indique la large applicabilité de l'attaque. bleepingcomputer
Le processus d'extraction des pixels individuels implique la création d'activités translucides avec une configuration spécifique :
java:
// Exemple conceptuel de création d'une activité de masquage
Window window = getWindow();
WindowManager.LayoutParams params = window.getAttributes();
params.alpha = 0.99f; // Presque entièrement transparent
params.flags |= WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE;
window.setAttributes(params);
// Réglage du flou pour induire des opérations graphiques
window.setBackgroundBlurRadius(20);
Après l'extraction des pixels, une technique similaire à la reconnaissance optique de caractères (OCR) est utilisée pour reconstruire le contenu original. L'algorithme analyse les motifs des pixels extraits et reconstruit les caractères et les chiffres. pixnapping+ 1
Google a d'abord tenté de corriger la vulnérabilité dans la mise à jour de sécurité Android de septembre 2025 en limitant le nombre d'activités qu'une application pouvait déclencher avec un flou. La société a noté dans un bulletin de sécurité : « Une application demandant plusieurs flous : (1) permet le vol de pixels en mesurant le temps de flou entre les fenêtres, et (2) est probablement invalide. » bleepingcomputer+ 2
Les chercheurs ont rapidement découvert une solution de contournement qui a restauré l'efficacité de l'attaque en modifiant les caractéristiques de synchronisation. Cette solution de contournement est toujours sous embargo et n'a pas été divulguée publiquement. pixnapping+ 2
Google développe un correctif plus complet, qui sera publié dans le bulletin de sécurité Android de décembre 2025. Cependant, les chercheurs notent qu'un correctif efficace pour Pixnapping nécessitera des modifications des mécanismes fondamentaux d'Android, comme permettre aux applications d'empêcher d'autres applications de superposer leur contenu sensible. cylab.cmu+ 2
Le problème fondamental est que le canal secondaire sous-jacent GPU.zip reste non corrigé. En date d'octobre 2025, aucun fabricant de GPU ne s'est engagé à corriger GPU.zip. Cela signifie que même avec les correctifs Android, la vulnérabilité matérielle reste exposée à de nouvelles méthodes d'attaque. pixnapping+ 1
Samsung a été informé de la vulnérabilité et averti que le correctif de Google était insuffisant pour protéger les appareils Samsung. La société a reconnu le problème mais l'a évalué comme « gravité faible » en raison de la complexité matérielle. currently.att.yahoo+ 2
1. Mises à jour en temps utile :
La recommandation principale des chercheurs est d'installer les correctifs Android dès que possible après leur publication. Les utilisateurs doivent activer les mises à jour de sécurité automatiques et vérifier régulièrement les nouveaux correctifs. cylab.cmu+ 1
2. Utilisation de portefeuilles matériels.
Pour les utilisateurs de cryptomonnaies, la protection la plus efficace consiste à utiliser des portefeuilles matériels. Les portefeuilles matériels stockent les clés privées et les phrases de récupération hors ligne, éliminant ainsi la possibilité de leur compromission par des attaques d'écran à écran. tradingview+ 1
3. Éviter d'afficher des informations sensibles.
Il est conseillé aux utilisateurs d'éviter d'afficher des phrases de récupération ou d'autres données hautement sensibles sur des appareils connectés à Internet. Si le stockage de phrases de récupération est nécessaire, utilisez des appareils hors ligne. currently.att.yahoo+1
1. Protection contre les superpositions :
Les développeurs peuvent implémenter une protection contre les superpositions en détectant lorsque d'autres applications tentent de créer des couches translucides au-dessus des leurs. Cela peut être fait en utilisant bitdefenderWindowManager.LayoutParams.FLAG_SECURE .
2. Minimiser le temps d'affichage.
Les informations critiques doivent être affichées à l'écran pendant la durée la plus courte possible. Par exemple, les codes 2FA peuvent être automatiquement masqués après de courts intervalles. bitdefender
3. Détection d'activités anormales :
Les applications peuvent surveiller les schémas d'activité anormaux, tels que les appels fréquents à l'API de flou ou les comportements de superposition inhabituels. bitdefender
1. L'amélioration des autorisations Android peut nécessiter des autorisations spéciales pour accéder à l'API de floutage et à d'autres opérations graphiques qui peuvent être exploitées lors d'attaques. cylab.cmu
2. Isolation des applications
Le renforcement de l'isolation entre les applications peut empêcher d'autres applications d'accéder aux pixels via des opérations graphiques. bitdefender
3. Solutions matérielles
Une solution à long terme peut nécessiter des modifications au niveau du GPU pour éliminer le canal secondaire GPU.zip. pixnapping+1
Dans le contexte de l'attaque Pixnapping (CVE-2025-48561), qui exploite les mécanismes matériels et logiciels d'Android pour intercepter visuellement les phrases de récupération et les clés privées, il est essentiel de considérer un vecteur d'attaque supplémentaire opérant à un niveau matériel plus fondamental. L'attaque Phoenix Rowhammer (CVE-2025-6202) représente une nouvelle génération d'exploitation des propriétés physiques de la mémoire DRAM, permettant aux attaquants de manipuler des bits de données individuels dans la mémoire DDR5, y compris les structures de données cryptographiques critiques des portefeuilles Bitcoin. github+ 4
Une étude conjointe du Computer Security Group (COMSEC) de l'ETH Zürich et de Google, publiée en septembre 2025, a démontré que la mémoire DDR5 de SK Hynix—le plus grand fabricant mondial de DRAM—reste vulnérable aux attaques Rowhammer malgré la mise en œuvre de mécanismes avancés de protection Target Row Refresh (TRR). Phoenix représente la première attaque Rowhammer au niveau système capable de contourner tous les schémas TRR modernes déployés dans les dispositifs DDR5 grâce à une technique révolutionnaire de synchronisation auto-correctrice. linkedin+ 7
Rowhammer est une vulnérabilité matérielle de la mémoire vive dynamique (DRAM) qui découle des limitations physiques de la technologie moderne de fabrication des puces mémoire. À mesure que les normes de fabrication de la DRAM diminuent (à 10 nm, 7 nm et en dessous), la distance physique entre les cellules mémoire individuelles diminue considérablement, entraînant une augmentation des interférences électromagnétiques entre les rangées de mémoire adjacentes. kaspersky+ 6
Mécanisme d'induction de basculement de bits :
Chaque cellule DRAM est un condensateur stockant une charge électrique correspondant à une valeur logique de 0 ou 1. Pour lire ou écrire des données dans une rangée de mémoire spécifique, une opération ACTIVATE est effectuée, qui élève le niveau de tension de la rangée cible (rangée agressive/rangée cible) à un niveau élevé tandis que les rangées voisines (rangées victimes) restent à un niveau de tension faible. L'activation répétée de la même rangée de mémoire en succession rapide crée des interférences électromagnétiques, qui accélèrent la décharge des condensateurs dans les rangées voisines, pouvant potentiellement conduire à des changements spontanés des valeurs de bits (basculements de bits) avant le prochain cycle de rafraîchissement. tomshardware+ 6
Modèle mathématique de la dégradation de charge :
Les recherches montrent que la probabilité d'un basculement de bit PflipP_{flip}Pflip dans une rangée victime dépend du nombre d'activations de la rangée agressive NactN_{act}Nact, du temps entre les opérations de rafraîchissement tREFt_{REF}tREF, et de la distance entre les cellules dcelld_{cell}dcell :
où VaggrV_{aggr}Vaggr est la tension d'activation de la rangée agressive. Les modules DDR5 modernes nécessitent des commandes de rafraîchissement toutes les 3,9 µs en moyenne par défaut, soit deux fois plus souvent que la DDR4, précisément pour contrer l'effet Rowhammer croissant. arxiv+ 4
DDR4 TRR : Protection de première génération
À partir de la DDR4, les fabricants de DRAM ont mis en œuvre le mécanisme Target Row Refresh (TRR)—un ensemble de compteurs matériels et de logique intégrés directement dans les puces DRAM pour détecter les schémas d'accès mémoire suspects. TRR fonctionne sur la base de deux paramètres clés : le Maximum Activate Count (MAC)—le nombre maximal d'activations de rangée—et la Maximum Activate Window (t~MAW~)—la fenêtre temporelle pendant laquelle les activations sont comptées. csdn+4 youtube
Lorsque le nombre d'activations d'une rangée particulière atteint le seuil MAC dans une fenêtre temporelle t~MAW~, TRR initie automatiquement une opération de rafraîchissement pour les rangées victimes adjacentes, empêchant les basculements de bits. Cependant, l'étude TRRespass (2020) a démontré une vulnérabilité critique de ce schéma : le mécanisme TRR utilise l'échantillonnage —surveillant uniquement un sous-ensemble limité de rangées de mémoire, plutôt que toutes les rangées simultanément. L'attaque Many-Sided Rowhammer exploite cette limitation en activant simultanément plusieurs rangées agressives (jusqu'à 19 dans certains cas), ce qui surcharge le mécanisme d'échantillonnage TRR et permet aux rangées « non surveillées » de continuer à marteler sans être contrecarrées par les opérations de rafraîchissement. usenix+4 youtube
DDR5 TRR amélioré : Protection de deuxième génération renforcée
La DDR5 a introduit des circuits TRR en-DRAM considérablement améliorés avec des algorithmes de détection et de contre-mesure plus sophistiqués. Les fabricants ont mis en œuvre des commandes de rafraîchissement plus fréquentes (toutes les 3,9 µs contre 7,8 µs en DDR4), un code de correction d'erreurs (ECC) intégré sur puce, et des mécanismes de suivi d'activation plus avancés. Avant la publication de Phoenix en septembre 2025, on pensait que la DDR5 démontrait une résistance accrue aux attaques Rowhammer dans les environnements de production, et « de manière inattendue, la DDR5 y parvient sans commandes de contrôle de rafraîchissement supplémentaires ». comsec-files.ethz+5
Le problème de la synchronisation et le mécanisme auto-correcteur
Une découverte clé des chercheurs de l'ETH Zürich est que les méthodes de synchronisation actuelles les plus avancées manquent régulièrement les commandes de rafraîchissement, ce qui les rend inadaptées aux attaques Rowhammer efficaces sur la DDR5. Phoenix résout ce problème avec deux techniques révolutionnaires : securityweek+ 2.
La première technique : la division des threads. Le martèlement et les accès de synchronisation sont répartis dans différents threads d'exécution pour améliorer la détection du rafraîchissement. Bien qu'il s'agisse d'une amélioration par rapport à l'état de l'art, cette approche ne peut toujours pas maintenir la synchronisation sur un nombre suffisamment grand d'intervalles de rafraîchissement, empêchant l'induction de basculements de bits. github+ 1
La deuxième technique est la synchronisation auto-correctrice. Au lieu d'essayer d'empêcher les commandes de rafraîchissement manquées, Phoenix détecte un rafraîchissement manqué et resynchronise l'exécution du schéma en conséquence. Cette technique permet à Phoenix de rester synchronisé avec les commandes de rafraîchissement pendant des fenêtres de rafraîchissement entières, ce qui est suffisant pour induire des basculements de bits avec de nouveaux schémas. security.googleblog+ 4
Modèle mathématique de la synchronisation auto-correctrice :
Contournement du TRR en exploitant les angles morts
Phoenix exploite les angles morts du mécanisme TRR—des fenêtres temporelles et spatiales où la surveillance des activations de rangées est affaiblie. Les chercheurs ont découvert que l'échantillonneur TRR doit échantillonner de manière cohérente les accès au même ensemble de rangées, permettant aux accès (non échantillonnés) à d'autres rangées de continuer à marteler sans l'intervention des opérations de rafraîchissement TRR. Phoenix synchronise les schémas d'accès avec les commandes de rafraîchissement afin que les rangées victimes soient en dehors de la zone de surveillance TRR active à des moments critiques. vusec+ 7
Configuration de test et dispositifs concernés
Les chercheurs de l'ETH Zurich ont testé Phoenix sur 15 modules UDIMM DDR5 fabriqués par SK Hynix, produits entre 2021 et 2024. Tous les dispositifs testés ont démontré une vulnérabilité à Phoenix, induisant avec succès des basculements de bits en quelques secondes sur chaque module. Les tests ont été menés sur une plateforme avec un processeur AMD Zen 4 et des plateformes de test Rowhammer spécialisées basées sur FPGA développées conjointement avec Antmicro. theregister+ 8
Уязвимость CVE-2025-6202 зарегистрирована с базовым CVSS-скором 7.1 (High severity). Description de la vulnérabilité : « Vulnérabilité dans SK Hynix DDR5 sur x86 permettant à un attaquant local de déclencher des basculements de bits Rowhammer impactant l'intégrité matérielle et la sécurité du système. Ce problème affecte la DDR5 : les DIMM produites de 2021-1 à 2024-12 ». thehackernews+5
Liste des processeurs AMD concernés avec prise en charge DDR5 : amd
Processeurs AMD EPYC 8004, 9004, 9005 Series ; AMD EPYC 9004, 9005 Embedded Series ; AMD Ryzen 6000, 7000, 7035, 7040, 7045, 8000, 8040, 9000 Series ; AMD Ryzen 9000HX Series ; AMD Ryzen AI 300, AI Max 300 Series ; AMD Ryzen Threadripper 7000, 9000 ; AMD Ryzen Embedded 7000, 8000, 9000 Series.amd
Scénarios d'attaque pratiques et caractéristiques temporelles
Les chercheurs ont démontré trois scénarios d'exploitation de bout en bout pour Phoenix : techradar+ 5
1. Manipulation des entrées de table de pages (PTE) pour l'élévation de privilèges : Phoenix effectue avec succès des basculements de bits sur les entrées de table de pages avec un taux de réussite de 100 %, obtenant un accès non autorisé aux zones mémoire restreintes. Cela permet à un attaquant local sans privilèges de modifier sa propre table de pages, obtenant un accès en lecture-écriture à toute la mémoire physique du système. pmc.ncbi.nlm.nih+ 4
2. Extraction de clés SSH depuis des machines virtuelles : Phoenix démontre un taux de réussite de 73 % dans l'extraction de clés SSH privées RSA-2048 depuis une machine virtuelle colocalisée sur le même serveur physique. Il s'agit d'une menace critique pour les environnements de cloud computing où plusieurs VM partagent la même mémoire physique. kaspersky+ 5
3. Élévation de privilèges vers root via la manipulation du binaire sudo : Phoenix atteint une probabilité de 33 % d'obtenir un accès root via la manipulation du binaire en mémoire de sudo. L'élévation complète de privilèges vers root sur un système standard avec les paramètres par défaut est réalisée en environ 109 secondes (moins de 2 minutes). linkedin+5
Fondements théoriques d'une attaque par injection de fautes ECDSA
L'algorithme de signature numérique à courbe elliptique (ECDSA) est une primitive cryptographique fondamentale dans Bitcoin, fournissant l'authentification des transactions et la preuve de propriété des actifs numériques. La clé privée dans ECDSA est une valeur scalaire ddd (256 bits pour secp256k1), à partir de laquelle la clé publique est calculée : Q = d⋅GQ = d \cdot GQ = d⋅G, où GGG est le point de base de la courbe elliptique. digital.wpi+ 7
Structure de la signature ECDSA :
Pour un message mmm avec un hachage h=H(m)h = H(m)h=H(m), la signature consiste en la paire (r,s)(r, s)(r,s), où :
où kkk est un nonce aléatoire, nnn est l'ordre du groupe de points sur la courbe secp256k1. securityboulevard+ 4
Attaque par injection de fautes via des basculements de bits induits par Rowhammer
La recherche Rubber Mallet (arXiv:2505.01518, mai 2025) a démontré que les techniques Rowhammer avancées peuvent induire des basculements de bits adjacents multiples à un taux significativement plus élevé que ce qui était documenté précédemment. De manière critique, ces basculements corrélés permettent des attaques efficaces de correction de signatures cryptographiques, démontrant comment de tels basculements peuvent permettre la récupération de clés privées ECDSA à partir d'implémentations OpenSSL où les approches à bit unique seraient irréalisables. arxiv+ 2
Mécanisme d'attaque par basculement de bits sur une clé privée :
Supposons qu'un attaquant puisse induire un basculement de bit dans le bit le moins significatif (LSB) de la clé privée ddd stockée en RAM avant l'opération de signature. Un basculement de bit dans le LSB conduira à l'un des deux résultats : trailofbits+ 2
Cas 1 : Bit 0 → 1, ce qui équivaut à d′=d+1d’ = d + 1d′=d+1
Cas 2 : Bit 1 → 0, ce qui équivaut à d′=d−1d’ = d − 1d′=d−1
Une signature créée avec la clé modifiée d′d’d′ peut être vérifiée en utilisant la clé publique modifiée :
Un attaquant génère une signature avec une clé privée inversée, puis vérifie la vérification de la signature en utilisant Q + GQ + GQ + G et Q − GQ − GQ − GQ − G. Si la signature se vérifie avec Q + GQ + GQ + G, le bit d'origine était 0 ; si avec Q − GQ − GQ − G, le bit était 1. En répétant ce processus pour d'autres positions de bits (inversant les bits aux positions 20, 21, 22, …, 2255 2^0, 2^1, 2^2, …, 2^{255} 20, 21, 22, …, 2255 et en vérifiant avec Q ±2i⋅GQ \pm 2^i \cdot GQ ±2i⋅G), l'attaquant peut reconstruire bit par bit la clé privée entière ddd. arxiv+ 5
Démonstration expérimentale sur OpenSSL ECDSA
Dans l’article de Kwong et al. (arXiv:2505.01518), les chercheurs ont démontré avec succès l’extraction de bout en bout de clés privées ECDSA d’une implémentation OpenSSL via des basculements de bits Rowhammer. Les expériences ont été menées sur plusieurs configurations de mémoire DDR4 (Corsair Vengeance, G.SKILL Ripjaws) à l’aide des outils Rowhammer TRRespass et BlackSmith. Une découverte critique est la fréquence élevée de basculements de bits localisés —plusieurs basculements de bits regroupés dans la même rangée de mémoire DRAM. arxiv+ 2
Une étude de Rahman et al. (2023) (digital.wpi.edu) a démontré une attaque sur la récupération de clés secrètes ECDSA dans une mémoire Samsung M378B5773DH0-2GB via une injection de fautes dans un serveur TLS. Les chercheurs ont initié 29 918 connexions au serveur en injectant des fautes dans la mémoire du serveur et ont collecté avec succès des signatures fautives pour récupérer la clé privée. Même si la taille de la clé ECDSA de 256 bits est nettement inférieure à la taille de page mémoire de 32 768 bits (la plupart des bits basculés se trouvent en dehors de la clé), l’attaque reste réussie avec un nombre suffisant de tentatives. digital.wpi
Stockage des clés privées dans la RAM et vecteurs d’attaque
Les portefeuilles Bitcoin, qu’ils soient logiciels ou certains matériels, chargent inévitablement les clés privées dans la RAM lors d’opérations critiques : signature de transactions, initialisation du portefeuille, dérivation de clés à partir de phrases de récupération et déchiffrement des fichiers wallet.dat. Même lors de l’utilisation du chiffrement AES-256-CBC pour protéger wallet.dat (comme dans Bitcoin Core), la clé privée doit être temporairement déchiffrée et stockée dans la RAM pour signer une transaction. cryptodeeptech+ 6
Modèle de menace pour les attaques Rowhammer sur les portefeuilles Bitcoin :
Scénario 1 : Attaquant local sur un système de bureau. L’attaquant exécute une application malveillante sur le même ordinateur que le portefeuille Bitcoin de la victime. Le processus malveillant induit des basculements de bits Rowhammer dans les régions mémoire où Bitcoin Core ou un autre portefeuille stocke les clés privées déchiffrées pendant les opérations de signature. Phoenix a démontré la capacité de lire et d’écrire des données arbitraires à partir d’une mémoire haute précision sur les systèmes DDR5. github+ 9
Scénario 2 : Attaque de co-localisation cloud/VPS. De nombreux utilisateurs de nœuds et portefeuilles Bitcoin hébergent leurs services sur des serveurs privés virtuels (VPS) sur des plateformes cloud. Phoenix a démontré un taux de réussite de 73 % pour l’extraction de clés SSH RSA-2048 à partir d’une machine virtuelle co-localisée. Une attaque similaire pourrait cibler les clés privées Bitcoin stockées dans la mémoire d’une machine virtuelle exécutant un nœud Bitcoin Core ou d’autres services de portefeuille. tomshardware+ 5
Scénario 3 : Rowhammer sur les appareils Android pour les portefeuilles Bitcoin mobiles. La combinaison de Pixnapping (CVE-2025-48561) et de variantes potentielles de Rowhammer pour les LPDDR4/LPDDR5 mobiles crée une menace multicouche. Bien que Phoenix soit spécifique aux DDR5 de bureau, les recherches montrent que la LPDDR4 inclut également des mécanismes TRR et est potentiellement vulnérable à des attaques Rowhammer adaptées. wikipedia+ 1
Modèle mathématique pour extraire une clé privée Bitcoin via des basculements de bits :
Supposons qu’une clé privée Bitcoin de 256 bits ddd soit stockée en mémoire à l’adresse AkeyA_{key}Akey. Un attaquant Rowhammer peut induire un basculement de bit au bit iii (où 0≤i≤2550 \le i \le 2550≤i≤255), modifiant la clé en d′=d⊕2id’ = d \oplus 2^id′=d⊕2i (XOR avec 2i2^i2i). Pour récupérer la clé d’origine, l’attaquant collecte de nombreuses signatures fautives {(rj,sj)}\{(r_j, s_j)\}{(rj,sj)}, chacune créée avec une version différente de la clé à bits basculés dj′d_j’dj′.
En utilisant des méthodes d’attaque par réseau euclidien (par exemple, le solveur du problème du nombre caché), un attaquant peut récupérer ddd avec une probabilité de succès :
où PflipP_{flip}Pflip est la probabilité de basculer avec succès le bit souhaité, NsamplesN_{samples}Nsamples est le nombre de signatures fautives collectées. pmc.ncbi.nlm.nih+ 3
ATTACKSAFE SOFTWARE et outil rowhammer_attack
L’écosystème de sécurité des cryptomonnaies comprend des programmes spécialisés pour analyser les vulnérabilités liées à Rowhammer. Le dépôt GitHub demining/Rowhammer-Attack démontre l’application pratique de l’analyse différentielle de fautes de signature pour ECDSA afin de dériver des clés privées à partir de transactions dans cinq portefeuilles Bitcoin différents .
Exemple pratique d’utilisation :
./attacksafe -tool rowhammer_attack -open RawTX.txt -save SecretKey.txtL’outil analyse les transactions Bitcoin RawTX et extrait les paramètres de signature ECDSA (r,s)(r,s)(r,s). Si un motif indiquant une signature fautive ou une réutilisation de nonce est détecté, l’outil applique des techniques cryptanalytiques pour récupérer la clé secrète KKK (nonce) ou la clé privée ddd. github
Exemple d’extraction réussie : github
Deployments ECDSA:
SecretKey = 0xe5fa9dccef88781e25e77bd1ea7830c0b33c57481b79007cda117da8139ea7c3
RawTX = 010000000104118e34a0d3c06c842d14707ed5f333d3ba1d35240086a4b5738a2fa810abec1d0000006a473044022004b1d0c7d278439811c27d9ff06b3bb0fd20d5cc90d97083266bdba7d0693bb20220282c6cea6b9ad6f4633596204ebad4716e2a086090faf62a6908bf63a1724ad501210335a395eca8191c43ccee4d91e98b9baef39476d7482cf636e5b71975c69feebdffffffff014e020000000000001976a914154813f71552c59487efa3b16d62bfb009dc5f1e88ac00000000Le libellé « Deployments ECDSA » indique une vulnérabilité critique dans la transaction de la blockchain Bitcoin. La clé secrète « K » au format HEX représente le nonce utilisé pour générer la signature. github
Plateformes de test Rowhammer open source basées sur FPGA
Google et l’ETH Zürich ont développé des plateformes de test open source spécialisées basées sur FPGA pour analyser les vulnérabilités Rowhammer des DDR5. En partenariat avec Antmicro, deux plateformes ont été créées : security.googleblog
Plateforme DDR5 RDIMM : Nouvelle carte de test DDR5 Tester pour tester la mémoire RDIMM (Registered DIMM), couramment présente dans les serveurs. security.googleblog
Plateforme SO-DIMM : Une version prenant en charge les brochages SO-DIMM standard, compatible avec les barrettes mémoire DDR5 SO-DIMM du commerce courantes dans les stations de travail et les appareils grand public. security.googleblog
Ces plateformes sont disponibles sur GitHub (comsec.ethz.ch/phoenix) et permettent aux chercheurs en sécurité de mener une analyse détaillée de la susceptibilité au Rowhammer de diverses configurations DRAM. comsec.ethz+1
Augmentation du taux de rafraîchissement : un compromis entre sécurité et performances
Les chercheurs de Phoenix recommandent d’augmenter le taux de rafraîchissement d’un facteur 3 (de 3,9 µs à ~1,3 µs) comme contre-mesure efficace. Cependant, cela entraîne une baisse de performances de 8,4 % , ce qui représente un compromis significatif pour les systèmes de production. De manière critique, les dispositifs DRAM ne peuvent pas être corrigés via des mises à jour du micrologiciel — la nature matérielle de la vulnérabilité signifie que les modules concernés resteront vulnérables pendant tout leur cycle de vie. techradar+ 5
Efficacité limitée de l’ECC et de l’ECC sur puce
Phoenix a prouvé que le code de correction d’erreurs (ECC) sur puce intégré aux DDR5 n’arrête pas Rowhammer . L’ECC sur puce est conçu pour corriger les erreurs sur un seul bit et certaines erreurs multi-bits provenant de la dégradation naturelle des cellules DRAM. Cependant, Rowhammer peut induire plusieurs basculements de bits corrélés dans la même région mémoire, dépassant la capacité de correction de l’ECC. reddit+ 7
Impossibilité de correctifs matériels rétrospectifs
Contrairement aux vulnérabilités logicielles qui peuvent être corrigées avec des correctifs de sécurité, Rowhammer représente un problème physique fondamental de l’architecture DRAM. En date d’octobre 2025, aucun fabricant de GPU ou de DRAM ne s’est engagé à corriger la vulnérabilité matérielle au niveau de la conception des puces. Cela signifie que des milliards d’appareils utilisant la mémoire concernée resteront potentiellement vulnérables pendant des années. pixnapping+12
Stratégie de sécurité multicouche pour les détenteurs de cryptomonnaies :
1. Portefeuilles matériels avec mémoire isolée. Utilisez des portefeuilles matériels (Ledger, Trezor, BC Vault One) avec mémoire ferroélectrique (FeRAM) ou éléments sécurisés qui isolent les clés privées de la DRAM principale du système. BC Vault One utilise la FeRAM pour stocker la clé privée, offrant une isolation physique contre les attaques Rowhammer sur la mémoire système. youtube itnext+ 3
2. Évitez de stocker de grandes quantités dans des portefeuilles chauds sur les systèmes DDR5. Les utilisateurs exécutant Bitcoin Core ou d’autres portefeuilles logiciels sur des systèmes SK Hynix DDR5 (2021-2024) devraient minimiser leur exposition en déplaçant leurs actifs principaux vers un stockage à froid. github+ 3
3. Isolez les opérations de signature dans des environnements air-gapped. Pour les transactions de grande valeur, utilisez la signature hors ligne sur des systèmes isolés qui ne se connectent jamais au réseau et n’exécutent pas de code non fiable. itnext+ 2
4. Audit régulier de la mémoire et détection d’anomalies. Surveillez la mémoire système pour détecter des schémas d’accès suspects caractéristiques des attaques Rowhammer (activations de rangées à haute fréquence, schémas de rafraîchissement anormaux). pmc.ncbi.nlm.nih+ 3
5. Passez à des systèmes corrigés lorsqu’ils sont disponibles. Bien qu’un correctif matériel ne soit pas possible, les futures puces DDR5 (post-2024) pourraient inclure des mécanismes TRR améliorés. Les utilisateurs devraient surveiller les bulletins de sécurité des fabricants de DRAM et mettre à jour leur matériel lorsque des modules plus sécurisés sont publiés. github+4
La combinaison des attaques Pixnapping (CVE-2025-48561) et Phoenix Rowhammer (CVE-2025-6202) démontre une évolution critique du paysage des menaces pour la sécurité des cryptomonnaies. Pixnapping attaque la couche matérielle et logicielle d’Android via les canaux auxiliaires GPU.zip et l’API de floutage de fenêtres pour intercepter visuellement les phrases de récupération. Phoenix attaque la couche physique fondamentale de la DRAM par induction d’interférences électromagnétiques, permettant une manipulation directe des bits des clés cryptographiques en mémoire. bleepingcomputer+ 10
Les deux attaques contournent les protections logicielles traditionnelles en exploitant les caractéristiques matérielles des appareils qui ne peuvent pas être corrigées. Pour les utilisateurs de Bitcoin, cela signifie qu’une refonte fondamentale du modèle de menace est nécessaire : la sécurité cryptographique n’est plus garantie uniquement par la complexité mathématique de l’ECDSA ou la fiabilité des phrases de récupération — les propriétés physiques du matériel deviennent la surface d’attaque critique. arxiv+ 9
La récupération de clés privées à partir de portefeuilles Bitcoin perdus en exploitant ces vulnérabilités représente à la fois une tâche légitime pour les services de récupération et un vecteur d’attaque dangereux pour les attaquants. L’avenir de la sécurité des cryptomonnaies nécessite une approche holistique intégrant des garanties de sécurité au niveau matériel, des implémentations cryptographiques à vérification formelle et une surveillance continue des menaces émergentes par canaux auxiliaires. trailofbits+ 7
La vulnérabilité Pixnapping représente une évolution significative des attaques mobiles, démontrant comment les optimisations de performances modernes peuvent être exploitées. L’attaque est particulièrement dangereuse pour les utilisateurs de cryptomonnaies, car la compromission de la phrase de récupération peut entraîner la perte complète des fonds. gbhackers
La nature fondamentale des vulnérabilités exploitées — l’utilisation d’API Android légitimes et d’optimisations matérielles GPU — indique qu’une solution complète nécessitera un effort coordonné de Google, des fabricants d’appareils et des fournisseurs de GPU. pixnapping+ 1
La recherche de Pixnapping souligne l’importance critique de prendre en compte les implications de sécurité lors de la mise en œuvre de nouvelles fonctionnalités système et d’optimisations matérielles. Alors que les appareils mobiles deviennent l’outil principal de gestion des actifs numériques, la protection contre de telles attaques sophistiquées devient vitale pour la sécurité de l’écosystème.
Le correctif de décembre de Google devrait offrir une protection plus robuste, mais une solution à long terme nécessitera des changements fondamentaux dans l’architecture d’Android et éventuellement dans le matériel GPU. En attendant, les utilisateurs devraient suivre les recommandations de sécurité et faire preuve d’une prudence particulière lors de la gestion des actifs en cryptomonnaies sur les appareils Android.
Ainsi, la vulnérabilité Pixnapping (CVE-2025-48561) n’est pas simplement un autre exemple de défaut logiciel, mais une démonstration d’une classe fondamentalement nouvelle d’attaques qui menacent les fondements de la sécurité cryptographique des actifs numériques. L’étude a montré que même les éléments visuellement inviolables de l’interface utilisateur Android peuvent devenir une source de fuite de données critique — des clés privées et phrases de récupération aux codes 2FA à usage unique qui protègent les portefeuilles de cryptomonnaies. Essentiellement, chaque pixel de l’écran devient un maillon faible de la chaîne d’authentification cryptographique.
Pixnapping est particulièrement dangereux en raison de sa discrétion et de sa polyvalence . L’attaque ne nécessite aucun privilège, échappe à l’utilisateur et est capable de reconstruire l’image de l’écran jusqu’aux pixels individuels en utilisant le canal auxiliaire matériel GPU.zip . Cela fait de tout appareil Android une source potentielle de compromission de données sensibles, y compris Bitcoin (BTC), Ethereum (ETH), XRP, Litecoin (LTC), et d’autres cryptomonnaies stockées dans des portefeuilles mobiles.
Le fait que cette attaque fonctionne même avec les dernières versions d’Android et les GPU modernes souligne une vulnérabilité fondamentale dans l’architecture des systèmes mobiles , où les optimisations de performances et visuelles entrent en conflit avec les exigences de confidentialité. Pixnapping brise l’illusion d’isolation visuelle entre les applications, démontrant que la protection des informations cryptographiques doit prendre en compte non seulement les vulnérabilités réseau et logiques, mais aussi les effets physiques et graphiques secondaires du calcul .
Pour garantir la stabilité de l’écosystème des cryptomonnaies, des mesures systémiques sont nécessaires : renforcer les politiques de sécurité d’Android, restreindre l’accès des applications tierces aux API graphiques de bas niveau et réviser les principes architecturaux de compression des données GPU. Sans ces barrières, même les algorithmes de chiffrement les plus sécurisés peuvent être vulnérables à des attaques capables de voler des clés littéralement depuis l’écran.
En fin de compte, Pixnapping a servi d'avertissement sérieux à toute l'industrie : la protection cryptographique n'a aucun sens sans isolation matérielle et visuelle . Si les données visuelles affichées à l'écran peuvent être reconstruites par un processus externe, alors chaque animation à l'écran, chaque phrase de récupération ou code QR devient un canal direct de fuite de fonds. Pour les utilisateurs de cryptomonnaies, cela signifie une chose : même l'apparition instantanée d'une clé privée à l'écran peut désormais leur coûter la totalité de leur capital numérique.
Ce matériel a été créé pour le portail CRYPTO DEEP TECH afin de garantir la sécurité des données financières et la cryptographie à courbe elliptique (secp256k1) contre les signatures ECDSA faibles dans la cryptomonnaie BITCOIN . Les développeurs de logiciels ne sont pas responsables de l’utilisation de ce matériel.
Telegram : https://t.me/cryptodeeptech
Vidéo : https://youtu.be/qZvJUonp228
Tutoriel vidéo : https://dzen.ru/video/watch/68ff42ad9f0528014a4b1cf8
Source : https://cryptodeeptech.ru/phoenix-rowhammer-attack