240 replies to this topic

[megaoctet]

Du coup comme le dit @eliboa on peut clairement affirmer que des fichiers de la sysnand peuvent être modifiés par l'emunand (en plus ça semble peut-être aléatoire), ça craint je trouve, auto-RCM ou non cela n'y change rien. Quelque soit les fichiers modifié cela ne devrait pas se produire, surtout que c'est la partition "SYSTEM" qui est modifiée.

Du coup petite théorie de ma part, il est possible que SX OS lance la partition "SYSTEM" pour rediriger ensuite vers l'emunand, expliquant qu'il puisse y avoir des modifications de la partition "SYSTEM". Pour vérifier cela il faudrait intentionnellement bricker la partition "SYSTEM" en supprimant tous les fichiers se trouvant dessus puis en lançant l'emunand (l'emunand devra bien-sûre être créé avant cela et les fichiers de la partition "SYSTEM" doivent être sauvegardées pour être restaurés ensuite après le test (attention, bien afficher le fichiers cachées pour être certains de tout sauvegarder/restaurer) ou sauvegarder/restaurer la partition "SYSTEM" avec HacDiskMount et Memloader, c'est plus simple au final).

Bon je test les fichiers de SYSTEM aprés les avoir extrait (via memloader et hacDiskMout)

Mais tout à l'air ok entre les deux "version" Avant et aprés lancement de l'Emunand!

Est ce que le soucis pourrait venir du dump du fichier SYSTEM depuis hekate? Ca m'étonnerait ! 

 

Je vois que dans les nouveautés de Sxos on peut dumper la sysnand (en plusieurs parties, USER, SYSTEM...)

Je tente de faire deux dumps via leur interface 

Ce message a été modifié par megaoctet - 23 décembre 2018 - 16:58.

[eliboa]

Je pense pas que ça puisse venir d'hekate, la partition ne pourrait pas être déchiffrée avec les BIS keys si elle était altérée par hekate, je pense. 

Pas bête sinon l'idée de shadow de bricker sa nand et voir si le CFW en emunand est capable de lancer Horizon tout seul. 

Il faudrait aussi qu'on sache si seul le fichier PRF2SAFE.RCV est touché.

j'espère qu'on aura le fin mot de cette histoire, vu le temps que vous avez passés megaoctet et Tesla ^^

[megaoctet]

Je pense pas que ça puisse venir d'hekate, la partition ne pourrait pas être déchiffrée avec les BIS keys si elle était altérée par hekate, je pense. 

Pas bête sinon l'idée de shadow de bricker sa nand et voir si le CFW en emunand est capable de lancer Horizon tout seul. 

Il faudrait aussi qu'on sache si seul le fichier PRF2SAFE.RCV est touché.

j'espère qu'on aura le fin mot de cette histoire, vu le temps que vous avez passés megaoctet et Tesla ^^

Bon j'ai comparé les fichier a l'interieur de SYSTEM ils sont tous pareil   SHA256 semblable)

Peut etre que ca aurait été deux dump identiques.

J'ai fait un dump sysnand complet "rawnand.bin"

un Dump via hekate de "SYSTEM"

un DUmp via HacDIsk de "SYSTEM"

J'ai copié les fichiers a l'interieur de SYSTEM

Je suis prêt a les supprimer et à tester

Je reviens!

 

Edit: Je suis bien dans l'emunand sans soucis

        Le lecteur "SYSTEM" une fois monté est toujours vide donc rien n'a été écrit

        Bon je confirme que la console ne boot plus en Sysnand

        Aprés restauration de SYSTEM tout est revenu dans l'ordre 

 

Donc comme dirait l'autre ne rien trouver c'est déjà trouver quelque chose ! 

Ce message a été modifié par megaoctet - 23 décembre 2018 - 20:01.

[eliboa]

Merci pour le test. Donc la partition SYSTEM est bien émulée correctement, c'est plutôt rassurant par contre c'est quand même bizarre que tu détectes aléatoirement une différence sur tes dumps. Il doit bien y avoir un moment ou quelque chose écrit sur SYSTEM mais quand exactement...

Tesla a dit qu'il allait regarder les différences détectés dans SYSTEM. A suivre

Ce message a été modifié par eliboa - 23 décembre 2018 - 20:05.

[shadow256]

Bon toujours la même question, pourquoi diable cette emunand modifie des fichiers de la sysnand alors, la question de départ reste toujours sans réponse malgré tout ces tests. En tous cas on pourra dire que vous l'aurez testé cet emunand.

Ceci dit maintenant je pense qu'il faudrait en parler à la TX en leur relatant les tests qui ont été fait ici ainsi que leur donner les résultats histoire de comprendre se qui change et pourquoi, je doute qu'on arrive à aller beaucoup plus loin maintenant et eux pourraient peut-être apporter des éclaircissement, enfin s'ils répondent bien-sûre mais je pense qu'ils répondront à ce genre de demande.

[lorie3000]

et si c’était hardware? peut être c est la switch elle même qui modifie la sysnand 

Ce message a été modifié par lorie3000 - 23 décembre 2018 - 21:50.

[Tesla]

Donc j'ai refait 4 backups, et j'ai eu QUE un changement de PRF2SAFE. (et aucun autre fichiers de modifié)  (entre le 1er et le 2eme backup)

Donc sa reste étrange et je n'ai rien trouver sur le net qui pourrais expliquer exactement le contenu de PRF2SAFE .

 

Ce fichier ne serait pas un fichier de backup créer lorsque les partitions sont monté en lecture écriture ? ( pour les cas de corruption pour une reparation ) Et donc que c'est bien plus bas niveau que Horizon OS.

 

Faudrait essayer de faire 5-10 backups a la suite (avec un power off entre chaque) pour être sur que se fichier ne change pas ^^ mais j'ai pas le courage aujourd'hui

 

 

shadow256: Ben si, la reponse a la question de base a été donné par milerwan, sa vien de la mise a jours des joycons 

 

 

 

Perso je doute fortement que sa soit l'emunand qui modifie se fichier. Et je pense pas que la SX répondent a des questions dans ce genre ^^

Ce message a été modifié par Tesla - 23 décembre 2018 - 22:06.

[eliboa]

Donc j'ai refait 4 backups, et j'ai eu QUE un changement de PRF2SAFE. (et aucun autre fichiers de modifié)  (entre le 1er et le 2eme backup)

Donc sa reste étrange et je n'ai rien trouver sur le net qui pourrais expliquer exactement le contenu de PRF2SAFE .

 

Ce fichier ne serait pas un fichier de backup créer lorsque les partitions sont monté en lecture écriture ? ( pour les cas de corruption pour une reparation ) Et donc que c'est bien plus bas niveau que Horizon OS.

 

Faudrait essayer de faire 5-10 backups a la suite (avec un power off entre chaque) pour être sur que se fichier ne change pas ^^ mais j'ai pas le courage aujourd'hui

Le fichier porte une extension *.RCV donc je verrai bien aussi un fichier RECOVERY.

Je me demande si c'est pas le simple fait de passer en mode RCM qui créerait ce fichier. Je vais faire quelques tests de mon côté.

[shadow256]

Le fichier porte une extension *.RCV donc je verrai bien aussi un fichier RECOVERY.
Je me demande si c'est pas le simple fait de passer en mode RCM qui créerait ce fichier. Je vais faire quelques tests de mon côté.

Intéressant, peut-être effectivement. Après j'en doute, le recovery n'a normalement pas accès aux partitions de la Switch juste en le lançant, peut-être la partie "boot1" ou pendant le "boot2" (je me réfère aux phases d'Atmosphere là) mais le RCM tout seul ça m'étonnerai beaucoup.

@Tesla : Effectivement, tu as peut-être raison au final. Ceci dit je suis surpris que la mise à jour des joycons provoque une demande de mise à jour de certains jeux, j'aurais jamais pu penser qu'une telle politique aurait été appliquée par Nintendo.

et si c’était hardware? peut être c est la switch elle même qui modifie la sysnand

Un comportement hardware m'étonnerai beaucoup car normalement, si l'emunand était bien faite, toutes les redirections devraient être faites sur l'emunand et donc le hardware ne devrait pas se rendre compte qu'il y a une sysnand. Après si l'écriture se produit pendant les phases "boot0", "boot1" ou "boot2" là c'est différent car l'emunand ne gère peut-être pas toutes ces phases ("boot0" c'est certains en tous cas). Après la phase du "boot2" par contre le problème est forcément software. Bon encore une fois je ne fais que théoriser, je peux clairement me tromper.

[megaoctet]

Hello ,

Je viens de faire un dernier test pour la route

J'ai dumper le fichierSYSTEM via HacDisk , j'en ai donc profiter pour récupérer les fichiers a l'intérieur.

J'ai lancé l'emunand, j'ai mis a jour en 6.2 via choixdujour

J'ai redumper le Fichier SYSTEM via HacDisk et j'ai récupérer les fichiers aussi.

 

Les deux fichiers SYSTEM ne matchent pas un offset en erreur "offset 10C082D0" juste la ligne tous le reste du fichier est ok

 

Je me suis dis chouette ayant récupérer les fichiers je vais bien trouvé le fautif

Le SHA256 de tous le dossier et exactement pareil pour les deux ca commence mal

 

Je suis pas sûr qu'il faille que je compare fichiers par fichiers via l'éditeur du coup !

 

Voilà je sais pas quand j'aurais le temps de me replonger la dedant  

[milerwan]

Par rapport aux Joy-Con mis à jour depuis l'OFW 6.2 (ou 6.1), je viens d'essayer de m'en servir depuis le CFW 5.1 en mode détachés de la console et ils ne sont plus reconnus.
J'ai mis à jour le CFW en 6.1 puis fait une synchronisation à l'aide des boutons sync pour qu'elles sont reconnues.

Edit: peut-être que juste la synchronisation aurait suffit.

Ce message a été modifié par milerwan - 24 décembre 2018 - 00:40.

[alcain]

PF2SAFE c pas un mise en veille de l'écran a tout hasard ??

[eliboa]

J'ai fait quelques tests hier soir et visiblement le mode RCM en lui-même n'écrit pas sur SYSTEM mais j'ai fait que 4 tests, ce n'est peut-être pas assez.

Effectivement @alcain ça pourrait aussi venir de la mise en veille ou sortie de mise en veille.

 

Je reviens sur ce que j'avais vu avant-hier, sur gbatemp un utilisateur indique :

Both SYSTEM and USER gain a PRF2SAFE.RCV file when forcibly powering off the console

Donc je pense que le test à effectuer est bien de faire un arrêt forcé sur une console dont le fichier PRF2SAFE a été supprimé manuellement via HacDiskMount et voir s'il réapparaît. 

 

@milerwan, du coup je pense aussi que le problème de @lorie viendrait de la mise à jour joy-con

Ce message a été modifié par eliboa - 24 décembre 2018 - 10:40.

[lorie3000]

donc le problème est hardware les joycons communique avec les jeux pour passer l'info qu'il faut mettre a jour le jeu ?

[shadow256]

donc le problème est hardware les joycons communique avec les jeux pour passer l'info qu'il faut mettre a jour le jeu ?

D'après les tests il semblerait que oui.

[milerwan]

@milerwan, du coup je pense aussi que le problème de @lorie viendrait de la mise à jour joy-con

Le hic c'est qu' à présent tous les jeux Nintendo (Mario Kart, Mario Odyssey, Mario Tennis, etc) réclament d'être mis à jour pour pouvoir être lancés. :/

 

Ce message a été modifié par milerwan - 25 décembre 2018 - 20:41.

[durbanpoison29]

Le hic c'est qu' à présent tous les jeux Nintendo (Mario Kart, Mario Odyssey, Mario Tennis, etc) réclament d'être mis à jour pour pouvoir être lancés. :/

Fait comme moi réalisé un dump de tes jeux et bizarrement le dump lui passe sans MAJ.
Petite question certainement idiote, est il possible de récupérer l'update des joy cons ?

[alcain]

Fait comme moi réalisé un dump de tes jeux et bizarrement le dump lui passe sans MAJ.
Petite question certainement idiote, est il possible de récupérer l'update des joy cons ?

Mais c pas le fait que les joycons soit a jour qui pose pb ??

Ce message a été modifié par alcain - 25 décembre 2018 - 22:56.

[durbanpoison29]

Si apparemment, mais une fois le dump fait étrangement il y a demande de MAJ mais il est possible de la passé et joué.
Bizarre car mon jeux cartouche lui ne veut pas se lancer sans MAJ mais le dump oui...

[milerwan]

Mais c pas le fait que les joycons soit a jour qui pose pb ??

Il semblerait oui car depuis la mise à jour des Joy-Con, la console réclame une mise à niveau de tous les jeux Nintendo d'office.
Je suis revenu à mon backup d'emuNAND en 5.1 et c'est pareil.

Ils sont vicieux chez Nintendo. Sûrement avez-ils envisagé tous les cas de figure en cas de hack de leur console pour forcer la mise à jour réseau des jeux et par la même de la console.

 

Ce message a été modifié par milerwan - 27 décembre 2018 - 11:07.