Le développeur kmx360 propose une mise à jour de l'exploit Xbox360BadUpdate proposé à l'origine par grimdoomer, le développeur kmx360 forke donc la solution originale en proposant une amélioration de la vitesse et du taux de réussite du stage 3, de façon importante.
Comme vous le savez Bad Update est un programme d'exploitation non persistant pour l'hyperviseur de la Xbox 360 qui fonctionne sur la dernière version du logiciel (17559). Il peut être utilisé pour exécuter du code non signé sur Xbox 360, en utilisant une vulnérabilité dans l'hyperviseur, avec le jeu Tony Hawk's American Wasteland (NTSC).
Les améliorations de kmx360 sont expliquées dans un billet spécifique :
Il s’agit d’une évolution élaborée pour améliorer la vitesse et le taux de réussite du stage 3.
Au lieu d'enregistrer le texte chiffré de l'oracle + le remplacement pour une seule valeur de blanchiment, je précalcule ceci pour essentiellement toutes (ou presque toutes) les valeurs de blanchiment possibles.
Ensuite, dans le thread d'écrasement, au lieu de faire l'écrasement si un texte chiffré spécifique correspond, je peux faire une recherche et si je trouve _un_ texte chiffré correspondant, je peux faire l'attaque.
J'ai néanmoins réussi à remporter la condition de concurrence avec la boucle d'écrasement plus lente en créant une table de correspondance indexée par certains bits du texte chiffré (j'appelle cela une « pseudo-table de hachage » dans le code). Avec ce schéma, une correspondance se résume à un chargement unique qui devrait toujours atteindre le cache L2. Avec un nombre soigneusement choisi de bits du texte chiffré, je peux intégrer cette table dans le cache du processeur et y conserver la quasi-totalité des paires texte chiffré + remplacement.
Je n'ai pas encore réussi à éliminer les plantages, mais même sans cela, le taux de réussite est d'environ 80 %, chaque exécution à partir du stage 3 prenant environ 15 secondes. Ces résultats sont basés sur mes propres tests et sur une preuve de concept préliminaire partagée avec les utilisateurs du serveur Discord Xbox 360 Hub, qui ont obtenu des résultats similaires.
Ma théorie sur les plantages actuels est que les deux threads se désynchronisent (mais cela n'a pas encore fait l'objet d'une vérification approfondie) :
- l'ovewriter détectant une correspondance canari et écrivant le remplacement correspondant, et effectuant l'écrasement du texte chiffré
- mais à ce moment-là, l'autre thread voit cette valeur, il se trouve sur une itération différente du payload XKE et ce texte chiffré n'est plus valide.
- l'écriture d'un texte chiffré non valide entraîne la lecture par le HV d'un pointeur indésirable et l'écriture des données LZX décompressées à cet endroit, ce qui entraîne une erreur.
Je publie ceci pour lancer une discussion sur la possibilité de l'upstreamer ou de poursuivre le développement via un fork. J'ai également apporté quelques modifications au code à mon goût au cours du développement, donc je n'ai malheureusement pas de delta minimal qui contienne simplement la nouvelle stratégie de recherche de texte chiffré. De plus, je développe ce code uniquement avec un compilateur C et un éditeur de liens personnalisé que j'ai écrit en Go ; je ne dispose donc pas de fichier ASM intermédiaire à fournir.
A noter que la même stratégie pourrait également être utilisée pour que le stage 2 prenne moins de 50 ms, le développeur a créé un PoC en C, mais il ne l'a pas encore converti en chaîne ROP. Les améliorations sont excellentes, et se retrouve compilée ici.
Téléchargement : Xbox360BadUpdate
