18 réponses à ce sujet

[blackjak]

Bonjour, d'apres vous, est ce qu'un emunand switch en OFW pourrait être une idée totalement stupide ou pas?

J'ai pensé à cette solution pour quelqu'un qui veut profiter des nouveautés sans pour autant mettre à jour sa console.

Est ce que Nintendo pourrait détecter que c'est un emunand et bannir?

 

Apres de toute façon, ça ne m'a pas l'air faisable pour l'instant (si j'ai bien compris, il n'y a que sx os qui fait de l'emunand et il ne peut que démarrer en cfw) mais j'avais cette idée qui tournait dans ma tête.

[eliboa]

Salut, ce que tu dis est impossible. Une emuNAND ne peut fonctionner qu'en CFW. L'OFW c'est le firmware officiel de Nintendo, donc sauf si Nintendo voulait lui-même faire une emuNAND ça n'arrivera jamais.

[blackjak]

Donc c'est impossible d'avoir une Emunand qui fonctionne exactement comme une Sysnand?

[eliboa]

Une emuNAND fonctionne exactement comme une sysNAND, simplement ça ne fonctionne qu'en CFW pas en OFW.

[blackjak]

Ah après documentation sur les firmware, c'est vrai que c'est impossible vu qu'une emunand ne pourra jamais être charger par un OFW ...

Je ne savais pas que la structure pour être dites officiel était aussi grosse.

[eliboa]

Je repose mon petit schéma que j'avais fait pour expliquer le principe d'emuNAND. 

[blackjak]

Ce schéma n'est pas toujours vrai, vu que même avec une emunand, on peut toujours avoir la sysNAND en CFW (donc il manque une fleche)

[Cdtthor]

 

Le schéma est pourtant bien explicite et vrai ! Je ne comprends pas ce que tu veux dire quand tu dis "on peut toujours avoir la sysNAND en CFW", je pense que tu n'as pas compris en fait, quand tu démarres en CFW sans emunand, en gros, le CFW utilise la sysnand pour démarrer (on esquive ainsi la vérif des efuses etc . . .), du coup, sans emunand, si ton OFW est en 8.0.1 et que tu boot en CFW, ce dernier sera lui aussi en 8.0.1, alors que ce n'est pas spécialement vrai avec une emunand, car dans ce cas précis, tu peux très bien avoir conserver une sysnand par exemple en 4.0.1 et mis à jour ton emunand (sur microSD donc) en 8.0.1.

 

EDIT: Essaye donc de lancer ne serait-ce qu'un ".xci" en OFW, si tu y arrives, tu me fais signe ^^

Modifié par Cdtthor, 13 juin 2019 - 21:57.

[eliboa]

Ce schéma n'est pas toujours vrai, vu que même avec une emunand, on peut toujours avoir la sysNAND en CFW (donc il manque une fleche)

Ce que tu dis est tout à fait juste

 

edit : Cdtthor, les gens qui n'ont pas d'emuNAND utilisent bien un CFW avec leur NAND (la seule, la sysNAND) donc il a raison. Le firmware et l'OS sont stockés sur la NAND (emu ou sys) et le CFW (qui gère essentiellement le boot, le hardware et la sécurité) peut très booter sur la sysNAND ou l'emuNAND.

Modifié par eliboa, 13 juin 2019 - 23:40.

[loule42]

Ce schéma n'est pas toujours vrai, vu que même avec une emunand, on peut toujours avoir la sysNAND en CFW (donc il manque une fleche)

Salut je pense plutôt qui veut dire que si on a une emunand on a encore la possibilité de boot sur la sysNAND en CFW avec le disabled de l emunand au démarrage de SX OS.
Enfin c est que j ai cru comprendre dans se que disait blackjak.

Modifié par loule42, 14 juin 2019 - 06:37.

[blackjak]

Oui c'est ça, on peut choisir si on boot le CFW en EmuNAND (en activant l'option) ou en SysNAND (en désactivant l'option)

Mais apres je comprend le fait de ne pas avoir mis la fleche, c'est pour éviter que des gens soit perdu quand ils font le tuto. C'est plus simple de leur dire OFW=SysNAND et CFW=EmuNAND

[shadow256]

La question du sujet est loin d'être idiote et c'est une vision qui pourrait être vrai si Hekate devient capable de booter une Emunand. Je m'explique, d'après se que j'ai compris du code de l'emunand d'Atmosphere, en fait l'emunand se charge au démarrage (les redirections semblent se faire à ce moment là) et ensuite tout semble se dérouler comme sur un firmware standard donc on pourrait imaginer un truc du genre dans la config de Hekate:

[stock emunand]
fss0=atmosphere/fusee-secondary.bin
stock=1
emunand=1
emu_boot0=emunand/boot0.bin
emu_boot1=emunand/boot1.bin
emu_rawnand=emunand/rawnand.bin

Note: Pour la rawnand on pourrait aussi imaginer pouvoir booter sur un dump splitté en indiquant le premier fichier du dump, Hekate se chargeant de retrouver le reste du dump dans le même dossier, un peu comme le fait SX OS.

Bon bien évidemment là je m'avance probablement beaucoup trop mais on pourrait imaginer un fonctionnement du genre qui appliquerai les patches en démarrant le firmware pour que les redirections soient faites puis le firmware serait un firmware officiel. Après niveau utilité c'est pas vraiment utile, déjà parce que je pense que Nintendo pourrait vérifier vers quel matériel le système écrit (via son ID par exemple) et le rapporter dans ses logs, causant un bannissement de la console si c'est vers la SD que la lecture/écriture a lieu (après il est peut-être possible de faire un fake ID puisqu'au final on s'en fou, la nand n'étant pas utilisée pourquoi pas utiliser ses infos qui en fait écrieraient vers la SD mais bon ça me semble compliquer de faire ainsi)) et surtout pourquoi utiliser l'emunand pour un OFW alors que le principe de l'emunand est plutôt de pouvoir bidouiller sans risque. Le seul intérêt éventuel d'une tel chose pourrait être de ne pas griller les Efuses tout en profitant d'un OFW mais bon là Nintendo n'a qu'à vérifier les Efuses grillés et faire une comparaison avec le firmware qui se connecte et si ça ne match pas c'est le bannissement de la console, procéder qui doit être très possible et puis le risque aussi est que le BOOT0 de l'emunand pourrait avoir l'auto-RCM activé sans qu'on s'en rende compte puisque sur l'emunand qu'on soit en auto-RCM ou pas ne change rien au comportement de la console et là on sait que Nintendo vérifie ce point et peut bannir là-dessus. Un autre cas de figure pouvant être utile, une console ne fonctionnant plus avec la nand normal mais fonctionnant en emunand (certaines consoles semblent pouvoir fonctionner ainsi selon certains retours), là ça permettrai d'utiliser la console normalement pour ceux qui le souhaitent mais voilà, on se heurte au procédés de vérifications de Nintendo qui pourraient probablement bannir la console très vite, rendant donc l'utilisation de l'emunand de cette façon relativement inutile.

Bref, beaucoup de théorie dans mon commentaire mais une chose est certaine, très peut d'intérêt de faire une emunand OFW car pour Nintendo je pense qu'il n'est pas très difficile de vérifier sur quel type de nand on se trouve, rien qu'en vérifiant vers quel périphérique la lecture/écriture se fait je pense que ça fonctionnerait et le bannissement de la console serait pour ainsi dire immédiat. Après faut voir, quand l'Emunand d'Atmosphere sera prête on pourra en savoir plus mais bon il vaudra toujours mieux faire un CFW en Emunand et un OFW en Sysnand, cela reste clairement plus logique et énormément moins risqué.

[eliboa]

Tu nous as encore fait un paté Shadow lol mais le sujet est intéressant effectivement.
Par contre je pense qu'on à une incompréhension de terminologie pour CFW/OFW. Ce qui est normal car ce sont des concepts assez flous en vérité.
Empiriquement le firmware est l'ensemble des programmes qui gèrent le hardware mais dans la scène du hack console et plus précisément Switch, le firmware désigne le package 1 (qui contient le bootloader) et le package 2 (qui contient le kernel et les sysmodules). C'est tout ça l'OFW et le CFW est donc une ré implémentation, en totalité ou en partie, de ces packages. A ma connaissance aucun des 3 CFW de la Switch ne ré-implémentent complètement le package 1&2. On peut aussi concevoir l'OFW en y incluant des patch pour Horizon, ou même Horizon (quand on parle de faire une maj fimware 8.0.1 par ex, on englobe aussi l'OS). À titre de comparaison, sur un PC le "firmware" n'est que le BIOS de la carte mère, c'est bien différent.

Sachant que hekate se substitue au package1, pour moi on ne peut ne plus parler d'OFW, on est déjà dans un CFW, ou si on veut être plus précis un custom bootloader.

Edit : l'emuNAND d'Atmosphère est un hyperviseur EL2, donc qui intervient à un niveau assez bas dans le processus de boot effectivement (en comparaison avec une redirection des accès eMMC via module). Après est-ce que c'est géré uniquement au niveau du bootloader et est-ce que Hekate pourrait donc booter une emuNAND ? Je ne saurai dire.

Modifié par eliboa, 14 juin 2019 - 16:29.

[blackjak]

Ah ouais, ils sont vraiment en alerte niveau vérification sur la switch Nintendo. Donc dans ce cas, c'est juste quelques choses à faire pour le coté technique.

Mais comme le dit eliboa, on ne peut pas vraiment dire que c'est un OFW si le bootloader est modifié

[shadow256]

Effectivement, Hekate est clairement un custom bootloader, tout comme SX Loader, Fusee Primary ou encore le payload de ReiNX mais pour moi l'utilisation de Hekate ne justifie pas une appellation de CFW en sois pour la Switch, c'est plutôt quand on patch le package 2 qui contient réellement l'OS qu'on commence à pouvoir parler de CFW pour cette console. Les traces du bootloader étant déchargées de la mémoire une fois son travail effectué (sauf son fichier de configuration sur la SD mais là je doute que Nintendo se permette de vérifier se qui se trouve sur la SD, faut pas abuser, même si c'est leur console ça ne donne pas tous les droits et je pense que de telles vérifications seraient juridiquement difficiles à justifier dans un certain nombre de pays), finalement il ne reste donc en mémoire que le package 2 donc si on y a pas touché on peut toujours parler d'OFW même par un lancement via Hekate car comme on exécute le bootloader dans la ram de la console et que celui-ci n'est pas gardé en mémoire, finalement le package 1 n'est jamais réellement touché donc Nintendo peut bien faire toutes les vérifications qu'ils veulent à ce niveau c'est pour ainsi dire invisible.

Après dans le cadre de l'Emunand il est clair que cela est différent, il va bien falloir patcher des choses pour que cela fonctionne donc techniquement on sera en CFW quoi qu'il arrive, le tout est de savoir à quel(s) moment(s) cela se passe et du coup tenter d'en déduire si la détection de l'utilisation de l'Emunand sera aisément détectable par Nintendo ou non, comme je le théorise dans mon message précédent si on peut faire les redirections très tôt dans le processus de boot ça peut devenir compliquer de le détecter si les choses sont bien faites. Après comme je le dis aussi, il va falloir attendre qu'Atmosphere implémente l'Emunand pour en connaître plus sur son fonctionnement exacte car avec SX OS on peut déduire des choses mais bon au final il n'est pas possible de savoir comment tout le procéder fonctionne à moins d'être un génie du reverse engeniring ou du hack, affaire à suivre.

[eliboa]

Le package1 est décrit sur switchbrew.org comme un package du firmware et j'aurai tendance à penser qu'il vaut mieux réserver le terme OFW à un firmware (dont package1) officiel et non modifié. Après je suis bien d'accord que le package1 à lui seul n'est pas le firmware et que Hekate et SX Loader proposent une option pour lancer l'OFW... A noter que le package1 contient aussi la TrustZone. Le package2 ne contient pas l'OS, à ma connaissance Horizon est dans la partition SYSTEM.

Sinon pour en revenir à l'intérêt de booter une emuNAND sans toucher aux kernel ni sysmodule, en supposant que ça soit possible, je ne vois pas trop l'intérêt non plus, à part pour tester des homebrews avec des droits userland ça va pas chercher bien loin. Ou effectivement comme tu le disais Shadow, ça pourrait être utile en cas de sysNAND brickée.

[shadow256]

@eliboa : Effectivement j'ai pas pris le temps de lire et de décortiquer toutes les infos de switchbrew.org donc clairement j'essaie de vulgariser un peu en globalisant le fonctionnement se qui est de fait plus approximatif dans le raisonnement et clairement sur ce genre de choses tes connaissances sont bien plus poussées que les miennes (en même temps avec le développement de NXNandManager tu as eu besoin d'étudier plus en détail ces points-ci et de mon côté je n'ai jamais vraiment étudier le fonctionnement précis du boot de la Switch) mais bon si on résume en faisant un parallèle avec un PC en gros on a le bios qui charge les composants matériels basique comme pour un PC (c'est lui qui contient le mode RCM) puis ça charge BOOT0 qui est le bootloader original qui s'occupe de la suite (si nand brickée ou que la bonne combinaison de touches est pressée on charge le mode RCM et sinon on charge Horizon (BOOT1 donc qui s'occupe de lancer le reste de la rawnand)) et disons qu'avec l'intermédiaire de Hekate on a accès au Grub (je prend lui comme exemple car je pense que c'est le plus connu pour les PC) qui lui s'occupe donc d'amorcer le système de la manière souhaitée (boot d'Horizon avec des patches ou non (je ne sais pas si Hekate repart de BOOT0 ou reprend à BOOT1 par contre), boot de Linux...) mais au final si on ne patch rien le système n'a aucun moyen de savoir via quelle méthode l'OS a été booté, finalement on ne fait qu'ajouter un intermédiaire qui peut aussi ne rien faire de spécial et qui donc sera complètement transparent puisque non installé sur la nand en plus. Après sur les utilités de booter l'Emunand en mode "OFW", si cela est possible, on est clairement d'accord que c'est très limité mais bon, limité ne signifie pas inutile.

Edit: Pour ceux que ça intéresse, voici le changelog de la version 0.9.0 de la branche emunanddev d'Atmosphere, on y trouve quelques infos intéressante sur le fonctionnement de l'emunand d'Atmosphere qui va donc apparaître dans cette version du CFW et c'est très instructif, en tous cas on aura les mêmes options que pour l'Emunand de SX OS (Emunand via fichiers ou via une partition de la SD) avec comme d'habitude des réglages fins qui pourront être effectués, ça va être une fonctionnalité aux petits oignons mais qui sera, comme l'indique le changelog, en phase Beta pour la 0.9.0 et des améliorations seront apportées sur cette fonctionnalité en 0.9.1 et probablement jusqu'à la version 1.0.0 pour stabiliser le tout.
Edit 2: Bon bah voilà, la version 0.9.0 d'Atmosphere est sortie, plus qu'à tester les fonctionnalités de l'emunand.

Modifié par shadow256, 16 juin 2019 - 11:02.

[hanced]

bonsoir rien a voir avec ce sujet mais une question importante pour moi .

je suis en ofw 5.1 et sxpro sx version 2.7.1 je veux jouer a mario et gear club mais cela me demande de mettre a jour ma console .

je peux l a mettre a jour en 8.0 ou sup ou pas

par contre pas de emunand ou je sais quoi

merci a celui qui pourras me renseigner

[shadow256]

bonsoir rien a voir avec ce sujet mais une question importante pour moi .
je suis en ofw 5.1 et sxpro sx version 2.7.1 je veux jouer a mario et gear club mais cela me demande de mettre a jour ma console .
je peux l a mettre a jour en 8.0 ou sup ou pas
par contre pas de emunand ou je sais quoi
merci a celui qui pourras me renseigner

La même question sur ce sujet et celui-ci, t'as pas l'impression d'abuser, d'autant plus pour poser une question qui a déjà été posée au moins 50 fois sur le forum et dont la réponse se trouve, entre autres, dans la FAQ? En plus là t'es complètement hors sujet.

Modifié par shadow256, 17 juin 2019 - 08:24.