0

I have inherited a zlib compressed file and long story short, I need to UN-zlib-compress this puppy back to its original content.

I have been racking my brain trying to figure out what in the world is happening, but I am hitting a wall and I am hoping you good people will help me out to figure out what's going on.

I have done alot of things so far, I won't bore you with every single thing, but this is what I landed on last, and all I get garbled output, don't know what in the heck is wrong, especially that the last step of decode complains about the data saying:

Warning: gzuncompress(): data error in C:\xampp\htdocs\test-box\index.php on line 6

Warning: zlib_decode(): data error in C:\xampp\htdocs\test-box\index.php on line 8

and this is the code - nothing fancy, I am trying to get it to work before going too crazy with it yet and so the simplicity should allow us to better analyze it.

<?php
    $filename = 'c5ytvbg4y.x';             // this is the zlib compressed file
    $file = filesize($filename);           // using this for the length
    $zd = gzopen($filename, "r");          // create valid pointer
    $contents = gzread($zd, $file);        // binary safe read the content
    $decoded = gzuncompress($contents);    // using gzdecode produces the same issue
    gzclose($zd);                          // close the pointer
    zlib_decode($decoded);                 // decode it but I get nothing but garble
?>

Any assistance would be appreciated. Ideally I want to be able to open it uncompress it back to normal and save it to a new file. But at the moment I would be happy just to find out why in the heck I get nothing but garbled text back. Also keep in mind that I know the $file above is not ideal, I will put a while !feof($zd) or something to that effect later, I wanted to keep it simple for now while trying get the larger issue figured out.

Any thoughts, recommendations, suggestions, code assistance, or whatnot would be greatly appreciated, TIA.

Additions

@Mark's Request:

0A 12 0F 04 04 D8 44 DA BF 63 C4 93 93 3B 49 51 17 A2 6F E3 0C 12 4D E4 24 F6 C8 BA D0 60 76 81
GµårÐïåñ
  • 2,846
  • 5
  • 31
  • 35
  • Why are you trying to use `gz*()` instead of just using zlib? – Ignacio Vazquez-Abrams Apr 27 '16 at 03:22
  • Please provide the first 30 bytes in hex. – Mark Adler Apr 27 '16 at 06:31
  • certainly, added it to the question, thank you. BTW just in case it matters, I have provided 32 :) – GµårÐïåñ Apr 27 '16 at 20:41
  • @IgnacioVazquez-Abrams, I have tried it both ways, doesn't matter, says the same error. The only reason I switched to gz was because of a few things I read about it, among other places here on SO but as I said, I have tried many things, including straight away with zlib_* functions. If you can help me with a functional code that uses zlib_* only, by all means please and thank you. – GµårÐïåñ Apr 27 '16 at 20:48

2 Answers2

1

It is definitely not a "zlib compressed file", at least not the first 32 bytes, nor is it any format that uses the deflate compression method (e.g. gzip, zip, png, etc.), because there is no valid deflate compressed data in the provided bytes.

Mark Adler
  • 101,978
  • 13
  • 118
  • 158
  • Interesting, I appreciate that heads up. Couple of questions, could the way the data is "handled" before being compressed, or the level of compression have any affect on what we are seeing? The reason I ask is that the developer of the software being used to create these files has assured me that it uses the zlib library from zlib.net and the only thing it leaves up to the users is the minify/not and level of compression, otherwise nothing special beyond that. In fact he is the one who told me it can be simply reversed using zlib implementations. I guess I want to know more before I go back. – GµårÐïåñ Apr 28 '16 at 19:30
  • I don't know what you mean by "handled", but in any case that data is not the start of a zlib stream, nor the start of _any_ sort of wrapped deflate compressed data, regardless of the compression level or any other zlib options. – Mark Adler Apr 28 '16 at 19:34
  • +1 Thank you for that clarification, I appreciate it. I will reach out to the developer and see if I can solicit some more assistance there. I think what I am trying to achieve in the long run will be worth the journey of discovery to find out if we can make it happen. – GµårÐïåñ Apr 28 '16 at 19:58
0

The zlib header typically starts with hexadecimal 78. Your data starts with 0A, which isn't valid as part of a zlib header. (Technically it is sort of valid, but it implies a compression format that isn't supported by any version of zlib.)

The gzip header starts with hexadecimal 1F 8B. That isn't present in your data either.

So, I'm not sure what this data is, but it's neither gzip nor zlib data. You'll need to do some more research to figure out what it is.

Community
  • 1
  • 1
  • Thank you, I appreciate that information and as soon as I hear back from Mark, or if you can answer the same questions in the comment, I would be grateful as well, never can have too many perspective knowledge to understand things, then at least I have a direction to go into to resolve it beyond just giving up. Again thank you all for taking the time. – GµårÐïåñ Apr 28 '16 at 19:33