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

• 資深大佬 : find

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

• 資深大佬 : hsddszjs

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

• 資深大佬 : augustheart

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

• 資深大佬 : lihongjie0209

  我觉得你的思路跑偏了.

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

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

• 資深大佬 : franklinray

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

• 資深大佬 : sunziren

  @lihongjie0209 你给了主致命一击

• 資深大佬 : augustheart

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

• 資深大佬 : augustheart

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

• 資深大佬 : guyeu

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

• 資深大佬 : bagel

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

• 資深大佬 : lihongjie0209

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

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

• 資深大佬 : bagel

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

• 資深大佬 : lihongjie0209

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

• 資深大佬 : bagel

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

• 資深大佬 : crystom

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

• 資深大佬 : lihongjie0209

  @bagel #14 眼睛不好去读题

• 資深大佬 : lihongjie0209

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

• 資深大佬 : iFlicker

  jni 调 cuda api

• 資深大佬 : bibitiger

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

• 資深大佬 : msg7086

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

• 資深大佬 : bibitiger

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

• 資深大佬 : alphatoad

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

• 資深大佬 : lihongjie0209

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

• 資深大佬 : bagel

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

• 資深大佬 : yutou527

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

• 資深大佬 : LostPrayers

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

• 資深大佬 : lsastaaa

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

• 資深大佬 : LostPrayers

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

• 資深大佬 : lihongjie0209

  @lsastaaa #26 参考 #11

• 資深大佬 : augustheart

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

• 資深大佬 : augustheart

  @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 之后，在内存中反复用不同的密码重试是没有任何难度的。

• 資深大佬 : augustheart

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

• 資深大佬 : LostPrayers

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

• 資深大佬 : lihongjie0209

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

• 資深大佬 : warcraft1236

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

• 資深大佬 : augustheart

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

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

• 資深大佬 : lihongjie0209

  @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

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

• 資深大佬 : augustheart

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

• 資深大佬 : lihongjie0209

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

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

• 資深大佬 : lihongjie0209

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

• 資深大佬 : augustheart

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

• 資深大佬 : lihongjie0209

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

• 資深大佬 : lihongjie0209

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

• 資深大佬 : ihciah

  致命一击笑死

• 資深大佬 : augustheart

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

• 資深大佬 : golden0125

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

• 資深大佬 : realpg

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

• 資深大佬 : liukangxu

  大型翻车现场

• 資深大佬 : wuwukai007

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

• 資深大佬 : mikicomo

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

• 資深大佬 : ztxcccc

  @ihciah 刀 刀 烈 火

• 資深大佬 : hhhsuan

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

• 主 資深大佬 : zzzmh

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

• 主 資深大佬 : zzzmh

  因为之前写过正常的压缩 zip、gzip、7z，所以打算先从这个入手，写个小工具，最终希望能 1 小时内至少跑完 8 位数字字母，这样才有可用性。如果有可能成的话，之后再扩展到 word 破解之类的上面，其实也没什么真的需要我破的文件，只是写着玩玩，顺便学学之前没写过的知识盲区

• 資深大佬 : lostpg

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

• 資深大佬 : dicc

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

• 資深大佬 : seraphv3

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

• 資深大佬 : seraphv3

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

• 資深大佬 : JerryCha

  主离挖矿原理又进了一步

• 資深大佬 : MadaraII

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

• 資深大佬 : appleUtils

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

• 主 資深大佬 : zzzmh

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

• 資深大佬 : monkeyWie

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

• 資深大佬 : springGun

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

• 資深大佬 : Umenezumi

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

• 資深大佬 : augustheart

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

• 資深大佬 : nightwitch

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

• 資深大佬 : augustheart

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

• 資深大佬 : aguesuka

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

• 資深大佬 : Narcissu5

  https://blogs.oracle.com/javamagazine/programming-the-gpu-in-java

• 資深大佬 : 4ier

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