FBI v2.4.3 disponible et s'adapte à waithax
[PS5] PS5 App Dumper 1.0 disponible
2.4.3@Steveice10 Steveice10 released this 17 hours ago · 4 commits to master since this releaseAdd waithax support. (untested)Add action to delete unused tickets.Add loading screens to multi-file operations.Check if FBI already has service access before executing kernel exploits.Delete existing file instead of overwriting when pasting. Fixes pasting into extdata.Improve title destination detection.Replace network installation with utility for generating a QR code to serve CIA files over local HTTP.Fix delete action use-after-free.Fix performing actions in current directory after renaming it.
waithax : toujours aussi lent que la tortue et comme son nom l'indique ?
Merci mais comme la Wii U, il faut un jeu VC donc je passeOui. Et s'il est lent, c'est juste parce que c'est long de créer 36 000 processus, pour incrémenter leur PID, jusqu'à revenir à zéro.waithax : toujours aussi lent que la tortue et comme son nom l'indique ?
edit: 36 000 est un expression, je ne connais pas le nombre exact
Euh... non, il ne faut pas de jeux Console virtuelle.... WTFMerci mais comme la Wii U, il faut un jeu VC donc je passeOui. Et s'il est lent, c'est juste parce que c'est long de créer 36 000 processus, pour incrémenter leur PID, jusqu'à revenir à zéro.waithax : toujours aussi lent que la tortue et comme son nom l'indique ?
edit: 36 000 est un expression, je ne connais pas le nombre exact
c'est pas ça du tout...Oui. Et s'il est lent, c'est juste parce que c'est long de créer 36 000 processus, pour incrémenter leur PID, jusqu'à revenir à zéro.waithax : toujours aussi lent que la tortue et comme son nom l'indique ?
edit: 36 000 est un expression, je ne connais pas le nombre exact
Ah oui c'est tout de suite plus clair..... non en fait j'ai rien compris du tout. En tous cas merci pour ton super boulot !!!!c'est pas ça du tout...Oui. Et s'il est lent, c'est juste parce que c'est long de créer 36 000 processus, pour incrémenter leur PID, jusqu'à revenir à zéro.waithax : toujours aussi lent que la tortue et comme son nom l'indique ?
edit: 36 000 est un expression, je ne connais pas le nombre exact
il faut faire un integer overflow du reference count d'un KSynchronizationObject (ici, j'ai choisi une KSemaphore). pour faire ça, il faut passer par WaitSynchronizationN et donner un handle invalide, ce qui ne décrémente pas le reference count. A chaque call à WaitSynchronizationN que je fais dans le code de mon exploit, le reference count est donc incrémenté de 0xFF (255). Il faut (2^32 - 1) / 255 appels à WaitSynchronizationN (soit 16,843,009 appels, ou 0x1010101), ce qui revient à incrémenter le reference count de 2^32 - 1 pour qu'il atteigne zéro et déclencher la désallocation de l'objet lorsqu'il est utilisé, pour pouvoir ensuite utiliser le prochain objet désalloué comme vtable, ce qui permet de lancer son propre code en tant que Kernel11.
Ah... Je crois que je viens de confondre WaitHax avec veryslowpidhax...c'est pas ça du tout...Oui. Et s'il est lent, c'est juste parce que c'est long de créer 36 000 processus, pour incrémenter leur PID, jusqu'à revenir à zéro.waithax : toujours aussi lent que la tortue et comme son nom l'indique ?
edit: 36 000 est un expression, je ne connais pas le nombre exact
il faut faire un integer overflow du reference count d'un KSynchronizationObject (ici, j'ai choisi une KSemaphore). pour faire ça, il faut passer par WaitSynchronizationN et donner un handle invalide, ce qui ne décrémente pas le reference count. A chaque call à WaitSynchronizationN que je fais dans le code de mon exploit, le reference count est donc incrémenté de 0xFF (255). Il faut (2^32 - 1) / 255 appels à WaitSynchronizationN (soit 16,843,009 appels, ou 0x1010101), ce qui revient à incrémenter le reference count de 2^32 - 1 pour qu'il atteigne zéro et déclencher la désallocation de l'objet lorsqu'il est utilisé, pour pouvoir ensuite utiliser le prochain objet désalloué comme vtable, ce qui permet de lancer son propre code en tant que Kernel11.
Oups!
C'est ce que j'avais lu quelque part, il faut un jeu et Field Runner en fait partie...Euh... non, il ne faut pas de jeux Console virtuelle.... WTFMerci mais comme la Wii U, il faut un jeu VC donc je passeOui. Et s'il est lent, c'est juste parce que c'est long de créer 36 000 processus, pour incrémenter leur PID, jusqu'à revenir à zéro.waithax : toujours aussi lent que la tortue et comme son nom l'indique ?
edit: 36 000 est un expression, je ne connais pas le nombre exact
veryslowpidhax permet uniquement d'avoir les privilèges que tu pourrais avoir avec certains PID (par exemple, inférieur à 5 => accès à tous les services).Ca ne sert à pas grand chose, cependant, et vu le temps que ça prend pour ce que c'est, mieux vaut l'oublier...J'ai pris une KSemaphore pour le champ à 0x24 (https://www.3dbrew.org/wiki/KSemaphore). Je crée une KSemaphore avec un maxcount correspondant à l'adresse du code que je veux exécuter sous Kernel11, puisque celle-ci sera utilisée comme vtable (en ayant été désallouée au préalable)Ah... Je crois que je viens de confondre WaitHax avec veryslowpidhax...c'est pas ça du tout...il faut faire un integer overflow du reference count d'un KSynchronizationObject (ici, j'ai choisi une KSemaphore). pour faire ça, il faut passer par WaitSynchronizationN et donner un handle invalide, ce qui ne décrémente pas le reference count. A chaque call à WaitSynchronizationN que je fais dans le code de mon exploit, le reference count est donc incrémenté de 0xFF (255). Il faut (2^32 - 1) / 255 appels à WaitSynchronizationN (soit 16,843,009 appels, ou 0x1010101), ce qui revient à incrémenter le reference count de 2^32 - 1 pour qu'il atteigne zéro et déclencher la désallocation de l'objet lorsqu'il est utilisé, pour pouvoir ensuite utiliser le prochain objet désalloué comme vtable, ce qui permet de lancer son propre code en tant que Kernel11.Oui. Et s'il est lent, c'est juste parce que c'est long de créer 36 000 processus, pour incrémenter leur PID, jusqu'à revenir à zéro.edit: 36 000 est un expression, je ne connais pas le nombre exactwaithax : toujours aussi lent que la tortue et comme son nom l'indique ?
Franchement, j'ai rien compris du toutveryslowpidhax permet uniquement d'avoir les privilèges que tu pourrais avoir avec certains PID (par exemple, inférieur à 5 => accès à tous les services).Ca ne sert à pas grand chose, cependant, et vu le temps que ça prend pour ce que c'est, mieux vaut l'oublier...J'ai pris une KSemaphore pour le champ à 0x24 (https://www.3dbrew.org/wiki/KSemaphore). Je crée une KSemaphore avec un maxcount correspondant à l'adresse du code que je veux exécuter sous Kernel11, puisque celle-ci sera utilisée comme vtable (en ayant été désallouée au préalable)Ah... Je crois que je viens de confondre WaitHax avec veryslowpidhax...c'est pas ça du tout...il faut faire un integer overflow du reference count d'un KSynchronizationObject (ici, j'ai choisi une KSemaphore). pour faire ça, il faut passer par WaitSynchronizationN et donner un handle invalide, ce qui ne décrémente pas le reference count. A chaque call à WaitSynchronizationN que je fais dans le code de mon exploit, le reference count est donc incrémenté de 0xFF (255). Il faut (2^32 - 1) / 255 appels à WaitSynchronizationN (soit 16,843,009 appels, ou 0x1010101), ce qui revient à incrémenter le reference count de 2^32 - 1 pour qu'il atteigne zéro et déclencher la désallocation de l'objet lorsqu'il est utilisé, pour pouvoir ensuite utiliser le prochain objet désalloué comme vtable, ce qui permet de lancer son propre code en tant que Kernel11.Oui. Et s'il est lent, c'est juste parce que c'est long de créer 36 000 processus, pour incrémenter leur PID, jusqu'à revenir à zéro.edit: 36 000 est un expression, je ne connais pas le nombre exactwaithax : toujours aussi lent que la tortue et comme son nom l'indique ?
, je pense que c'est pas mon niveau 
