Salut, j'ai une switch XAJ40051852944. Quand je vais sur ce site : https://damota.me/ssnc/checker/, elle apparait en orange. Du coup pas sur que le hack passe mais peut etre que si... Je ne trouve pas plus de précisions. Probablement que seul le test permettrait d'y voir plus clair.
C'est la qu'est ma question : ma console est en 10.0.2
Si je rentre en rcm avec un jig (a priori toutes les swicth peuvent le faire) :Je voudrais le faire partir de mon pc avec tegrarcmgui : logiquement l'icone verte doit s'allumer.
Si j'ai bien compris c'est ensuite que rien ne se passe quand la switch est patchée?
Que se passe il si ca marche pas ? Y a t il un risque de la briquer ?
est ce que je peux sauvegarder la nand sans hacker la console ? Y a t il un risque pour celle ci ?
merci pour vos reponses je préfere ne pas m'enflammer pour pas faire de betises.
Dump Nand debutant ++
Discutez ici des logiciels gravitant autour du hack de la Switch. N'hésitez pas à poser vos questions, à partager vos trouvailles, conseils ou bonnes pratiques, etc.
-
badablek
- Administrateur
- Réactions :
- Messages : 1369
- Enregistré le : 08 avr.avr. 2019, 20:19
- Localisation : Nancy
salut nucleus,
c'est simple à tester. Tu mets la console en RCM, et tu injectes le payload de Hekate. Si tu restes sur un écran noir, c'est mort. Si Hekate se lance, c'est OK.
le mode RCM ne modifie rien à la console, c'est un processus d'urgence qui offre la possibilité de lancer un binaire en outrepassant le système de démarrage normal (et les protections qui vont avec, base du hack Switch). Donc ce que tu testeras en mode RCM n'affectera jamais ta console.
Si ta console s'avère compatible, tu pourras à ce moment-là dumper ta NAND sans aucun problème, et poursuivre son hack par la méthode de ton choix (Atmosphère ou SXOS)
c'est simple à tester. Tu mets la console en RCM, et tu injectes le payload de Hekate. Si tu restes sur un écran noir, c'est mort. Si Hekate se lance, c'est OK.
le mode RCM ne modifie rien à la console, c'est un processus d'urgence qui offre la possibilité de lancer un binaire en outrepassant le système de démarrage normal (et les protections qui vont avec, base du hack Switch). Donc ce que tu testeras en mode RCM n'affectera jamais ta console.
Si ta console s'avère compatible, tu pourras à ce moment-là dumper ta NAND sans aucun problème, et poursuivre son hack par la méthode de ton choix (Atmosphère ou SXOS)
super merci pour cette réponse rapide c'est exactement ca que je voulais savoir !!!
grand merci
grand merci
Bonn ben j'ai testé ce soir, la bonne nouvelle c'est que j'arrive a rentre en rcm ! le voyant est au vert et l'injection semble vouloir fonctionner du coup ma switch serait hackable ?
par contre j'ai des messages d'erreur :
mise en route en rcm ok
injection payloade ok
mais au demarage de la console
message en jaune :
missing lp0 (sleep mode)library!
missing or old minerva library!
update your bootloader folder
j apuis quand meme, encore d otre message en rouge qui s afiche 2 seconde .
la j arive sur hekate
en bas un warning en rouge : nys is missing
quand jhe fais tools, j'ai juste autorcl dans other
du coup pas possible de sauvegarder ma nand
des idées ?
EDIT : j'ai trouvé : je suis allé sur github retelechargé le pack. Reformater ma sd en exfat, copier coller le bootloader sur la sd. ca roule je sauvegarde
par contre j'ai des messages d'erreur :
mise en route en rcm ok
injection payloade ok
mais au demarage de la console
message en jaune :
missing lp0 (sleep mode)library!
missing or old minerva library!
update your bootloader folder
j apuis quand meme, encore d otre message en rouge qui s afiche 2 seconde .
la j arive sur hekate
en bas un warning en rouge : nys is missing
quand jhe fais tools, j'ai juste autorcl dans other
du coup pas possible de sauvegarder ma nand
des idées ?
EDIT : j'ai trouvé : je suis allé sur github retelechargé le pack. Reformater ma sd en exfat, copier coller le bootloader sur la sd. ca roule je sauvegarde
-
badablek
- Administrateur
- Réactions :
- Messages : 1369
- Enregistré le : 08 avr.avr. 2019, 20:19
- Localisation : Nancy
bah bonne nouvelle, je confirme (mais tu l'as bien compris) : ta Switch est hackable 
donc là, dump de la sysNAND (impératif ! et à garder au chaud), et après tu pourras t'amuser avec Atmosphère.
donc là, dump de la sysNAND (impératif ! et à garder au chaud), et après tu pourras t'amuser avec Atmosphère.
merci pour ton retour c'est cool !
j'ai récupéré un fichier de 29.1go et 2 fichier boot c'est bien ca ?
après ca la switch ne craint plus rien ?
j'ai récupéré un fichier de 29.1go et 2 fichier boot c'est bien ca ?
après ca la switch ne craint plus rien ?
-
badablek
- Administrateur
- Réactions :
- Messages : 1369
- Enregistré le : 08 avr.avr. 2019, 20:19
- Localisation : Nancy
C'est bien ça.
avec ces fichiers, tu retomberas toujours sur tes pattes. Par contre, c'est une image à un instant t, avec un nombre d'efuses correspondant au firmware actuel. Imaginons que, demain, tu passes à une MAJ supérieure majeure (qui crame un efuse), qu'elle se passe mal et que tu décides de réinjecter ton dump, le nombre d'efuses ne sera pas bon, et la console ne démarrera pas sans autorcm ou en passant par hekate.
Mais c'est un moindre mal, tu pourras toujours avoir une console fonctionnelle.
avec ces fichiers, tu retomberas toujours sur tes pattes. Par contre, c'est une image à un instant t, avec un nombre d'efuses correspondant au firmware actuel. Imaginons que, demain, tu passes à une MAJ supérieure majeure (qui crame un efuse), qu'elle se passe mal et que tu décides de réinjecter ton dump, le nombre d'efuses ne sera pas bon, et la console ne démarrera pas sans autorcm ou en passant par hekate.
Mais c'est un moindre mal, tu pourras toujours avoir une console fonctionnelle.
tu me parles chinois mais je te crois ;o)) c'est quoi un efuse ?
-
badablek
- Administrateur
- Réactions :
- Messages : 1369
- Enregistré le : 08 avr.avr. 2019, 20:19
- Localisation : Nancy
c'est un fusible électronique, présent directement dans le CPU (Tegra X1) de la console. Tu en as un nombre défini (je crois que c'est 99) et à chaque mise à jour, majeure ou non, Nintendo peut décider d'en "cramer" un ou plusieurs.
Admettons que tu partes de 0 fusible, console vierge (ce qui suit n'est que pure hypothèse pour appuyer mes propos, ça n représente pas des firmwares existants ni un décompte d'efuses réel) :
Nintendo sort un firmware 2.0 et crame un efuse, le décompte est donc de 1 efuse HS
Puis sort un firmware 3.0 et crame un efuse, le décompte est donc de 2 efuses HS
Puis sort une petite mise à jour de ce firmware en 3.1 sans cramer de efuse, le décompte reste à 2 efuses HS
Et enfin un firmware 4.0 qui crame 2 efuses, le décompte est donc de 4 efuses HS
Imaginons que tu sois en 3.1 et qu'il te prend l'idée (mauvaise !) de repasser au firmware 2.0, dont on vient de découvrir une faille en or, le truc qui te permet de hacker la console à vie, sans dongle, sans jig.
Tu tentes de réinstaller le firmware 2.0, qui se déroule super (hélas). Tu redémarres, et tu sors les mouchoirs, parce que ta console ne démarre plus du tout. Le Firmware 2.0 attend un compteur de efuses HS à 1, mais ton CPU a 2 efuses cramés puisque tu étais à l'origine en 3.1 ! Donc kernel panic, la console refuse de démarrer.
Par contre, comme entre les firmwares 3.0 et 3.1, Nintendo n'a pas cramé de efuses, tu pourrais tout à fait repasser de 3.1 à 3.0, par exemple.
Et idem dans l'autre sens, admettons que tu veuilles passer de 3.1 à 4.0 de manière non officielle, avec les outils que le hack te propose, et que tu décides de ne pas cramer d'efuses intentionnellement (t'autorisant ainsi à revenir en 3.1/3.0 si tu veux !), si tu essaies de démarrer la console (sans hack), ton compteur CPU efuses sera à 2 alors que le firmware en attendra 4 (et la console va alors automatiquement cramer les efuses nécessaires ! donc plus de retour possible dans ce cas
Bref, les efuses sont un moyen d'empêcher les retours en arrière de firmware (downgrades) tout en maîtrisant les firmwares exécutables (un firmware trop récent avec un compteur efuses trop bas, et c'est le drame), puisque le CPU et le firmware tiennent le compte et se mettent en carafe si les deux valeurs ne correspondent pas (sauf si le firmware attend plus de efuses cramés que ce que ne contient le CPU, auquel cas le firmware va cramer le nombre nécessaire pour que ça corresponde)
Le cas d'un dump NAND (admettons en 3.0), qui serait réinjecté alors que tu avais passé la console en (admettons toujours) 4.0 par exemple, correspond exactement à un downgrade. Le dump NAND contient un firmware 3.0 qui attend 2 efuses cramés, alors que ton CPU en contient 4 cramés. Et oui, je ne l'ai pas précisé, mais ça me semble évident, on parle de efuses directement DANS le CPU. Quand c'est cramé, c'est pour de bon. Ce n'est pas comme un tableau électrique où tu peux changer le fusible
Admettons que tu partes de 0 fusible, console vierge (ce qui suit n'est que pure hypothèse pour appuyer mes propos, ça n représente pas des firmwares existants ni un décompte d'efuses réel) :
Nintendo sort un firmware 2.0 et crame un efuse, le décompte est donc de 1 efuse HS
Puis sort un firmware 3.0 et crame un efuse, le décompte est donc de 2 efuses HS
Puis sort une petite mise à jour de ce firmware en 3.1 sans cramer de efuse, le décompte reste à 2 efuses HS
Et enfin un firmware 4.0 qui crame 2 efuses, le décompte est donc de 4 efuses HS
Imaginons que tu sois en 3.1 et qu'il te prend l'idée (mauvaise !) de repasser au firmware 2.0, dont on vient de découvrir une faille en or, le truc qui te permet de hacker la console à vie, sans dongle, sans jig.
Tu tentes de réinstaller le firmware 2.0, qui se déroule super (hélas). Tu redémarres, et tu sors les mouchoirs, parce que ta console ne démarre plus du tout. Le Firmware 2.0 attend un compteur de efuses HS à 1, mais ton CPU a 2 efuses cramés puisque tu étais à l'origine en 3.1 ! Donc kernel panic, la console refuse de démarrer.
Par contre, comme entre les firmwares 3.0 et 3.1, Nintendo n'a pas cramé de efuses, tu pourrais tout à fait repasser de 3.1 à 3.0, par exemple.
Et idem dans l'autre sens, admettons que tu veuilles passer de 3.1 à 4.0 de manière non officielle, avec les outils que le hack te propose, et que tu décides de ne pas cramer d'efuses intentionnellement (t'autorisant ainsi à revenir en 3.1/3.0 si tu veux !), si tu essaies de démarrer la console (sans hack), ton compteur CPU efuses sera à 2 alors que le firmware en attendra 4 (et la console va alors automatiquement cramer les efuses nécessaires ! donc plus de retour possible dans ce cas
Bref, les efuses sont un moyen d'empêcher les retours en arrière de firmware (downgrades) tout en maîtrisant les firmwares exécutables (un firmware trop récent avec un compteur efuses trop bas, et c'est le drame), puisque le CPU et le firmware tiennent le compte et se mettent en carafe si les deux valeurs ne correspondent pas (sauf si le firmware attend plus de efuses cramés que ce que ne contient le CPU, auquel cas le firmware va cramer le nombre nécessaire pour que ça corresponde)
Le cas d'un dump NAND (admettons en 3.0), qui serait réinjecté alors que tu avais passé la console en (admettons toujours) 4.0 par exemple, correspond exactement à un downgrade. Le dump NAND contient un firmware 3.0 qui attend 2 efuses cramés, alors que ton CPU en contient 4 cramés. Et oui, je ne l'ai pas précisé, mais ça me semble évident, on parle de efuses directement DANS le CPU. Quand c'est cramé, c'est pour de bon. Ce n'est pas comme un tableau électrique où tu peux changer le fusible
whaou... jamais entendu parler de ca... un bon plan antipiratage
merci pour les explications
ca a progressé depuis la wii !!!
Si je comprends bien dans mon cas, ne jamais redescendre en dessous du firmware 10.2.0 et si fais un downgrade firmware, sachant que si je met a jour mon firmware dans le future avec le homebrew ca protegera les efuses (qui resteront a l'étape 10.2.0) ? C'est bien ca ?
En gros plus ta console a été piratée tot, plus tu as de chances de pouvoir fairez ce que tu veux dans le futur ?
La question qu'il me reste c'est que si le hack disparait des que la console est eteinte ? Imùaginons qu'entre temps nintendi soit passé en 10.8.0
Du coup je rebasculerai en 10.2.0 mais est ce que j'aurais la possibilité de la signer en 10.8.0 officiel sans tout planter ?
merci pour les explications
ca a progressé depuis la wii !!!
Si je comprends bien dans mon cas, ne jamais redescendre en dessous du firmware 10.2.0 et si fais un downgrade firmware, sachant que si je met a jour mon firmware dans le future avec le homebrew ca protegera les efuses (qui resteront a l'étape 10.2.0) ? C'est bien ca ?
En gros plus ta console a été piratée tot, plus tu as de chances de pouvoir fairez ce que tu veux dans le futur ?
La question qu'il me reste c'est que si le hack disparait des que la console est eteinte ? Imùaginons qu'entre temps nintendi soit passé en 10.8.0
Du coup je rebasculerai en 10.2.0 mais est ce que j'aurais la possibilité de la signer en 10.8.0 officiel sans tout planter ?