HashCrack程序規劃

最近幾天在思考如何遍歷md5找出原碼字符串，但九十多個可見字符，96^6 782757789696，就算只遍歷6位組合也是非常驚人的巨量數據，單機根本無法完成，根據常用密碼合成規律，我們可以采用分而治之的方法解決，方法大致如下：

1、 使用很多機器，機器越多覆蓋的范圍越大。

2、 優先覆蓋最常用的范圍，如全數字組合，小寫字母組合，小寫數字混合組合，大寫字母組合，夾雜一個非字母數字字符的組合，… 之后覆蓋非常見組合，如所有可見字符的N個全排列。

3、 采用c/s結構，中心機管理區段分配策略，優先覆蓋常用區段，所有slave和master一起構成一個覆蓋網。

4、 不僅支持md5，也支持sha等其他類似算法。

5、 Master和slave也支持添加字典，為了覆蓋盡可能多的組合，可添加任何合適的字典組合。

實現難點：

1、 數據組織。

方案一、考慮過磁盤存儲方案，研究了sqlite，寫效率大概10w/s，加了索引大概5w/s，sqlite存儲效率也不是很高，比berkeley存儲浪費很多空間，加了索引后空間放大了一倍。也嘗試過berkeley方案，寫效率大概只有4.5w/s，存儲相對sqlite緊湊一些。但由于寫效率太低，都難于實現我所希望的一個slave一下分配1億數據量的模式（1億數據大概要占磁盤5-10G，最經濟模式大概也要占2.xG）。由于對btree+不太熟悉，暫時還沒有找到高效的存儲方案。

方案二、其實首先是考慮了內存方案，用內存相比磁盤其實要簡單一些，不過受機器可用內存的限制以及客戶接受程度的限制，難于讓一臺slave處理1億以上的數據量，默認大概只能分配2000w-5000w左右的數據量（大概占用內存400M-1.2G）。

以上兩種方案其實選擇方案一更合適一點，因為一般的機器擠2G左右的磁盤基本都沒有問題，甚至20G-200G可能都問題不大，但要持久占用1G內存可能不大好，畢竟大多數用戶比容易接受。第一版暫時用了方案二，待高速寫存儲方案做好后替換一個dll即可（該dll已經留好了接口可直接替換）。

2、 區段劃分

單純的劃分某一個區段也是比較容易的，如10個數字的8個組合，可用如下方法表示

Digits = “0123456789”

Range(Digits, 8, 0, 20000000) 表示digits 8個字母的排列 [0,20000000]

但將一些常用區段單獨出來之后涉及到和更大范圍字母全排列的重合情況就不大好扣出來，暫時沒有找到較好的表示方法，好在小范圍排列被冗余也問題不是很大，此表示方法待繼續研究，暫時采用冗余方案。

3、 Master 發現機制

其實這是一個經典的問題，可考慮得很復雜，也可考慮得很簡單，由于我名下幾個域名都被禁止解析了，所以這個問題變得不是那么方便，不過暫時還是用個域名部署一下最為簡單，存儲空間也是個問題，待我聯系幾個朋友看看能不能找到一個合適的存儲地點，待找到后第一版就這么部署出去吧。

實現方法：

由于要有一個中心提供調度方案，因此該系統肯定有一個中心（不管是一個點還是N個點），所以考慮采用c/s模式，第一版采用一個master和N個slave的方案。

master主要實現以下功能：

1、 覆蓋最常用區段排列，籍此提供最基本的查詢服務。

2、 支持大量slave接入（暫采用iocp模式接入）。

3、 提供區段劃分功能，slave接入斷開自動分配區段，優先分配常用區段，其次分配非常用區段。

4、 查詢轉發功能，接收slave的查詢請求，轉發給其他slave。

slave實現以下功能：

1、 和master交互，接收分配的區段，處理區段內的數據并提供該區段數據查詢服務（此功能由一個接口dll實現，可輕易替換）。

2、 支持查詢功能。

3、 在客戶端還計劃支持api，slave是api的proxy，api通過消息向slave發送查詢請求，slave通過給master發送查詢請求，在整個群落里面提供查詢服務，此功能為該體系的一大亮點，暫時沒考慮做什么限制，主要為吸引用戶提供很主動的編程功能，第一版通過一個c的dll提供api調用功能，在此api基礎上用戶應該可以很容易包裝出其他語言的調用接口，如lua、python的接口等。

進度說明：

由于該項目只是一個即興性項目，沒打算耗費很多時間，計劃在一周內完成，已經過去了3天，所以在細節上暫時無法抽出很多時間仔細研究，待整體功能成型后看情況再斟酌算法，易改變部分暫時都用接口dll實現，該項目代碼部分大概完成了一半左右，未來2-3天左右大概可以做完第一版。