tuto boot

Pour celle et ceux qui ont franchi le pas vers HOS 20.0.1, quelque soit la raison, vous pourriez rencontrer des problèmes avec plusieurs aspects:

Sigpatches et/ou sys-patch
Pour rappel, depuis la version Atmosphere 1.7.0 et ultérieure, les correctifs IPS KIP ne sont plus pris en charge. Ils étaient utilisés pour le piratage. Par conséquent, les sigpatches ne fonctionneront pas correctement, sauf si:

• Vous chargez le package3 Atmosphère via le FSS0 Hekate. Vous devrez redémarrer Hekate puis accéder à Launch et sélectionner emuNAND CFW ou sysNAND CFW (selon celui utilisé)


• Si vous avez téléchargé les sigpatches depuis ce tuto:
  
  • Le fichier hekate_ipl.ini présent dans bootloader est nommé volontairement hekate_ipl.ini.template. Il suffit de le renommer hekate_ipl.ini et vous aurez déjà tout ce dont vous avez besoin.
  
  
  • Les modifications engagées (ou a engager) sont:
    

    [+] CLIQUER POUR AFFICHER

    • La clé fss0 était utilisée pour indiquer, dans le boot, qu'il fallait charger un package3 Atmosphere. Le nom de la clé a été renommée en pkg3. Vous devez donc modifier fss0=atmosphere/package3 par pkg3=atmosphere/package3
    
    
    • La configuration utilisée atmosphere=1 n'est plus nécessaire car le correctif est effectué pour les parties extraites du Package3. Cette clé a été renommée en kernelprocid. Lorsque vous activez ce paramètre, le correctif d'envoi/réception de l'ID de processus du noyau est activé
      
      • Vous pouvez le supprimer ou le laisser dans emuNAND CFW ou sysNAND CFW
      
      
      • Dans Stock - sysMMC, la clé atmosphere=1 doit être renommée par kernelprocid=1 si vous le paramétrer
    
    
    • Vous pouvez agir dessus comme vous l'entendez et vérifiez quels sont les changements apportés avec votre ancien fichier hekate_ipl.ini ou l'ouvrant avec bloc-notes



• Vous pouvez aussi trouver les versions modifiées du CFW Atmosphere et fusee.bin avec la prise en charge des correctifs IPS Kip. Aucun lien sur le forum !


• Vous pouvez utiliser sys-patch au lieu de sigpatches. Sys-patch sera le nouveau moyen simple de les obtenir à long terme

Les Modules

L'histoire de perte de mémoire pour les modules a été compensée en réservant 20 MB de moins sur un autre élément d'Atmosphere pour limiter les problèmes. Au lieu de 40 MB on tombe à 34 MB. La perte n'est pas si importante et c'est dans certains cas très spécifiques que cela pourrait poser des problèmes

Pour PS3 compatibles CFW:

Le développeur evilnat propose son CFW 4.92 CEX - PEX - DEX - D-PEX (Standard/OC/NoBT-NoBD). Ceux déjà jailbreak peuvent mettre à jour. Pour les autres non jailbreak, BGToolset n'est pas encore porté !

Liens:

• Mega :CFW 4.92 CEX - PEX - DEX - D-PEX (Standard/OC/NoBT-NoBD)
  
• MediaFire: CFW 4.92 CEX - PEX - DEX - D-PEX (Standard/OC/NoBT-NoBD)

Le développeur Littlebalup propose son CFW DualBoot 4.92

Liens:

• Littlebalup Dual Boot 4.92
  
• Littlebalup Dual Boot & Hybrid 4.92

Pour PS3 compatibles HEN

Le développeur Joonie propose son HFW 4.92-1
HEN v3.4.0 prend en charge OFW 4.80 - 4.82, OFW DEX 4.82, HFW DEX 4.84, et HFW 4.83 - 4.92 !

Liens:

• HFW_4.92.1_PS3UPDAT.PUP
  
• PS3HEN_3.4.0_4.92_FW

Pour PS3 compatibles HAN:

Il semblerait que le HAN soit maintenant disponible pour 4.92. Il n'y a plus de soutien pour ce projet, c'est juste pour ceux qui veulent toujours l'utiliser !

Liens:

• HFW_4.92.1_PS3UPDAT.PUP
  
• ps3_tools-v3.0.9-HAN492_HFW_release_PS3Xploit

MDProz Wrote:Ce tutoriel date un peu et depuis, pas revenu dessus. L’écran rouge indique soit que la console avait déjà un CFW installé ou alors que boot.3dsx n’est pas présent à la racine de la SD. Il faudrait vérifier les éléments sur la SD également.

Tu peux aussi te référer à ce guide complet:
https://3ds.hacks.guide/

Bonsoir à toi MDProz, ça date depuis l'époque, effectivement un peu inactif mais je te remercie pour le support de mon post depuis tout ce temps, il y a des posts plus à jour depuis bien que celui-ci puisse toujours servir, si besoin je me relancerait bien dans la scène mais plutôt côté PSP, ça bouge en ce moment, bref tout ça c'est pour clôturer, j'ai toujours pris un plaisir de dingue sur toutes les scène Undergroud, bref, profitez bien et j'espère avoir à nouveau à partager avec vous tous !

Encore merci MDProz !!!

Le module sys-patch reste conseillé, en complément, pour un boot via Hekate et est nécessaire, pour un boot via Fusée.

@nikkko003
Parfait. Merci pour ton retour.

@rotou
Pour jouer à tes jeux legits, tu as deux possibilités:

• Tu peux soit y jouer en mode normal (boot sans hack) et ainsi, tu vas utiliser ta sysNAND.


• Soit en bootant en mode hack sur ta sysNAND. Tu peux aussi booter en mode hack sur ton emuNAND mais les données seront sauvegardées sur cette dernière. Le tout est de ne pas connecter ta console aux serveurs dans les deux cas.

Les jeux legits, type cartouche, peuvent se jouer en mode normal ou hack. Il n’y a pas de contre indication si ce n’est de ne pas connecter sa console. Pour ce qui est de la SD, si tu décides de lancer ta console, sans hack, pour jouer à un jeu cartouche, le fait de la laisser ne pose aucun problème tant que tu ne connectes pas la console.

En revanche, pour ce qui concerne le mode online, j’ai tendance à ne pas le conseiller mais cela appartient à chacun. Personne ne peut affirmer avec certitude ce que la télémétrie opère donc si hack, les précautions et préconisations doivent être opérées. Les retours indiquent avec certitude que la console doit démarrer en mode normal et donc sans hack. De plus, le bootloader doit être celui de Nintendo et pas celui d’Hekate donc le mode Launch Stock de Hekate n’est pas conseillé. Et pour la carte SD, certains ont été ban et d’autres non lorsqu’elle était dans la console en mode normal et connectée.

Pas évident tout cela d’où le fait que le risque zéro n’existe pas malgré tout et que le online reste déconseillé.

Pour ce qui est des jeux cartouches qui ne demandent pas du online, cela ne pose aucun problème à les utiliser en mode normal et hack sur sysNAND pour en profiter. En emuNAND, c’est possible aussi, c’est juste que les données de sauvegarde se feront sur celle ci. Donc à voir mais si tu souhaites continuer ta progression en évitant de dumper et restaurer ta sauvegarde de jeu, choisi la NAND système sur la laquelle tu booteras tout le temps pour ton jeu.

Et pour les jeux cartouche qui demandent une connexion, ce sera toujours en mode normal sans hack mais sans confirmation de quoi que ce soit en termes de ban.

Pour différencier sysNAND et emuNAND, il y a la possibilité de changer de thème. Ainsi, à l’issue du boot, tu sais où tu te situes.

Toutes les questions posées depuis ont leur réponse dans la FAQ qu’il faut lire pour comprendre un peu mieux car là je vais résumer grossièrement !

Le hack n’est pas permanent et si tu redémarres ta console, tu te rends bien compte que rien n’est installé sauf les fichiers NSP (qui eux ne fonctionneront pas puisque le hack n’est pas actif). Le fait d’injecter un payload permet de loader et cela depuis ta SD et non depuis la console. Pour Hekate qui est un custom bootloader, c’est ainsi (et pour d’autres également).

En revanche, en fonction de ce que tu utilises, cela laisse des traces dans la télémétrie d’où le fait de ne pas utiliser sa sysNAND pour les aspects underground et de créer une emuNAND. Les deux sont déliées.

Pour Hekate, il utilise un bootloader personnalisé qui n’est pas celui de Nintendo d’où le fait de ne pas aller sur le online. Il possède trois mode de boot qui utilisent son bootloader donc la connexion est à éviter. En démarrant la console normalement, elle utilise le bootloader de Nintendo. Le hack n’est plus actif.

Rien est installé lorsqu’il s’agit d’utiliser un payload (fichier bin) qui se charge de loader depuis la SD et non depuis la console.

Comme dit plus haut, ce qui modifie la NAND, c’est l’installation de NSP, certains homebrews comme RetroArch, le mode autoRCM car il se charge de corrompre la boot et autres.
La sysNAND, c’est la NAND système de la console et l’emuNAND, c’est la NAND système sur la SD. Donc pour éviter de modifier la NAND système de la console avec l’underground, on crée et on utilise une emuNAND.

L’emuNAND est un aspect important. Sans compter le fait qu’elle permet de protéger son système de toutes corruptions de données ou brick, elle apporte aussi le fait de se prémunir d’un ban. Les deux sont déliées et ne communiquent pas ensemble.
Ne pas l’avoir créée au début implique d’avoir utilisé sa sysNAND pour l’underground et cela a donc modifié la NAND. Ce qui engendrera un ban après utilisation du online et connexion sur les serveurs de Nintendo donc cela est conseillé d’éviter. Et ce en espérant que la connexion a été configurée pour éviter cela au départ.

Pour revenir à un système sain, propre de toutes modifications, il existe la possibilité de restaurer une sauvegarde de NAND, si cette dernière a été faite au préalable, via Hekate et il existe Haku33:
https://gamergen.com/forums/underground ... 73953.html
Une simple réinitialisation, via les paramètres de la console, ne suffira pas.

Avant de procéder à cela, faire un dump des sauvegardes est préconisé pour les restaurer ensuite. Ainsi, après la création de l’emuNAND, les sauvegardes pourront être restaurées après lancement du jeu pour créer une 1re sauvegarde. Cela peut se faire avec JKSV ou autre.

Bien que les deux NAND soient déliées, je ne préconise pas d’utiliser le online lorsque la console est hack. Il y a des informations complémentaires dans la FAQ du tutoriel. Une erreur ou un oubli est si vite arrivé. Dans tous les cas, le hack ne doit s’utiliser que sur l’emuNAND et aucune connexion au online ou sur les serveurs ne doit se faire lorsque le boot s’opère sur l’emuNAND. Pour ce qui concerne l’utilisation de la sysNAND, elle doit être clean et la console doit démarrer normalement, sans hack, pour utiliser le loader de Nintendo. Lorsque le boot s’opère avec Hekate, il utilise son loader personnalisé que ce soit en sysNAND, emuNAND ou stock. Ces informations sont détaillés en FAQ.