13 replies to this topic

[tralala]

Le développeur Steveice10 nous propose de découvrir une nouvelle version de FBI v2.4.3,  FBI est un incontournable pour tous ceux qui dispose d'un CFW digne de ce nom. C'est un homebrew qui permet d'installer et de désinstaller des fichiers sous format CIA et il est totalement open source. Il est proposé par son auteur aux formats CIA, 3DS et 3DSX. Donc tous ceux qui ont accès aux hack 3DS de près ou de loin peuvent l'installer, à condition de pouvoir exploiter au minimum la faille Ninjhax, et d'avoir patché le service.

 

 

 

 

Avec la version v2.4.3, le développeur ajoute le support de waithax, il a amélioré certaines vérifications, amélioré les détections et apporté des corrections spécifiques à certains bugs. 

 

 

2.4.3

@Steveice10 Steveice10 released this 17 hours ago · 4 commits to master since this release

 

Add 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.

 

 

 

Téléchargement : FBI v2.4.3

 

[smada]

Merci pour la news

[Blue3ds67]

Merci tralala^^

[chronoss]

waithax : toujours aussi lent que la tortue et comme son nom l'indique ?

[Omegあ1]

waithax : toujours aussi lent que la tortue et comme son nom l'indique ?

Oui...

Ce message a été modifié par Omegあ1 - 18 December 2016 - 18:36.

[jad67tony]

merci pour les améliorations

[chronoss]

waithax : toujours aussi lent que la tortue et comme son nom l'indique ?

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 exact

Merci mais comme la Wii U, il faut un jeu VC donc je passe

[Omegあ1]

waithax : toujours aussi lent que la tortue et comme son nom l'indique ?

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 exact

Merci mais comme la Wii U, il faut un jeu VC donc je passe

Euh... non, il ne faut pas de jeux Console virtuelle.... WTF

[Mrrraou]

waithax : toujours aussi lent que la tortue et comme son nom l'indique ?

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 exact

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.

Ce message a été modifié par Mrrraou - 18 December 2016 - 11:09.

[danielou]

waithax : toujours aussi lent que la tortue et comme son nom l'indique ?

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 exact

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.

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 !!!!

[Omegあ1]

waithax : toujours aussi lent que la tortue et comme son nom l'indique ?

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 exact

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.

Ah... Je crois que je viens de confondre WaitHax avec veryslowpidhax... Oups!
....Hmm. On est d'accord, veryslowpidhax n'est pas un exploit permettant d'avoir des privilèges arm11 kernel, n'est-ce pas ?
Pourquoi as tu choisis un KSepmaphore ?

Ce message a été modifié par Omegあ1 - 18 December 2016 - 18:44.

[chronoss]

waithax : toujours aussi lent que la tortue et comme son nom l'indique ?

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 exact

Merci mais comme la Wii U, il faut un jeu VC donc je passe

Euh... non, il ne faut pas de jeux Console virtuelle.... WTF

C'est ce que j'avais lu quelque part, il faut un jeu et Field Runner en fait partie...

[Mrrraou]

waithax : toujours aussi lent que la tortue et comme son nom l'indique ?

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 exact

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.

Ah... Je crois que je viens de confondre WaitHax avec veryslowpidhax... Oups!....Hmm. On est d'accord, veryslowpidhax n'est pas un exploit permettant d'avoir des privilèges arm11 kernel, n'est-ce pas ?Pourquoi as tu choisis un KSepmaphore ?

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)

Ce message a été modifié par Mrrraou - 18 December 2016 - 20:12.

[chronoss]

waithax : toujours aussi lent que la tortue et comme son nom l'indique ?

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 exact

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.

Ah... Je crois que je viens de confondre WaitHax avec veryslowpidhax... Oups!....Hmm. On est d'accord, veryslowpidhax n'est pas un exploit permettant d'avoir des privilèges arm11 kernel, n'est-ce pas ?Pourquoi as tu choisis un KSepmaphore ?

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)

Franchement, j'ai rien compris du tout , je pense que c'est pas mon niveau