44 replies to this topic

[Pekoms]

J'espère que ça débouchera ver un hack soft, ou une solution hen.

Je crois que cela a été dit de nombreuses fois, un hard hardware est obligatoire pour lancer l'exploit.
Corrigez-moi si je me trompe.

Pour l'instant un hardware est obligatoire
Mais n'oublie pas que la ps3 ultra silm était aussi soit disant inhackable

[DOCKY99]

Ce qui est "embêtant " c'est que Nvidia  c’est "concentré" sur la partie graphique et "moins" sur la partie sécurité qui semblais important au vu de la cible embarqué du soc .

Les clients qui l'utilise comme Nintendo doit êtres un peu remonté sur ce sujet .

Par contre on pourras pas reprocher à Nvidia de ne pas fournir de bonne docs

Ce message a été modifié par DOCKY99 - 03 June 2020 - 08:52.

[eliboa]

Apparement Nvidia ont "oublier" d'ajouter les protections contres le type de glitch utiliser dans le bootrom lors d'un check d'un hash important... Alors qu'ils ont implementer les protections ailleurs (d'ou le tweet de hexquyz que "c'est le meme exploit" qu'ils avaient utiliser pour obtenir les clées de la switch originale)

Le pire dans tout ca, c'est que sansNvidia, on serait pas bien loin dans le hack sur les versions post 5.0.0 en ce moment.

Oui, j'avais pas trop compris au début mais en lisant les explications de hedgeberg sur discord, c'était plus clair.

Pour ceux que ça intéressent voici une traduction grossière :

"Au début on a pensé que la puce (sx core) ne glitchait pas le BCT check, parce que la bootrom était supposément pleine de délais aléatoires. On avait en fait décidé de ne pas continuer avec ce glitch sur mariko car nous supposions que le délai entre la dernière lecture emmc et le BCT check était "aléatoire". Et bien non. NVIDIA semble avoir... oublié... d'ajouter un délai aléatoire entre la fin de la dernière lecture emmc, avant le BCT check, et le BCT check en lui-même. Ce qui veut dire que même si la bootrom est remplie de timings aléatoires, cela n'affecte pas la partie qui compte le plus. Il semblerait bien que nvidia ait merdé à nouveau".

Selon hexkyz, la TX n'aurait pas pu faire du RE (soft) sur cette nouvelle bootrom pour y arriver, elle aurait plutôt observé les timings et recherché un déterminisme dans les délais. Pour dumper/déchiffrer la bootrom d'autres glitchs seraient nécessaires.

 

edit : ça discute aussi sur le discord pour savoir si une nouvelle version iPatched de mariko pourrait bloquer la puce TX ou si celle-ci saurait s'adapter à des délais aléatoires. A priori, la puce s'adapte déjà dans un sens ou les paramètres du glitch varient d'une console à une autre (la puce ajuste les paramètres jusqu'à ce qu'ils soient corrects pour la dite switch), ce qui ne veut pas dire qu'elle puisse s'adapter à des délais aléatoires. En fait le délai va varier d'une switch à une autre mais l'essentiel est qu'il y ait toujours un déterminisme à l'oeuvre dans ce délai. Verrons-nous bientôt apparaître une révision de Mariko ? C'est bien possible.

 

edit2 : apparemment il y a autre chose qui intéresse la team RS, c'est de pouvoir dumper le firmware de la puce TX (en glitchant la puce qui glitche ^^), c'est pourquoi ils tentent de connaître le type de MCU utilisé (peut-être une série STM32F3). Ce qu'ils voudraient c'est obtenir la clé du firmware afin de comprendre ce qui se cache derrière la mise à jour du fw du mcu qui est faite au premier boot (il passe de 1.0 à 1.1)

Ce message a été modifié par eliboa - 03 June 2020 - 11:07.

[Samus-AR]

J'espère que ça débouchera ver un hack soft, ou une solution hen.

Je crois que cela a été dit de nombreuses fois, un hard hardware est obligatoire pour lancer l'exploit.
Corrigez-moi si je me trompe.

Pour l'instant un hardware est obligatoire
Mais n'oublie pas que la ps3 ultra silm était aussi soit disant inhackable

C'est clair, de tout façon l'espoir fait vivre, alors soyons optimiste ☺.

[armagad]

De toute maniere les hacks c est toujours un oublie de securisation a quelque part. Si tout etait ultra securise il n y aurait aucun hack disponible

Vive les failles

[Jackpot3000]

putain il nous faut ce genre de devs sur les autres platformes, des mecs doués et humbles qui pètent pas plus haut que leurs fesses pas les gamins qu'on a sur ps4 (même si sur ps4 on a aussi d'excellent
devs mais qui malheureusement ne peuvent pas tout faire seuls)

[Wind]

Merci la Team Xecuter, sans eux on aurais pas eu ça

Ouaip, et merci SciresM, et merci Nintendo, et merci NVIDIA. Sans eux on aurait pas eu ça .

Ça fais les aveugles mais aucun problème, ça change rien à la réalité

[Haevens]

Purée, je commence à en avoir marre de voir cette guerre de...
sur TX et Atmosphère c'est bon depuis longtemps ça était prouvé que TX a utilisé du code d'Atmosphère.
Après TX ta juste les XCI et le disque dur externe en plus.
Je suis désolé mais suffit de regarder à chaque nouveau firmware si ta pas SciresM on pourrait attendre des mois que TX ne mettrait pas à jour.

PS : J'utilise SX OS/Atmosphère.
Bien que je préfère largement Atmosphère vu toutes les possibilités dessus maintenant.

On dirait les guerre des... sur les consoles : À non la ps4 est mieux que la Xbox Blabla.

Ce message a été modifié par Haevens - 03 June 2020 - 11:40.

[JohnConnor]

Bonjour,

On dit Nvidia a laisser des failles mais bon il doit pas avoir beaucoup de personne comme SciresM pour les trouver.

[Boukaki76]

En tout cas nvidia perd très gros, la prochaine gen de nintendo.
il vont pouvoir ce mettre un gros doigt dans le fi..
Je pense pas que nintendo seront prêt à retravailler avec eux .

[Lestat___]

Purée, je commence à en avoir marre de voir cette guerre de...
sur TX et Atmosphère c'est bon depuis longtemps ça était prouvé que TX a utilisé du code d'Atmosphère.
Après TX ta juste les XCI et le disque dur externe en plus.
Je suis désolé mais suffit de regarder à chaque nouveau firmware si ta pas SciresM on pourrait attendre des mois que TX ne mettrait pas à jour.

PS : J'utilise SX OS/Atmosphère.
Bien que je préfère largement Atmosphère vu toutes les possibilités dessus maintenant.

On dirait les guerre des... sur les consoles : À non la ps4 est mieux que la Xbox Blabla.

Ben pour le coup la ps4 est bien mieux que la Xbox,
Par contre la Xbox one est bien mieux que la playstation.

Ce message a été modifié par Lestat___ - 03 June 2020 - 12:03.

[Fatiguant]

Oui, j'avais pas trop compris au début mais en lisant les explications de hedgeberg sur discord, c'était plus clair.
Pour ceux que ça intéressent voici une traduction grossière :
"Au début on a pensé que la puce (sx core) ne glitchait pas le BCT check, parce que la bootrom était supposément pleine de délais aléatoires. On avait en fait décidé de ne pas continuer avec ce glitch sur mariko car nous supposions que le délai entre la dernière lecture emmc et le BCT check était "aléatoire". Et bien non. NVIDIA semble avoir... oublié... d'ajouter un délai aléatoire entre la fin de la dernière lecture emmc, avant le BCT check, et le BCT check en lui-même. Ce qui veut dire que même si la bootrom est remplie de timings aléatoires, cela n'affecte pas la partie qui compte le plus. Il semblerait bien que nvidia ait merdé à nouveau".
Selon hexkyz, la TX n'aurait pas pu faire du RE (soft) sur cette nouvelle bootrom pour y arriver, elle aurait plutôt observé les timings et recherché un déterminisme dans les délais. Pour dumper/déchiffrer la bootrom d'autres glitchs seraient nécessaires.
 
edit : ça discute aussi sur le discord pour savoir si une nouvelle version iPatched de mariko pourrait bloquer la puce TX ou si celle-ci saurait s'adapter à des délais aléatoires. A priori, la puce s'adapte déjà dans un sens ou les paramètres du glitch varient d'une console à une autre (la puce ajuste les paramètres jusqu'à ce qu'ils soient corrects pour la dite switch), ce qui ne veut pas dire qu'elle puisse s'adapter à des délais aléatoires. En fait le délai va varier d'une switch à une autre mais l'essentiel est qu'il y ait toujours un déterminisme à l'oeuvre dans ce délai. Verrons-nous bientôt apparaître une révision de Mariko ? C'est bien possible.
 
edit2 : apparemment il y a autre chose qui intéresse la team RS, c'est de pouvoir dumper le firmware de la puce TX (en glitchant la puce qui glitche ^^), c'est pourquoi ils tentent de connaître le type de MCU utilisé (peut-être une série STM32F3). Ce qu'ils voudraient c'est obtenir la clé du firmware afin de comprendre ce qui se cache derrière la mise à jour du fw du mcu qui est faite au premier boot (il passe de 1.0 à 1.1)

On le voit tout de suite que la puce s’adapte, au premier lancement de la console avec mochip installé le demarrage pour ma part a ete un tentinet plus long que les boots suivants. Ca me fait pensez au timming du srgh pour Ace V3 qui peuvnt aussi faire cela temps que la console n’est pas debrancher elle garde en memoire le meilleur timming pour ellee.

[mikimike]

Merci la Team Xecuter, sans eux on aurais pas eu ça

Ouaip, et merci SciresM, et merci Nintendo, et merci NVIDIA. Sans eux on aurait pas eu ça .

Ça fais les aveugles mais aucun problème, ça change rien à la réalité

Y'en a qui font les aveugles comme tu dis,mais bon toi t'as oublié tes jumelles.

[eliboa]

On le voit tout de suite que la puce s’adapte, au premier lancement de la console avec mochip installé le demarrage pour ma part a ete un tentinet plus long que les boots suivants. Ca me fait pensez au timming du srgh pour Ace V3 qui peuvnt aussi faire cela temps que la console n’est pas debrancher elle garde en memoire le meilleur timming pour ellee.

Intéressant mais je me demande si ce délai, dans le cas du premier boot, est lié à soit :

- comme tu dis, l'adaptation du glitch en lui même

- le temps pour flasher la BCT et le package1 sur la NAND. Allez il faut dumper, déchiffrer, réécrire, rechiffrer et restaurer à peine 0x800 Kb à tout casser mais ça doit prendre un peu de temps quand même.

- le temps pour flasher le firm du MCU qui si j'ai tout compris est lu dans boot.dat sur la mmc.

 

C'est sans doute un peu des trois j'imagine. Par contre, par rapport à ta ref au glitch du Ace v3, je me demande comment ça fonctionne sur le SX Core, est-ce que le meilleur timing est enregistré autre part que sur la mémoire volatile ? Autrement dit est-ce l'adaptation du glitch ne se fait qu'au tout premier boot ou à d'autres moment ?

Ce message a été modifié par eliboa - 03 June 2020 - 12:40.

[Fatiguant]

Ca sur le chan ils ne veulent absolument pas s’avancer sur comment elle fonctionne. Au tout debut des test j’ai demandé de comment la hack agissait sur la console. La reponse a ete simple on est pas la pour parler de cela. J’ai demandé si une fois rendu publique ils allaient en parler et je m’etais avancé sur la possibilité que ce soit un hack bootroom. La reponse a ete oui c’est un hack du bootroom via glitch pour le reste tu le sauras bien assez vite une fois la puce sortie...

[mikimike]

En rêvant un peu(vu que je ne sais pas du tout comment on pourrait faire sans passer par un dongle,un trinket M0 ou un smartphone/tablette)cela pourrait aboutir à faire booter un cfw sur une switch non patchée sans passer par ces gadgets.

[jerodoalle]

tout le monde parle de guerre ...mais en fait y a un seul truc ...et c est le hack payant de sxos ! et quand la version est foireuse , les gens s en donnent a coeur joie....et moi le premier !

[choc]

Sa sent bon tout sa

[Fatiguant]

Sa sent bon tout sa

Bha ca te donnera pas de hack soft que peut etre un clone des modchips plus rapidement.

[DED FR]

Encore une console inviolable sans modchip, tout comme le furent la ps3 metldr2 et la ps vita...
La vrai question pour la mariko n'est pas si elle sera hackée software mais plutot quand.

Ce message a été modifié par DED FR - 03 June 2020 - 18:46.