数据是一个大文件的一部分,从中我知道布局,所以我设法找出了一些东西。我所知道的:我没有二进制可执行文件来加载数据,我只有更新版本,不再支持旧的压缩算法。我以多种方式折磨了它,只是它不包含相应的代码
它被压缩了(可以确保100%确定)
它可以被自制,因为以后会被替换(见下文)
/>到目前为止,还没有魔术数字
这不是很简单:
压缩(错误的标题)
lzma(错误的标题)
gzip(错误的标题)
Quantum(错误的标头)
Microsoft CAB(错误的标头)
Bzip2(错误的标头)
Zip(错误的标头)
未压缩的大小是在包含数据的文件中给定,此文件布局被完全颠倒并且不包含任何线索
它可能已加密,但由于速度要求而不太可能
如果已加密,则给出的输出相同在序列开始时输入相同的数据(通过猜测附近的一些未压缩数据)
它是2001年的数据,并已由deflate取代,因为这些数据中的某些仅输出ASCII且无任何输出lse(我从容器文件的布局中知道它),每次的压缩率约为0.30(compressedSize / uncompressedSize)
可悲的是,我之前/之后没有任何数据
编辑:十六进制中有32个第一个字节:
b9daed36cb64bedb61b9dd2cb72afd8ee565b0dd2ea00f0afda2c36eb25b0016
我制作了其中一些数据的直方图,它们都与特定模式匹配。 2的幂显然正在发生某些事情,但是我看不到是什么。任何人都知道这可能是什么吗?我该怎么做以收集更多信息?它看起来基于Lempel-Ziv吗?如果是,我该如何扭转?
#1 楼
首先,您忘记了lzo。 AFAIR最早是在1996年发明的。直方图看起来并不像压缩的数据直方图那样,它可能具有某种内部结构(可能是大小之前的斑点?)。
我建议编写脚本对部分数据运行不同的解压缩算法并观察结果。
评论
如果您没有可执行文件,您是如何获得此文件的?另外,显示头的16-32字节的转储。更新以回答+标头的十六进制转储
您可能会发现有趣的问题和答案:>是否有任何工具或脚本可用于识别可执行文件中的压缩算法?
“输出是ASCII,什么都没有” –加上比率“约0.30”实际上表明了一种简单的压缩方案,而不是复杂的:专用的纯文本压缩方案。我们可以看到这个文件吗?
您是否尝试过与制造该软件的公司联系?