从十六进制解压缩 zlib 网络数据包

发布于 2024-09-10 20:55:53 字数 1053 浏览 12 评论 0 原文

我正在逆向某种协议,看起来它正在使用 zlib 压缩,当前数据包是:

170300002009254CBCE1DC7A5578D1588577EF63AE8DDCA721FFCA453775BCA7375CB65EE31703000090AA883A355CB9A7450EA7BA8D485C655EB5FCB71E22F274E9FF03F326296E7F2D5960AB7CFB2986C4985D6B7D33BE2C7348142D738B522C3B89AA3723A5CADB9C3DF124B3AB405E0513766384D3C0C6C11395D51E317F1DF342F3731D498C84EE0BE9172C130A89C7EE287560E64337E4A0D49A211E40F846DBAF019ADEF2F2F601A145C1F587C792CF3C2EE1CEE558031703000020259BAFBADABE5B22360C727D6E2494C41542FC3E14EEE3B5317C13F06044BB77170300005012E5BF7E631E9E3C5F0D133890808281A769C3AEC50ACF8BB0FBF39CAEC0E2EA75C09BAD7A3F22A15DC2B5C3751561DB3219164AB80E55A7DB141F5F6FAB4DE9189CC145C47E49D741075DDAA6EFD2A6

如果我们看一下 rfc1950,我们会看到格式的规范,在我的脚本(php)中,我提取 zlib 相关信息上面的数据包:

compression method : 1
compression info   : 7
------------------------------
flag check          : 0
flag dict           : 0
flag level          : 3

但是我找不到解压缩十六进制数据的方法,即使我使用 pack('H*',$data) 将其转换为二进制字符串,它仍然会给出有关错误的错误数据。

是否可以使用命令行程序并向其提供上述十六进制数据,其中命令行实用程序以十六进制形式返回未压缩的字符串。

I am reversing some kind of protocol and it looks like it is using zlib compression, the current packet is :

170300002009254CBCE1DC7A5578D1588577EF63AE8DDCA721FFCA453775BCA7375CB65EE31703000090AA883A355CB9A7450EA7BA8D485C655EB5FCB71E22F274E9FF03F326296E7F2D5960AB7CFB2986C4985D6B7D33BE2C7348142D738B522C3B89AA3723A5CADB9C3DF124B3AB405E0513766384D3C0C6C11395D51E317F1DF342F3731D498C84EE0BE9172C130A89C7EE287560E64337E4A0D49A211E40F846DBAF019ADEF2F2F601A145C1F587C792CF3C2EE1CEE558031703000020259BAFBADABE5B22360C727D6E2494C41542FC3E14EEE3B5317C13F06044BB77170300005012E5BF7E631E9E3C5F0D133890808281A769C3AEC50ACF8BB0FBF39CAEC0E2EA75C09BAD7A3F22A15DC2B5C3751561DB3219164AB80E55A7DB141F5F6FAB4DE9189CC145C47E49D741075DDAA6EFD2A6

If we take a look at rfc1950 we see the specifications of the format, in my script (php) i extract the zlib related info for the above packet :

compression method : 1
compression info   : 7
------------------------------
flag check          : 0
flag dict           : 0
flag level          : 3

However I cannot find a way to uncompress the hex data, even if I convert it to a binary string with pack('H*',$data) it still gives an error about wrong data.

Is it possible to use a commandline program and feed it with the above hex data where the commandline utility returns the uncompressed string in HEX.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

格子衫的從容 2024-09-17 20:55:53

这是一个用于解压缩 zlib 流的 python 脚本:

https://web.archive.org/web/20130305133247/http://blog.2of1.org/2011/03/03/decompressing-zlib-images/

..但是您的数据未经过 zlib 压缩。

粗略地看一下,您的数据被 4 字节标记“17 03 00 00”清楚地划分,后面跟着一个指示该段大小的长度字节。

17 03 00 00 20 09 25 4C BC E1 DC 7A 55 78 D1 58
85 77 EF 63 AE 8D DC A7 21 FF CA 45 37 75 BC A7
37 5C B6 5E E3 

               17 03 00 00 90 AA 88 3A 35 5C B9
A7 45 0E A7 BA 8D 48 5C 65 5E B5 FC B7 1E 22 F2
74 E9 FF 03 F3 26 29 6E 7F 2D 59 60 AB 7C FB 29
86 C4 98 5D 6B 7D 33 BE 2C 73 48 14 2D 73 8B 52
2C 3B 89 AA 37 23 A5 CA DB 9C 3D F1 24 B3 AB 40
5E 05 13 76 63 84 D3 C0 C6 C1 13 95 D5 1E 31 7F
1D F3 42 F3 73 1D 49 8C 84 EE 0B E9 17 2C 13 0A
89 C7 EE 28 75 60 E6 43 37 E4 A0 D4 9A 21 1E 40
F8 46 DB AF 01 9A DE F2 F2 F6 01 A1 45 C1 F5 87
C7 92 CF 3C 2E E1 CE E5 58 03 

                              17 03 00 00 20 25
9B AF BA DA BE 5B 22 36 0C 72 7D 6E 24 94 C4 15
42 FC 3E 14 EE E3 B5 31 7C 13 F0 60 44 BB 77 

                                             17
03 00 00 50 12 E5 BF 7E 63 1E 9E 3C 5F 0D 13 38
90 80 82 81 A7 69 C3 AE C5 0A CF 8B B0 FB F3 9C
AE C0 E2 EA 75 C0 9B AD 7A 3F 22 A1 5D C2 B5 C3
75 15 61 DB 32 19 16 4A B8 0E 55 A7 DB 14 1F 5F
6F AB 4D E9 18 9C C1 45 C4 7E 49 D7 41 07 5D DA
A6 EF D2 A6

所以这里的长度是:

0x20 in first case
0x90 in second segment
0x20 in 3rd segment
0x50 in 4th segment.

这与标记位置正确对应。

我可以花一些时间来扭转这个局面,但我认为这应该足以让你回到正确的道路。

希望这有帮助。

Here's a python script for decompressing zlib streams:

https://web.archive.org/web/20130305133247/http://blog.2of1.org/2011/03/03/decompressing-zlib-images/

.. but your data is not zlib compressed.

Cursory look shows that your data is cleanly divided by a 4 byte marker "17 03 00 00" followed by a length byte indicating size of that segment.

17 03 00 00 20 09 25 4C BC E1 DC 7A 55 78 D1 58
85 77 EF 63 AE 8D DC A7 21 FF CA 45 37 75 BC A7
37 5C B6 5E E3 

               17 03 00 00 90 AA 88 3A 35 5C B9
A7 45 0E A7 BA 8D 48 5C 65 5E B5 FC B7 1E 22 F2
74 E9 FF 03 F3 26 29 6E 7F 2D 59 60 AB 7C FB 29
86 C4 98 5D 6B 7D 33 BE 2C 73 48 14 2D 73 8B 52
2C 3B 89 AA 37 23 A5 CA DB 9C 3D F1 24 B3 AB 40
5E 05 13 76 63 84 D3 C0 C6 C1 13 95 D5 1E 31 7F
1D F3 42 F3 73 1D 49 8C 84 EE 0B E9 17 2C 13 0A
89 C7 EE 28 75 60 E6 43 37 E4 A0 D4 9A 21 1E 40
F8 46 DB AF 01 9A DE F2 F2 F6 01 A1 45 C1 F5 87
C7 92 CF 3C 2E E1 CE E5 58 03 

                              17 03 00 00 20 25
9B AF BA DA BE 5B 22 36 0C 72 7D 6E 24 94 C4 15
42 FC 3E 14 EE E3 B5 31 7C 13 F0 60 44 BB 77 

                                             17
03 00 00 50 12 E5 BF 7E 63 1E 9E 3C 5F 0D 13 38
90 80 82 81 A7 69 C3 AE C5 0A CF 8B B0 FB F3 9C
AE C0 E2 EA 75 C0 9B AD 7A 3F 22 A1 5D C2 B5 C3
75 15 61 DB 32 19 16 4A B8 0E 55 A7 DB 14 1F 5F
6F AB 4D E9 18 9C C1 45 C4 7E 49 D7 41 07 5D DA
A6 EF D2 A6

So lengths here are:

0x20 in first case
0x90 in second segment
0x20 in 3rd segment
0x50 in 4th segment.

And this corresponds correctly with marker positions.

I could spend a while to reverse this, but I think this should be enough to bring you back to correct path.

Hope this helps.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文