CODEWITHSUNDEEP
compressionzlibdeflate
Phi
Phi

Reputation: 497

Cannot inflate content from older zlib library

Heyo,

I have two versions of a networking library - one original where source code was lost - and mine, which is a newer implementation. In my newer one, I was using zlib 1.2.5, then updated to 1.2.11.

This upgrade broke the compression entirely. The newer library can no longer understand output of older one, and vice versa. Since there will be readers with both my version and the old version of the networking library, that's not suitable.

I have confirmed that the (compressed) message bytes are as expected; correct size and data, bytes unchanged from what was sent. I've compared them in a hex editor just to be sure. My only conclusion is that there has been something changed about the library.

A test input is: "This is a test binary message." (ASCII, with null byte terminator)

Result from old library (possibly zlib 1.1.3):

00000000: 1f00 0000 789c 0bc9 c82c 5600 a244 8592  ....x....,V..D..
00000010: d4e2 1285 a4cc bcc4 a24a 85dc d4e2 e2c4  .........J......
00000020: f454 3d06 00af cc0a ce                   .T=......

Result from new library (zlib 1.2.11):

00000000: 78da 0bc9 c82c 5600 a244 8592 d4e2 1285  x....,V..D......
00000010: a4cc bcc4 a24a 85dc d4e2 e2c4 f454 3d06  .....J.......T=.
00000020: 00af cc0a ce                             .....

Decompression produces either "invalid block type", or "incorrect header check".

To produce the same compressed result, I've tried following this post which recommends messing with MAX_WBITS, but MAX_WBITS, -MAX_WBITS, and MAX_WBITS + 16 still result in Z_DATA_ERROR and wrong output sizes (37, 31, and 49 bytes respectively).

I'm not sure if it's deflate or zlib, I checked this post but none of them seem to fully match (closest is .z). The documentation says "zlib", but since it's a single block of binary send as a message, I think it's more likely to use raw deflate.

Any advise on what could cause this would be appreciated. Oh, and here's my code.

Upvotes: 0

Views: 360

Answers (1)

Phi
Phi

Reputation: 497

Turns out the older zlib - or possibly the older networking library - had a 32-bit "uncompressed output" size prepended to its compressed output. Replicating that behaviour in newer version returned things back to working and backwards-compatible.

Upvotes: 1

Related Questions