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
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).
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.
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 stableQuel 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
Tu n'as pas accès à la fonction backup avant d'avoir flashé le boot0C'é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 ^^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
Oui, apparemment ça flashe la partition BOOT0, donc le mieux est d'avoir un backup des boots à minima.
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 aussileurs 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 stableQuel 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
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
Le process peut corrompre la nand donc a partir de là n'importe quel modèle est concerné !non comme toi je ne penses pas que les 1ere switch ça les brick en quoi que ce soitleurs 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 stableQuel 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
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
Tu n'as pas accès à la fonction backup avant d'avoir flashé le boot0
Arf oui ^^
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 V1Le process peut corrompre la nand donc a partir de là n'importe quel modèle est concerné !non comme toi je ne penses pas que les 1ere switch ça les brick en quoi que ce soitleurs 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 stableQuel 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
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
Le process peut corrompre la nand donc a partir de là n'importe quel modèle est concerné !non comme toi je ne penses pas que les 1ere switch ça les brick en quoi que ce soitleurs 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 stableQuel 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
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
oui 1er chargement du boot.dat ça injecte du codeQuand 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 ansLe process peut corrompre la nand donc a partir de là n'importe quel modèle est concerné !non comme toi je ne penses pas que les 1ere switch ça les brick en quoi que ce soitJe 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.. lolleurs 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 stableQuel 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
Franchement je m'en tapetu 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 V1Le process peut corrompre la nand donc a partir de là n'importe quel modèle est concerné !non comme toi je ne penses pas que les 1ere switch ça les brick en quoi que ce soitJe 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.. lolQuel 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 balleleurs 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
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 ...
Exemple simple v1 avec data HS seul solution cette ModchipHum 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..
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 ...
Exemple simple v1 avec data HS seul solution cette ModchipHum 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..
+ 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.0De 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é.
Tu n'as pas accès à la fonction backup avant d'avoir flashé le boot0
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.
C'est bien le seul leak que j'ai loupé Oo
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 ?
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.
si vous regarder une version alpha fourni aux beta testeur vous irez pas loin
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
si vous regarder une version alpha fourni aux beta testeur vous irez pas loin
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
t'es un troll ?
il donne les hash SHA256 des clés, pas les clés en elles-mêmes.
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
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.
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
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.
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.