83 replies to this topic

[armagad]

Silien3 c est pas faux effectivement il y a peut etre des firmwares differents en fonctionne des patche et non patche

J ai hate de voir les tests en approfondi.
Mais ta piste me semble tres judicieux

[silien3]

Silien3 c est pas faux effectivement il y a peut etre des firmwares differents en fonctionne des patche et non patche

J ai hate de voir les tests en approfondi.
Mais ta piste me semble tres judicieux

la puce est récente ont sera quoi bien assez tot comme dit see you soon lol

[Fatiguant]

Tkt trantor, cela ne concerne que les switchs patchées.

Je suis d'accord avec TheDark91, les béta-testeurs de la puce auraient quand même pu remonter l'info! Quand on teste, on teste à fond, pas simplement avoir une puce gratuite et faire la pose et l'utilisation de base, mais plutôt pousser à l’extrême, chercher les limites.. 10.0.3 est sorti le 26 mai, 10.0.4 le 05 juin.. Ça fait 2 semaines quand même.

L’info a ete dite depuis le debut des tests, et ces repeté un peu partout par la Tx.

J’aimerais bien te voir toi mdr allez on te donne une puce, tu prends le risque deja a la base de l’installer et tu voudrais qu’on fasse expret de lancer des hombrews pour voir si ca brique notre console personnel sans avoir d’outil de recuperation wow ! En fait la Tx aurait du sortir des outils debug en premier lieu tout simplement mais vue les situation actuelle du corona virus l’appat du gain est plus grand.

[Fatiguant]

Y a pas de question à se poser tout simplement que le processus est différent donc les outils ne sont pas compatible.
Choidujour brick uniquement en cas d’utilisation de l’autoRCM !
Suffit juste de faire des test avec une 2ème Nand

C’est pas juste l’autorcm hihi, t’a pas vu ce que tx avait inscrit ?

[JohnConnor]

bonjour,

Sur un commentaire ( sur les puce TX je pense ) un beta testeur ( apparemment ) avait écrit que c’était l'auto rcm qui planter tout

[trantor]

Y a pas de question à se poser tout simplement que le processus est différent donc les outils ne sont pas compatible.
Choidujour brick uniquement en cas d’utilisation de l’autoRCM !
Suffit juste de faire des test avec une 2ème Nand

C’est pas juste l’autorcm hihi, t’a pas vu ce que tx avait inscrit ?

qu'avais inscrit la tx j'ai zappé excuses , bon week end

[Linkynimes]

l'idéal pour vérifier tout sa serais de faire un topic sur forum et de tout complété au fur et a mesure comme la FAQ pour les V1 (rédigé par shadow qui plus est)

Ce message a été modifié par Linkynimes - 19 juin 2020 - 13:28.

[foxan]

Je comprends pas pourquoi les utilisateurs ce sont rush sur ces puces ...(plus général sur toute les nouvelle façon de hack une console)

 

Je peux comprends qu'on veut hack la console mais quand il s'agit d'une nouveau puce sur des console non hackable de base il vaut mieux attendre quelques semaine de plus et ne rien "casser, brick"(ça fait cher 300€ + ~60€) le temps que tous les outils sorte correctement ou soit fixe. On le sait  la TX a sortie les puces un peu prématurément pour ce faire de l'argent et sûrement à cause des leak/Nintendo donc on le sait aussi que c'est fonctionnelle mais pas opérationnelle à 100%.

 

Bref dans 1 mois atmosphère et les homebrew seront compatible à se moment là pour les utilisateur lambda ça sera utile de les faire poser avant c'est vraiment "idiot".

 

 

l'idéal pour vérifier tout sa serais de faire un topic sur forum et de tout complété au fur et a mesure comme la FAQ pour les V1 (rédigé par shadow qui plus est)

Je pense que se  sujet peut être ajouter à la FAQ après faudra voir si il y a une différence dans les futur outils entre les V1 ou les mariko pour créer une FAQ à part. 

Ce message a été modifié par foxan - 19 juin 2020 - 13:31.

[milerwan]

Sans avoir besoin de faire un backup de la NAND :
1. création de l'EmuNAND en fichiers depuis la microSD
2. sauvegarde des fichiers de l'EmuNAND sur l'ordi
3. faîtes n'importe quoi sur l'EmuNAND (mise à jour ou autre)
4. en cas de problème restauration des fichier de l'EmuNAND
5. zéro problème de brickage de la console possible

Merci, aurevoir.

PS: Si c'est l'activation de l'auto RCM qui est en cause c'est un autre problème.

Ce message a été modifié par milerwan - 19 juin 2020 - 13:59.

[Batman23]

Salut,

Oui hélas pour celles&ceux qui ont une puce sxos pour l'instant mise a jour via wifi uniquement (donc via serveur nintendo)


Note: Je pense que ces une sécurité de la team xecuteur ou alors un oublie dans le logciel de leurs puces.

Ce message a été modifié par Batman23 - 19 juin 2020 - 14:00.

[mikimike]

Je sais pas mais à ce train là m'étonnerait pas qu'ils sortent une rev2 ou rev3 de leur puce(tous ça est un peu précipité et on a droit à un produit mi fini mi alpha avec quand même des contraintes de brick)

Ce message a été modifié par mikimike - 19 juin 2020 - 14:39.

[trantor]

Salut,

Oui hélas pour celles&ceux qui ont une puce sxos pour l'instant mise a jour via wifi uniquement (donc via serveur nintendo)


Note: Je pense que ces une sécurité de la team xecuteur ou alors un oublie dans le logciel de leurs puces.

pour ceux en sx lite et core obligé via serveur nintendo pour mettre a jour et si ils ce font ban pfiou ?

Ce message a été modifié par trantor - 19 juin 2020 - 15:12.

[shadow256]

Sans avoir besoin de faire un backup de la NAND :
1. création de l'EmuNAND en fichiers depuis la microSD
2. sauvegarde des fichiers de l'EmuNAND sur l'ordi
3. faîtes n'importe quoi sur l'EmuNAND (mise à jour ou autre)
4. en cas de problème restauration des fichier de l'EmuNAND
5. zéro problème de brickage de la console possible

Merci, aurevoir.

PS: Si c'est l'activation de l'auto RCM qui est en cause c'est un autre problème.

Oui mais non en fait, c'est pas si simple car si t'as une mauvaise détection de quelques chose même l'exécution d'un outil sur l'emunand pourrait bricker la sysnand (sur le principe ça ne devrait pas être le cas mais dans les faits on en sait rien), ta méthode n'est pas du tout prudente. En plus qui te dit que l'emunand sur ce type de console n'est pas différente de la sysnand sur quelques tout petits points, faut aussi vérifier çà avant. Quand on fait des tests on les fait vraiment en suivant une méthodologie la plus précise possible, pas n'importe comment en ne se basant que sur des suppositions, la méthode que je propose est la seule garantie sans risque de brick logiciel impossible à résoudre (pour les bricks matériels là c'est différent). Et puis bon un technicien qui conseil implicitement de ne pas faire le dump de la nand franchement c'est pas terrible quand même.

@silien3 : Se qui est certains c'est que les consoles patchées sur un firmware 5.X.X et supérieurs génèrent autrement leurs Bis keys (voir un des changelogs d'Atmosphere récent, je ne me souviens plus lequel), chose qui n'est pas prévu par ChoiDuJour-NX. Autre chose, les clés Mariko sont aussi différentes des clés Erista donc ça non plus ChoiDuJour-NX ne le gère pas, j'ai déjà pu vérifier que les fichiers des firmwares 6.2.0 et supérieurs possèdent des fichiers identiques mais nommés différemment, probablement que cela a un lien avec les clés uniques à chaque console. Bref, il est clair que se sont les homebrews qui sont en cause car ils doivent être adaptés tout comme les payloads.

[TheDark91]

Sans avoir besoin de faire un backup de la NAND :
1. création de l'EmuNAND en fichiers depuis la microSD
2. sauvegarde des fichiers de l'EmuNAND sur l'ordi
3. faîtes n'importe quoi sur l'EmuNAND (mise à jour ou autre)
4. en cas de problème restauration des fichier de l'EmuNAND
5. zéro problème de brickage de la console possible

Merci, aurevoir.

PS: Si c'est l'activation de l'auto RCM qui est en cause c'est un autre problème.

Hello,
Comment fait on un backup de l'EmuNAND ?
J'ai une puce sur une V1 avec SXOS, faut-il faire ce backup juste après la pause de la puce ? ou on peut le faire après du moment que la console fonctionne bien ?
Merci pour ton aide.

[Ochidoris]

Sans avoir besoin de faire un backup de la NAND :
1. création de l'EmuNAND en fichiers depuis la microSD
2. sauvegarde des fichiers de l'EmuNAND sur l'ordi
3. faîtes n'importe quoi sur l'EmuNAND (mise à jour ou autre)
4. en cas de problème restauration des fichier de l'EmuNAND
5. zéro problème de brickage de la console possible

Merci, aurevoir.

PS: Si c'est l'activation de l'auto RCM qui est en cause c'est un autre problème.

Hello,
Comment fait on un backup de l'EmuNAND ?
J'ai une puce sur une V1 avec SXOS, faut-il faire ce backup juste après la pause de la puce ? ou on peut le faire après du moment que la console fonctionne bien ?
Merci pour ton aide.

Bonsoir,
Il ne s'agit pas de faire un backup de l'emunand mais de la sysnand sinon aucun intérêt.
Il est d'usage de la faire avant le lancement d'un cfw directement sur la sysnand pour avoir sa base propre en cas de restauration. Après, si tu as toujours eu une emunand, ta sysnand est clean.
Dans tous les cas, fait une sauvegarde même si ta sysnand n'est pas clean, ça pourrait te servir en cas de problème sérieux. Cdt

[bastendo]

C’est chaud pour mettre à jour sa Switch avec cette puce

[evilmanes]

Hum quel merdre une fois bricke ce bon pour la poubelle,et acheter une autre switch ce nintendo qui va etre content

[damien58]

Evidemment que sa marche pas deja est ce que les update sont les même si non sa revient comme 3ds ou on met pas l update new3ds sur la simple 3ds la ses update mariko sur mariko ect vu qu il n y avait rien personne ne savait dumper une maj des lite et mariko pour comparer si même que les autre ou pas si ses pas le cas ses normal que sa brick donc choix du jour y est peut être pour rien ou si s est chois du jour vu que sa a eter programmer pour les autre ses 2 switch différent vous pouvez dire se que vous voulez tant qui a pas eu des vérification et de l adaptation ses normal que sa n ira pas (et se pour beaucoup de chose qui allait avant) les code/securiter des switch  sont normalement différente des v1 a v2 et se même si l update est le même (et aussi ceux des puce diffère des switch d ailleurs)
 
mais tout sa ses pas dit on crashe direct tx (je dit pas que tx n a pas mit une telle limitation ni  qu ils l ont fait)
 
je souligne un point crucial avant de dire si y a limitation/bug ou pas

Ça pique les yeux..

[trantor]

C’est chaud pour mettre à jour sa Switch avec cette puce

heu oui je gardes mes 2 switch V1 en trinlet M0 ^^

Ce message a été modifié par trantor - 19 juin 2020 - 19:19.

[milerwan]

Oui mais non en fait, c'est pas si simple car si t'as une mauvaise détection de quelques chose même l'exécution d'un outil sur l'emunand pourrait bricker la sysnand (sur le principe ça ne devrait pas être le cas mais dans les faits on en sait rien), ta méthode n'est pas du tout prudente. En plus qui te dit que l'emunand sur ce type de console n'est pas différente de la sysnand sur quelques tout petits points, faut aussi vérifier çà avant. Quand on fait des tests on les fait vraiment en suivant une méthodologie la plus précise possible, pas n'importe comment en ne se basant que sur des suppositions, la méthode que je propose est la seule garantie sans risque de brick logiciel impossible à résoudre (pour les bricks matériels là c'est différent). Et puis bon un technicien qui conseil implicitement de ne pas faire le dump de la nand franchement c'est pas terrible quand même.

Depuis l'arrivée de l'EmuNAND, je n'ai pas vu l'utilité, en effet, de réaliser un dump de la NAND sur une console équipée de ce système.
Outre le temps à y consacrer, il ne s'est jamais posé la question jusqu'à présent aux utilisateurs de ce système de s'occuper de la NAND car on ne fait que bidouiller sur l'EmuNAND.

D'ici quelques temps on y verra plus clair dans ces histoires de bricks, d'ici là on peut toujours conseiller aux utilisateurs de puces TX de dumper la NAND par prudence c'est sûr.

Ce message a été modifié par milerwan - 19 juin 2020 - 19:23.