Aller au contenu


Manulemalin

Inscrit(e) (le) 02 mai 2015
Déconnecté Dernière activité juil. 01 2020 13:06
-----

#1016360 [Switch] SX OS 2.0 disponible

Posté par eliboa - 24 septembre 2018 - 16:38

je suis encore en 5.1.0

J avais désactivé l'autoRCM au cas ou pour faire la sauvegarde... grosse erreur  LOL

Ben non c'est ce qu'il fallait faire logiquement, j'aurai fait pareil ^^, mais y'a visiblement un bug au niveau du SX bootloader




#1016256 [Switch] SX OS 2.0 disponible

Posté par BigDady - 23 septembre 2018 - 23:19

Étant donné que tout le monde semble avoir une idée du fonctionnement d’Emunand en regardant simplement les notes de publication, j’ai pensé essayer de découvrir comment exactement Emunand dans SX OS fonctionnait réellement. Aucune affirmation de conneries, de vrais faits.

Donc, j'ai créé une sauvegarde NAND sans emunand, puis effectué une autre sauvegarde NAND après la création d'emunand.

Voici ce que j'ai découvert à ce jour:

- boot0 est non modifiée
- boot1 est modifié avec EMUNAND0 viré à la fin (une zone non utilisée)

- TPG est UNMODIFIED
- Toutes les positions de partition / tailles sont UNMODIFIED
- Tout est non modifié , sauf pour la partition USER , en quels nouveaux fichiers ont été créés (appelés NAND01.bin, NAND02.bin, etc.)

Cela signifie qu'aucun redimensionnement n'a eu lieu. Seuls les nouveaux fichiers ont été créés, comme le ferait un système d'exploitation Nintendo classique.

Donc, de ce que nous pouvons conclure jusqu'ici: le mode OFW est en fait parfaitement sûr . Nintendo devrait activement commencer à détecter la magie EMUNAND0 dans boot1 ou commencer à détecter les nouveaux fichiers, ce qui serait hilarant s'ils commençaient à le faire. Ce point détectable est en réalité discutable , car avec EmuNAND stocké sur la microSD, Nintendo serait également capable de le détecter s’il commençait activement à le faire.

La partition redimensionnée prétend que tout le monde a craché des conneries .


Ok, voyons maintenant ce que contiennent exactement ces fichiers NAND?

En fin de compte, il reproduit la disposition du Switch eMMC mais à l’intérieur des fichiers NAND! Il est divisé en plusieurs parties de fichiers bin NAND.

Voici ce que j'ai découvert:
- boot0 à emunand est 100% exactement le même que le vrai
- Boot1 dans emunand est 100% le même que le vrai ( sans la magie EMUNAND0 )
- TPG dans emunand est SAME comme vrai
- Tous les partitions sont les mêmes sauf la partition USER.

Jusqu'à présent, tout est pareil et voici la différence: la taille du volume de la partition emunand USER est de 15 Go . Plus petit que le vrai.
C'est tout. C'est la seule différence.

Je pense qu'il est possible que la partition USER prenne la même taille que la partition réelle USER, mais remplissez la table FAT avec les clusters marqués USED.
HEY TX ÊTES-VOUS À L'ÉCOUTE ? Cela le rendrait EXACTEMENT identique à la partition réelle de l'utilisateur du point de vue du commutateur!

Mais avec cela dit, je ne vois aucune télémétrie envoyant la taille de la partition USER, donc cela n'a pas vraiment d'importance pour le moment .
Si je me trompe à ce sujet, faites-moi savoir quelle télémétrie il envoie et je le modifierai ici.

La télémétrie "NANDTotalSize" semble être modifiée, mais je ne l'ai pas encore vérifiée. Je le ferai plus tard.

C'est tout pour l'instant ce que j'ai réussi à découvrir, mais je pense qu'il est prudent de dire que les gens crachent des conneries jusqu'ici sans de réels faits.



Autre remarque: les fichiers bin NAND étant situés dans la partition USER, ils ne peuvent pas être pris en charge avec des modifications triviales apportées au module sysm FS.

Pour que cela fonctionne, vous devez réellement ... dire .. ÉMULER les commandes de lecture / écriture eMMC avec des correctifs dans le module sys FS.