244 réponses à ce sujet

[DOCKY99]

@tosuya86 je sais pas trop disont que j'avais quelque freeze et j'ai incriminé mon theme OS mais d'autres on le mmê; genre de problème

 que j'avais pas ou faiblment sur SX OS 1.9 .

Sinon faite un tour sur le forum

[BigDady]

É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.

Modifié par BigDady, 23 septembre 2018 - 23:35.

[gamo29]

bien expliqué mais il me manque un trou,
(je vais parler au conditionnel)
si la nand est dupliqué, elle contient m'on immatriculation? si cette immatriculation est grillé la nand original l'est aussi? a moins que la nand grillé nintendo injecte un code dedans?
si vous pouvez m’éclairer ca serait top , gracias !

Modifié par gamo29, 23 septembre 2018 - 23:31.

[megaoctet]

Merci @bigdady pour le temps passé a faire tes comparaisons et sur ce retour .

[eliboa]

bien expliqué mais il me manque un trou,
(je vais parler au conditionnel)
si la nand est dupliqué, elle contient m'on immatriculation? si cette immatriculation est grillé la nand original l'est aussi? a moins que la nand grillé nintendo injecte un code dedans?
si vous pouvez m’éclairer ca serait top , gracias !

oui ça ne change rien concernant le certifiat, c'est le même en emuNAND donc une console bannie l'est tout autant en OFW qu'en CFW (avec emuNAND).

 

Merci @bigdady pour le temps passé a faire tes comparaisons et sur ce retour .

ça ressemble à une traduction de ce post sur gbatemp => https://gbatemp.net/...nd-work.518936/

[tekuni]

bien expliqué mais il me manque un trou,
(je vais parler au conditionnel)
si la nand est dupliqué, elle contient m'on immatriculation? si cette immatriculation est grillé la nand original l'est aussi? a moins que la nand grillé nintendo injecte un code dedans?
si vous pouvez m’éclairer ca serait top , gracias !

oui ça ne change rien concernant le certifiat, c'est le même en emuNAND donc une console bannie l'est tout autant en OFW qu'en CFW (avec emuNAND).
 

Merci @bigdady pour le temps passé a faire tes comparaisons et sur ce retour .

ça ressemble à une traduction de ce post sur gbatemp => https://gbatemp.net/...nd-work.518936/

[Z0rP]

Le développeur Mike Heskin aka hexkyz a déchiffré la v2.0 de SX OS.

Ce qui ressort:

Spoiler

• SX OS silencieusement "implémenté" soutien pour IPS32 Patching (sous "sxos/exefs_patches")
• Tout est géré au démarrage qui commence par le montage de 3 dispositifs: "0:" (sdcard), "1:" (EmuNAND) et "3:" (NAND original)
• La partition NAND d'origine est rétrécie à environ la moitié de sa dimension
• Les contenus NAND originaux sont copiés dans l'espace libre;
• Deux blocs (0x200 bytes et 0x1000 bytes) sont écrits dans la partition Calo d'origine de la NAND (au décalage 0x3C0000). Les 0x200 bytes bloquent les êtres avec la valeur magique "EMUNAND0".
• Au démarrage, le bootloader vérifie la magie "EMUNAND0" et si elle le trouve, la deuxième copie NAND sera utilisée à la place
• Point de bonus: le bootloader vérifie maintenant si TPIDR_EL2 est défini et si elle est, EmuNAND est fortement désactivée et l'utilisateur sera toujours au démarrage dans le menu bootloader
  
• Le commutateur n'utilise pas EL2, mais vous pouvez vous rappeler un certain projet qui est prévu sur l'utilisation de EL2 pour EmuNAND (sous entendu d'un projet prévu avec atmosphère)

[shadow256]

Une chose que j'aimerai bien faire pour la FAQ serait d'avoir une archive des anciennes versions du SX OS mais comme j'ai perdu les fichiers suite à un crash disque je ne les aient plus. Du coup si quelqu'un les a je suis preneur.

[Toons62]

Je dois en avoir quelques unes genre 1.4, 1.5 ou 1.6 pas sur d'avoir les 2 et 1.9

[shadow256]

Se sera déjà un début, merci à toi. Si tu peux me faire une archive avec celle que tu as se sera déjà bien.

[jgjules]

Mister JBAM a posté une vidéo sur YouTube disant de ne surtout pas faire la mise a jour SX 2.0 qu'il aurait eu des informations confidentielle qui ne peux pas révéler

 

Pour ma part c'est trop tard déjà installé

D'ou faut écouté  ce qu'il et marqué ici et non dans les vidéo les gars eliboa et d'autre la dit d'attendre de voir

 

et je suis en sx 2.0 l'autorcm et bien désactivé j'ai pue tester aucun soucie sous firm 6.0

 

édit: par contre si ça intéresser quelqu'un j'ai garde l'archive du sx os 1.9

Modifié par jgjules, 24 septembre 2018 - 07:21.

[eliboa]

Bonjour à tous, suite aux différents retours d'utilisateurs lus ici ou là (gbatemp, discord, reddit), il devient de plus en plus évident que cette version 2.0 présentent plusieurs bugs. 

Aussi je ne serai pas surpris que la TX prépare une mis à jour pour les tous prochains jours. Il est sans doute plus prudent d'attendre avant d'utiliser cette version 2.0.

 

New éditée :

Edit 24/09 :

- Plusieurs utilisateurs remontent que SX OS 2.0 ne fonctionne pas pour les firmware 3.X. Restez en SX OS 1.9 si vous êtes dans ce cas, en attendant une correction.

- L'activation/désactivation de l'option AutoRCM semble ne plus fonctionner.

- Certains joueurs en FW 6.0 constatent des freeze/plantages lors de la sortie du mode veille alors qu'un jeu est en cours

 

[rafa020797]

Hello,
Malheureusement le SX OS 1.9 a été retiré de leur serveur... Quelqu'un aurait une copie à partager ? Aucune trace sur internet de ce dernier... Merci d'avance !

[jgjules]

Hello,
Malheureusement le SX OS 1.9 a été retiré de leur serveur... Quelqu'un aurait une copie à partager ? Aucune trace sur internet de ce dernier... Merci d'avance !

le voici j'ai gardé au cas ou 1.9 https://mega.nz/#!fa...DVHpvTyvHjLGfHE

Modifié par jgjules, 24 septembre 2018 - 08:45.

[trantor]

Bonjour à tous, suite aux différents retours d'utilisateurs lus ici ou là (gbatemp, discord, reddit), il devient de plus en plus évident que cette version 2.0 présentent plusieurs bugs. 
Aussi je ne serai pas surpris que la TX prépare une mis à jour pour les tous prochains jours. Il est sans doute plus prudent d'attendre avant d'utiliser cette version 2.0.
 
New éditée :

Edit 24/09 :
- Plusieurs utilisateurs remontent que SX OS 2.0 ne fonctionne pas pour les firmware 3.X. Restez en SX OS 1.9 si vous êtes dans ce cas, en attendant une correction.
- L'activation/désactivation de l'option AutoRCM semble ne plus fonctionner.
- Certains joueurs en FW 6.0 constatent des freeze/plantages lors de la sortie du mode veille alors qu'un jeu est en cours

 

comment ce fait t'il qu'ils sortent des versions aussi buggés comme ça c'est pas bon ça pour une team comme ça , donc ont beta test alors ? donc vivement conseillé de rester en 1.9 ? car il y a une personne ici qui soit disant ne boot plus sur le sx os depuis le 2.0 ? mais boot sur les autres cfw

Modifié par trantor, 24 septembre 2018 - 10:04.

[jgjules]

comment ce fait t'il qu'ils sortent des versions aussi buggés comme ça c'est pas bon ça pour une team comme ça , donc ont beta test alors ? donc vivement conseillé de rester en 1.9 ? car il y a une personne ici qui soit disant ne boot plus sur le sx os depuis le 2.0 ? mais boot sur les autres cfw

je pense qu'il teste mais pas a 100% doive sortir leur os trop vite ! pour la personne qui boot plus en 2.0 faut voir si il et pas en firmware 3.X.X mais en 6.0 aucun soucie d'ou pour ça que eliboa a bien dit d'attendre!

Modifié par jgjules, 24 septembre 2018 - 10:15.

[trantor]

comment ce fait t'il qu'ils sortent des versions aussi buggés comme ça c'est pas bon ça pour une team comme ça , donc ont beta test alors ? donc vivement conseillé de rester en 1.9 ? car il y a une personne ici qui soit disant ne boot plus sur le sx os depuis le 2.0 ? mais boot sur les autres cfw

je pense qu'il teste mais pas a 100% doive sortir leur os trop vite ! pour la personne qui boot plus en 2.0 faut voir si il et pas en firmware 3.X.X mais en 6.0 aucun soucie d'ou pour ça que eliboa a bien dit d'attendre!

moi j'ai remis en 1.9 et concernant l'emunand je ne le ferais pas car je vois que trop de risques !

Modifié par trantor, 24 septembre 2018 - 10:27.

[eliboa]

comment ce fait t'il qu'ils sortent des versions aussi buggés comme ça c'est pas bon ça pour une team comme ça , donc ont beta test alors ? donc vivement conseillé de rester en 1.9 ? car il y a une personne ici qui soit disant ne boot plus sur le sx os depuis le 2.0 ? mais boot sur les autres cfw

Oui sans doute un manque de tests, faut dire que ça coûte cher les tests et c'est long. Clairement la TX n'a pas pris le soin de tester la 2.0 sur chaque firmware vu le problème sur 3.X.

Le bug de l'autoRCM semble systématique sur 6.0 donc ils ont visiblement pas du tout testé cette fonction. Après les bugs aléatoires comme les freeze c'est sans doute plus dur à détecter et corriger. Quand aux briks suite à l'installation de l'emuNAND ou NAND dump, si c'est vrai c'est une grosse faute de leur part.

Et comme le dit @jgjules, il est fort probable qu'ils voulaient sortir l'emuNAND avant tout le monde pour augmenter les ventes car depuis qu'on peut convertir des XCI en NSP ils ont besoin de proposer une nouvelle exclu par rapport aux solutions gratuites. Après, autant je suis critique sur leur éthique, autant je pense qu'on peut compter sur eux pour apporter les corrections nécessaires rapidement.

Modifié par eliboa, 24 septembre 2018 - 10:30.

[trantor]

comment ce fait t'il qu'ils sortent des versions aussi buggés comme ça c'est pas bon ça pour une team comme ça , donc ont beta test alors ? donc vivement conseillé de rester en 1.9 ? car il y a une personne ici qui soit disant ne boot plus sur le sx os depuis le 2.0 ? mais boot sur les autres cfw

Oui sans doute un manque de tests, faut dire que ça coûte cher les tests et c'est long. Clairement la TX n'a pas pris le soin de tester la 2.0 sur chaque firmware vu le problème sur 3.X.
Le bug de l'autoRCM semble systématique sur 6.0 donc ils ont visiblement pas du tout testé cette fonction. Après les bugs aléatoires comme les freeze c'est sans doute plus dur à détecter et corriger. Quand aux bricks suite à l'installation de l'emuNAND ou NAND dump, si c'est vrai c'est une grosse faute de leur part.
Et comme le dit @jgjules, ils est fort probable qu'ils voulaient sortir l'emuNAND avant tout le monde pour augmenter les ventes car depuis qu'on peut convertir des XCI en NSP ils ont besoin de proposer une nouvelle exclu par rapport aux solutions gratuites. Après, autant je suis critique sur leur éthique, autant je pense qu'on peut compter sur eux pour apporter les corrections nécessaires rapidement.

si j'etais en 2.0 hier et comme je n'ais pas cree d'emunand et que j'ai pas activé l'auto RCM et touché a rien , la ce jour je suis repassé passé en 1.9 a nouveaux , l'auto RCM en 2.0 ne s'activait pas automatiquement ? j'ai rien besoin de toucher mise a part que jai remis en 1.9 vu que j'avais juste booté sur l'OS 2.0 et fait aucunes manip d'emunand ou autre ? en faite j'avais juste booté en sx os 2.0 c'est tout , rien fait d'autre

Modifié par trantor, 24 septembre 2018 - 10:32.

[eliboa]

si j'etais en 2.0 hier et comme je n'ais pas cree d'emunand et que j'ai pas activé l'auto RCM et touché a rien , la ce jour je suis repassé passé en 1.9 a nouveaux , l'auto RCM en 2.0 ne s'activait pas automatiquement ? j'ai rien besoin de toucher mise a part que jai remis en 1.9 vu que j'avais juste booté sur l'OS 2.0 et fait aucunes manip d'emunand ou autre ? en faite j'avais juste booté en sx os 2.0 c'est tout , rien fait d'autre

Non à mon avis ça devrait être bon pour toi.

Sinon pour info, on peut activer / désactiver l'autoRCM via Hekate (CTCaer mod), même s'il a été activé via le SX Loader.