Après avoir utilisé le XorHack pendant un moment, j'ai réalisé qu'il manquait quelques choses donc j'ai décidé qu'il était temps pour une update. De nouvelles "syscalls" ont été ajoutées pour donner un contrôle plus fin sur l'accès aux données, fournissant maintenant 8, 16, 32 et 64 bits en lecture et écriture. Aussi de nouveaux "ioctls" ont été ajoutés pour fournir au code de l'espace utilisateur des fonctions additionnelles intéressantes. Enfin, de nouvelles applications pour l'espace utilisateur ont été ajoutées pour vous donner la possibilité de lire, écrire et éxécuter de la mémoire depuis une ligne de commande.
L'Exploit Hyperviseur Change
Quelques syscalls ont été ajouté à l'hyperviseur quand initialement ils exploitaient la ps3. Ils utilisent un numérotation différente de Syscall du précédent exploit afin de les regrouper tous ensemble évitant ainsi les dispersions. Cela devrait rendre le suivit plus pratique. Il y a maintenant 9 Syscalls à exploiter qui sont ajoutés à la PS3 . Ils sont ajouté comme les syscalls 32 à 40 inclus. Précédement les syscall 16 et 20 étaient utilisé pour "64Bits peek" et "64bits poke", ils ne sont dorénavant plus installé.
Le Module Kernel Module Change
Dans le niveau intermédiaire j'ai ajouté le support de l'interfaçage pour les 9 nouvelles "syscalls" ainsi qu'un nouvel "ioctl" pour laisser les applications de l'utilisateur convertir les adresses des "lpar" en adresses réelles et encore un autre pour laisser les applications de l'utilisateur effectuer une "ioremap" sur la mémoire. J'ai aussi répare le "syscall" qui exécutait du code via une adresse mémoire réelle, puisque qu'auparavant il ne sauvegarder pas le lien du registre, ce qui n'est pas bon ... Enfin j'ai tracké le problème que j'avais avec les appels des "ioctls" depuis le code de l'espace utilisateur. Il s'avère qu'il y a des problèmes du au fait d'envoyer des "ioctls" a un kernel 64bit depuis un code de l'espace utilisateur 32bit. Quand vous envoyez un "ioctl" depuis un code de l'espace utilisateur, il y a une une fonction cachée qui tente de "le rendre compatible" avant de l'envoyer au kernel. Cela était transparent ce qui causait que quelques "ioctls" n'est pas compatible avec mon code du kernel. Ces choses là font que je déteste Linux eheh. Pour réparer cela, il va falloir avoir recours à une compilation des section du kernel, donc au lieu de le forcer, j'ai essayé tout les numeros des "ioctl" jusqu'a trouver le bon qui le rendait OK et qui les installait pour les utiliser à la place. Lors de l'envoie de ces "ioctls", une poignée est utilisé pour le XorHack, donc je ne suis pas trop inquiet à propos du fait qu'ils s'égarent et qu'ils fassent des ravages.
Les librairies utilisateurs changent
Finalement sur les niveaux les plus exterieurs j'ai ajouté le support pour permettre aux nouveaux "syscalls" de lire et d'écrire 8, 16, 32 ou 64 bits en même temps. En faisant cela j'ajoute le support des adresses "non alignées" sans que l'utilisateur ait à verifier ou s'occuper d'une telle chose. Si l'adresse à laquelle on souhaite acceder est alignée alors nous y accéderons via une seule "syscall" d'une taille spécifique. Si l'adresse n'est pas alignée il utilisera à la place plusieurs "syscalls" ou un "syscall" d'une taille d'accès plus important. J'ai aussi rajouté des fonctions qui permettent de vérifier si le système à bien été rendu exploitable, pour transcrire l'adresse "lpar" vers une adresse reelle, pour "io-remapping" des adresses et exécuter le code donné à l'adresse reelle. Un nouveau header du fichier xorhack_sc.h à été ajouté, il contient les transcriptions entre les "syscalls" comme ils devraient être utilisé en mode kernel et dans l'interface utilisateur. J'ai seulement fait quelques petites choses ici, mais cela devrait être suffisant pour suivre Ie modèle et créer d'autres transcriptions pour tout autre "syscalls". Si quelqu'un complète ces transcriptions, qu'il me les envoi pour les inclure à la prochaine version de XorHack.
Les exemples d'application changent
En plus des ajouts et modifications ci dessus j'ai ajouté 3 nouvelles applications en ligne de commande ; "ps3peek", "ps3poke" et "ps3exec" qui permettent la lecture, l'écriture et l'execution dans la mémoire. "ps3peek" et "ps3poke" fonctionnent de manière similaire. Tous les deux sont capable d'effectuer des accès aux données 8bit, 16bits, 32 bits et 64bits et peuvent acceder à de multiples tailles de données en un appel. "ps3peek" peut afficher les données à l'écran en caractere Hexadécimaux et ASCII, similaire à ce que l'on trouve dans les éditeurs hexadécimaux, ou peut afficher les données et les rediriger dans un fichier. "ps3poke" n'affiche pas les données à l'écran mais peut écrire les données dans la mémoire depuis des valeurs passé de la ligne de commande ou des valeur lues depuis un fichier.
Ici vous trouverez plusieurs exemples de ce qui peut être fait avec ces outils
Dumper l'Hyperviseur
Ceci lit 0×10000000 octets (16MB) de données démarrant a l'adresse zéro en utilisant une taille d'accès au données de 8 octets (64bits) et l'affiche sous forme binaire qui est ensuite rediriger dans le fichier hvdump.bin. Remarquez que l'accès 64bis est utilisé car il nécessite 8 fois moins de "syscalls" pour obtenir la même quantité d'informations que si nous avions utilisé l'accès par défaut de 8bit
Code: Tout sélectionner
ps3peek 0 -s 0×1000000 -d 8 -b > hvdump.bin
Reading the status register for spu0
ps3peek 0×20000044024 -d 4
Loading metldr..
Les scripts peuvent être écrit en utilisant "ps3peek", "ps3poke" et "ps3exec" et en utilisant les fichiers pour stocker des valeurs entre fonctions. En faisant comme ça, de nombreuses tâches peuvent être faites comme paramétrer les registres nécessaire au chargement du metldr
Modifié par kelkal, 20 mars 2010 - 22:54.
