Notre amis Sunriseur et développeur Eliboa vient de mettre en ligne une nouvelle version de son logiciel TegraRcmGUI. Il s'agit d'une GUI (Guide User Interface) pour TegraRcmSmash de rajkosto.
Cette version est la 2.5.
TegraRcmGUI permet d'injecter des payloads, de lancer Linux sur Nintendo Switch ou encore de monter la carte SD comme étant une clé USB.
Changelog :
Payloads embarqués :
- TegraRcmSmash mis à jour en version 1.2.1-3
- memloader mis à jour en version 3
- Ajout des exemples UMS de rajkosto pour monter les partitions eMMC
- biskeydump v7 ajouté : dumper les BIS keys pour déchiffrer le contenu eMMC
- Ajout d'une console de journalisation
Credits :
- Fusee primary (Atmosphere bootloader)
- Hekate CTCaer 4.6
- ReiNX bootloader
- SX Loader (SX OS bootloader)
- Rajkosto : TegraRcmSmash, memloader, SD tool, biskeydump
- SciresM : Atmosphere
- CTCaer : Hekate
- Reisyukaku : ReiNX
Eliboa nous informe sur la fonction dump :
Pour info, en montant votre rawNAND via memloader v3 et en utilisant HacDiskMount, le dump de la NAND prend environ 100 minutes.
L'avantage est que vous pouvez directement dumper la NAND à l'endroit où vous souhaitez conserver le dump (sur un NAS par exemple).
Cela permet d'économiser l'étape de transfert du dump de la SD vers votre PC/NAS. si j'ai le temps j'essaierai d'intégrer une fonctionnalité de dump de NAND directement depuis TegraRcmGUI
Disponible ici : https://github.com/e...RcmGUI/releases
Le changelog en français :
Changelog :
- TegraRcmSmash mis à jour en version 1.2.1-3
- memloader mis à jour en version 3
- Ajout des exemples UMS de rajkosto pour monter les partitions eMMC
- biskeydump v7 ajouté : dumper les BIS keys pour déchiffrer le contenu eMMC
- Ajout d'une console de journalisation
- Issue #22 corrigée
Payloads embarqués :
- Fusee primary (Atmosphere bootloader)
- Hekate CTCaer 4.6
- ReiNX bootloader
- SX Loader (SX OS bootloader)
Pour info, en montant votre rawNAND via memloader v3 et en utilisant HacDiskMount, le dump de la NAND prend environ 100 minutes.
Ben pas celle qui sont patchée normalement... c'est le principe du patch hardware.merci
ca marche sur toutes les consoles ? n'importe qu'elle S/N ?
@eliboa serait-il possible d'ajouter un script wget ou équivalent pour mettre à jour la version portable stp?
Merci pour ton taf.
J'y ai déjà pensé plusieurs fois mais ça prendrait un peu de temps à coder. Pour le moment je me concentre sur des fonctionnalités spécifiques à la Switch mais pourquoi pas dans une prochaine version majeure un gestionnaire de mise à jour (ou au moins contrôler qu'une maj est dispo). Une fois que j'aurai codé la feature de dump/restore des partitions de la NAND, peut-être que je m'y mettrai ^^
News mise a jourLe changelog en français :
Changelog :- TegraRcmSmash mis à jour en version 1.2.1-3- memloader mis à jour en version 3- Ajout des exemples UMS de rajkosto pour monter les partitions eMMC- biskeydump v7 ajouté : dumper les BIS keys pour déchiffrer le contenu eMMC- Ajout d'une console de journalisation- https://github.com/e...cmGUI/issues/22 corrigée Payloads embarqués :- Fusee primary (Atmosphere bootloader)- Hekate CTCaer 4.6- ReiNX bootloader- SX Loader (SX OS bootloader)
Pour info, en montant votre rawNAND via memloader v3 et en utilisant HacDiskMount, le dump de la NAND prend environ 100 minutes.
L'avantage est que vous pouvez directement dumper la NAND à l'endroit où vous souhaitez conserver le dump (sur un NAS par exemple).
Cela permet d'économiser l'étape de transfert du dump de la SD vers votre PC/NAS. si j'ai le temps j'essaierai d'intégrer une fonctionnalité de dump de NAND directement depuis TegraRcmGUI
Je peux te coder ça en quick and dirty pour un 1er jet si tu veux, je le balance sur ton git en issue ou uen post sur LS, après tu en fais ce que tu veux au pire.J'y ai déjà pensé plusieurs fois mais ça prendrait un peu de temps à coder. Pour le moment je me concentre sur des fonctionnalités spécifiques à la Switch mais pourquoi pas dans une prochaine version majeure un gestionnaire de mise à jour (ou au moins contrôler qu'une maj est dispo). Une fois que j'aurai codé la feature de dump/restore des partitions de la NAND, peut-être que je m'y mettrai ^^@eliboa serait-il possible d'ajouter un script wget ou équivalent pour mettre à jour la version portable stp?
Merci pour ton taf.
Je peux te coder ça en quick and dirty pour un 1er jet si tu veux, je le balance sur ton git en issue ou uen post sur LS, après tu en fais ce que tu veux au pire.
:-)
Je dis pas non, si ça me fait gagner du temps je prends thx
Alors là cette fonctionnalité serait intéressante, je suis curieux de savoir comment tu vas coder çà. Tu penses t'appuyer sur un soft genre DD? J'avais jamais pensé à faire ce truc, se serait une fonctionnalité à ajouté à mon script, merci pour l'idée.Une fois que j'aurai codé la feature de dump/restore des partitions de la NAND, peut-être que je m'y mettrai ^^
merci à tous pour vos retours sympas
Alors là cette fonctionnalité serait intéressante, je suis curieux de savoir comment tu vas coder çà. Tu penses t'appuyer sur un soft genre DD? J'avais jamais pensé à faire ce truc, se serait une fonctionnalité à ajouté à mon script, merci pour l'idée.
J'ai déjà bien avancé, en 2 heures en fait ^^. Je voulais partir de zéro mais j'imagine qu'un dd pour Windows ferait aussi l'affaire.
En C tu peux créer facilement un handle vers un disque physique avec la fonction CreateFileW, même sans lettre affectée au disque, via son adresse du style \\.\PHYSICALDRIVE2. Après il suffit juste de lire en boucle dans un buffer (ReadFile) depuis le handle, puis écrire ce buffer dans un stream de sortie. En théorie c'est vraiment assez simple. Pour l'instant j'ai testé qu'avec un partition boot (4MB) et le dump est 100% identique à celui fait par Hekate mais faut que je teste sur la raw NAND car je sais pas ce que ça va donner concernant les temps de traitement, je cherche à savoir quelle taille de buffer utiliser pour être le plus rapide possible.
Si ça fonctionne et que ça t'intéresse je pourrais en faire une version CLI pour que tu puisses l’intégrer dans ton script
Alors clairement oui, je suis totalement pour la version CLI si tu y arrives et effectivement en théorie c'est pas trop compliquer, au moins pour le dump, en plus si tu compares le MD5 (ou autre méthode de hash) de la nand puis le MD5/autre hash du dump effectué pendant la procédure tu devrais avoir un résultat plutôt fiable (comme Hekate le fait au final mais par contre çà prend du temps). Par contre pour la restauration là faut voir, en théorie c'est pas plus compliquer mais en pratique à mon avis faut bien gérer l'histoire et bien faire les contrôles d'erreurs parce que sinon ça va être le drame.merci à tous pour vos retours sympas
J'ai déjà bien avancé, en 2 heures en fait ^^. Je voulais partir de zéro mais j'imagine qu'un dd pour Windows ferait aussi l'affaire.
En C tu peux créer facilement un handle vers un disque physique avec la fonction CreateFileW, même sans lettre affectée au disque, via son adresse du style \\.\PHYSICALDRIVE2. Après il suffit juste de lire en boucle dans un buffer (ReadFile) depuis le handle, puis écrire ce buffer dans un stream de sortie. En théorie c'est vraiment assez simple. Pour l'instant j'ai testé qu'avec un partition boot (4MB) et le dump est 100% identique à celui fait par Hekate mais faut que je teste sur la raw NAND car je sais pas ce que ça va donner concernant les temps de traitement, je cherche à savoir quelle taille de buffer utiliser pour être le plus rapide possible.
Si ça fonctionne et que ça t'intéresse je pourrais en faire une version CLI pour que tu puisses l’intégrer dans ton script
@shadow256
Tu peux pas utiliser les long ou unsigned int en batch ? C'est vrai que c'est pas pratique sinon avec ces ordres de grandeur ^^
Oui je vais tester le nom du disque (Linux UMS disk...) et la taille d'abord pour m'assurer de choisir le bon disque. J'avais vu aussi que tu pouvais le faire en requêtant le service WMI (comme dans le script dans ton lien), d'ailleurs une commande powershell sympa pour lister les disques est "Get-WmiObject Win32_DiskDrive". En C j'ai pas encore regardé comment faire mais ça doit être possible sinon je passerai pas une commande système. Comme je trouve le nom du disque trop générique, je pense que j'irai aussi vérifier les magic offsets (comme celui du package1 dans boot0) pour m'assurer qu'il s'agit bien de telle ou telle partition de la NAND (ne serait-ce que pour départager boot0 et boot1 qui font la même taille).
Pour vérifier l'intégrité du dump je le ferai sans doute par checksums. Pour calculer le hash de l'eMMC je vois pas trop comment faire encore... Je vais voir comment fait CTCaer dans Hekate. Je sais pas s'il y a moyen de générer le hash en même temps que la copie (à chaque écriture du buffer) pour éviter de lire 2 fois l'eMMC.
Pour le restore par contre les vérifications seront mes tests car une fois la NAND écrite difficile de revenir en arrière . Après je peux toujours recalculer le hash de l'eMMC mais ça me parait long. Je crois pas qu'hekate le refasse une fois le dump restauré, si ? Le plus important est quand même d'avoir un dump sûr à 100% après pour restaurer y'a plusieurs solutions.
Je te tiens au courant pour le CLI. Je viens de tester le dump des 32Go. Avec un buffer de 0x40000 ça prend 93 minutes sans vérifications. Comparé à environ 100 minutes en le faisant partition par partition via HacDiskMount, ça me parait pas mal ^^.
Faudrait aussi que je pense à faire une version qui splite le dump en fichier < 4go comme SX OS pour ceux qui veulent restaurer par SX OS ou pour ceux qui veulent dumper sur une partition en FAT32 (les irréductibles lol). Enfin si j'ai le temps, je proposerait une fonctionnalité pour dumper/restaurer la NAND partitions par partitions (pour ça faudra lire la GPT). Tout un programme ^^
Yes merci pour ta proposition, ça pourrait m'aider pour les derniers tests, surtout qu'il faut pas que je merde sinon ça pourrait bricker des consoles hé hé.
Du coup je pars sur un programme CLI autonome de TegraRcmGUI dans un premier temps. Je verrai ensuite comment l’y intégrer. Je te tiens au courant dès que je comitte quelque chose sur github. Faudrait déjà que je trouve un nom pour le programme, avec ma créativité débordante je sens ça va être un truc aussi banal que "NX Dumper" ^^
NX-Nand-Tool? Bon je suis pas hyper créatif non plus dans le nom des programmes...
T'as vu les noms de mes scripts, niveau nom de programme je suis juste mauvais.Je vois que tu es autant inspiré que moi