@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 仍然是大头

@bagel #14 眼睛不好去读题

@bagel #10 楼主的做法是 : 从 0 开始逐个测试密码 密码不对就接着试的那种, 不管你使用的是那种加密算法, 都当做黑盒破解

@augustheart #7 那么假设读取到内存之后测试密码耗时为 0, 那么程序的主要耗时是第一个读取文件到内存 + 生成 N 位字符串的排列.

假如我们需要破解一个 1GB 的压缩文件, 那么你需要的 IO 时间肯定是 ms 级别的, 但是循环的时间可能都不到 ms

我觉得你的思路跑偏了.

暴力破解属于 IO 密集型任务, 读取文件是主要耗时, 你所谓的算力在暴力破解中只是一个 for 循环的事情用来生成下一个密码.

我们可以假设一个极端的情况, 你提前生成好了 6 位密码的所有可能排列, 那么是不是说你就知道密码是什么了? 当然不是, 你必须把文件打开, 然后测试你生成的密码. 所以暴力破解文件密码不存在任何算力瓶颈.

一个 for 循环搞定, 有什么问题吗? 不知道用什么 library 吗?

每个进程都维护一个 PCB, PCB 中有一个字段 root, 当你访问 /opt 的时候, / 就是这个 root.

所以这个只能做到文件系统的一个隔离. 你如果要限制 CPU, 限制内存, 还有网络端口号的命名空间, 那么你使用 chroot 是没办法实现的.

@index90 #9 感谢回复, 我比较好奇你们的 service 层和 dao 层是做单元测试的.

@royzxq #5 嗯

没见过用户访问只靠数据库撑起来的, 你反向代理撑不起来怎么办, 你应用撑不起来怎么办

@lidongyx #1 不管你用什么方式调用, 微信的接口返回时间都是 900ms