bootloader

Nop, ce dont tu parles concerne le SX OS et sa version 2.0 qui est boguée.
Il n'existe pas ce moyen avec les bootloader pour le moment.

Tu parles de l'emuNAND mais en rien cela est moins risqué. Tout du moins proposée ainsi. Cela n'a rien à voir avec ce qui existe sur 3DS par exemple. Cette partition se fait directement sur la NAND (eMMC) mais est détectable par Nintendo.

J'en parle déjà dans le Tutoriel qui concerne SX OS. Pas besoin des liens que tu proposes.

MDProz Wrote:La Team Xecuter ajoute l'emuNAND avec sa v2.0. Toutefois, ce n'est pas une vraie emuNAND. Il s'agit d'une partition de la NAND de 15Go, un partage entre votre sysNAND et votre emuNAND. Le principe aurait été mieux de virtualiser une seconde NAND sur la carte SD sans altérer la NAND principale mais ce n'est pas le cas !

eliboa Wrote:
Il faut savoir que le module de télémétrie (qui collecte les données et les envoi à Nintendo lors d'un crash), Creport, détecte la taille de votre NAND (NANDTotalSize). Nintendo sera donc en mesure de détecter l'emuNAND de la TX. Vous êtes prévenus !

L'emuNAND de la TX fonctionne comme une emuNAND classique :
- Installer un firmware différent que celui de votre sysNAND sera possible. Ainsi vous gardez votre OFW sur la version la plus basse.
- Tous les homebrews et jeux installés sur votre emuNAND ne seront pas accessibles via l'OFW. Cela devrait, en théorie, échapper à toute détection de la part de Nintendo mais rien ne le confirme ni l'infirme !

La scène est à son début donc pour le moment, parler d'outils pour se prémunir du ban est un peu juste tant le développement prend forme petite à petit. Les bootloader sont les prémices du hack et le CFW atmosphère est issu de cette utilisation que nous en faisons. Ce que je veux dire par là, c'est que les travaux de SciresM et d'autres sont la base de ce qui existe actuellement.

Pour ce qui est du online, il faut partir du principe qu'à partir du moment qu'une console est modifiée, cela est à proscrire même si des outils seraient proposés pour se prémunir du ban. Il suffit de regarder la scène underground PS3 pour s'apercevoir que le risque zéro n'existe pas. L'ensemble des firmes ont basé leur développement sur le online. C'est leur bénéfice et elles ne lâcheront rien en termes de sécurité.

Pour en revenir à ton cas, le mode autoRCM te sera utile pour utiliser ChoiDujourNX mais à l'issu, tu peux le désactiver. Tu grilleras tes eFuses car le downgrade te t'intéresse pas tant que cela selon tes demandes depuis. Sinon, tu peux restaurer ta NAND propre et faire la mise à jour 6.0.0 sans passer par celui-ci.

Après, si tu es déçu d'avoir fait la mise à jour en 5.1.0, je te dirais de patienter le temps que Xecuter propose une version 2.1 qui permettra une emuNAND aboutie peut être. Ainsi, ta SysNAND sera en 5.1.0 et ton emuNAND pourra être en 6.0.0.
C'est aussi cela, l'aspect de l'emuNAND.

Pour ce qui des updates de jeu et DLC, s'ils venaient à demander le FW 6.0.0 pour ceux que tu utiliserais, tu auras un message tout simplement. Et ce avant l'installation et détection de ton firmware. Après, je ne sais comment SX OS va évoluer pour cet aspect.

Pour tinfoil qui s'utilise avec les bootloader, le fait de pouvoir ignorer cela a aussi ces limites à un moment donné. Reste à voir comment cela évoluera aussi.

Donc il faudra être patient et voir comment la scène va évoluer. Dans tous les cas, SciresM, développeur de atmosphère n'a pas l'ambition de proposer quelques aspects que ce soit pour ce qui est de la gestion des backups. D'autres non plus d'ailleurs mais cela ne veux pas dire qu'un Dev ne s'en préoccupera pas. Rien ne le confirme mais rien ne l'infirme. Tinfoil existe bien à ce niveau mais sera t-il la solution qui perdurera ? C'est peu probable car d'autres sont en développement mais rien ne fuite à ce niveau. Chaque scène à eu son lot de gestionnaires de backup.

Les bootloader actuels font le taff. Après, mais il faudra encore être patient, le CFW freeware sera atmosphere-nx de SciresM. Pour le moment, il est toujours en développement suite à la libération du FW 6.0.0. Le développeur s'est accordé un moment avant de libérer une première version de son CFW afin d'analyser cette version comme il se doit.

Oui, si le mode RCM se déclenche, tu peux essayer d'injecter Hekate, ReiNX ou RajNX. Il y a aussi Fusée Gelée qui est le test premier pour être certain mais les bootloader le confirmeront sans problème

Le développeur Rei propose la version 1.7 de ReiNX. La partie du tuto qui concerne le bootloader en FAQ nécessite une actualisation mais rien d'insurmontable si vous souhaitez l'utiliser via Hekate. La démarche reste à peu près la même.

Vous pouvez également l'utiliser directement associé avec son toolkit.

Et si vous n'êtes pas certains de ce que vous faites, SDSetup vous sera utile.

ChangeLog

[+] CLIQUER POUR AFFICHER

• Les modifications utilisateur:
  
  • fs_mitm accroît la prise en charge de la version 6.0
  
  
  • Le texte de débogage ReiNX apparaît uniquement si vous démarrez en mode prolixe (maintien du démarrage)
  
  
  • Boot ReiNX sans carte SD
  
  
  • Tous les kips sont compilés et regroupés avec ReiNX. La boîte à outils peut être utilisée pour les activer / désactiver. (alternativement il suffit de les déplacer de sysmodules.dis à sysmodules, et vice versa)


• Modifications techniques:
  
  • Réécriture du code Kernel

Le développeur CTCaer propose la version 4.2 de son bootloader Hekate.

ChangeLog

[+] CLIQUER POUR AFFICHER

• Prise en charge du caractère générique du dossier "*" dans la clé kip1
  
  Utiliser <folder> / * peut maintenant analyser et charger tous les fichiers kip et kip1 dans ce dossier.


• Ajouter une option pour activer / désactiver la désactivation automatique de HOS
  
  Si vous n'utilisez pas de puce / dongle, vous trouverez peut-être que cette fonctionnalité est ennuyeuse. Options-> Auto HOS hors tension pour désactiver.


• Autoriser l'annulation du processus de vérification
  
  Vous pouvez maintenant annuler le processus de sauvegarde et de vérification. Si la phase de sauvegarde est terminée, l'annulation de la vérification conservera vos fichiers.


• Quelques petites corrections de bugs et supporte certains cfw sur sa version stock

Pour compléter ton lien, le développeur Mike Heskin aka hexkyz a déchiffré la v2.0 de SX OS.

Ce qui ressort:

[+] CLIQUER POUR AFFICHER

• 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)

Pas difficile à comprendre, que ce soit du XCi ou du NSP sous SX OS ou autres bootloader, personne ne peut dire exactement ce que la télémétrie transmet au serveur de Nintendo.

Une chose est certaine, toute modification de la NAND est un risque. Ce qui modifie celle ci est le NSP, l'autoRCM, et certains Homebrew.
Le format XCi ne la modifie pas mais cela ne signifie en rien qu'il n'y a pas un risque.
Les sauvegardes modifiées et les cheat code sont également déconseillés.

J'ai déjà apporté des indications dans les pages précédentes que tu peux lire pour t'aider à mieux comprendre car répéter sans cesse devient redondant. Ce n'est pas un reproche mais plutôt que cela à déjà été abordé plusieurs fois.

Les retours que je lis à droite et à gauche sont divers et variés pour le ban.
L'aspect qui est certain, si tu décidais de te connecter online, est que l'utilisation d'eShop non officiels entraîne un ban direct, que l'installation de NSP (jeux, update, DLC) provoque un ban à court terme et pour finir, l'utilisation de XCi est également concernée à long terme.

Je ne m'avancerai pas sur le moyen de détection mais Nintendo a renforcé sa sécurité depuis et cela est d'autant plus prononcé en 6.0.0. La chasse que mène Nintendo ne fait que commencer.

Inutile de me citer si tu me réponds à l'issu.

Double post volontaire pour une information à tous

Le développeur CTCaer propose la version 4.1 de son bootloader Hekate. TumGER l'avait déjà intégré dans son update !

ChangeLog

[+] CLIQUER POUR AFFICHER

• Prise en charge complète de 6.0.0
  
  Correctifs Secmon / noyau, correctifs FS, mode veille, configuration hw, etc.


• Amélioration de la gestion des fichiers .ini / payload
  
  hekate_ipl.ini n'est plus requis et hekate ne se bloque pas sur les dossiers vides.


• Rétro-éclairage PWM
  
  Vous pouvez maintenant modifier la luminosité du rétroéclairage.


• Mise hors tension automatique lorsque l'appareil est sorti de l'alimentation de HOS
  
  Utilisable avec les modchips / dongles lors de l'utilisation d'AutoRCM. (Vous pouvez le voir comme un rétro-éclairage respirant avec le logo de hekate).


• La sauvegarde peut maintenant être annulée lors de l'écriture (barre blanche), en appuyant sur VOL UP + DOWN.


• Le chargement en chaîne à mise à jour automatique vérifie correctement le numéro de version maintenant pour éviter les charges non égales.


• Soutenir les charges utiles avec une installation hw cassée / incorrecte ...


• Ajout des infos ipatches et vidage du bootrom et des ipatches patchés / non corrigés


• Correction de certaines modifications de la configuration matérielle trouvées dans la version 5.x-6.0.0


• Plus de raisons de démarrage et de registres bootrom reviennent à la normale


• Il restaure maintenant correctement la BCT sur les unités de développement à partir de laquelle il est censé le faire.


• Message d'avertissement ajouté lorsque la bibliothèque du chargeur de démarrage du mode veille est manquante.


• Et beaucoup de corrections de bugs

Le firmware 6.0.0 est maintenant correctement pris en charge par toutes les possibilités présentes au sein de la scène underground.

Les versions mises à jour pour cela:

• Hekate depuis la v4.1


• SDFilesSwitch depuis la v9


• ReiNX depuis la v1.6


• Toolkit ReiNX depuis la v1.1

À prendre en compte que tinfoil accompagne la compilation SDFilesSwitch. Et que d'autres outils comme EdiZon etc suivent également la portabilité.

RajNX est mis à niveau. Sans oublier que SX OS dans sa version 1.9 l'est aussi.
Bon jailbreak !