Aller au contenu


eliboa

Inscrit(e) (le) 14 mars 2018
Déconnecté Dernière activité Privé
-----

Sujets que j'ai initiés

Redimensionner la partition FAT32 d'une SD formatée avec SX OS ?

21 octobre 2019 - 19:50

Quelqu'un à déjà réussi à redimensionner la partition FAT nommée "TXNAND" qui est créée par SX OS lors de la creation d'une emuNAND en partition cachée de la SD ?

Chaque fois que je la redimensionne, SX OS n'arrive pas à trouver BOOT.dat alors qu'Hekate arrive bien à lire/écrire sur cette partition, même redimensionnée...


Organisation du forum

26 juin 2019 - 22:42

Aux modos et membres actifs,

Je me dit que ça ferait pas de mal de remanier un peu la section Switch. Le forum "Hack" est plein de threads épinglés, la F.A.Q est hyper exhaustive (peut-être trop?), et avec l'arrivée des exploits pour les switch non patchées, plein de personnes posent des questions pour avoir des tutos "simples" ou des messages "clairs" sur comment hacker leur console (notez l'ironie). Bref, je me dis que ça serait pas mal de faire un thread pour les "beginners" qui explique simplement les méthodes disponibles (et les risques) avec des liens vers les tutos utiles. Je pense qu'il faudrait aussi aussi épurer la liste des sujets épinglés car perso je trouve que ça fait trop. Il faudrait les référencer dans un post comme la F.A.Q ou justement un dans un guide pour les débutants.

Voilà, les habitués, qu'en pensez-vous ? Etes-vous d'accord et/ou quelles sont vos idées pour réduire la pollution des news/forums avec des questions qui reviennent sans cesse (malgré la FAQ de shadow, tellement complète pourtant) ?

PS : Je suis bien conscient qu'il y aura toujours des gens qui poseront des questions sans chercher, j'ai juste l'impression que le "trop d'information" et tutos épinglés rend l'accès à l'information difficile pour les nouveaux venus.

[Switch] La TX à la peine concernant SX OS ?

11 mars 2019 - 11:39

Un mois et demi après la sortie du firmware 7.0 (suivi peu après du 7.0.1), le CFW de la Team Xecuter n’est toujours pas compatible avec ce nouveau firmware. L’attente se fait longue pour les propriétaires de licence SX OS qui ont mis à jour leur console.

 

Alors que les développeurs d'Atmosphère (SciresM en tête) ont réussi à cracker le nouveau firmware du TSEC (Tegra Security Co-processor), et ainsi rendu le CFW (libre et open source) compatible avec le FW 7.0, force est de constater que les choses sont plus compliquées du côté de la TX.

 

Avec l’attente les rumeurs vont bon train, est-ce que la TX est vraiment capable de cracker ce TSEC ? Certains prévoient même la mort du SX OS... Mais faut-il vraiment s’inquiéter (ou se réjouir) de cette longue attente ?

 

“Sept”, le nouveau payload permettant de dériver les clés du FW7.0 a été protégé de la copie sauvage par l’équipe d'Atmosphère. Une partie du payload est chiffré afin de ne pas divulguer le nouvel exploit utilisé pour cracker le TSEC FW (l’ancien exploit basé sur un bug du SMMU étant rendu inopérant car le nouveau TSEC FW contourne lui même le SMMU).

SciresM et ses collègues nous offrent donc une possibilité d’exploiter le nouveau TSEC FW tout en gardant privé leur exploit aux yeux de Nintendo et autres…

 

Justement, la TX, connue pour n'avoir aucun scrupule à voler le code source d’autres développeurs, ne peut cette fois-ci pas se servir dans le pot de confiture. Ils pourraient utiliser Sept pour lancer leur SX OS mais un logo Atmosphère s’afficherait à chaque démarrage du CFW...

 

Est-ce la raison qui explique cette longue attente (toute relative) ? Pas nécessairement, même si on peut légitiment se poser la question. Premièrement, de l'aveu même de SciresM, cracker ce nouveau TSEC FW n'est pas chose facile, il est donc normal que ça prenne du temps.

De plus, si “Sept” est chiffré, c’est avant tout pour se cacher aux yeux de Nintendo et ainsi ne pas “griller” un exploit de taille pour la prochaine révision matérielle Mariko. Evidemment, SciresM n’est pas dupe des tentatives de la TX pour lui chiper l’exploit, comme en atteste sa réponse (ce matin) à un nouvel inscrit sur Gbatemp, qui à créé un topic pour demander de l’aide pour cracker le nouveau TSEC FW :

“A lire ce topic, on pourrait dire que tu es un employé de la TX, même si évidemment tu pourrais juste être un mec lambda... ce qui n’est pas le plus probable.

Un projet public pour cracker le TSEC serait imprudent avec Mariko à l’horizon. Je pense que la plupart des gens ici sont conscients de ça.”

https://gbatemp.net/...allenge.533376/

 

Du côté de la TX, la communication est verrouillée mais officiellement rien ne bloque l’avancement de leurs travaux sur le support du FW 7.0. Sur le forum officiel de la TX , un admin indiquait ce samedi :

“Je sais que des personnes s'énervent et veulent savoir quand sera disponible l’update mais tout ce que je peux dire est que les choses suivent leur cours et qu’il n’y a aucun obstacle sur le chemin”

https://team-xecuter...warning.130461/

 

Au passage, l’admin en question avait l’air passablement énervé de voir le torrent d’insultes et de harcèlement dont les modos du forum font l’objet depuis quelques temps.

 

Officiellement donc tout va bien et l’attente ne devrait plus être longue. Est-ce que cela sera suffisant pour faire taire les rumeurs ? Pas certain. Même si la TX n’est pas une équipe de bras cassés (comme certains le pensent), on ne peut que constater qu’ils sont à la remorque d’Atmosphère depuis un petit moment (concernant le hack à proprement parler, c’est-à-dire la recherche d’exploit).

 

On peut retenir quelque chose de positif de cette histoire, c’est qu’Atmosphère est revenu sur le devant de la scène et c’est amplement mérité compte tenu du travail acharné de ses développeurs et de toutes les avancées qu’ils ont initié sur la très prolixe scène Switch. En plus le CFW est gratuit, c’est pas beau ?

 

Pour passer facilement de SX OS à Atmosphère, vous pouvez utiliser le pack Kosmos.

Je rappelle également que l’emuNAND du SX OS fonctionne bien malgré une sysNAND en 7.0 (il faut toutefois que la version de FW de l’emuNAND soit <= 6.2).

Enfin, les plus prudents, ceux qui ne se sont pas empressés de mettre à jour leur console en 7.0, peuvent continuer à profiter du SX OS sans entrave, en attendant la prochaine version.


[Switch] Retour sur l'emuNAND du SX OS, sa fiabilité et le risque de ban

09 janvier 2019 - 18:15

Cela fait plusieurs semaines maintenant que l'emuNAND est disponible avec la solution SX OS de la Team Xecuter. Maintenant que nous avons un peu de recul, et comme je l’avais promis à @oob, c’est le moment de faire un petit retour d’expérience et de répondre à la question que beaucoup se posent : l’emuNAND est-elle vraiment fiable et si oui, permet-elle de réduire drastiquement les risques de bannissement de sa console ?
NB : Seule l’emuNAND sur SD a été testée. Je ne vous conseille pas de créer une emuNAND en partition de votre NAND (la première emuNAND à avoir été disponible, celle du SX OS 2.0) car elle peut théoriquement être détectée par Nintendo.

Rappel : l’emuNAND c’est quoi ?

Le concept d’emuNAND a été inventé afin de limiter les risques inhérents au hack lorsque vous utilisez un CFW. Le principe est simple : il s’agit de virtualiser (ou émuler) une NAND qui sera dédiée au système d’exploitation du custom firmware (CFW).

Concrètement, lorsque vous allumez votre Switch, que ce soit en bootant sur l’OFW (firmware officiel) ou le CFW, le firmware indique au système d’exploitation où se trouve la mémoire physique qui lui est dédiée, en l’occurrence dans la mémoire flash embarquée (eMMC). C’est-à-dire que quand le système d’exploitation veut écrire sur la mémoire de votre Switch (pour installer un jeu par exemple), le firmware redirige toute les données vers la mémoire eMMC (la mémoire embarquée).

Voilà pour le fonctionnement normal. Maintenant imaginez que le CFW, plutôt que de diriger les données vers la mémoire eMMC (embarquée), choisisse de la rediriger vers la mémoire MMC (la SD), ça serait plutôt pratique vous ne trouvez pas ?
En bien c’est ça l’emuNAND. Vous vous retrouvez donc avec deux NAND ! La première, la sysNAND est la mémoire disponible lorsque vous lancez la console en OFW, la seconde, l’emuNAND est réservée pour l’utilisation d’un CFW :
emunNAND.png

L’intérêt de l’emuNAND est donc de conserver une sysNAND propre, c’est-à-dire vierge de toute modification/utilisation non conventionnelle. Le CFW en emuNAND servira à installer/lancer des backups (offline), homebrews et autres émulateurs. Tandis que la sysNAND pourra être utilisée online depuis le firmware officiel, pour jouer en ligne par exemple, sans risque de bannissement (en théorie).

Le fait d’utiliser SX OS en emuNAND protège-t-il vraiment la sysNAND ?

Peu avant Noël, des tests ont été effectués par certains sunriseurs (essentiellement @megaoctet et @Tesla) afin de garantir la fiabilité de l’emuNAND. Pour s'en assurer, il fallait vérifier que le CFW n’altérait pas la NAND originale, la sysNAND. Le seul moyen fiable de la vérifier était donc de faire ces tests :
1) Faire un dump de la NAND et le garder de côté
2) Lancer le CFW en emuNAND, lancer/installer des backups et naviguer dans Horizon OS
3) Eteindre la console et faire un nouveau dump de la NAND
4) Comparer le dump n°1 et le dump n°2 pour s’assurer qu’il n’y a aucune différence (vérification des checksums)
5) Répéter l’opération plusieurs fois et par des utilisateurs différents pour corroborer les résultats


Les résultats de ces tests nous ont d’abord vraiment inquiétés car des différences entre les dumps étaient parfois constatées (mais de manière aléatoire). Après investigation, il s’avère qu’un seul fichier était altéré entre les deux dumps. Il s’agit d’un fichier présent sur la partition SYSTEM : PRF2SAFE.RCV.
Nous n’avons pas été en mesure d’expliquer pourquoi ce fichier était créé/modifié aléatoirement lors de l’utilisation du CFW mais ma théorie sur le sujet est qu’il s’agit d’un fichier de restauration (extension RCV comme ReCoVery) sans doute écrit par un processus de bas niveau, avant que la NAND ne soit virtualisée par le CFW. En tout cas, ce fichier ne semble pas être écrit par le système d’exploitation.
Toutes les autres partitions de la NAND restent complètement intactes après utilisation du CFW, notamment la partition contenant tous les données de l’utilisateur (USER), celle sur laquelle sont installés les NSP par exemple.

En conclusion, les tests effectués à plusieurs reprises par nos amis sunriseurs indiquent que SX OS en emuNAND n’écrit pas sur la NAND, tous les accès en lecture/écriture à la NAND effectués par le système d’exploitation (Horizon) sont bien virtualisés.

Quelle utilisation pour l’emuNAND ? Et protège-t-elle du bannissement ?

Tout d’abord, soyez bien conscient que l’emuNAND ne protège PAS du bannissement en soit. Si vous connectez votre Switch en emuNAND à internet (sans le Stealth Mode) alors que vous avez installé des jeux NSP par exemple, vous aurez autant de risque de bannissement que si vous le faisiez sans emuNAND. Pour rappel, Nintendo bannit en réalité un certificat qui est ajouté dans votre console à l’usine et ce certificat est le même en sysNAND et en emuNAND, donc si l’une est bannie, l’autre aussi.

Ensuite en ce qui concerne les risques de bannissement, sachez qu’il est très difficile d’affirmer que telle ou telle solution vous protège du ban. On est obligé de rester dans la théorie et le plausible quand on parle de hack car on ne connait pas toutes les techniques actuelles ou futures utilisées par Nintendo pour détecter le hack.

Cela étant dit, l’emuNAND peut vous protéger de manière indirecte du bannissement si vous respectez bien les recommandations suivantes :
- L’emuNAND ne doit jamais être connectée online (ou alors il faut que le Stealth Mode soit activé pour bloquer les serveurs Nintendo)
- Toutes les installations et lancements de backups (jeux non legits) doivent être faits depuis le CFW en emuNAND.
- La sysNAND doit rester vierge de tout hack (aucune installation de NSP, thèmes personnalisés, pas d’autoRCM).
- Les mises à jour du FW de la sysNAND doivent être fait de manière conventionnelle, pas via ChoiDuJourNX (pour plus de sécurité car on ne sait pas garantir que ce type de mise à jour est indétectable).
- La sysNAND ne peut être connectée online qu’en OFW. Via un CFW il subsiste un risque, même si minime.
- Jouer en multi online n’est possible que depuis la sysNAND en OFW et seulement avec des jeux légaux évidemment (que ce soit des cartouches ou jeux eshop).
- Il est théoriquement possible pour Nintendo de détecter l'emuNAND présente sur votre SD quand vous utilisez la console en OFW, c'est pourquoi il est préférable de retirer la carte SD quand vous passez en OFW.

Si vous suivez scrupuleusement ces principes, vous devriez réduire considérablement le risque de bannissement. Certains le font depuis plusieurs semaines déjà et ils ne sont pas bannis. On ne peut jamais complètement écarter tous les risques (et je ne le garantis pas) mais on peut dire aujourd’hui que l’emuNAND (sur SD) de la TX semble fiable et permettrait de profiter d’une utilisation à la fois légale et illégale de sa console, sans être obligé d’avoir deux Switch ^^.

Pour aller plus loin vous pouvez consulter le tuto d'@inconnux : Créer une EmuNAND d'une Switch avec SX OS / SX PRO

PS1 : Comme indiqué plus haut, si vous souhaitez connecter votre sysNAND online, je vous recommande de ne PAS activer le mode autoRCM car il altère la NAND. Même si le risque est sans doute minime. Vous ne pourrez donc pas préserver vos eFuses lors d’une mise à jour via l’OFW.
PS2 : Merci à @megaoctet, @tesla, @inconnux, @shadow256 et @lorie3000 pour les tests et/ou le brainstorming sur le sujet de l'emuNAND ^^
PS3 : Je ne saurai être tenu responsable personnellement d'un éventuel bannissement d'un utilisateur (coucou @fatiguant)

[GUIDE] Comprendre les eFuses et le mode autoRCM

20 décembre 2018 - 18:49

Dans ce thread, je vais vous expliquer ce que sont les eFuses, à quoi il servent et les avantages et inconvénients du mode autoRCM. Si vous voyez quelque chose à ajouter n'hésitez pas à m'en faire part dans les commentaires et je mettrai à jour ce guide.

 

eFuse c'est quoi ?

Ce sont des nano fusibles intégrés dans la puce Tegra (NVIDIA) qui équipe la Nintendo Switch. Ces fusibles grillent (ou brûlent) après une mise à jour firmware. Il s'agit d'un dispositif anti downgrade.

La Nintendo Switch dispose de 32 eFuses (ils sont vraiment microscopiques) :

 

efuse.png

 

 

Lorsque vous démarrez votre console normalement, le bootloader (tout premier programme exécuté) vérifie que vous avez bien le bon nombre de fuses grillés en fonction de votre version de firmware : 

efuses.png

 

Par exemple :
- Si vous tentez de démarrer votre console en FW 6.0 et que votre nombre de fuses grillés est à 6 (ou moins) alors ça va vous en griller un de plus (ou plusieurs, jusqu'à arriver à 7)
- Si vous tentez de démarrer votre console en FW 5.1 et que votre nombre de fuses grillés est à 7 alors ça affichera un écran noir (bootloader panic) et vous serez bloqués.

 

Vous comprenez donc que ce dispositif est là pour empêcher de downgrader le firmware d'une console.
Si vous avez installé une emuNAND, notez bien que le contrôle des fuses ne se fait que sur la version de firmware installée sur votre sysNAND.

 

Connaître son nombre d'eFuses

Hekate propose une fonction permettant de connaitre son nombre d'eFuses grillés. Injectez simplement Hekate puis dans "Console info" sélectionnez "Print fuse info" :

hekate_fuse.png

 

 

Pourquoi vouloir préserver ses eFuses ?

La seule bonne raison de préserver ses eFuses est de vouloir downgrader sa console, c'est-à-dire installer une version de firmware plus ancienne que celle installée sur votre console. Ok, mais quel est l'intérêt de downgrader sa console ?

 

La raison la plus évidente est de pouvoir un jour profiter d'un exploit qui ne fonctionnerait que sur certaines versions de firmware. Il existe un exploit chain nommé "déjà vu" qui permet de démarrer un CFW sans passer par l'exploit RCM et donc sans avoir besoin d'un Jig ou dongle. Cet exploit chain est pour le moment réservé aux firmware <= 4.1 (sous le nom de cafeine/nereba, voir ce tuto si votre firmware est compatible. Si vous n'avez pas préservé vos eFuses, vous ne pourrez pas profiter de cet exploit.

 

Si au contraire vous n'avez que faire de pouvoir profiter d'un nouvel exploit plus simple à utiliser, alors vous n'avez pas vraiment d'intérêt à préserver vos eFuses.

 

Notez bien que même si vous ne préservez pas vos fuses, il sera tout de même possible de downgrader votre firmware mais vous ne pourrez le lancer que par un custom bootloader, et donc appliquer l'exploit RCM à chaque démarrage. Ce qui évidemment ne présente plus aucun intérêt pour un futur exploit.

 

Attention : il n'est pas possible de préserver les eFuses d'une switch patchée. La suite de ce thread s'adresse à ceux qui disposent d'une Switch non patchée (usinée avant Juillet 2018).

 

Comment contourner le contrôle/grillage des eFuses ?

Etant donné que c'est le bootloader qui contrôle et grille les eFuses au démarrage, la seule manière de contourner ce contrôle est d'utiliser un custom bootloader tels que Hekate, Fusee ou SX Loader (pour ne citer qu'eux). En effet, ces bootloaders sont injectés dans la console via l'exploit RCM (fusée gelée), avant que le bootloader officiel ne soit exécuté. Ils viennent donc remplacer le bootloader officiel.

 

En théorie, il suffit donc de toujours démarrer/redémarrer sa Switch en mode RCM pour ne pas griller ses fuses. Seulement en pratique il n'est pas évident de ne jamais booter sur le bootloader officiel. Lorsque votre console vous demande de redémarrer (après une mise à jour) il faudrait systématiquement refuser et faire un hard shutdown (appui long de 15 sec sur le bouton POWER) puis démarrer la console en mode RCM. De plus, sur une console à l'arrêt, il suffit simplement d'appuyer par inadvertance sur le bouton POWER pour lancer le bootloader officiel.

 

C'est pourquoi les développeurs ont inventé le mode autoRCM.

 

autoRCM, c'est quoi ?

Cela consiste à bricker intentionnellement sa console afin qu'elle ne puisse plus démarrer sur le bootloader officiel. Plus précisément le bootloader va entrer en mode panic puis passer automatiquement en mode recovery "RCM", sans avoir besoin d'un jig ou d'un court-circuit dans le joycon. Cela peut paraître surprenant de bricker intentionnellement sa console mais c'est la seule façon efficace de se prémunir d'un grillage de fuses. Mais soyez rassurés, la méthode consiste simplement à altérer quelques bits inutiles dans la partition BOOT0 de votre NAND. Cette méthode est totalement réversible et laisse votre NAND propre une fois le mode autoRCM désactivé.

 

Ce mode autoRCM peut être activé via les custom bootloader comme Hekate ou SX Loader ou bien via le payload briccmii.
L'homebrew ChoiDuJourNX, qui permet d'installer manuellement un firmware, active également ce mode par défaut. Notez bien que lorsque ChoiDuJourNX est lancé depuis l'emuNAND, l'autoRCM ne s'activera pas (même si l'application peut le laisser penser).

 

Attention : ne jamais activer le mode autoRCM sur une Switch patchée (non vulnérable à l'exploit RCM, aka Fusée Gelée), sans quoi vous allez bricker votre Switch sans jamais pouvoir la debricker.

 

Les avantages :

- Empêche de démarrer le bootloader officiel et donc empêche de griller ses eFuses

- Permet de se passer du Jig/court-circuit et de la combinaison de touche (POWER + VOL UP) pour démarrer en mode RCM.

- Dans une moindre mesure, empêche de démarrer facilement sur le firmware officiel qui fait beaucoup plus de télémétrie qu'un CFW (donc plus de risque de ban)

 

Les inconvénients :

- L'inconvénient majeur de ce mode est le risque de se retrouver avec une batterie déchargée. En effet il n'est pas simple de distinguer une Switch éteinte d'une switch en mode RCM (écran noir, pas de réaction aux commandes digitales). Si vous ne faites pas attention, votre console va rester en mode RCM et se décharger petit à petit jusqu'à être complétement déchargée. Le hic, c'est qu'une console brickée avec 0% de batterie ne peut plus se recharger normalement, c'est très long, il faudrait pouvoir l'allumer correctement en bootant sur le firmware pour qu'elle puisse être rechargée mais l'autoRCM nous en empêche !

- La fonction "éteindre" de l'OS de la Switch ne fonctionnera pas correctement et fera basculer votre Switch sur le mode RCM (donc on revient au problème de batterie). Le seul moyen fiable pour l'éteindre complètement est de rester appuyé 15 secondes sur le bouton POWER.

- Pour une Switch éteinte, un simple appui sur le bouton POWER ou le simple fait de la connecter via USB à un PC ou dongle va démarrer la console en mode RCM, ce qui là encore, va décharger votre batterie.

 

Pour éviter les problèmes de batterie, je vous conseille de ne pas tenter d'éteindre totalement votre console (sauf si vous allez la rallumer tout de suite après) mais la laisser en veille, elle se déchargera moins vite.

 

Que faire si ma console ne démarre plus suite à un downgrade de firmware ?

Si vous n'avez pas activé le mode autoRCM alors que vous avez downgradé votre firmware (via l'installation d'un firmware inférieur ou la restauration d'un dump de NAND avec un firmware inférieur), et que vos fuses sont en missmatch alors vous ne verrez qu'un écran noir lorsque vous allumerez la console normalement.

 

Dans ce cas il faudra passer par un custom bootloader tel Hekate ou SX Loader pour démarrer votre OFW (firmware officiel), et ce jusqu'à temps que votre version de firmware et votre nombre de fuse ne soit plus en missmatch.

 

Que faire si ma batterie est déchargée à cause de l'autoRCM ?

Il est possible qu'il reste un tout petit peu de jus dans votre batterie pour injecter un payload mais pas assez pour lancer le CFW. Il existe une technique très simple et éprouvée qui fonctionne dans ce cas : il faut injecter votre bootloader préféré et dès qu'il est injecté (il faut être très rapide), connecter le chargeur secteur à la Switch, ce qui lui donnera assez de jus pour lancer le CFW. Dès qu'Horizon OS est chargé, votre batterie commencera à se recharger.

 

Si votre batterie est vraiment à plat, essayez de la brancher sur secteur le temps qu'elle se charge (min 45min/1heure) pour avoir assez de jus pour injecter un payload. Si ça ne fonctionne pas, Il faudra démonter votre batterie, la remonter dans une autre console, cette fois-ci non brickée (sans l'autoRCM d'activé) et la recharger avant de la replacer dans sa console d'origine.

 

eFuses LOTUS

 

Les eFuses LOTUS sont des fuses de la puce du port cartouche, qui est une puce différente du SoC Tegra, et est en charge des communications avec le port cartouche de la console.

Ces eFuses fonctionnent peu ou prou de la même manière que les eFuses du SoC. Ils sont brûles à chaque mise à jour du firmware LOTUS (le firmware du port cartouche donc). Lorsque la version du fw et le nombre de fuses LOTUS ne correspondent pas, le port cartouche est alors rendu inopérant.

La grosse différence avec les eFuses du SoC, c'est qu'il est impossible de contourner le contrôle des fuses LOTUS. Il n'existe pas d'exploit bootrom pour cette puce comme c'est le cas pour le Tegra X1. Aussi, il faut bien comprendre que lorsque votre firmware LOTUS est mis à jour (en même temps que la maj du fw principal, comme ça a été le cas pour les fw 4.1 et 9.0), votre port cartouche ne fonctionnera plus si vous downgradez le firmware principal de votre console.

Pour empêcher votre port cartouche d'être mis à jour en CFW, il est possible d'appliquer un patch "nogc" (qui se configure dans BCT.ini par exemple pour le bootloader d'Atmosphère, disponible aussi pour Hekate) qui bloque le port cartouche (et donc sa mise à jour) lors de l'utilisation d'un CFW.

Soyez donc très vigilant également au fuses LOTUS si vous souhaitez un jour profiter de votre port cartouche sur un FW plus bas que votre celui sysNAND ou emuNAND actuel.