这是一个创建于 1769 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题，就是写了自己玩玩的那种不开源不发布不盈利的 大概思路就是用 java 读 rar、zip、7z 等 从 0 开始逐个测试密码 密码不对就接着试的那种 如果只是开多线程用 cpu 算的话，感觉效率太低
早些年我接触过一个毛子大神写的 wifi 密码握手包的破解器 是用 gpu 运算的，算力贼强
迫于自身实力有限，就只会 java 一门后端语言 想问问有没有 java 调用 gpu 来运算的可能性？ 如果需要再学 python 的话就算了。。。
 |
1
find 2020-01-19 09:48:28 +08:00 via iPhone  1
肯定可以啊，jni 你不知道？ python 也是去 call c
|
 |
2
hsddszjs 2020-01-19 09:52:35 +08:00 1
|
 |
3
augustheart 2020-01-19 09:53:15 +08:00
当然可以，想怎么搞就怎么搞。不过老实说暴力破解一点玩头都没有，毫无技术含量。
|
 |
4
lihongjie0209 2020-01-19 09:56:05 +08:00 8
我觉得你的思路跑偏了.
暴力破解属于 IO 密集型任务, 读取文件是主要耗时, 你所谓的算力在暴力破解中只是一个 for 循环的事情用来生成下一个密码. 我们可以假设一个极端的情况, 你提前生成好了 6 位密码的所有可能排列, 那么是不是说你就知道密码是什么了? 当然不是, 你必须把文件打开, 然后测试你生成的密码. 所以暴力破解文件密码不存在任何算力瓶颈. |
 |
5
franklinray 2020-01-19 10:00:13 +08:00
@lihongjie0209 楼主是想通过 GPU 来达到将整个 for 循环并行的目的吧。不过在尝试密码的时候不知道是不是需要读取文件，或者能不能通过其他方式进行密码的尝试
|
 |
6
sunziren 2020-01-19 10:00:57 +08:00
@lihongjie0209 你给了楼主致命一击
|
|
7
augustheart 2020-01-19 10:08:38 +08:00 5
@lihongjie0209 并不需要每次都做文件操作的，至少 zip 是能够在内存中处理的。假如某个压缩包真的必须每次做文件操作，肯定是采取极端做法整个读入内存。
走 io 操作这种超级低效的方法正常写破解代码的都不会这么干 |
|
8
augustheart 2020-01-19 10:12:02 +08:00
@lihongjie0209 而且和你说的相反，暴力破解依赖的就是算力。
|
 |
9
guyeu 2020-01-19 10:13:41 +08:00
纯 java 做不到。。只能 jni，GPU 相关的逻辑用 C 实现。
|
 |
10
bagel 2020-01-19 10:15:13 +08:00 12
@sunziren 还致命一击。。楼上又暴露一堆不懂装懂的。暴力破解 AES 是典型的 CPU 密集任务，我只需要读取头一个 block （ AES 采用 16 字节 block ），就可以进行破解计算了，哪来的 IO ？
|
|
11
lihongjie0209 2020-01-19 10:16:25 +08:00
@augustheart #7 那么假设读取到内存之后测试密码耗时为 0, 那么程序的主要耗时是第一个读取文件到内存 + 生成 N 位字符串的排列.
假如我们需要破解一个 1GB 的压缩文件, 那么你需要的 IO 时间肯定是 ms 级别的, 但是循环的时间可能都不到 ms |
|
12
bagel 2020-01-19 10:16:51 +08:00
为什么提 AES，因为 Zip 标准加密有两种方式，一种是 AES，一种是更弱鸡已不建议使用的 Zip 自己的加密算法。
|
|
13
lihongjie0209 2020-01-19 10:17:53 +08:00
@bagel #10 楼主的做法是 : 从 0 开始逐个测试密码 密码不对就接着试的那种, 不管你使用的是那种加密算法, 都当做黑盒破解
|
|
14
bagel 2020-01-19 10:18:45 +08:00 3
@lihongjie0209 #11 还在杠，多读点书，不懂装懂很好玩吗。
|
 |
15
crystom 2020-01-19 10:18:50 +08:00
@lihongjie0209 很明显测试密码的耗时远大于生成排列
|
|
16
lihongjie0209 2020-01-19 10:19:37 +08:00
@bagel #14 眼睛不好去读题
|
|
17
lihongjie0209 2020-01-19 10:21:37 +08:00
@crystom #15 可能, 要看具体的压缩文件类型和库实现方式, 不过 IO 仍然是大头
|
 |
18
iFlicker 2020-01-19 10:25:21 +08:00
jni 调 cuda api
|
 |
19
bibitiger 2020-01-19 10:27:54 +08:00
如果只会 java 就放弃吧，jni 需要 c 或者 c++
|
|
21
bibitiger 2020-01-19 10:32:49 +08:00
@lihongjie0209 对于 IO 来说，空间换时间，多线程多进程。解密来说，首先肯定要知道加密方式，接着根据加密方式提取密文开始破解就好了，不需要全部重复 IO
|
|
23
lihongjie0209 2020-01-19 10:35:32 +08:00
@bibitiger #20 嗯, 高级一点可以这么玩. 不过从楼主的问题来看应该是想黑盒暴力破解.
|
|
24
bagel 2020-01-19 10:42:45 +08:00 1
这个问题实际都不需要懂技术细节，有点常识的人就知道。你解压一个带密码的很大的文件，输入错误密码，程序立刻会告诉你密码错误。就和删除一个大文件（普通删除），是立刻完成，不会 IO 很久。设计计算机的人没有有些人那么蠢。
|
 |
25
yutou527 2020-01-19 10:51:52 +08:00
他的假设算力无限大的情况 IO 确实是大头，但是这可能吗？
|
 |
26
LostPrayers 2020-01-19 10:53:30 +08:00
@lihongjie0209 兄弟你是测试吧，典型的测试思维。
在有程序的情况下哪里需要这样搞啊，更别提还是 zip、7z 这类大众熟知的软件。直接 ida 出解密算法的执行 call，写成 hook 让 java 程序用 jni 调用就行了，这里其实用 java 还是 js 还是 py 做前端都没啥区别，关键是上一步的反编译需要 C 或者 C++。或者你不会反编译,直接用 java 实现关键解密算法也行(针对 zip\7z 这类开源的) 然后到了 GPU 运算这里，我不太熟不知道有没有什么现成框架，照理是有的那你用什么前端做开发都差别不大 |
 |
27
lsastaaa 2020-01-19 10:57:05 +08:00
@lihongjie0209 不是就算如你所说，你也不用每次循环都去读文件啊。 在循环外把文件读出来，在循环内只做密码验证。
|
|
28
LostPrayers 2020-01-19 10:58:03 +08:00
@lihongjie0209
而你说的那种瓶颈在 IO 上的, 一般是 WEB 或者远程服务的后台爆破吧, 代码不在本地上跑, 确实只能消耗大量的网络 IO. 但如果你知道加解密算法的时候,情况又不一样了, 又变回纯算力爆破了. 下次遇到不理解的领域还是先不要头铁的好 |
|
29
lihongjie0209 2020-01-19 11:00:05 +08:00
@lsastaaa #26 参考 #11
|
|
30
augustheart 2020-01-19 11:08:16 +08:00
@lihongjie0209 不需要，你读一下 libzip 的代码。
目前我知道的压缩格式中没有任何一个是需要读取所有的 binary 才能知道密码是否正确的，这不是正常的产品设计思路。 |
|
31
augustheart 2020-01-19 11:13:46 +08:00
@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 之后，在内存中反复用不同的密码重试是没有任何难度的。 |
|
32
augustheart 2020-01-19 11:18:04 +08:00
@LostPrayers 通过服务器破解也不用反复通过网络解密。通过网络一次性传输需要的关键数据后，所有的后续操作都可以在服务端完成。
因为这只是检查密码，而不是整个解压 |
|
33
LostPrayers 2020-01-19 11:21:47 +08:00
@augustheart 额,我的意思不是通过服务器破解，而是爆破远程服务的密码
|
|
34
lihongjie0209 2020-01-19 11:24:36 +08:00
@augustheart #30 好的, 我去研究一下
|
 |
35
warcraft1236 2020-01-19 11:31:30 +08:00
@LostPrayers 求不黑测试，测试也不是不知道代码逻辑的，解压密码判断正确，还需要反复读取文件，这个逻辑听起来就有问题，正常人怎么可能这么搞
|
|
36
augustheart 2020-01-19 11:34:51 +08:00
@LostPrayers 好吧，领会错了。因为这个帖就是说压缩文件，我直接想到当初毛子弄的远程破解密码服务了
|
 |
37
luozic 2020-01-19 11:38:44 +08:00 via iPhone
到底是网络跑字典，还是本地通过 gpu 加速跑字典？
|
|
38
lihongjie0209 2020-01-19 11:46:02 +08:00
@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)`. 最后还是很感谢这种有意义的讨论, 学到了不少东西 |
|
39
augustheart 2020-01-19 11:49:49 +08:00
@lihongjie0209 读取整个文件只可能用在解压缩的时候，这个时候当然是需要读取所有数据了然后逐块输出。
只是解密的话就相当于在压缩软件上点下测试键。 |
|
40
augustheart 2020-01-19 11:51:06 +08:00
@augustheart 测试键的比拟不恰当，实际上测试键只是省去了输出，它还是要判断二进制数据是否完整。
|
|
41
lihongjie0209 2020-01-19 11:51:22 +08:00
@bagel #23 按照黑盒测试, 使用 zip4j 作为 zip 文件的类库, 每次尝试解压都会读取一个 1024 * 4 的 buff, 读取之后进行 AES 校验, 失败抛出密码错误异常. 那么假设你的字典有 10000 项, 那么你需要进行 10000 次 read, 也就是 10000 次 IO(排除 JVM 对 IO 的优化).
参考: net.lingala.zip4j.tasks.AbstractExtractFileTask#unzipFile |
|
42
lihongjie0209 2020-01-19 11:52:34 +08:00
@augustheart 看一下 40 楼, 忘记 @你了
|
|
43
augustheart 2020-01-19 12:01:07 +08:00
@lihongjie0209 这是一个专门用来解压缩的类库的具体实现，它并不需要考虑解密的速度，它的设计就只是为了输出解压后的数据，不管你的实际目的是什么，它都会把整个解压缩流程跑一遍。这就好比我坐公交需要刷上下车两次卡，但是我上车没刷卡，下车刷了一次卡，我只需要跑前面再刷一次卡补上就行，并不需要再坐个全程来补全刷卡。
你不要把你的思想局限在具体的类库的调用方式上，你这就好比写个批处理调用 zip 来判断压缩包密码，是非常低效且无脑的。 往大了说，编程就是算法+数据结构。io 并不是必须的。 |
|
44
lihongjie0209 2020-01-19 12:02:37 +08:00
@augustheart #42 是的, 如果黑盒测试这种浪费和低效是无法避免的.
|
|
45
lihongjie0209 2020-01-19 12:06:08 +08:00
@augustheart #42 具体要看楼主的取舍了, 如果黑盒测试, 那么瓶颈在 IO. 如果白盒测试(针对具体每个压缩文件类型以及加密算法), 那么瓶颈在研发难度以及时间.
|
 |
46
ihciah 2020-01-19 12:08:53 +08:00 via iPhone 2
致命一击笑死🤣
|
|
47
augustheart 2020-01-19 12:11:56 +08:00
@lihongjie0209 从楼主的需求出发的话是不存在取舍这东西的
|
 |
48
golden0125 2020-01-19 12:25:05 +08:00 8
真的佩服有些人,脸皮是厚如城墙,卖弄一知半解的知识恨不得用上所有自己知道的名词,被人现场打脸居然还能大言不惭怼回去,牛逼牛逼
|
 |
49
realpg 2020-01-19 13:36:25 +08:00
暴力破解 RAR 加密现在有条件 忘了是必须加密文件名还是文件名必须不加密了
而且确实是计算密集型应用而不是 IO 密集型应用 |
 |
50
liukangxu 2020-01-19 13:53:22 +08:00
大型翻车现场🤣
|
 |
51
wuwukai007 2020-01-19 13:58:45 +08:00 via Android
生成 8 位的非纯数字密码估计都要好久吧，
|
 |
52
mikicomo 2020-01-19 14:13:24 +08:00
下次发表评论前，还是要先提高自己的姿势水平，不然挺容易翻车的
 |
 |
54
hhhsuan 2020-01-19 14:26:05 +08:00
可以尝试一下 jcuda： http://www.jcuda.org/
|
 |
55
zzzmh OP 厉害了 ， 早上摸摸鱼发个帖没想到这么多人回复， 感谢各位大佬指点 ，我其实就是过年期间没事干想写的好玩的东西 ，其实目前还没开工， 就先做做准备的功课。
|
|
56
zzzmh OP 因为之前写过正常的压缩 zip、gzip、7z，所以打算先从这个入手，写个小工具，最终希望能 1 小时内至少跑完 8 位数字字母，这样才有可用性。如果有可能成的话，之后再扩展到 word 破解之类的上面，其实也没什么真的需要我破的文件，只是写着玩玩，顺便学学之前没写过的知识盲区
|
 |
57
lostpg 2020-01-19 15:22:58 +08:00 via Android
暴力破解 io 密集。。。你说是，那就是，不反驳。
|
 |
58
dicc 2020-01-19 15:47:09 +08:00
Passware Kit Forensic 2017 v1 (64-bit)
下载个破解的就可以了 |
 |
59
seraphv3 2020-01-19 16:04:52 +08:00
以前玩过破解 wifi，用的 CDLinux，GPU 的确比 CPU 要快得多
|
|
60
seraphv3 2020-01-19 16:11:15 +08:00
@seraphv3 用 CDLinux 抓包，EWSA 在 windows 上跑包。这种方式一次都没有解出来过。后来有一次我把抓的包给专门跑包的人跑，跑了 2 个包，有一个跑出来了。不过如果是开了 WPS 的 wifi，尝试 PIN 码，一晚上就一定能跑出来
|
 |
61
JerryCha 2020-01-19 16:33:33 +08:00
楼主离挖矿原理又进了一步
|
 |
62
MadaraII 2020-01-19 16:57:50 +08:00
暴力破解密码还是用汇编的好,找个知道密码的压缩包,直接跟踪解压程序到第一个写磁盘操作,随便把这个指令改下,改成把本次尝试的密码写到磁盘就完事了,剩下的事就是找个 U 多的电脑,开个内存盘把压缩文件拷进去,随便编个程序开上几百线程就刷改完的那个解压程序.这么搞什么算法都不用,全靠解压软件自己跑就完事了.你要是能把调用解压软件给嵌入到 GPU 去算,那就得研究解压算法,那样也行
|
 |
63
appleUtils 2020-01-19 17:01:25 +08:00
io 确实不是瓶颈，算力才是，io 只需读取一小部分，然后不停的通过密码试错，这个解秘过程就是计算过程，算力越大，解密越快
|
|
64
zzzmh OP @seraphv3 我们玩的应该是同款， 之前我这里用 gpu 跑纯数字 11 位 不到 30 分钟，cpu 就没跑完过太慢了
|
 |
65
monkeyWie 2020-01-19 18:37:04 +08:00 via Android
笑死，这种暴力破解竟然是 io 密集型，难道你打开一个 10g 的加密压缩文件在输错密码之后要等 10g 数据验证完才提示密码错误吗
|
 |
66
springGun 2020-01-19 19:10:33 +08:00
区块链有没有这方面相关的应用落地?可以尝试使用某些区块链现成的算力,当然我瞎猜的
|
 |
67
Umenezumi 2020-01-19 20:17:49 +08:00
就一次 IO，何来 IO 密集型？
|
|
68
augustheart 2020-01-19 22:02:22 +08:00
@MadaraII 你打了这么多字是认真的？
|
 |
69
nightwitch 2020-01-19 22:11:51 +08:00
|
|
70
augustheart 2020-01-19 22:13:38 +08:00
@springGun 分布式计算平台啊，只是不发币而已
|
 |
71
aguesuka 2020-01-19 23:12:18 +08:00 via Android
杠精翻车现场，看得我尴尬，赶紧拉黑
|
 |
72
Narcissu5 2020-01-19 23:16:48 +08:00 1
|
 |
73
4ier 2020-01-19 23:26:06 +08:00 via Android
最近正在研究这个方向，感谢楼中各位分享，感谢楼主的好问题
另外，开放讨论，畅所欲言，楼中个别看热闹的戾气好重 |
Select Language