[Switch] Le SXOS 3.0.0 a été leaké

1412 visiteurs sur le site | S'incrire

Accédez aux coordonnées de l’ensemble des techniciens professionnels recommandés par logic-sunrise 20 derniers dossiers et tutoriaux
Wii / Wii U
[Switch] Le SXOS 3.0.0 a été leaké
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. 
 
 
Dimanche 31 Mai 2020, 18:33 par tralala
Source : twitter.com/hexkyz
31 mai 2020, 18:43
Approuver ce commentaire (+1)
+1
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
Répondre à ce commentaire
31 mai 2020, 18:57
Approuver ce commentaire (+1)
+1
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 ;)
Répondre à ce commentaire
31 mai 2020, 18:59
Approuver ce commentaire (+1)
+6

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

Répondre à ce commentaire
31 mai 2020, 19:05
Approuver ce commentaire (+1)
+3

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

Répondre à ce commentaire
31 mai 2020, 19:13
Approuver ce commentaire (+1)
+5
Enorme la scène Switch et ses avancées , faudrait des leak sur la scène PS4 aussi....
Répondre à ce commentaire
31 mai 2020, 19:26
Approuver ce commentaire (+1)
+2
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).
Répondre à ce commentaire
31 mai 2020, 19:29
Approuver ce commentaire (+1)
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 XD
Répondre à ce commentaire
31 mai 2020, 19:32
Approuver ce commentaire (+1)

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
Répondre à ce commentaire
31 mai 2020, 19:35
Approuver ce commentaire (+1)

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 XD

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.

Répondre à ce commentaire
31 mai 2020, 19:38
Approuver ce commentaire (+1)
+1

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 XD

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..
Répondre à ce commentaire
31 mai 2020, 19:38
Approuver ce commentaire (+1)

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 XD

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 :S
Répondre à ce commentaire
31 mai 2020, 19:41
Approuver ce commentaire (+1)

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 XD

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
Répondre à ce commentaire
31 mai 2020, 19:43
Approuver ce commentaire (+1)

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 XD

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é !
Répondre à ce commentaire
31 mai 2020, 19:44
Approuver ce commentaire (+1)

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

Arf oui ^^ 

Répondre à ce commentaire
31 mai 2020, 19:45
Approuver ce commentaire (+1)

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 XD

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
Répondre à ce commentaire
31 mai 2020, 19:47
Approuver ce commentaire (+1)

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 XD

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
Répondre à ce commentaire
31 mai 2020, 19:51
Approuver ce commentaire (+1)

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 XD

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 XD

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 :P 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 XD
Juste respecter c'est le deal
Répondre à ce commentaire
31 mai 2020, 20:03
Approuver ce commentaire (+1)
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..
Répondre à ce commentaire
31 mai 2020, 20:15
Approuver ce commentaire (+1)
Bonjour,

du coup la team Xecuter avait des clés que SciresM avait pas ?
.......
Répondre à ce commentaire
Utilisateur en ligne
31 mai 2020, 20:19
Approuver ce commentaire (+1)
+1

De toute façon la 3.0 "c'est "pour les mariko ; elle apporte rien en terme de fonctionnalité pour les v1 a part pour ceux  qui veule toujours êtres la la dernière version puis qui vont venir  se plaindre après ...

Répondre à ce commentaire
31 mai 2020, 20:23
Approuver ce commentaire (+1)

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

Exemple simple v1 avec data HS seul solution cette Modchip :)
Répondre à ce commentaire
31 mai 2020, 20:26
Approuver ce commentaire (+1)
+1

De toute façon la 3.0 "c'est "pour les mariko ; elle apporte rien en terme de fonctionnalité pour les v1 a part pour ceux  qui veule toujours êtres la la dernière version puis qui vont venir  se plaindre après ...


Apparemment (d'après un beta testeur à qui j'ai fait tester x et y choses) elle fixerait bien les bugs inhérents à la 2.9.5 donc je n'irai pas jusqu'à dire qu'elle ne sert à que dalle.

Et même si t'as totalement raison et que rien ne presse s'agissant d'upgrade son FW au plus vite avec les outils actuels à dispo pour retarder l'échéance (NSCB en tête), il n'empêche que ce n'est pas se plaindre que de constater que la 2.9.5 est foutrement pétée et d'escompter que ce soit fixé.
Répondre à ce commentaire
31 mai 2020, 20:30
Approuver ce commentaire (+1)

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

Exemple simple v1 avec data HS seul solution cette Modchip :)


Ok.. mais ça reste étrange.. Limite ça sent le boot.dat malicieux comme à l'époque du Gateway qui brickait les 3DS qui ne l'utilisaient pas lol
Répondre à ce commentaire
31 mai 2020, 20:33
Approuver ce commentaire (+1)

De toute façon la 3.0 "c'est "pour les mariko ; elle apporte rien en terme de fonctionnalité pour les v1 a part pour ceux  qui veule toujours êtres la la dernière version puis qui vont venir  se plaindre après ...


Apparemment (d'après un beta testeur) elle fixerait bien les bugs inhérents à la 2.9.5 donc je n'irai pas jusqu'à dire qu'elle ne sert à que dalle.

Et même si t'as totalement raison et que rien ne presse s'agissant d'upgrade son FW au plus vite avec les outils actuels à dispo pour retarder l'échéance (NSCB en tête), il n'empêche que ce n'est pas se plaindre que de constater que la 2.9.5 est foutrement pétée et d'escompter que ce soit fixé.

+ 1 c'est vrais il a raison , il parait quil ny a plus ces bug la de la 2.9.5 dans la 3.0.0
Répondre à ce commentaire
31 mai 2020, 22:36
Approuver ce commentaire (+1)
+2

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

Oui, sauf si tu démontes le module et que tu le mets sur une console non patchée puis que tu effectues le backup à partir de cette dernière, pour moi c'est la solution pour avoir un dump non modifié sur les Switch patchées (pas besoin de clés pour faire le backup/restore). Pour les Switch lite par contre je ne sais pas si c'est la même nand au niveau matériel que pour les Switch "normales", si non alors il faudra passer par une autre technique de dump.

Pour la modification de BOOT0 par contre si ça le fait aussi sur les Switch non patchées ça risque de ne pas plaire à la communauté surtout que ça n'aurait que très très peu d'intérêts sur ces consoles d'avoir à faire çà, après ça fera peut-être comme la première version de l'emunand de SX OS qui était sur la nand de la console qui a été une méthode vivement critiquée et la TX a revu ensuite la méthode.

Répondre à ce commentaire
31 mai 2020, 22:55
Approuver ce commentaire (+1)
C'est bien tout ça..mais ca nous amêne à rien pour le moment...^^
Répondre à ce commentaire
31 mai 2020, 23:06
Approuver ce commentaire (+1)
+1
Il n'y a aucune modification du boot0 sur les consoles non patchées
ainsi le lancement de cette 3.0.0 est exactement pareil que les versions antérieurs
Répondre à ce commentaire
01 juin 2020, 01:57
Approuver ce commentaire (+1)
C'est bien le seul leak que j'ai loupé Oo
Répondre à ce commentaire
01 juin 2020, 02:37
Approuver ce commentaire (+1)
+1

C'est bien le seul leak que j'ai loupé Oo


De même(telle un pokemon rare qui s'est ramené à un moment précis pour l'attraper et que tu as raté).
Répondre à ce commentaire
01 juin 2020, 10:20
Approuver ce commentaire (+1)
Hexkyz a livré de nombreux détails également .

https://twitter.com/...release.566383/

https://twitter.com/...803301774835712
Répondre à ce commentaire
01 juin 2020, 10:36
Approuver ce commentaire (+1)
Bravo à lui
On se souvient tous de l'autre guignol pragma
Répondre à ce commentaire
01 juin 2020, 10:44
Approuver ce commentaire (+1)
bientôt l'arrivé des clones :)
Répondre à ce commentaire
01 juin 2020, 10:47
Approuver ce commentaire (+1)
Ils ferait mieux de donner une vidéo du montage de la puce sx core sur mariko...
Répondre à ce commentaire
01 juin 2020, 11:14
Approuver ce commentaire (+1)
le script tx_decompress_v3_internal.py utilisé est fourni par hexyz
Répondre à ce commentaire
01 juin 2020, 12:05
Approuver ce commentaire (+1)
En même temps la team xecuter n'a plus trop le choix, ce leak ...
Ils ont peut être eu INTERDICTION de donner ce boot.dat V3.0 qui intègre des données privée voir sensible.
Enfin moi c'est ce que j'aurai fait
Niqué pour niqué

Merci pour la news, si ce leak existe ont peux l'avoir maintenant ?
Répondre à ce commentaire
01 juin 2020, 14:51
Approuver ce commentaire (+1)
Ben disons ce que je ne comprends pas ceux qu il me semble c'est que la TX avait indique que leur puce fonctionnerai avec atmosphere..... donc forcement il aurait fallait ce fameux boot.dat
Répondre à ce commentaire
01 juin 2020, 15:40
Approuver ce commentaire (+1)

pour les puces c'est sur et certain que des alternative serait sortie tôt ou tard (peut être plus rapidement avec ça maintenant) 

 

Vu qu'ils ont décrypter le boot.dat peut être une intégration du support XCI et DDext sur atmo ou reiNX ou je trompe complet la ?

Répondre à ce commentaire
01 juin 2020, 15:47
Approuver ce commentaire (+1)

Pour la modification de BOOT0 par contre si ça le fait aussi sur les Switch non patchées ça risque de ne pas plaire à la communauté surtout que ça n'aurait que très très peu d'intérêts sur ces consoles d'avoir à faire çà, après ça fera peut-être comme la première version de l'emunand de SX OS qui était sur la nand de la console qui a été une méthode vivement critiquée et la TX a revu ensuite la méthode.

 

A mons avis seuls les SoC "Mariko" sont concernés. Si on en croit cette citation de hexkyz qui indique que la puce (sx core) flashe BOOT0 avec une BCT et un nouveau package1 (bootloader), chiffré avec la BEK de Mariko et une clef de la TX. C'est donc ce package1 qui est lancé par la puce au lieu du package1 officiel. Ce custom bootloader irait d'abord vider les keyslots afin d'éviter qu'un tiers puisse obtenir les clés Mariko en utilisant la puce sx. Mais bon ça n'a servi à rien puisque SciresM et hexkyz les ont trouvé en moins de 24h héhé 

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. 

Je me demande par contre comment est flashé BOOT0, j'imagine que le package1 "normal" (offset 0x100000) est remplacé, mais quid du "backup" (offset 0x140000) ? Est-ce qu'il est flashé aussi ou s'agit-il du package1 officiel ? A moins qu'il ne soit backupé plus loin dans BOOT0, à un endroit non alloué habituellement).

 

 

Ben disons ce que je ne comprends pas ceux qu il me semble c'est que la TX avait indique que leur puce fonctionnerai avec atmosphere..... donc forcement il aurait fallait ce fameux boot.dat

C'est pas la puce de la TX qui permettra de lancer Atmosphère (ou n'importe quel payload), c'est leur bootloader (comme c'est déjà le cas en fait). Donc oui il faudra boot.dat mais à priori pas besoin de licence SX OS.

Répondre à ce commentaire
01 juin 2020, 22:25
Approuver ce commentaire (+1)

si vous regarder une version alpha fourni aux beta testeur vous irez pas loin  :ninja-speed:

 

de plus le faite que scirm fourni se genre de clés a tout public fais se poser des question sur son intergriter et la dangereusitez future fasse au gens mal attentionnée qui ont maintenant accès sans trop chercher

 

et étrangement personne dit rien quand ses lui de manière aussi flagrante par contre pour tx de simple rumeur et sa critique a tout va même quand ses faut ou par accusation sans preuve  :badplayer:

Répondre à ce commentaire
01 juin 2020, 22:42
Approuver ce commentaire (+1)

si vous regarder une version alpha fourni aux beta testeur vous irez pas loin  :ninja-speed:

 

de plus le faite que scirm fourni se genre de clés a tout public fais se poser des question sur son intergriter et la dangereusitez future fasse au gens mal attentionnée qui ont maintenant accès sans trop chercher

 

et étrangement personne dit rien quand ses lui de manière aussi flagrante par contre pour tx de simple rumeur et sa critique a tout va même quand ses faut ou par accusation sans preuve  :badplayer:

t'es un troll ?

il donne les hash SHA256 des clés, pas les clés en elles-mêmes.

Répondre à ce commentaire
01 juin 2020, 22:51
Approuver ce commentaire (+1)

t'es un troll ?

il donne les hash SHA256 des clés, pas les clés en elles-mêmes.

va lire la ba http://www.logic-sun...x-corelite.html

 

sa dit bien que le truc créer par scirm et reswitcher compromet la puce sx 

 

edit: de toute façon même les SHA256 ne se donne pas comme sa ne serve pas au gens lambda et les donner facilite l accès a ceux qui vont tenter de décrypter donc reviens a se que j ai dit 

Répondre à ce commentaire
01 juin 2020, 23:04
Approuver ce commentaire (+1)

edit: de toute façon même les cles SHA256 ne se donne pas comme sa ne serve pas au gens lambda et les donner facilite l accès a ceux qui vont tenter de décrypter donc reviens a se que j ai dit 

Tu t'enfonces là. Explique nous comment tu obtiens les clés à partir de leur hash ? 

Tu débarques sur la scène hack ou quoi ? C'est courant que les hackeurs donnent les hash des clés qu'ils trouvent. C'est un moyen de signaler, à ceux qui possèdent déjà ces clés, qu'ils les ont trouvé. Dans ce cas, seule la TX et une poignée de personnes peuvent savoir si ces hash sont corrects.

Répondre à ce commentaire
01 juin 2020, 23:07
Approuver ce commentaire (+1)

Tu t'enfonces là. Explique nous comment tu obtiens les clés à partir de leur hash ? 

Tu débarques sur la scène hack ou quoi ? C'est courant que les hackeurs donnent les hash des clés qu'ils trouvent. C'est un moyen de signaler, à ceux qui possèdent déjà ces clés, qu'ils les ont trouvé. Dans ce cas, seule la TX et une poignée de personnes peuvent savoir si ces hash sont corrects.

j ai pas dit qu il obtenait les cles j ai dit facilite ils n auront pas a chercher le SHA256 

 

edit: de toute facon avec l autre poste sa dit tout http://www.logic-sun...x-corelite.html

Répondre à ce commentaire
02 juin 2020, 12:18
Approuver ce commentaire (+1)

j ai pas dit qu il obtenait les cles j ai dit facilite ils n auront pas a chercher le SHA256 

 

edit: de toute facon avec l autre poste sa dit tout http://www.logic-sun...x-corelite.html

Chercher le SHA256 ? T'es bourré ou tu sais pas de quoi tu parles ?

Tu crois vraiment que quelqu'un cherche un hash de clé ? 

Stp, arrêtes de parler si tu maîtrises pas un minimum ton sujet. La crypto n'est pas un notion facile en informatique, je te conseille de commencer par des sujet plus simples comme la bureautique, Word, Excel tout ça.

Répondre à ce commentaire
02 juillet 2020, 14:48
Approuver ce commentaire (+1)
J'y connais rien .. mais si un leak de SxOs pouvait offrir la possibilité de voir la fonction de lecture des jeux directement sur un support USB ... sur atmosphere ou via un homebrew .. ça serait chouette.
Répondre à ce commentaire
02 juillet 2020, 15:13
Approuver ce commentaire (+1)

J'y connais rien .. mais si un leak de SxOs pouvait offrir la possibilité de voir la fonction de lecture des jeux directement sur un support USB ... sur atmosphere ou via un homebrew .. ça serait chouette.

Les devs d'Atmosphère ont pas besoin de s'embêter à dé-compiler SX OS pour ça, il sauraient faire sans crois moi.

Mon avis : le support HDD pour les backups ne sert qu'un seul but : le piratage de masse, voilà pourquoi tu n'as pas cette fonction sur Atmopshère.

Répondre à ce commentaire
Cliquer ici pour continuer sur le forum
Envoyer