这是一个创建于 1913 天前的主题，其中的信息可能已经有所发展或是发生改变。
文件头和程序里的字符串看不出什么有效信息。
解密程序每次都是跳过前两个字节，从第三个字节开始读取。头两个字节也许是长度，但目前没有证明的办法。
解密程序的时候总共有三层，
最外层是循环，用于将明文一个字节一个字节地写入另一块内存。不知道是加密还是压缩算法。
第二层是获取明文的最后步骤，明文要不然是拿第三层的密文截取第一个字节得到，要不然是用密文去查表得到。表是另外的地方生成的
第三层是拿第三个字节和第四个字节组合成新的密文，再拿新的密文和第五个字节组合成更新的密文....一直这么下去
 |
1
augustheart 2019-08-10 08:52:44 +08:00
lz77?
虽然不是和你的描述很符合 |
 |
2
shawndev 2019-08-10 09:25:38 +08:00
看样子像是数字信封和数字签名，第三层说的应该是 aes 的 cbc 模式？
|
 |
3
AX5N OP @augustheart 我觉得很有可能，我这里有一份编译后 vs 生成的 map 文件，在里面逛了一圈，发现有 lzfdecompress，但我找了个 lzf 的库尝试解压，但没解压出来，不知道是不是缺失了文件头，补了 3 个字节的文件头上去好像也没成功。不知道哪里错了。
|
|
4
augustheart 2019-08-10 19:07:18 +08:00
如果是 lz 系列的算法，前两个字节可能是标记，也可能是文件大小。
lz 系列算法在开始一定有文件大小，要么在前两个字节处，要么紧接着标记后面。 lz 系列这种基本上需要逆向看一下处理流程，这个变种很多。微软那个 lz 解压缩并不通用。 按名字看似乎是 lzf 算法。这个我不熟。网上应该是能找到文章的 |
Select Language