28G超大密码字典居然是个坑

我是笑林新记，分享一下我使用C#的一些用法，希望对大家有帮助！

Visual Studio版本：Enterprise 2015

.net Framework版本：3.5

1

28G字典

前两天有份PDF文件的密码忘记了，打算弄个暴力破解试试。所以在网上下载了一份28G的密码字典，然后因为受限于CPU的性能，每秒只能运行200次，28G的密码字典41亿行数据。大概算了一下，24小时不停机得跑237天左右，果断放弃了，由于不死心，今天有试了一下，结果发现这个超大的字典就是个坑，一点球用都没有。

2

数据分析

首先就是这个txt文件太大了，28G的大小，总共约41亿行数据，每行就是一个密码，Windows自带记事本工具、Notepad++等工具无法直接打开，我8G的内存。不知道哪位朋友有32G以上的内存，可以试试看不能直接打开。

直接用程序读取，一次性全部读取肯定是不可能的了，采用StreamReader加载，然后一行一行地读取。用时190秒，共41亿数据

然后我取了前面1W行数据，这里就不展示了，结果发现，字典采用包含0-9，a-z，A-Z以及特殊符号32个，共94个字符的排列组合，根据排列组合5位密码的组合可能为94的五次方，结果是73.3亿

5位密码的可能就是73.3亿，我这个28G的字典才41亿啊，不妙啊，这个字典不会连5位的密码都不够吧，赶紧再用程序执行一次，果然：超级坑啊！最长的字符串长度居然是5，还好之前放弃是正确的，没有去运行，要不然我测试的密码是123456都破不出来。

3

结论：弃坑

所以这个字典是真正的暴力猜测，从一位到5位的挨个试验，如果采用这种方式，6位数的密码大概有4696亿种，要想破解密码，估计得用银河级的超级计算机了吧。

看到这篇文章的朋友，要记得以后设置密码，多用点特殊符号，然后长度最低6位以上，这样如果靠暴力猜解基本上是没戏。

4

下节预告

28G的没戏了，我只好自己在网上找常用的字典，然后去重合并，得到了一份470W行数据的字典。

下一篇文章我们来说一下，不同txt文件怎么合并去重，常用的方式就是两个循环，假设两个都是百万级的数据，可以试试需要多长时间。欢迎大家评论。

28G字典大家可以自行查找下载，470W的可以私我。