Discussion :

[n5Rzn1D9dC]

Salut,

J'ai passé pas mal de temps à essayer de décompresser un gzip de serveur http en utilisant la zlib, mais pas moyen.
Alors déjà, je n'ai jamais vu un code aussi mal conçue, d'un point de vue pratique.

Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
	mov	rcx,163
	mov	edx,dword [buf1_ptr]
	mov	esi,dword [dstlen_ptr]
	mov	edi,dword [buf2_ptr]
	xor	eax,eax
	call	[uncompress]
 
buf1_ptr   dq buf1
buf2_ptr   dq buf2
buf3_ptr   dq buf3
dstlen_ptr dq dstlen
 
buf1   rb 512
buf2   rb 512
buf3   rb 512
dstlen dq 512

Etre obligé de faire des pointeurs de pointeurs pour une fonction aussi basique, je trouve ça complètement ridicule et vraiment énervant. Tellement énervant que j'avais commencé à lire la rfc pour faire mon propre code, mais bon, ça me prendrait du temps que je n'ai pas en ce moment car j'ai d'autre chose à coder plus importante.
Si encore ça fonctionnerait, mais ce n'est pas le cas.
Tout aussi ridicule de devoir préciser la taille des deux buffers, taille qui pourrait être calculer avec 5 lignes d'asm.
Je m'attendais vraiment à du lourd pour l'implémentation d'algo de compression/codage, mais là c'est tout l'inverse.

Quand je tente de compresser et decompresser des bytes dans un buffer, ça fonctionne parfaitement.
J'ai même récupéré les bytes compressés, puis lancé de nouveau le code avec uniquement "uncompress", au cas où l'une n'aurait pas pu fonctionner à part de l'autre, mais non, ça fonctionne également.

Par contre, impossible de déchiffrer les byte que j'ai récupéré d'une page web, celle-ci:
http://www.perdu.com/

J'ai lancé Wireshark pour récupérer le code gzip du push+ack de la page d'acceuil de ce site.
Donc ce code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
1f8b0800000000000003358fb10ec2300c4477bec213480814d115cb4c0c6c9dd84363914825298e5389bf2721e2d6f7ce3aa3d7d74ce8d93a420d3a33dd53c97055ce30b2b80217341da0e9da23b94fad9ca8f35c04e6dd2d2a4b646d7a45e8071a6d06c7b0d818de850f9022ac16d676de06c752c58130aba4f8245c84096af680c7962e6e790a329ddb9a300534cd42f3ef983ec5fc9ed87c01b4a18a2dcc000000

Il est dans le fichier texte en pièce, parfaitement déchiffrable avec un zcat test.txt, ou un gzip -d -c test.txt

Mais pas moyen avec la zlib, alors là je capte vraiment pas.
La fonction me revoit un code -3 "Z_DATA_ERROR"

La seule explication que je vois c'est que ce n'est pas du gzip, mais du deflate pur.
Mais alors pourquoi zcat et gzip me le décompresseraient..
De plus Wireshark utilise la zlib pour déchiffrer.
A moins qu'il utilise d'autres api de la zlib liées spécialement au deflate.
J'ai tracé les appels, rien de visible concernant la zlib. Je trouve ça étrange également, car Wireshark est censé vérifier si la zlib est présente lors de la compilation, c'est donc qu'il utilise la librairie, est non qu'il dispose de sa propre implémentation de celle-ci.

Bref, je suis perdu.
Si quelqu'un arrive à déchiffrer ce fichier avec la zlib, bah bravo, parce que moi c'est mort et j'ai cherché longtemps.

[ctrlD]

A tout hasard, il y aurai pas un souci avec le format d'encodage de la chaîne ?

Ou bien rapidement lu sur stackoverflow :

To decompress a gzip format file with zlib, call inflateInit2 with the windowBits parameter as 16+MAX_WBITS, like this:

inflateInit2(&stream, 16+MAX_WBITS);

If you don't do this, zlib will complain about a bad stream format. By default, zlib creates streams with a zlib header, and on inflate does not recognise the different gzip header unless you tell it so. Although this is documented starting in version 1.2.1 of the zlib.h header file, it is not in the zlib manual. From the header file:

windowBits can also be greater than 15 for optional gzip decoding. Add 32 to windowBits to enable zlib and gzip decoding with automatic header detection, or add 16 to decode only the gzip format (the zlib format will return a Z_DATA_ERROR). If a gzip stream is being decoded, strm->adler is a crc32 instead of an adler32.



The structure is different from zlib gzip. ZLIB uses rfc 1950 and gzip uses rfc 1952, so have different headers but the rest have the same structure and follows the rfc 1951.

Si ça peut aider...

[n5Rzn1D9dC]

Ah ok, donc les fonctions inflate fonctionnerait avec uncompress.
Je ne pensais pas que c'était lié.
Faut dire qu'avec leur gros paté de commentaires qui font entre 10 et 50 lignes entre chaque fonction du header, c'est soit tu lis tout et t'en as pour plusieurs heures, soit tu lis rien et tu comprends à moitié.

Arf dès que j'aurais le temps je vais faire un code digne de ce nom pour gzip et deflate. Un truc simple comme le monde qui pourra être appelé comme ça:
call decompress,out,in

Avec au pire, une fonction à appeler avant pour sélectionner le format et la compression:
call config,flag,level

0 = deflate
1 = gzip

J'ai pourtant cherché un pur code asm, mais pas moyen, j'en ai trouvé aucun, même sur le forum de Fasm, ce qui est très étonnant puisque sur ce forum il y a vraiment des trucs de dingue. J'ai déjà trouvé une pure implémentation d'AES par exemple, ce qui est infiniment plus complexe à implémenter.
Aucun code asm, quelque soit le compilo pour une librairie aussi ancienne et connue, je trouve ça incroyable. Ou alors c'est que les mecs gardent leur code privé.

Et je ne critique pas zlib parce que c'est du C.
Il y a des api vraiment excellente sous Linux, comme par exemple SSL et la libcrypto.
Utiliser SSL, ça m'a pris genre 15 minutes, le temps d'écrire le code.
J'ai juste eu à lire la partie "description" de cette page:
http://www.openssl.org/docs/ssl/ssl.html

Rien d'autre.
Comme quoi quand c'est bien pensée, bien codé, pas besoin d'écrire des patés de 50 lignes entre chaque fonction, ni de faire des far ptr pour une fonction externe.

Tout est mal fait pour la zlib. Le code, le header, la doc.

Autre chose, les fonctions gz qui ne fonctionnent qu'avec un file descriptor..
C'est les premières fonctions que j'ai essayé d'utiliser, et là je me suis dit "mais c'est quoi ce délire ? On fait comment pour déchiffrer un simple buffer !"

Enfin bref..
Je vais explorer ce que tu m'as indiqué ctrlD. merci.

edit:
A première vu ce serait bien les fonctions inflate qu'il faut utiliser:

inflate() can decompress and check either zlib-wrapped or gzip-wrapped
deflate data. The header type is detected automatically, if requested when
initializing with inflateInit2(). Any information contained in the gzip
header is not retained, so applications that need that information should
instead use raw inflate, see inflateInit2() below, or inflateBack() and
perform their own processing of the gzip header and trailer. When processing
gzip-wrapped deflate data, strm->adler32 is set to the CRC-32 of the output
producted so far. The CRC-32 is checked against the gzip trailer.

Et dans le header, inflateInit et inflateInit2 sont toutes les deux mises en commentaires.
Funny quand même leur façon de faire.
Donc même si j'aurais tout lu, il y a de forte chance que j'aurais zappé ces deux passages en voyant que les exports étaient en commentaire.

[n5Rzn1D9dC]

Impossible de faire fonctionner inflateinit.

J'ai regardé dans Wireshark, et apparemment, on dirait que zlib n'est pas réellement une implémentation, puisqu'il faut soit même gérer les éléments de la structure stream, avec next_in, next_out, etc..
Bref j'arrête avec ça. C'est du n'importe quoi. Pour faire ça autant rien faire.

Par contre j'ai trouvé un autre truc "libarchive", qui a l'air pas mal à première vu.
Déjà je lance la première fonction à lancer, et ça ne plante pas et renvoi pas d'erreur, incroyable !

Idem pour la deuxième fonction ! Incredible !

Sans oublier que le programme dispose d'une doc qui ressemble à une doc et qui indique l'ordre de lancement des fonctions !
Serais-je enfin tombé sur ce que je cherche depuis des années..

[n5Rzn1D9dC]

Non c'est la même avec cette api. Complètement bloqué à partir d'un moment.
Là c'est bon ça m'a soulé. Je vais faire ma propre implémentation, ça ira plus vite que d'essayer de comprendre comment fonctionne leur truc.

a+

[n5Rzn1D9dC]

Bon je viens de faire mon crc32.
Basé sur la version fast-crc de la rfc gzip.
Et optimisé asm:
1 - dword inutiles virés et remplacés par registre 8bits.
2 - "and" inutles viré, grace au (1) (il n'y a pas plus tuant en performance qu'un "and" reg/mem, sur mon proc en tout cas).
3- Aucune variable locale ni utilisation de pile (sauf une seule pour le stockage de la table)
Etc...

Ca m'a pris quand même une heure, le temps d'apprendre à lire le C. Jusqu'à présent j'étais vraiment dans une connaissance très rudimentaire du C : /
Mais vu que tous les exemples sont en C, pas le choix.
Ca devrait aller plus vite proportionnellement pour le reste.

Idem je vais faire un code optimisé à mort. Tout ce qui ne peut être fait en C quoi (sans asm inline bien entendu).

Au début j'ai cru que mon crc n'était pas bon, car je suis tombé sur deux sites donnant un résultat différent du miens. Alors je ne sais pas si ils avaient mal fait leur code, ou si c'était un crc spécial. En tout cas c'était bien écrit "crc-32".
J'ai finalement trouvé plusieurs sites donnant le même résultat que mon code.

[n5Rzn1D9dC]

Finalement c'est bien du deflate pur comme je le pensais:

Abstract
This specification defines a lossless compressed data format that is
compatible with the widely used GZIP utility. The format includes a
cyclic redundancy check value for detecting data corruption. The
format presently uses the DEFLATE method of compression but can be
easily extended to use other compression methods. The format can be
implemented readily in a manner not covered by patents.

http://www.ietf.org/rfc/rfc1952.txt

Apparemment la différence est juste au niveau du header et du checksum.
Bon je ne met pas le topique en résultat parce qu'il ne sera pas résolu même quand j'aurais fini mon code, le faite est que je n'arriverais pas pour autant à le lire avec la zlib mais ça n'aura plus aucune importance.
Vous pouvez le mettre en résolu si vous voulez.

a+

[n5Rzn1D9dC]

Il y a vraiment des trucs bizarres avec les crc y-a pas à dire.
Jusqu'à présent je n'avais testé le résultat que d'une seule chaine.
Quel intérêt d'en tester une autre en même temps..
Normalement, si je tombe sur au moins un site donnant le même résultat que moi, c'est que c'est bon, car ils sont tous censé donner le même résultat..

Les deux premiers sites donnaient un résultat différent de moi, mais également un résultat qui était différent entre-eux..
Ensuite j'ai trouvé deux autres sites donnant le même résultat que moi.
Aujourd'hui je me dit "tiens, je vais quand même tester une autre chaine", bien qu'il n'y a aucune raison pour que ça ne fonctionne pas vu que le code peut prendre n'importe quelle taille en entrée.
Bref, je teste une autre chaine, résultat différent !
Je teste sur le second site, résultat identique !

Quand même c'est étrange..
Voici le site donnant un résultat différent d'une chaine à l'autre:
http://www.zorc.breitbandkatze.de/crc.html

J'ai essayé plusieurs chaines et il n'y a que la première que j'ai essayé qui fonctionne.
"La petite maison dans la prairie"
Celle-ci et aucune autre. Même en effaçant le cache, rechargeant, rien à faire, aucune autre ne passe.
Ce serait interessant de voir si c'est pareil de votre côté, afin de déterminer si c'est uniquement la première chaine de testé qui fonctionne, ou spécialement cette phrase..

Et le site donnant un résultat identique quelque soit la chaine:
http://www.tools4noobs.com/online_php_functions/crc32/

"tools4noobs", ahah, ça fait à peine prétentieux. Je ne suis pas "noob" et pourtant j'ai eu besoin de son site pour être certain que mon code fonctionne parfaitement.
En dehors de ça, il aurait fallu que le télécharge un truc avec crc pour le calculer.

Donc en gros je n'ai trouvé qu'un seul site online donnant des résultats identiques au miens quelque soit la chaine.
En même temps il y a peu de site online pour crc32.

Bref, là je vais passer à la construction du "tree" deflate, en essayant de trouver la méthode la plus performante possible pour de l'asm.

[n5Rzn1D9dC]

Je viens de me rendre compte que le calcul du next_code peut être fait on-the-fly.
Du coup j'ai codé une étape qui ne sert à rien. Celle du calcul bl_count.

2) Trouver la valeur numérique du plus petit code pour chaque longueur de code :
code = 0;
bl_count[0] = 0;
for (bits = 1; bits <= MAX_BITS; bits++) {
code = (code + bl_count[bits-1]) << 1;
next_code[bits] = code;
}

http://abcdrfc.free.fr/rfc-vf/rfc1951.html

Les longueurs données:
"3, 3, 3, 3, 3, 2, 4, 4"

2 = 1 = 0 code, donc exit.

1er "3" = code "2" (car 0+1)
Si dernier "3"
> calcul du next code
> sinon: reg ++
jnz @b

dernier "3" = code "6"

next code = code du 1er "3" (donc "2") + code du dernier "3" dec (donc 6-1 = 5) shl 1
= 14

: /

A moins que j'ai raté quelque chose mais à voir comme ça, j'ai l'impression que ça devrait fonctionner pour la suite également.
Une simple sauvegarde de la première longueur clone avec un contrôle de la dernière longueur clone permet de le calculer.
Et à moins également que les bl_count ne soient nécessaires pour autre chose que le calcul des next_code. Je n'ai pas encore tout lu, je viens seulement de m'y mettre.

C'est passionnant tout ça ^

Et hop, 45 lignes de code en moins.

[n5Rzn1D9dC]

Je pense que je finirais par publier mon code sous forme de contribution pour Linux.
Car après tout, même si c'est de l'asm, ça peut être compilé automatiquement comme avec gcc.

Dépend de "nasm"

Nasm s'installe, compile le programme, puis à la limite, se désinstalle après la compilation.
Je crois même me souvenir avoir déjà fait un "apt-get install" sur un programme qui a procédé de cette façon.

Mais ça ce sera pour plus tard, quand je jugerais que le code est parfait, et qu'il y aura toutes les options pour la compression et la décompression, car tout n'est pas obligatoire par défaut, et là comme je le fais déjà pour moi, je ne vais pas tout mettre tout de suite.

a+

[n5Rzn1D9dC]

Non je disais n'importe quoi dans l'avant dernier post.
J'ai confondu avec la fatigue.

La formule exacte c'est:
next_code = "dernier next_code + prochain bl_count" x2

D'ailleurs je trouve ça plutôt abusé qu'il donne la formule sous forme de code C plutôt que sous forme litterale.
Et encore si il n'y avait que ça qui ne va pas dans cette rfc.

Les résultats pour leur exemples, pour ceux que ça interesserait:

Pour "2":
(0 + 1) shl 1 = 2

Pour "3":
(2 + 5) shl 1 = 0xe

Pour "4":
(0xe + 2) shl 1 = 0x20

Et finalement non, je ne peux pas le faire en même temps que l'attribution de code.
Arf tanpis, ça l'aurait fait.
De toute façon vu les calculs et les classements qu'il y a faire, c'est pas vraiment pratique pour faire un code orienté performance, mais je vais faire au mieux.
Puis bon, j'ai trouvé un code C qui respecte la rfc, au point d'avoir copié-collé les codes données en exemples.
Bah au final, 65ko..
Quand mon code sera terminé, j'en serais très très loin ^

a+

[n5Rzn1D9dC]

Je viens d'écrire un alpha-decompresseur.
15 lignes de code, lol !
Pour le format fixed uniquement.
Alpha car je l'ai fait en dix minutes et je dois rajouter les traitements spéciaux, mais au final ce sera encore plus petit que je le pensais.

Ensuite je passerais au dynamique, qui est apparemment assez complexe.
J'avais d'ailleurs commencé par le format dynamique sans le savoir (bl_count, next_code, etc).
Faut que dire qu'elle est tellement bien ordonnée cette rfc ^

a+

[n5Rzn1D9dC]

Bon j'ai fini le fixed.
J'avais peur qu'il y ait des problèmes lors de la comparaison des longueurs de codes.
Par exemple, j'aurais testé si la valeur 9 bits aurait été dans la plage de valeur attribuée.
Et ça m'aurait dit oui, alors qu'en faite ça n'aurait pas été le cas, mais ça aurait été une valeur 8 bits qui avec le 9ème bits aurait été "par hasard" dans la plage de valeur 9 bits.

Mais apparemment non.
J'ai l'impression que l'auteur de deflate a viré des plages de valeurs pour que ce genre de chose n'arrive pas. Donc c'est plutôt bien pensé, et beaucoup plus facile que je l'aurais pensé.
A moins que ce soit quand même possible et qu'il faille éviter ça autrement, mais ça voudrait dire que j'aurais eu un coup de bol pour tout ce que j'ai testé..
Ca je verrais quand je passerais au dynamique. Tout ce qui est gros est chiffré en dynamique automatiquement, donc je ne peux pas tester de gros binaire pour l'instant.

Mais bon, sinon, j'ai réussi à le faire sans far ptr et sans avoir à préciser de longueur en entrée ! Incredible !! Surnaturel !
http://www.youtube.com/watch?v=rbBX6aEzEz8

[Forthman]

'soir !

J'ai pas tout compris à tout ça, mais je voulais juste te dire que tu ne parlais
pas tout seul

[n5Rzn1D9dC]

Yep t'inquiète. J'ai vu qu'il y avait pas mal de monde qui passait par ici, alors même si personne ne poste, je me suis dit que je pouvais continuer à commenter. Puis si ça peut aider des gens à comprendre ou leur donner envie de se mettre à l'asm.

[Obsidian]

'soir !

J'ai pas tout compris à tout ça, mais je voulais juste te dire que tu ne parlais
pas tout seul

Yep t'inquiète. J'ai vu qu'il y avait pas mal de monde qui passait par ici, alors même si personne ne poste, je me suis dit que je pouvais continuer à commenter. Puis si ça peut aider des gens à comprendre ou leur donner envie de se mettre à l'asm.

J'approuve !

C'est juste qu'effectivement, le fil est un peu long et il faut du temps pour réassimiler le sujet entier avant de poster.

[n5Rzn1D9dC]

Je trouvais qu'il y avait des choses étranges dans les résultats de crc32 des différents sites que j'avais trouvé pour tester le miens.
Et bien avec le dynamique deflate, c'est 10 fois pire. ^

Il y en a un pour lequel j'ai un doute quand même vu que le mec a écrit un bouquin sur la cryptographie.
Mais bon, il parle d'une chaine de bits qui n'existe pas dans le code d'exemple qu'il fournit.
La seule explication que je vois, c'est qu'il aurait recodé son exemple après coup, avec une nouvelle version de gzip sans faire exprès. Mais je trouve ça étrange quand même.

J'attends de voir, histoire d'être sur qu'ils se contredisent tous comme pour le crc32, et je posterais tout ça à la fin si c'est bien le cas afin de donner une explication clair.

[bifur]

je me suis apperçu d'une chose en travaillant sur le calcul du crc16 modbus c'est que le crc16 se calcul toujours de la même façon mais uttilise des valeurs initiales différente suivant l'usage qui doit en être fait

le sujet que j'avait lancé sur le crc16http://www.developpez.net/forums/d99.../calcul-crc16/

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
calcrc32:
;ds:esi=d‚but de la chaine
;ecx=Nb d'octet de la chaine
;eax=valeur initiale du CRC
;edx="polynome";
;sortie: ax=valeur du CRC
 
crc32:
xor al,[esi]
 
shr eax,1
jnc no1
xor eax,edx
no1:
shr eax,1
jnc no2
xor eax,edx
no2:
shr eax,1
jnc no3
xor eax,edx
no3:
shr eax,1
jnc no4
xor eax,edx
no4:
shr eax,1
jnc no5
xor eax,edx
no5:
shr eax,1
jnc no6
xor eax,edx
no6:
shr ax,1
jnc no7
xor eax,edx
no7:
shr eax,1
jnc no8
xor eax,edx
no8:
inc esi
dec ecx
jnz crc32
ret

est ce que permet de calculer un crc 32bit? (avec la valeur du polynome initialisé a 0EDB88320h pour le crc du gzip) cette fonction ne fait que calculer la valeur du crc32 et ne fait rien d'autre
la version 16 bit fonctionnait (d'après ce que j'avait testé) et je me demande si la version 32 bit aussi

[n5Rzn1D9dC]

J'ai répondu à ta réponse par mp la dernière fois, je suppose que tu l'as raté.

Je met une copie ici au cas où ça interessait d'autres personnes:

Pour le crc16, je ne sais pas.
Je sais qu'on peut faire du crc16 à partir d'un crc32, car d'après ce que j'ai lu dans la rfc 1952 (gzip), c'est juste la taille prise en compte en sortie qui change.
Ton code ressemble à la première partie d'un crc32 mais sans stockage de la table.

Ci-dessous le code crc32 de la rfc. Ton code ressemble à partie "make_crc_table", mais sans le stockage des 256 dword créés, qui servent justement pour la partie "update_crc".
Et avant de faire le "shr reg,1", il y a un "and reg,1" à faire.
Si "and reg,1" = 1
alors faire:
shr reg,1
xor reg,polynome

sinon faire:
shr reg,1

Stocker le dword tout les 8 tours, et faire 256 tours.

Ensuite ça passe à la partie "update_crc", où les dword stocké précédemment sont chargé en fonction d'un calcul xor avec un byte de la string.
Pour ça que la table doit être créé avant, car si par exemple edx contient le byte 0xB6, tu ne pourras pas loader le dword de table:
mov ebx,dword [table+edx*4]
sur lequel ensuite il faut appliquer un xor.

M'enfin il y a plein de façon de faire. Perso j'ai choisi celle de la rfc, sans savoir si elle était complète vu que c'est juste exemple, mais finalement leur code est bon.

L'exemple crc32 se trouve à la fin:
http://www.ietf.org/rfc/rfc1952.txt

edit:
Tout ce dont je suis sur, c'est que l'exemple fast-crc de la rfc gzip fonctionne parfaitement.
T'en as pas pour longtemps à le coder.
Par contre méfie toi des sites. Au final ils disaient bien tous n'importe quoi.
Tous les crc32 que je vérifie pour le format gzip sont bien identiques aux résultats que j'obtiens lorsque je vérifie avec mon code (donc celui de la rfc).
Ce qui veut dire que la quasie intégralité des sites "online crc32" ne donnait pas un bon résultat.
Soit c'était pas du crc32, soit ils ont mal codé leur code, je ne sais pas.

[bifur]

j'avais pas zappé ta réponse en mp je le remettait juste ici au cs ou ça interesse qqn d'autre

la fonction que j'ai écrit est une fonction générique qui calcule la valeur crc d'une chaine et ne se préoccupe pas de la partie comparaison (si on veux verfier que la transmission s'est bien passé) ou de la partie stockage (avant de transmettre la trame)

j'aimerais bien avoir le temps de m'y interresser un peu plus pour pouvoir participer plus activement a la discution mais je vais devoir me contenter d'etre simplement dans le public.

bon courage en tout cas!!