lihongjie0209

@augustheart #42 具体要看楼主的取舍了, 如果黑盒测试, 那么瓶颈在 IO. 如果白盒测试(针对具体每个压缩文件类型以及加密算法), 那么瓶颈在研发难度以及时间.

@augustheart #42 是的, 如果黑盒测试这种浪费和低效是无法避免的.

@augustheart 看一下 40 楼, 忘记 @你了

@bagel #23 按照黑盒测试, 使用 zip4j 作为 zip 文件的类库, 每次尝试解压都会读取一个 1024 * 4 的 buff, 读取之后进行 AES 校验, 失败抛出密码错误异常. 那么假设你的字典有 10000 项, 那么你需要进行 10000 次 read, 也就是 10000 次 IO(排除 JVM 对 IO 的优化).

参考: net.lingala.zip4j.tasks.AbstractExtractFileTask#unzipFile

@augustheart #29

我之前认为楼主用的是类似 zip4j 之类的库, 然后尝试解压, 抛出异常进行下一次尝试.

目前看来提取关键信息然后尝试那么就需要楼主手动进行这些二进制数据的解析.

我同时查了一下 John the Ripper, 也是用来暴力破解的, 按照 https://stackoverflow.com/questions/15442565/how-do-you-get-the-password-hash-of-a-zip-file 上面的说法, 它会提取类似你说的关键信息


```
Output Line Format:
*
* For type = 0 for files encrypted with "rar -hp ..." option
* archive_name:$RAR3$\*type\*hex(salt)\*hex(partial-file-contents):type::
::archive_name
*
* For type = 1 for files encrypted with "rar -p ..." option
* archive_name:$RAR3$\*type\*hex(salt)\*hex(crc)\*PACK_SIZE\*UNP_SIZE\*0\*
archive_name\*offset-for-ciphertext\*method:type::file_name
*
* or
*
* archive_name:$RAR3$\*type\*hex(salt)\*hex(crc)\*PACK_SIZE\*UNP_SIZE\*1\*
hex(full encrypted file)\*method:type::file_name

```

前两种格式的关键信息和你说的类似, 但是它会有一种变体, 也就是最后一个, 需要读取整个文件 `hex(full encrypted file)`.


最后还是很感谢这种有意义的讨论, 学到了不少东西

@augustheart #30 好的, 我去研究一下

@lsastaaa #26 参考 #11

@bibitiger #20 嗯, 高级一点可以这么玩. 不过从楼主的问题来看应该是想黑盒暴力破解.

@crystom #15 可能, 要看具体的压缩文件类型和库实现方式, 不过 IO 仍然是大头