46 réponses à ce sujet

[tralala]

Après Nintendo, voilà que c'est désormais la Team Xecuter qui subit un leak, il faut dire que le SXOS 3.0.0 dispose lui même d'informations intéressantes sur la sécurité de la Switch Lite et de la Switch patchée Mariko.

 

Le développeur SciresM, que l'on ne présente plus, a posté sur son profil Twitter la clé du boot Mariko, et la clé d'encryptage Mariko, obtenu grâce à un script qui lui a permi d'extraire le fichier boot.dat.

 

 

 

 

 

De là à penser qu'une solution au moins partiellement open-source sera à plus ou moins long terme publié, il n'y a qu'un pas, peut être que justement son objectif est de montrer qu'il serait possible d'injecteur le loader du chargeur dans le boot d'Atmosphere ou via Hekate.

 

 

 

 

 

 

Les informations de ce type sont nombreuses, il y a deux ans nous vous annoncions que SXOS avait été hacké, mais il n'en ai rien sorti par la suite, la solution hardware proposée par la TX sera certainement pérenne durant plusieurs mois, voir plusieurs années. 

 

 

[xave]

oui encore du hack ce qui aime pas la version 2.95 et autre cfw si deviens gratuit avec le hack du 3.0 si compatible avec d'autre cfw beaucoup vont l'aimer maintenant

[Waikiki]

Concrètement cela va apporter quoi à la scène switch ? Désolé je ne vois pas en quoi ces clés sont utiles. Intégrer SXOS pour les utilisateurs d'atmosphère ? Merci à tous pour vos réponses

[eliboa]

Oui j'ai vu ça ce matin sur Twitter, c'est cool si SciresM and co ont pu avoir accès à ce leak, visiblement ça leur a été bien utile.

D'après les tweets de ScriresM, ce serait encore NVIDIA qui aurait merdé, visiblement c'est pas un nouvel exploit, c'est la même technique que pour l'exploit RCM (sauf qu'il faut un mod hardware maintenant)

 

Hexkyz aussi à posté son script pour décompresser SX OS 3.0 :

Scripts for the leaked SXOS v3.0.0 (SHA-256 of 54ce0f58cac9643559991b0b86252424c1bbc59c5c77496110d999814a4a7d52)

As for a changelog, this version's purpose is to support Mariko and the modchip ecosystem, so there are no new features.

Aside from removing all KIPs except for Loader, most of the changes are DRM related. 

Bootloader has new code to interact with and update the modchip.

Patchers now include full copies of each Mariko package1 encrypted with a T210B01/T214 specific key.

All applications have been updated and rebuilt to match current AMS and libnx. 

On the very first boot the bootloader will attempt to update the modchip from version 1.0 to 1.1. Update firmware is stored encrypted inside the bootloader and is likely meant to patch a handful of vulnerabilities and broken code already identified. 

The modchip itself flashes a custom BCT and bootloader to the boot0 partition on the eMMC. These are stored encrypted with the Mariko BEK (Boot Encryption Key) and signed with TX's own key. Once the glitch succeeds, TX's bootloader will run instead of Nintendo's. 

The initial stages focus mostly on DRM and clear out all keyslots (except keyslot number 6) that were filled by the bootrom as a way to block any other third party from obtaining Mariko keys using the modchip. This is, however, ineffective. 

...

It's not a new exploit per se, in fact it's the exact same technique used to achieve code execution on the original units: glitch the PKC hash check.

This was made more difficult with Mariko but the modchip is capable of self-adapting the timings.

Source : Twitter

Modifié par eliboa, 31 mai 2020 - 18:26.

[eliboa]

Concrètement cela va apporter quoi à la scène switch ? Désolé je ne vois pas en quoi ces clés sont utiles. Intégrer SXOS pour les utilisateurs d'atmosphère ? Merci à tous pour vos réponses

Les clés, ça veut juste dire qu'ils ont réussi à avoir les 2 clés les plus importantes qui permettent de dériver toutes les clés et donc déchiffrer tout le contenu des nouvelles switch (mariko), en gros ^^.

Donc SciresM a maintenant accès au secure monitor et peut étudier la TrustZone sur ces Switch. Pour te répondre ça va apporter des connaissances pour adapter Atmosphère aux switch Mariko, mais ça n'apporte rien comme nouvel exploit. Donc il faudra à priori passer par une puce pour injecter un bootloader et lancer Atmosphère, si toutefois c'est un jour possible (à mon avis oui).

Modifié par eliboa, 31 mai 2020 - 18:06.

[overload]

Enorme la scène Switch et ses avancées , faudrait des leak sur la scène PS4 aussi....

[mikimike]

Pour faire avancer à grand pas toute les scènes,rien ne vaut des leak à droite et à gauche(une dispute entre membre d'une team....leak,tu l'aimes pas.....leak).

[ConsoleX]

Quel dommage d'avoir lâché ça dans la nature avant une diffusion public.
Pour avoir ce fameux boot.dat il fallait monter patte blanche et après on avait un boot.dat signé !
D'ailleurs je vous conseil pas trop forcement de l'utiliser car des cas de brick sont survenu !!!
Dans le process la modchip inject du code dans la nand si j'ai bien compris avec mon english à 2 balle

Modifié par ConsoleX, 31 mai 2020 - 18:30.

[trantor]

leurs os sont quasi toujours buggés en meme temps c'est pas nouveaux ça , j'utilises sx pro depuis le début mais ont a souvent eu des version pas stable , aprés ça aurais été préférable qu'il soit sortis officiellement

Modifié par trantor, 31 mai 2020 - 18:35.

[eliboa]

Quel dommage d'avoir lâché ça dans la nature avant une diffusion public.
Pour avoir ce fameux boot.dat il fallait monter patte blanche et après on avait un boot.dat signé !
D'ailleurs je vous conseil pas trop forcement de l'utiliser car des cas de brick sont survenu !!!
Dans le process la modchip inject du code dans la nand si j'ai bien compris avec mon english à 2 balle

C'était un peu inévitable vu le nombre de testeurs je pense. Et puis c'est de bonne guerre, la TX serait la première à sauter sur un leak ^^

Oui, apparemment ça flashe la partition BOOT0, donc le mieux est d'avoir un backup des boots à minima.

[bidobido]

Quel dommage d'avoir lâché ça dans la nature avant un diffusion public.
Pour avoir ce fameux boot.dat il fallait monter patte blanche et après on avait un boot.dat signé !
D'ailleurs je vous conseil pas trop forcement de l'utiliser car des cas de brick sont survenu !!!
Dans me process la modchip inject du code dans a nand si j'ai bien compris avec mon english à 2 balle

leurs os sont quasi toujours buggés en meme temps c'est pas nouveaux ça , j'utilises sx pro depuis le début mais ont a souvent eu des version pas stable

Je pense qu'il parle de la mise à jour initialisée au 1er démarrage du CFW post install' de la puce. Là possiblement ça doit injecter du code dans les Mariko/Lite. Mais pour nous autres qui avons du matos faillible (les premières Switchs), je doute qu'il y ait un risque de brick supp'..

Encore heureux la 2.9.5 étant déjà bien mitée, manquerait plus que ça lol

À moins qu'il y ait diverses versions de sxos et là encore si ils commencent à éclater les process de patch pour tel ou tel modèle, on est pas non plus sorti de l'auberge vu la léthargie et le manque de communication..

Modifié par bidobido, 31 mai 2020 - 18:42.

[ConsoleX]

Quel dommage d'avoir lâché ça dans la nature avant une diffusion public.
Pour avoir ce fameux boot.dat il fallait monter patte blanche et après on avait un boot.dat signé !
D'ailleurs je vous conseil pas trop forcement de l'utiliser car des cas de brick sont survenu !!!
Dans le process la modchip inject du code dans la nand si j'ai bien compris avec mon english à 2 balle

C'était un peu inévitable vu le nombre de testeurs je pense. Et puis c'est de bonne guerre, la TX serait la première à sauter sur un leak ^^
Oui, apparemment ça flashe la partition BOOT0, donc le mieux est d'avoir un backup des boots à minima.

Tu n'as pas accès à la fonction backup avant d'avoir flashé le boot0

Modifié par ConsoleX, 31 mai 2020 - 18:38.

[trantor]

Quel dommage d'avoir lâché ça dans la nature avant un diffusion public.
Pour avoir ce fameux boot.dat il fallait monter patte blanche et après on avait un boot.dat signé !
D'ailleurs je vous conseil pas trop forcement de l'utiliser car des cas de brick sont survenu !!!
Dans me process la modchip inject du code dans a nand si j'ai bien compris avec mon english à 2 balle

leurs os sont quasi toujours buggés en meme temps c'est pas nouveaux ça , j'utilises sx pro depuis le début mais ont a souvent eu des version pas stable

Je pense qu'il parle de la mise à jour initialisée au 1er démarrage du CFW post install' de la puce. Là possiblement ça doit injecter du code dans les Mariko/Lite. Mais pour nous autres qui avons du matos faillible (les premières Switchs), je doute qu'il y ait un risque de brick supp'.. Encore heureux la 2.9.5 étant déjà bien mitée, manquerait plus que ça.. lol

non comme toi je ne penses pas que les 1ere switch ça les brick en quoi que ce soit la 3.0 , a moins qu'il ais 2 version de sx os comme tu dit ^^ mais ont peux pas avoir pire que la miteuse 2.9.5 comme tu le dit aussi

Modifié par trantor, 31 mai 2020 - 18:44.

[ConsoleX]

Quel dommage d'avoir lâché ça dans la nature avant un diffusion public.
Pour avoir ce fameux boot.dat il fallait monter patte blanche et après on avait un boot.dat signé !
D'ailleurs je vous conseil pas trop forcement de l'utiliser car des cas de brick sont survenu !!!
Dans me process la modchip inject du code dans a nand si j'ai bien compris avec mon english à 2 balle

leurs os sont quasi toujours buggés en meme temps c'est pas nouveaux ça , j'utilises sx pro depuis le début mais ont a souvent eu des version pas stable

Je pense qu'il parle de la mise à jour initialisée au 1er démarrage du CFW post install' de la puce. Là possiblement ça doit injecter du code dans les Mariko/Lite. Mais pour nous autres qui avons du matos faillible (les premières Switchs), je doute qu'il y ait un risque de brick supp'.. Encore heureux la 2.9.5 étant déjà bien mitée, manquerait plus que ça.. lol

non comme toi je ne penses pas que les 1ere switch ça les brick en quoi que ce soit

Le process peut corrompre la nand donc a partir de là n'importe quel modèle est concerné !

[eliboa]

Tu n'as pas accès à la fonction backup avant d'avoir flashé le boot0

Arf oui ^^ 

[trantor]

Quel dommage d'avoir lâché ça dans la nature avant un diffusion public.
Pour avoir ce fameux boot.dat il fallait monter patte blanche et après on avait un boot.dat signé !
D'ailleurs je vous conseil pas trop forcement de l'utiliser car des cas de brick sont survenu !!!
Dans me process la modchip inject du code dans a nand si j'ai bien compris avec mon english à 2 balle

leurs os sont quasi toujours buggés en meme temps c'est pas nouveaux ça , j'utilises sx pro depuis le début mais ont a souvent eu des version pas stable

Je pense qu'il parle de la mise à jour initialisée au 1er démarrage du CFW post install' de la puce. Là possiblement ça doit injecter du code dans les Mariko/Lite. Mais pour nous autres qui avons du matos faillible (les premières Switchs), je doute qu'il y ait un risque de brick supp'.. Encore heureux la 2.9.5 étant déjà bien mitée, manquerait plus que ça.. lol

non comme toi je ne penses pas que les 1ere switch ça les brick en quoi que ce soit

Le process peut corrompre la nand donc a partir de là n'importe quel modèle est concerné !

tu as peur comme tu est beta testeur je supposes que l'ont la trouve et que l'ont l'utilises , en plus la puce est pour toutes les switch meme les V1 , donc la 3.0 c'est aussi pour les V1

Modifié par trantor, 31 mai 2020 - 18:52.

[bidobido]

Quel dommage d'avoir lâché ça dans la nature avant un diffusion public.
Pour avoir ce fameux boot.dat il fallait monter patte blanche et après on avait un boot.dat signé !
D'ailleurs je vous conseil pas trop forcement de l'utiliser car des cas de brick sont survenu !!!
Dans me process la modchip inject du code dans a nand si j'ai bien compris avec mon english à 2 balle

leurs os sont quasi toujours buggés en meme temps c'est pas nouveaux ça , j'utilises sx pro depuis le début mais ont a souvent eu des version pas stable

Je pense qu'il parle de la mise à jour initialisée au 1er démarrage du CFW post install' de la puce. Là possiblement ça doit injecter du code dans les Mariko/Lite. Mais pour nous autres qui avons du matos faillible (les premières Switchs), je doute qu'il y ait un risque de brick supp'.. Encore heureux la 2.9.5 étant déjà bien mitée, manquerait plus que ça.. lol

non comme toi je ne penses pas que les 1ere switch ça les brick en quoi que ce soit

Le process peut corrompre la nand donc a partir de là n'importe quel modèle est concerné !

Quand tu parles de process, tu parles bien de cette mise à jour au premier démarrage post installation de la puce ? Ou tu parles de l'initialisation du boot.dat ? Parce que si tu parles du boot.dat, je ne comprends pas pourquoi ça modifierait la NAND sur les Switch "classiques" qui n'useront pas de cette puce

Modifié par bidobido, 31 mai 2020 - 18:51.

[ConsoleX]

Quel dommage d'avoir lâché ça dans la nature avant un diffusion public.Pour avoir ce fameux boot.dat il fallait monter patte blanche et après on avait un boot.dat signé !D'ailleurs je vous conseil pas trop forcement de l'utiliser car des cas de brick sont survenu !!!Dans me process la modchip inject du code dans a nand si j'ai bien compris avec mon english à 2 balle

leurs os sont quasi toujours buggés en meme temps c'est pas nouveaux ça , j'utilises sx pro depuis le début mais ont a souvent eu des version pas stable

Je pense qu'il parle de la mise à jour initialisée au 1er démarrage du CFW post install' de la puce. Là possiblement ça doit injecter du code dans les Mariko/Lite. Mais pour nous autres qui avons du matos faillible (les premières Switchs), je doute qu'il y ait un risque de brick supp'.. Encore heureux la 2.9.5 étant déjà bien mitée, manquerait plus que ça.. lol

non comme toi je ne penses pas que les 1ere switch ça les brick en quoi que ce soit

Le process peut corrompre la nand donc a partir de là n'importe quel modèle est concerné !

Quand tu parles de process, tu parles bien de cette mise à jour au premier démarrage post installation de la puce ? Ou tu parles de l'initialisation du boot.dat ? Parce que si tu parles du boot.dat, je ne comprends pas pourquoi ils modifieraient ça sur les Switch "classiques" sachant que c'est déjà éprouvé depuis un bail et les multiples versions de sxos sorties depuis le lancement de leur soluce y'a maintenant 2 ans

oui 1er chargement du boot.dat ça injecte du code

Quel dommage d'avoir lâché ça dans la nature avant un diffusion public.Pour avoir ce fameux boot.dat il fallait monter patte blanche et après on avait un boot.dat signé !D'ailleurs je vous conseil pas trop forcement de l'utiliser car des cas de brick sont survenu !!!Dans me process la modchip inject du code dans a nand si j'ai bien compris avec mon english à 2 balle

leurs os sont quasi toujours buggés en meme temps c'est pas nouveaux ça , j'utilises sx pro depuis le début mais ont a souvent eu des version pas stable

Je pense qu'il parle de la mise à jour initialisée au 1er démarrage du CFW post install' de la puce. Là possiblement ça doit injecter du code dans les Mariko/Lite. Mais pour nous autres qui avons du matos faillible (les premières Switchs), je doute qu'il y ait un risque de brick supp'.. Encore heureux la 2.9.5 étant déjà bien mitée, manquerait plus que ça.. lol

non comme toi je ne penses pas que les 1ere switch ça les brick en quoi que ce soit

Le process peut corrompre la nand donc a partir de là n'importe quel modèle est concerné !

tu as peur comme tu est beta testeur je supposes que l'ont la trouve et que l'ont l'utilises en plus la puce est pour toutes les switch meme les V1 , donc la 3.0 c'est aussi pour les V1

Franchement je m'en tape
Juste respecter c'est le deal

Modifié par ConsoleX, 31 mai 2020 - 18:52.

[bidobido]

Hum très étrange ça.. Tu m'excuses mais je n'arrive pas à saisir le but de la manoeuvre pour ceux qui n'ont pas besoin d'installer cette puce pour avoir accès au hack RCM.

Y'a un truc qui m'échappe, ça me semble tellement illogique sachant qu'il n'en a rien été durant 2 ans et la sortie de la soluce avec dongle, je ne vois pas pour quel raison technique ils auraient à injecter du code qui modifierait la NAND aujourd'hui pour ces Switch là.

Wait and see tte façon..

Modifié par bidobido, 31 mai 2020 - 19:05.

[JohnConnor]

Bonjour,

du coup la team Xecuter avait des clés que SciresM avait pas ?
.......