POC Download avec Hash+Taille => GégènBinaire

* jusqu'à FF FF FF FF FF (pardon ; pas jusqu'à 11 11 11 11 11)
* pour la retenue : 00 FF + 01 = donne 00, je retiens 01 = 01 00

< À choisir selon l'autonomie du script ; par exemple, ImDisk doit à priori être installé ... >
* Nom et emplacement : C:\Fonctionne sans installation\AutoDownloGenerator ADG (icon)
* Nom et emplacement : C:\Fonctionne avec installation\AutoDownloGenerator ADG (icon)
< / À choisir selon l'autonomie du script ; par exemple, ImDisk doit à priori être installé ... >
* Note pour l'ajout d'un module dans le script, très basique au départ, amélioré ensuite :
- Pour utiliser la mémoire vive au lieu d'un support physique lent comme un disque dur.
- InfoLogiciel = ImDisk = Disquettes virtuelles (ET+) | CommentCaMarche :
- http://www.commentcamarche.net/forum/affich-24302838-infologiciel-imdisk-disquettes-virtuelles
* Script en ".bat" ou en ".vbs" ... ? Licence du tout, logiciel libre et gratuit ; à vie of course !
* Nom pour la rubrique = Author(s) : "By People of the world (Because it is a free tool) !"
* Ajout d'une rubrique = Participant(s) : nom et lien web total confiance (seb, korb, par ex.)
* Disponibilité des hashs du script sur des sites fiables afin de pouvoir en vérifier l'intégrité.
* Lien web vers source(s), vers sites fiables de stockage étique ; ccm, sourceforge.net ...

* Malheureusement, même si pour écrire, "XVI32" va quand même servir, "XVI32" ne peut pas lire les données (j'ai testé un peu pour essayer de comprendre le fonctionnement), comme HexDump le fait (par Rich Pasco = http://www.richpasco.org/utilities/hexdump.html) et vous ne pouvez pas faire des tests conditionnels facilement directement dans les scripts de "XVI32". Il faut donc utiliser HexDump, simplement pour pouvoir lire la valeur voulue et pour la transmettre. (L'option pour lire dans "XVI32" ; http://www.chmaas.handshake.de/delphi/freeware/xvi32/xviscr.htm : "Verify that <hex string> is found at current address, otherwise execution of script will be aborted with an error message." C'est donc prévu pour planter avec une erreur quand on veut lire une valeur non présente. Si quelqu'un de plus crédible que moi peut écrire à l'auteur, ce serait sympa, merci.)
* Reste le codage de l'itérateur hexadécimale à faire, puis l'assemblage de tous les modules dans un conteneur zip pour faciliter la vie de l'utilisateur, mais en respectant la licence, même si c'est des freewares, de chacun des modules.
* C'est frustrant de manquer de connaissances pour le faire soi-même et rapidement, alors que certains le feraient rapidement et en un seul bloc. merci d'aider ; faut un bootstrap, un script fonctionnel ; d'autres prendront la relève si ils voient que ça fonctionne, même si c'est lent à générer un fichier. merci.

Google translate :
Si je comprends bien, vous voulez reconstruire un fichier binaire de grande taille à partir de plusieurs valeurs de hash MD5 + SHA1 + + crc32 sha256, réalisant ainsi une compression énorme. Ce n'est pas possible. En voici la preuve:

Il ya 2 ** N possibles différents fichiers de longueur N bits, et 2 ** fichiers différents M de M bits de longueur. Par conséquent, toute la cartographie à partir de fichiers de longueur N bits pour les fichiers de M bits de longueur, M <N, doit être beaucoup-to-one.

Autrement dit, une petite collection de mots de passe courts ne contient pas suffisamment d'informations pour reconstruire uniquement le fichier d'origine. Bien sûr, vous pouvez générer un fichier avec les mêmes valeurs de hachage, mais il ne sera pas nécessairement identique au fichier original.

Message in french (at the top) and in english (at the bottom) !
Message en français (en haut) et en anglais (en bas) !

- - - -

Bonjour et merci beaucoup d'avoir pris sur votre temps pour répondre suite à mon courriel (interface sur votre site web ; et pour HexDump).

Non, ce n'est pas du tout ce que vous avez décrit dans votre message, ce n'est pas cela. Non, ce n'est pas un algorithme de compression ; non, rien à voir. Le hash CRC32 et les autres hashs sont déduits avec un algorithme mais cela n'est pas le sujet. Vous pouvez aussi devoir traiter un fichier zip ; là aussi, rien à voir. Rien à voir avec les problèmes liés à : http://en.wikipedia.org/wiki/Entropy_(information_theory) ; ce n'est pas ce que je propose.

Mon POC consiste simplement en une recherche systématique d'une correspondance (on apprend cela en maternelle : http://img99.imageshack.us/img99/3207/cubeducatifvt1.jpg ; ce n'est pas une blague). Rien de magique ; si un hash recherché correspond à celui généré depuis le fichier dont la taille est déjà identique au fichier d'origine, on sait que le contenu du fichier correspond au fichier original. Les problèmes de collisions sont connues ; je parle d'utiliser 4 hashs uniquement pour éviter les problèmes de collisions ; on vérifie le hash CRC32 (ou un autre hash plus rapide), et uniquement si il correspond, on vérifie les autres hashs, MD5 + SHA1 + SHA256 ; comme pour n'importe quel fichier.

Démonstration : considérez par exemple, la création d'un fichier vide ; ici une image de disquette standard de 1474560 octets ; la taille d'une image de disquette est toujours pareil mais le contenu peut changer sauf erreur :

Commande Windows :
fsutil file createnew c:\disquette.img 1474560

Commande Linux :
dd if=/dev/zero of=disquette.img bs=1k count=1474560

Donnez-moi s'il vous plaît les hashs CRC32 + MD5 + SHA1 + SHA256 de l'image d'une disquette que vous avez chez vous (vous pouvez utiliser http://implbits.com/HashTab.aspx ; ajoutez SHA256 dans les options). La taille de l'image de la disquette doit être de 1474560 octets. Si la taille n'est pas de 1474560 octets, indiquez la taille en plus des hashs, on fera un fichier vide de la taille correcte. Ok, s'il vous plaît ; vous comprenez le principe de la démarche ?

Donnez-moi s'il vous plaît aussi le nom original de votre fichier avec l'extension.

Donnez-moi s'il vous plaît les timecodes pour améliorer la reproduction à l'identique ; ac.exe Attribute Changer http://www.petges.lu/download/ permet de changer les dates et heures des fichiers ; mais n'est pas pilotable par un script, sauf erreur.

NOTE : C'est mieux, s'il vous plaît, de fournir les informations pour un fichier zip, avec le fichier voulu dedans, car c'est moins long à traiter si la taille est plus petite ; car il y a moins d'itérations à faire. Ce n'est pas la peine de faire un zip si la taille n'est pas moindre.

Maintenant que j'ai le nom du fichier avec l'extension, les timecodes, la bonne taille du fichier et les hashs CRC32 + MD5 + SHA1 + SHA256 (plusieurs hashs pour la sécurité et la vérification = pour la redondance et pour éviter les risques de collisions), je peux commencer la procédure.

On a donc un fichier vide de 1474560 octets nommé disquette.img ne contenant que des 0x00 (zéros) ; vérifiez cela avec un éditeur hexadécimal ou vérifiez que le hash CRC32 = 00000000 (zéro). La valeur CRC32 est toujours zéro pour un fichier vide, sauf erreur.

Le contenu du fichier vide qui ne contient pour l'instant que des zéros va être itéré séquentiellement en ajoutant +0x01 à chacune des étapes, après la vérification du hash le plus rapide. On test un seul hash, le CRC32 (standard et rapide), puis les autres (MD5 + SHA1 + SHA256) uniquement si il y a un résultat positif avec le hash CRC32.

C'est la vitesse d'itération et la vitesse de vérification du hash CRC32 (ou d'un hash plus rapide) qui peut poser un problème.

La modification du fichier est simple à comprendre :
Par exemple, avec un fichier de 4 octets ; itération de +0x01 :

Step 1 : XXXXX = 0x 00 00 00 00 <= CRC32=00000000 ; pas de blague !
Step 2 : +0x01 = 0x 00 00 00 01 <= Test CRC32 ok ou non ? non, step 3
Step 3 : +0x01 = 0x 00 00 00 02 <= Test CRC32 ok ou non ? non, step n
(...)
Step n : +0x01 = 0x FF FF FF FF <= Arrivez ici, vous avez fait une erreur ou vous n'avez pas de chance ; une image de disquette (normale) ne peut pas être remplie que de valeur hexadécimale FF (habituellement) !

C'est simple à comprendre ? Il faut ajouter +0x01 dans le contenu du fichier à droite (à la fin du fichier) avec un script pilotant un éditeur hexadécimal ou avec un outil dédié. On vérifie si le hash CRC32 correspond ou pas à chaque itération (+ MD5, SHA1, SHA256, si le hash CRC32 donne un résultat positif).

Il manque une fonction dédiée que j'ai envie de nommer "push" permettant d'ajouter +0x01 ou de retrancher -0x01 dans un fichier pour itérer rapidement le contenu d'un fichier. HexDump est parfait pour lire la valeur d'un offset dans un fichier et XVI32 permet d'écrire laborieusement dans un offset, ce qui est bien que l'on puisse le faire mais c'est trop lent d'utiliser deux outils et non-dédiés pour faire ce que je souhaite. Il faudrait un outil unique et dédié.

HexDump est un outil très pratique pour lire la valeur d'un offset en utilisant le programme dans un script ; la possibilité d'écrire serait un plus énorme. C'est pour cela que je vous ai écrit.

HexDump peut créer un fichier de sortie contenant la valeur de l'offset lu ; ce processus est trop lent pour faire ce que je souhaite. Il faudrait des variables créées et lues automatiquement par HexDump ; par exemple :

set "HexDump_abcd1234_Offset1Read="
set "HexDump_abcd1234_Offset1ReadValue="

set "HexDump_abcd1234_Offset1Write="
set "HexDump_abcd1234_Offset1WriteValue="

set "HexDump_abcd1234_OffsetMultiReadFirst="
set "HexDump_abcd1234_OffsetMultiReadLatest="
set "HexDump_abcd1234_OffsetMultiReadChainValue="

set "HexDump_abcd1234_OffsetMultiWriteFirst="
set "HexDump_abcd1234_OffsetMultiWriteLatest="
set "HexDump_abcd1234_OffsetMultiWriteChainValue="

set "HexDump_abcd1234_OffsetValuePush="+0xnn|-0xnn (valeur et sens pour l'itération)

set "HexDump_abcd1234_OffsetGoPush=" (HexDump attend et lit la valeur, utilise les variables indiquées ci-dessus et efface cette valeur et écrit une autre valeur ci-dessous)

set "HexDump_abcd1234_OffsetOkPush=" (le script de pilotage attend une valeur, enregistre que c'est ok, et peut continuer)

Actuellement, la syntaxe de HexDump utilisable avec un script est :

hexdump filename [ /skip:n] [ /keep:n] [ /bare] > dumpfile.txt

/skip:n = Offset where to begin dumping (prefix hex with $)
/keep:n = Number of bytes to dump
/bare = Omit headings

Améliorations ; suggestions :

hexdump [ /Write:YES] [ /push:script |+0xnn |-0xnn] [ /idscript:abcd1234(default) |abcd1234_abcd1234.. |allinstances] [ /cmdscript:findallinstances |gopush |pauseusefile |resumeusefile |stopandask |stopnoask |waitokpush] filename [ /skip:n] [ /keep:n] [ /bare[ :appendmode |dataonly]] [ /modespace:A_A_F_F |AA_FF(default) |AAFF] [ /varmode:file |var |bothfilevar] [ >[ >] dumpfile.txt]

/Write:YES = Allow writing ; command case sensitive, in lowercase and uppercase as a precaution (En français : Autoriser l'écriture ; commande sensible à la casse, en minuscule et majuscule par précaution)

/push:script|+0xnn|-0xnn :
/push:script = Option permettant de gérer la fonction push depuis un script en lien avec les variables spéciales lues et écrites par HexDump. Les variables "HexDump_abcd1234_OffsetGoPush" et "HexDump_abcd1234_OffsetOkPush" permettent à un script et à HexDump de communiquer. HexDump et le fichier traité par HexDump peuvent rester ouverts (voir l'aide complète pour cette fonction).
/push:+0xnn = Ajoute par exemple +0x01 à la valeur hexadécimale lue dans le fichier ou à la chaine lue dans le fichier ou à la fin du fichier.
/push:-0xnn = Retranche par exemple -0x01 à la valeur hexadécimale lue dans le fichier ou à la chaine lue dans le fichier ou à la fin du fichier.

L'option qui serait utilisable depuis un script pour pouvoir écrire dans un fichier serait très appréciée. L'option "push" permettrait d'accélérer la procédure d'itération (au format hexadécimale) du contenu de l'intérieur des fichiers de travail. Les boucles de traitement (for loop if ... do them else) seraient plus rapides dans les scripts avec une fonction "push" dédiée. Merci pour au moins ajouter la fonction "/Write:YES".

La vitesse est le problème, mais ça fonctionne.

J'ai déposé du code dans ce sujet, j'ai amélioré la présentation (code que chez moi pour l'instant) mais c'est pas facile de tout incorporé et personne ne m'aide directement :

POC AutoDownloGenerator.bat (OpenSource) svp :
http://www.commentcamarche.net/forum/affich-24327979-poc-autodownlogenerator-bat-opensource-svp

à vous lire (et oui, merci Google Traduction ; texte retravaillé à la main)
(j'ai mis trois jours pour écrire ce message ; merci)
http://translate.google.fr/?hl=fr#fr|en|

- - - -

Hello and thank you very much for taking on your time to answer following to my email (interface on your website ; and for HexDump).

No, not at all what you described in your post, it's not that. No, this is not a compression algorithm, no, nothing to do. The CRC32 hash and other hashes are derived with an algorithm but it is not the issue. You may also have to deal with a zip file, again, nothing to do. Nothing to do with the problems : http://en.wikipedia.org/wiki/Entropy_(information_theory) ; this is not what i propose.

My POC is simply a systematic search for a match (we learn this in kindergarten : http://img99.imageshack.us/img99/3207/cubeducatifvt1.jpg ; it's not a joke). Nothing magic, if a desired hash matches that generated from the file whose size is already identical to the original file, we know that the contents of the file matches the original file. The collision problems are known, i talk to use to use four hashes only to avoid collision problems, we check the CRC32 hash (or other faster hash), and only if it matches, we will checks the other hashes, MD5 + SHA1 + SHA256, as for any file.

Demonstration : Consider by example, the creation of an empty file ; here a standard floppy disk image of 1474560 bytes, the size of a floppy disk image is always the same but the content may change unless error :

Command Windows :
fsutil file createnew c:\disquette.img 1474560

Command Linux :
dd if=/dev/zero of=disquette.img bs=1k count=1474560

Give me please the hashes CRC32 + MD5 + SHA1 + SHA256 of a floppy disk image that you have at home (you can use http://implbits.com/HashTab.aspx ; add SHA256 in options). The size of the floppy disk image should be of 1474560 bytes. If the size is not of 1474560 bytes, specify the size in most of the hashes, we will make a empty file of the correct size. Ok, please, you understand the principle of the process ?

Give me please also the name of your original file with the extension.

Give me please the timecodes to improve the identical reproduction ; ac.exe Attribute Changer http://www.petges.lu/download/ allows to change the date and time of files, but is not controllable by a script, unless error.

NOTE : This is better, please, provide the information for a zip file with the file you want into it, because it takes less time to process if the size is smaller, because there are fewer iterations to do. It's not worth making a zip file if size is not reduced.

Now that i have the file name with extension, the timecodes, the good file size and the hashes CRC32 + MD5 + SHA1 + SHA256 (multiple hashes for security and verification = for redundancy and to avoid risks collisions), i can start the procedure.

So we have an empty file named disquette.img 1474560 bytes containing only 0x00 (zero) ; verify this with a hex editor or check the hash CRC32 = 00000000 (zero). The CRC32 value is always zero for an empty file, unless error.

The contents of the file void that currently contains only zeros will be iterated sequentially adding 0x01 at each steps, after verifying the hash the most fastest. We test a single hash, the CRC32 (standard and fast) and others (MD5 + SHA1 + SHA256) only if there is a positive result with the hash CRC32.

It is iteration speed and speed verification CRC32 hash (or an hash most faster) which can be a problem.

Changing the file is simple to understand :
For example, with a file of 4 bytes ; iteration of 0x01 :

Step 1 : XXXXX = 0x 00 00 00 00 <= CRC32=00000000 ; no joking around !
Step 2 : +0x01 = 0x 00 00 00 01 <= Test CRC32 ok or no ? no, step 3
Step 3 : +0x01 = 0x 00 00 00 02 <= Test CRC32 ok or no ? no, step n
(...)
Step n : +0x01 = 0x FF FF FF FF <= Come here, you made a mistake or you are out of luck ; a floppy image (normal) can not be filled only with the values hexadecimal FF (usually) !

It is easy to understand ? We must add +0x01 in the file contents on the right (end of file) with a script driving a hex editor or with a dedicated tool. We check if the hash matches CRC32 or not at each iteration (+ MD5, SHA1, SHA256, if the hash CRC32 gives a positive result).

It lacks a dedicated function that i want to call "push" to add +0x01 or to subtract -0x01 in a file to iterate quickly the contents of a file. HexDump is perfect for reading the value of an offset in a file and XVI32 allows you to write laboriously in an offset, which is good that we can do but it's too slow to use two tools and non-dedicated to do what i want. There should be a tool, unique and dedicated

HexDump is a very handy tool to read the value of an offset using the program in a script, the ability to write would be a huge plus. This is why i wrote you.

HexDump can create an output file containing the offset value read ; this process is too slow to do what i want. Variables should be created and automatically read by HexDump ; by example :

set "HexDump_abcd1234_Offset1Read="
set "HexDump_abcd1234_Offset1ReadValue="

set "HexDump_abcd1234_Offset1Write="
set "HexDump_abcd1234_Offset1WriteValue="

set "HexDump_abcd1234_OffsetMultiReadFirst="
set "HexDump_abcd1234_OffsetMultiReadLatest="
set "HexDump_abcd1234_OffsetMultiReadChainValue="

set "HexDump_abcd1234_OffsetMultiWriteFirst="
set "HexDump_abcd1234_OffsetMultiWriteLatest="
set "HexDump_abcd1234_OffsetMultiWriteChainValue="

set "HexDump_abcd1234_OffsetValuePush="+0xnn|-0xnn (value and direction for iteration)

set "HexDump_abcd1234_OffsetGoPush=" (HexDump expects and reads the value, using the variables listed above and delete this value and write another value below)

set "HexDump_abcd1234_OffsetOkPush=" (the driver script expects a value, stores it's ok, and can continue)

Currently, the syntax of HexDump usable with a script is :

hexdump filename [ /skip:n] [ /keep:n] [ /bare] > dumpfile.txt

/skip:n = Offset where to begin dumping (prefix hex with $)
/keep:n = Number of bytes to dump
/bare = Omit headings

Improvements ; suggestions :

hexdump [ /Write:YES] [ /push:script |+0xnn |-0xnn] [ /idscript:abcd1234(default) |abcd1234_abcd1234.. |allinstances] [ /cmdscript:findallinstances |gopush |pauseusefile |resumeusefile |stopandask |stopnoask |waitokpush] filename [ /skip:n] [ /keep:n] [ /bare[ :appendmode |dataonly]] [ /modespace:A_A_F_F |AA_FF(default) |AAFF] [ /varmode:file |var |bothfilevar] [ >[ >] dumpfile.txt]

/Write:YES = Allow writing ; command case sensitive, in lowercase and uppercase as a precaution (In french : Autoriser l'écriture ; commande sensible à la casse, en minuscule et majuscule par précaution)

/push:script|+0xnn|-0xnn :
/Push:script = Option to handle the push from a script related to the special variables read and written by HexDump. The variables "HexDump_abcd1234_OffsetGoPush" and "HexDump_abcd1234_OffsetOkPush" allow to a script and to HexDump to communicate. HexDump and file processed by HexDump can remain open (see the full help for this function).
/push:+0xnn = Add by example +0x01 to the hexadecimal value read inside the file or the string read inside the file or at the end of file.
/push:-0xnn = Subtract by example -0x01 to the hexadecimal value read inside the file or the string read inside the file or at the end of file.

The option would be used from a script to be able to write to a file would be much appreciated. The "push" would accelerate the iteration procedure (in hexadecimal format) of the contents of the interior working files. The processing loops (for loop if ... else do them) would be most fasters in scripts with a function "push" dedicated. Thank you for at least add the "/Write:YES".

Speed is the problem, but it works.

I have filed a piece of code in this topic, i have improved the presentation (code only at my home, for now) but it is not easy to all incorporated and no one helps me directly :

POC AutoDownloGenerator.bat (OpenSource) svp :
http://www.commentcamarche.net/forum/affich-24327979-poc-autodownlogenerator-bat-opensource-svp

to read you (and yes, thank you Google Translation ; text reworked by hand)
(it took me three days to write this message ; thank you)
http://translate.google.fr/?hl=fr#fr|en|