28 réponses à ce sujet

[eliboa]

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

Modifié par eliboa, 04 février 2019 - 20:22.

[shadow256]

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

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.

Avec DD for Windows je pense que ça peut fonctionner, j'ai pas testé mais la commande "dd --list" permet bien de trouver le volume, après le souci est de trouver comment le repérer à coup sûre parce que là faut pas faire de connerie. Alors oui, on peut se baser sur la taille mais c'est pas suffisant, faut trouver une manière d'avoir d'autres paramètres. En cherchant un peu j'ai trouvé comment le détecter de manière plus certaine via un vb script, voir cette page (j'ai dû modifier un peu le script pour qu'il fonctionne en remettant toutes les lignes séparées sur une seul (les lignes qui se finissent par un "_")) et avec çà on peut avoir le nom du disque, à savoir "Linux UMS disk 0 USB Device" et donc savoir facilement à quel nom de disque il est rataché, ensuite plus qu'à vérifier si la taille correspond et là il y a très peu de chances de se tromper de disque. Après clairement en C ou en Python il doit y avoir des méthodes pour faire cela, comme celle que tu décris mais méfiance au niveau de la restauration d'un dump, il faut un sacré contrôle d'erreurs (par exemple se méfier de l'écriture d'un byte nul pendant le processus qui pourrait tout foutre en l'air), c'est pour cela que je pense qu'il vaudrait mieux utiliser un outil comme DD pour faire le dump ou la restauration, au moins il y a déjà des contrôles d'erreurs dans ces logiciels et comme çà il n'y a qu'à détecter le bon disque sur lequel écrire et çà c'est facile au final. Faut aussi vérifier que la taille du fichier qu'on écrit correspond bien à la taille requise mais là non plus c'est pas sorcier.

Par contre, j'aimerai bien trouver une version plus récente de DD que le DD for Windows qui est un peu vieux maintenant, j'ai vu que Git en intègre une mais va falloir que je vérifie s'il a besoin de dépendances spécifiques pour fonctionner mais s'il n'en a pas besoin (se que mes premiers tests basiques tendent à confirmer) alors là ça peut devenir très intéressant. En tous cas je vais aussi procéder à des tests de mon côté pour développer ce truc, je trouve çà intéressant comme petit défit et le faire avec du batch je vais m'amuser, surtout avec la gestion de la taille de la rawnand qui dépasse la limite des nombres gérés par le batch (entiers codés sur 32 bits maximum, type "int" quoi) mais j'avais trouvé une feinte dans mon script de réunification de nand splitées.

PS: Faut vraiment que je me remette au C, ça fait longtemps que j'en ai pas fait et d'avoir développé un peu en Python ces derniers jours m'a donné envi de m'y remettre un peu même si je trouve que les phases de compilation sont chiantes (j'aime pas les environnements de développement type Visual Studio) mais c'est clair que ce langage est top, c'était mon préféré quand j'ai fait mes études de développement. Après Python c'est assez sympa aussi et puis c'est multi-plateformes se qui est vraiment non négligeable.

[Linkynimes]

Merci pour la News et un gros GG a Eliboa pour sont taff

[eliboa]

@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 ^^

Modifié par eliboa, 05 février 2019 - 01:21.

[shadow256]

C'est clair, là tu te lances dans un sacré truc mais par contre c'est super intéressant. Du coup je ne vais pas me lancer là dedans si tu le fais, inutile qu'on fasse chacun un truc pour faire la même chose au final. En tous cas si je peux apporter de l'aide ou si tu as besoin de faire des tests de cette fonctionnalité pas de souci, tu n'as qu'à demander, en tous cas je vais suivre de prêt le Github de ton Tegra RCM Gui ces prochains temps.

Par contre le hash à la volé je pense que ça ne va pas être possible ou du moins tu risques d'au final y perdre du temps. Il me semble que dans Hekate il fait le dump puis il fait les deux hash qu'il compare ensuite et il me semble qu'avec la plus haute fiabilité c'est un hash en sha256, c'est pour ça que c'est long.

Pas mal le dump via ce genre de méthode, une bonne dizaine de minutes de gagné c'est pas négligeable (bon sans les hash bien-sûre).

Et non, pas de "long" en batch, juste des "int". L'avantage dans ce genre de cas c'est que comme on compare des valeurs qui seront toujours les mêmes quoi qu'il arrive c'est gérable, faut juste comparer l'infériorité/égalité/supériorité chiffre par chiffre avec la valeur connue, c'est un peu chiant et très tordu mais faisable. Le batch est pratique mais alors pas très puissant et parfois bien galère (la gestion des bloques est bien chiante par exemple) mais bon au moins on assure un maximum la compatibilité avec les différentes versions de Windows grâce à cela alors qu'avec du Powershell on peut se heurter à des problèmes de versions différentes selon les Windows et là ça peut devenir compliquer à gérer, autant faire du C ou du Python pour le coup.

Modifié par shadow256, 04 février 2019 - 23:59.

[eliboa]

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" ^^

[shadow256]

NX-Nand-Tool? Bon je suis pas hyper créatif non plus dans le nom des programmes...

[eliboa]

NX-Nand-Tool? Bon je suis pas hyper créatif non plus dans le nom des programmes...

Je vois que tu es autant inspiré que moi En tout cas c'est plus approprié car l'appli ne fera pas que dumper donc "Tool" est assez générique pour les évolutions futures.

J'ai réussi à coder la partie calcul et vérification des hash MD5. J'arrive à générer le checksum de l'eMMC à la volée, en même temps que la copie des données, ce qui est plutôt cool .

Du coup le seul temps de calcul supplémentaire (après dump) est le calcul du hash pour le fichier généré. Là pour le coup ça dépend de la vitesse de lecture du dique sur lequel on dumpe (avec un SSD c'est assez rapide).

Je commence à avoir un truc fonctionnel pour dumper la NAND. Plus qu'a ajouter la détection du disque et les contrôle des magic offset et je ferai un premier commit.

[shadow256]

Excellent, t'as fait çà vite et bien dis-moi... En plus calcul du hash à la volé donc pas de perte de temps, carrément top. Je sent que je vais l'aimer ton outil et qu'il va bien me servir.

Je vois que tu es autant inspiré que moi

T'as vu les noms de mes scripts, niveau nom de programme je suis juste mauvais.