问个问题， Java 有没有办法接入 gpu 运算，想写个暴力破解压缩包

肯定可以啊，jni 你不知道？ python 也是去 call c

hashcat
https://hashcat.net/wiki/doku.php?id=hashcat

当然可以，想怎么搞就怎么搞。不过老实说暴力破解一点玩头都没有，毫无技术含量。

我觉得你的思路跑偏了.

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

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

@lihongjie0209 楼主是想通过 GPU 来达到将整个 for 循环并行的目的吧。不过在尝试密码的时候不知道是不是需要读取文件，或者能不能通过其他方式进行密码的尝试

@lihongjie0209 你给了楼主致命一击

@lihongjie0209 并不需要每次都做文件操作的，至少 zip 是能够在内存中处理的。假如某个压缩包真的必须每次做文件操作，肯定是采取极端做法整个读入内存。
走 io 操作这种超级低效的方法正常写破解代码的都不会这么干

@lihongjie0209 而且和你说的相反，暴力破解依赖的就是算力。

纯 java 做不到。。只能 jni，GPU 相关的逻辑用 C 实现。

@sunziren 还致命一击。。楼上又暴露一堆不懂装懂的。暴力破解 AES 是典型的 CPU 密集任务，我只需要读取头一个 block （ AES 采用 16 字节 block ），就可以进行破解计算了，哪来的 IO ？

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

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

为什么提 AES，因为 Zip 标准加密有两种方式，一种是 AES，一种是更弱鸡已不建议使用的 Zip 自己的加密算法。

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

@lihongjie0209 #11 还在杠，多读点书，不懂装懂很好玩吗。

@lihongjie0209 很明显测试密码的耗时远大于生成排列

@bagel #14 眼睛不好去读题

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

jni 调 cuda api

如果只会 java 就放弃吧，jni 需要 c 或者 c++

@bagel 你看看他的发帖历史就知道了，不懂装懂多久了都，吓得我赶紧 Block 了。

@lihongjie0209 对于 IO 来说，空间换时间，多线程多进程。解密来说，首先肯定要知道加密方式，接着根据加密方式提取密文开始破解就好了，不需要全部重复 IO

@bagel 真是辛苦你了，我也搞不懂他在 io 些啥

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

这个问题实际都不需要懂技术细节，有点常识的人就知道。你解压一个带密码的很大的文件，输入错误密码，程序立刻会告诉你密码错误。就和删除一个大文件（普通删除），是立刻完成，不会 IO 很久。设计计算机的人没有有些人那么蠢。

他的假设算力无限大的情况 IO 确实是大头，但是这可能吗？

@lihongjie0209 兄弟你是测试吧，典型的测试思维。
在有程序的情况下哪里需要这样搞啊，更别提还是 zip、7z 这类大众熟知的软件。直接 ida 出解密算法的执行 call，写成 hook 让 java 程序用 jni 调用就行了，这里其实用 java 还是 js 还是 py 做前端都没啥区别，关键是上一步的反编译需要 C 或者 C++。或者你不会反编译,直接用 java 实现关键解密算法也行(针对 zip\7z 这类开源的)
然后到了 GPU 运算这里，我不太熟不知道有没有什么现成框架，照理是有的那你用什么前端做开发都差别不大

@lihongjie0209 不是就算如你所说，你也不用每次循环都去读文件啊。 在循环外把文件读出来，在循环内只做密码验证。

@lihongjie0209
而你说的那种瓶颈在 IO 上的, 一般是 WEB 或者远程服务的后台爆破吧, 代码不在本地上跑, 确实只能消耗大量的网络 IO.
但如果你知道加解密算法的时候,情况又不一样了, 又变回纯算力爆破了.
下次遇到不理解的领域还是先不要头铁的好

@lsastaaa #26 参考 #11

@lihongjie0209 不需要，你读一下 libzip 的代码。
目前我知道的压缩格式中没有任何一个是需要读取所有的 binary 才能知道密码是否正确的，这不是正常的产品设计思路。

@lihongjie0209
struct trad_pkware *ctx;
...
if ((ctx = (struct trad_pkware *)malloc(sizeof(*ctx))) == NULL) {
zip_error_set(&za->error, ZIP_ER_MEMORY, 0);
return NULL;
}
...
ctx->key[0] = KEY0;
ctx->key[1] = KEY1;
ctx->key[2] = KEY2;
decrypt(ctx, NULL, (const zip_uint8_t *)password, strlen(password), 1);
if ((s2 = zip_source_layered(za, src, pkware_decrypt, ctx)) == NULL) {
pkware_free(ctx);
return NULL;
}

from zip_source_pkware.c
解密码的关键就在这个 ctx 结构体，预填充 ctx 之后，在内存中反复用不同的密码重试是没有任何难度的。

@LostPrayers 通过服务器破解也不用反复通过网络解密。通过网络一次性传输需要的关键数据后，所有的后续操作都可以在服务端完成。
因为这只是检查密码，而不是整个解压

@augustheart 额,我的意思不是通过服务器破解，而是爆破远程服务的密码

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

@LostPrayers 求不黑测试，测试也不是不知道代码逻辑的，解压密码判断正确，还需要反复读取文件，这个逻辑听起来就有问题，正常人怎么可能这么搞

@LostPrayers 好吧，领会错了。因为这个帖就是说压缩文件，我直接想到当初毛子弄的远程破解密码服务了

到底是网络跑字典，还是本地通过 gpu 加速跑字典？

@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)`.


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

@lihongjie0209 读取整个文件只可能用在解压缩的时候，这个时候当然是需要读取所有数据了然后逐块输出。
只是解密的话就相当于在压缩软件上点下测试键。

@augustheart 测试键的比拟不恰当，实际上测试键只是省去了输出，它还是要判断二进制数据是否完整。

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

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

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

@lihongjie0209 这是一个专门用来解压缩的类库的具体实现，它并不需要考虑解密的速度，它的设计就只是为了输出解压后的数据，不管你的实际目的是什么，它都会把整个解压缩流程跑一遍。这就好比我坐公交需要刷上下车两次卡，但是我上车没刷卡，下车刷了一次卡，我只需要跑前面再刷一次卡补上就行，并不需要再坐个全程来补全刷卡。
你不要把你的思想局限在具体的类库的调用方式上，你这就好比写个批处理调用 zip 来判断压缩包密码，是非常低效且无脑的。
往大了说，编程就是算法+数据结构。io 并不是必须的。

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

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

致命一击笑死

@lihongjie0209 从楼主的需求出发的话是不存在取舍这东西的

真的佩服有些人,脸皮是厚如城墙,卖弄一知半解的知识恨不得用上所有自己知道的名词,被人现场打脸居然还能大言不惭怼回去,牛逼牛逼

暴力破解 RAR 加密现在有条件 忘了是必须加密文件名还是文件名必须不加密了
而且确实是计算密集型应用而不是 IO 密集型应用

大型翻车现场

生成 8 位的非纯数字密码估计都要好久吧，

下次发表评论前，还是要先提高自己的姿势水平，不然挺容易翻车的

@ihciah 刀 刀 烈 火

可以尝试一下 jcuda： http://www.jcuda.org/

厉害了 ， 早上摸摸鱼发个帖没想到这么多人回复， 感谢各位大佬指点 ，我其实就是过年期间没事干想写的好玩的东西 ，其实目前还没开工， 就先做做准备的功课。

暴力破解 io 密集。。。你说是，那就是，不反驳。

Passware Kit Forensic 2017 v1 (64-bit)
下载个破解的就可以了

以前玩过破解 wifi，用的 CDLinux，GPU 的确比 CPU 要快得多

@seraphv3 用 CDLinux 抓包，EWSA 在 windows 上跑包。这种方式一次都没有解出来过。后来有一次我把抓的包给专门跑包的人跑，跑了 2 个包，有一个跑出来了。不过如果是开了 WPS 的 wifi，尝试 PIN 码，一晚上就一定能跑出来

楼主离挖矿原理又进了一步

暴力破解密码还是用汇编的好,找个知道密码的压缩包,直接跟踪解压程序到第一个写磁盘操作,随便把这个指令改下,改成把本次尝试的密码写到磁盘就完事了,剩下的事就是找个 U 多的电脑,开个内存盘把压缩文件拷进去,随便编个程序开上几百线程就刷改完的那个解压程序.这么搞什么算法都不用,全靠解压软件自己跑就完事了.你要是能把调用解压软件给嵌入到 GPU 去算,那就得研究解压算法,那样也行

io 确实不是瓶颈，算力才是，io 只需读取一小部分，然后不停的通过密码试错，这个解秘过程就是计算过程，算力越大，解密越快

@seraphv3 我们玩的应该是同款， 之前我这里用 gpu 跑纯数字 11 位 不到 30 分钟，cpu 就没跑完过太慢了

笑死，这种暴力破解竟然是 io 密集型，难道你打开一个 10g 的加密压缩文件在输错密码之后要等 10g 数据验证完才提示密码错误吗

区块链有没有这方面相关的应用落地?可以尝试使用某些区块链现成的算力,当然我瞎猜的

就一次 IO，何来 IO 密集型？

@MadaraII 你打了这么多字是认真的？

@lihongjie0209
读取一次进内存，然后直接 for 循环尝试密码，直到找到正确密码退出。
整个过程只会 io 一次

@springGun 分布式计算平台啊，只是不发币而已

杠精翻车现场，看得我尴尬，赶紧拉黑

最近正在研究这个方向，感谢楼中各位分享，感谢楼主的好问题
另外，开放讨论，畅所欲言，楼中个别看热闹的戾气好重