带有修改器CRYPT_ARCH_ZIP的CryptDecode - 如何使用？ - 页 8

新评论
 
Mikalas:
我已经试过了--它不起作用 :(

我知道CryptDecode 使用CRC32？- 如果是这样，你可以从存档中获取CRC32哈希值，并将其塞入打包数组的末端。

struct ZIP_HEADER
{
  ...
  ushort last_mod_date;
  uint   crc_32;            // Берем это число и помещаем его в конец массива, который нужно распаковать
  uchar  ll_crc;
  ...
};
Z.I. 现在我读到hash是一个可选的属性，在某些情况下可以用零来填充。
 

不，不是CRC32，是Adler32

(他们纠正了文字，他们纠正了文字，我也纠正了文字--重读)

我写道，它不工作!!!!!

 
Mikalas:

不，不是CRC32，是Adler32

(他们已经纠正了文本，重新阅读)

我写道，它不工作!!!!!

对。

米卡拉斯。

...和我粘贴的ZIP档案的CRC32 - 它没有解压:(

 
Mikalas:

谢谢你。

没有4个字节和CRC32的ZIP档案不能解压:(

瓦西里，我们的想法不会成功。

当然，除非MQ公司的人能够满足我们的要求，在 "我的 "中添加一个标志。

函数CryptDecode(CRYPT_ARCH_ZIP, data, key, result,NO_READ_CRC) 。

或从ZIP文件中提取CRC32。

CryptDecode(CRYPT_ARCH_ZIP, data, key, result,USE_CRC_FROM_ZIP) 。

你不需要添加旗帜。只需改变CryptDecode，使其接受CRC码，如果它存在的话。如果缺少了它，而且代码字段被填上了零，就没有使用CRC代码，就是这样。另外，不是每个档案都能包含哈希值。

有时在写LocalFileHeader 的时候不可能计算出数据，那么就在crc32、compressedSize和uncompressedSize 中写入0，GeneralPurposeBitFlag中的第三位被设置为1，在LocalFileHeader之后加入一个类似数据描述符 的结构。

http://blog2k.ru/archives/3391

 
C-4:

没有必要添加一个标志。只需改变CryptDecode，使其接受CRC码，如果有的话。如果它不存在，并且代码字段被填成了0，那么CRC代码就不会被使用，就是这样。另外，不是每个档案都能包含哈希值。

我不知道MQ是如何实现这个功能的，所以我提出了一些建议

(也许有了旗帜，他们会更容易做到)

 
亲爱的MQ!请给我们一个答案。你能不能让哈希匹配成为可选项？
 

这将是非常好的。

快速访问ZIP档案中的大量文件!

一个小型的数据库，可以快速访问文件--超级棒!

打开ZIP--制作一个对应表，通过偏移量进行 "竞赛"。

 

...他们一定在想。

他们一定很惊讶，当地的工匠会发现CRYPT_ARCH_ZIP 有如此意外的用途。

Mikalas:

这将是非常好的。
快速访问ZIP档案中的大量文件!
小巧的数据库，快速的文件访问--超级棒!
打开ZIP--制作一个匹配表，通过偏移量进行 "竞赛"。

+100 归档是非常有用的。当然，在完全保留MQ的内容控制的情况下。

 
C-4:

...他们一定在想。

他们一定很惊讶，当地的工匠会发现CRYPT_ARCH_ZIP 有如此意外的用途。

+100 归档是非常有用的。当然，要完全保留MQ的内容控制。归档文件内没有exe和可执行文件，应该是。

Vasiliy!

是否有EXE并不重要!

我可以从看似不起眼的文件中 "构建 "一个可执行文件。

通过增加或修改字节来实现。

你不必用ZIP来做这件事!

只要我们能够下载和保存文件，制作一个EXE就是小菜一碟了。

 
Mikalas:

Vasiliy!

是否有EXE并不重要!

我可以从看似不起眼的文件中 "构建 "一个可执行的文件!

你不必为此而使用ZIP!

事实上，是的。有可能对一个可执行文件进行加密，使其与一组随机的字节没有区别。
12345678910
新评论