[Switch] TX Hidden Emunand Backup Tool disponible
sa récupère le rawnand cacher de SXOSMerci pour la news
En gros cet outil sert a backup l’emunand en un fichier rawnand.bin c sa?
Peut-être déjà le cas qui saitBonjour
Merci, j espère qu il va l évoluer pour les emumand de hekate
Cdt
Bonjour
Peut-être déjà le cas qui sait
Pas encore release alors, et il en parles pas sur gba pour l instant pour les evolutions
Et son code et lier pour SX car c est les meme valeur qu on peut utiliser avec DD
Cdt
Merci pour la news.
Bonjour
Merci, j espère qu il va l évoluer pour les emumand de hekate
Le dev l'ajoutera sans doute dans une future version mais c'est un peu plus compliqué car l'emuMMC peut être sur n'importe quelle partition MBR de la SD, alors que l'emuNAND de la TX commence dès le premier secteur de la MMC ^^
Au passage la future version de NxNandManager pourra faire pareil et permettre le backup/restore d'une emuNAND (TX ou emuMMC, en partition ou en fichier).
Merci pour la news.
Bonjour
Merci, j espère qu il va l évoluer pour les emumand de hekate
Le dev l'ajoutera sans doute dans une future version mais c'est un peu plus compliqué car l'emuMMC peut être sur n'importe quelle partition MBR de la SD, alors que l'emuNAND de la TX commence dès le premier secteur de la MMC ^^
Au passage la future version de NxNandManager pourra faire pareil et permettre le backup/restore d'une emuNAND (TX ou emuMMC, en partition ou en fichier).
bonjour, a la fin on se retrouve avec 3 fichiers ?
perso j'ai boot0 et boot1 et des fichiers full..
merci
Oui la RAWNAND est dumpée en 1 seul fichier si on en croit le code. Tu confonds pas avec l'emuNAND de la TX en fichiers ?
#Setting up the values to execute a prettier line
$boot0 = $tfold.ToString() + '\Boot0.bin'
$boot1 = $tfold.ToString() + '\Boot1.bin'
$rawnand = $tfold.ToString() + '\Rawnand.bin'
#Execute each section and put any output into variables for just incase
$boot0res = .\secinspect.exe -backup $physicaldrive $boot0 2 8192
$boot1res = .\secinspect.exe -backup $physicaldrive $boot1 8194 8192
$rawnandres = .\secinspect.exe -backup $physicaldrive $rawnand 16386 61071360
La copie se fait à partir des offsets des secteurs "codés en dur", donc le programme peut ne pas fonctionner pas avec une emuNAND redimensionnée
non mon Emunand est pas redimensionnée
Pour une emunand sur sd ...il suffit de faire copié collé. Rien de transcendant.
On parle ici d'une emuNAND en partition, pas d'une emuNAND en fichier. Sinon oui effectivement c'est plutôt simple.
Perso, je trouve ça plus compliqué et moins fiable de retrouver le fichier emummc.ini sans demander la localisation du fichier à l'utilisateur car tu ne sais pas de base sur quelle partition (FAT32 ou exFat) de la carte SD est placé ce fichier (il peut y avoir d'autres partitions sur la SD). Comme je suis en plein dedans pour NxNM, ce que j'ai préféré faire personnellement est de parcourir la table des partitions primaires MBR de la carte SD et pour chaque partition chercher la signature de l'emmc (nombre magique) qui correspond à la GPT de la RAWNAND (vraisemblablement à l'offset 0x4001 après les deux partitions BOOT). SI la signature est OK, on dumpe. SInon on passe la partition suivante. C'est d'ailleurs comme ça qu'Hekate trouve les partitions emuMMC dans son outil de migration de l'emuNAND. On ne sait jamais ce que les utilisateurs peuvent bien faire avec leurs fichier *.ini ^^Se serait faisable d'adapter le code source pour l'emummc d'Atmosphere je pense avec un algorithme basique de ce type:
- Indiquer la SD sur laquelle travailler.
- Chercher partition cachée de l'emunand SX OS et si les 1024 premiers octets correspondent à celle-ci, dumper.
- Si partition SX OS non trouvée, chercher le fichier "emummc/emummc.ini" sur la SD et voir si la valeur "sector" est définie et si oui, dumper l'emunand à partir de celui-ci (il faudra aussi vérifier que certaines valeurs dans ce fichiers ne se contrarie pas comme par exemple si "sector" et "path" sont définies, dans ce cas avertir d'un problème possible ou ne pas lancer le traitement; d'autres vérifications à ce niveau sont aussi à faire).
- Indiquer le dossier de sortie et lancer le dump selon les paramètres précédemment analysé par le programme.
Si si Atmo fonctionne maintenant en emunand fichier. L'interet de l'emunand en partition cachée de la TX (donc en fait c'est pas vraiment une partition) permet de rendre l'emunand invisble sous Windows par ex, ce qui empêche des erreurs utilisateurs et donc des corruptions possible. Ca crée d'autres problèmes cela dit.bonjour,
une question simple me trotte dans la tete. Pourquoi passer par une partition cachée ? Alors que l'on a la possibilité de faire sous SXos une Emunand en fichier sur la SD. Qui pour moi est bien plus pratique pour les sauvegardes et restauration. J'ai cette solution sur ma switch et je trouve cela très pratique. J'ai aussi cru comprendre qu'atmosphère ne gère pas L'Emummc par fichiers sur la carte SD. Pourquoi ?
Merci de vos réponses.
Si si Atmo fonctionne maintenant en emunand fichier
Pas faux, pas faux du tout même.Perso, je trouve ça plus compliqué et moins fiable de retrouver le fichier emummc.ini sans demander la localisation du fichier à l'utilisateur car tu ne sais pas de base sur quelle partition (FAT32 ou exFat) de la carte SD est placé ce fichier (il peut y avoir d'autres partitions sur la SD). Comme je suis en plein dedans pour NxNM, ce que j'ai préféré faire personnellement est de parcourir la table des partitions primaires MBR de la carte SD et pour chaque partition chercher la signature de l'emmc (nombre magique) qui correspond à la GPT de la RAWNAND (vraisemblablement à l'offset 0x4001 après les deux partitions BOOT). SI la signature est OK, on dumpe. SInon on passe la partition suivante. C'est d'ailleurs comme ça qu'Hekate trouve les partitions emuMMC dans son outil de migration de l'emuNAND. On ne sait jamais ce que les utilisateurs peuvent bien faire avec leurs fichier *.ini ^^
Non, pas possible d'utiliser la même emummc fichiers avec SX OS et Atmosphere, ceci n'est possible qu'avec l'emummc via partition car Atmosphere utilise d'autres noms de fichiers que SX OS pour détecter l'emummc, c'est pas la seule différence de se que je sais car j'avais essayé de réécrire le code source d'Atmosphere pour qu'il gère ceci mais ça bloquait après la vérification des fichiers, même s'ils étaient détecté il y avait des choses qui n'allaient pas ensuite donc j'ai abandonné. Avec l'emummc via partition on utilise une petite feinte dans le fichier de configuration pour indiquer que l'emummc commence au secteur 0x2 de la SD, se qui permet de sauter les 1024 octets inscrit par SX OS avant le vrai début de l'emummc via partition.Merci beaucoup @eliboa
C'est tu s'il est possible de ce servire de la même Emunand/Emummc en fichier sur la SD pour Sxos et Atmosphère ?
Car j'aimerai tester Atmosphere en Emummc. Je sais que pour la version partition cachée il suffit juste d'étider le fichier .ini
Est ce que c'est la même configuration ?
Merci
Merci beaucoup @eliboa
C'est tu s'il est possible de ce servire de la même Emunand/Emummc en fichier sur la SD pour Sxos et Atmosphère ?
Car j'aimerai tester Atmosphere en Emummc. Je sais que pour la version partition cachée il suffit juste d'étider le fichier .ini
Est ce que c'est la même configuration ?
Merci
Nope a ma connaissance ca fonctionne que pour les emunand en partiton.
Edit : shadow plus rapide et plus complet ^^
En théorie l'emunand en partition devrait mieux fonctionner que celle qui est fichiers ?Aussi l'emunand en partition est plus simple a emuler pout le CFW qu'une Nand en fichier, ce qui explique pourquoi au debut il n'existait que ce type d'emunand
En théorie l'emunand en partition devrait mieux fonctionner que celle qui est fichiers ?
C'est surtout que c'est plus simple à mettre en œuvre dans le code d'emuMMC. Après niveau perf, j'imagine que tu perds un peu en emunand fichier mais je ne sais pas dire si c’est significatif en FAT32. L’emuMMC en fichier sur une partition exFat edit: FAT32 de la SD est très lente cela dit.
Le truc c’est qu’en mode fichier ton emuNAND peut être fragmentée (logique des FS FAT), ce qui oblige le CFW à passer par la FAT de la partition contenant les fichiers emunand pour switcher sur les bons clusters lors des accès en lecture/écriture, puis de repasser par la FAT (cette fois-ci de l’emuNAND fichier) pour enfin accéder aux vraies données. Bref ça fait double emploi, en tout cas pour les partitions FAT de la RAWNAND (essentiellement SYSTEM et USER).
@eliboa C'est très surprenant car moi qui suis en Emunand SXos sur une carte SD scandisk de 400 Go en FAT32, je trouve mon Emunand super rapide.
Oui apparemment le problème de lenteur ne concerne que emuMMC, pas l'emuNAND de la TX.
Oui apparemment le problème de lenteur ne concerne que emuMMC, pas l'emuNAND de la TX.@eliboa C'est très surprenant car moi qui suis en Emunand SXos sur une carte SD scandisk de 400 Go en FAT32, je trouve mon Emunand super rapide.