HashCrack程序規(guī)劃
最近幾天在思考如何遍歷md5找出原碼字符串，但九十多個可見字符，96^6 782757789696，就算只遍歷6位組合也是非常驚人的巨量數(shù)據(jù)，單機根本無法完成，根據(jù)常用密碼合成規(guī)律，我們可以采用分而治之的方法解決，方法大致如下：
1、 使用很多機器，機器越多覆蓋的范圍越大。
2、 優(yōu)先覆蓋最常用的范圍，如全數(shù)字組合，小寫字母組合，小寫數(shù)字混合組合，大寫字母組合，夾雜一個非字母數(shù)字字符的組合，… 之后覆蓋非常見組合，如所有可見字符的N個全排列。
3、 采用c/s結(jié)構(gòu)，中心機管理區(qū)段分配策略，優(yōu)先覆蓋常用區(qū)段，所有slave和master一起構(gòu)成一個覆蓋網(wǎng)。
4、 不僅支持md5，也支持sha等其他類似算法。
5、 Master和slave也支持添加字典，為了覆蓋盡可能多的組合，可添加任何合適的字典組合。
實現(xiàn)難點：
1、 數(shù)據(jù)組織。
方案一、考慮過磁盤存儲方案，研究了sqlite，寫效率大概10w/s，加了索引大概5w/s，sqlite存儲效率也不是很高，比berkeley存儲浪費很多空間，加了索引后空間放大了一倍。也嘗試過berkeley方案，寫效率大概只有4.5w/s，存儲相對sqlite緊湊一些。但由于寫效率太低，都難于實現(xiàn)我所希望的一個slave一下分配1億數(shù)據(jù)量的模式（1億數(shù)據(jù)大概要占磁盤5-10G，最經(jīng)濟模式大概也要占2.xG）。由于對btree+不太熟悉，暫時還沒有找到高效的存儲方案。
方案二、其實首先是考慮了內(nèi)存方案，用內(nèi)存相比磁盤其實要簡單一些，不過受機器可用內(nèi)存的限制以及客戶接受程度的限制，難于讓一臺slave處理1億以上的數(shù)據(jù)量，默認大概只能分配2000w-5000w左右的數(shù)據(jù)量（大概占用內(nèi)存400M-1.2G）。
以上兩種方案其實選擇方案一更合適一點，因為一般的機器擠2G左右的磁盤基本都沒有問題，甚至20G-200G可能都問題不大，但要持久占用1G內(nèi)存可能不大好，畢竟大多數(shù)用戶比容易接受。第一版暫時用了方案二，待高速寫存儲方案做好后替換一個dll即可（該dll已經(jīng)留好了接口可直接替換）。
2、 區(qū)段劃分
單純的劃分某一個區(qū)段也是比較容易的，如10個數(shù)字的8個組合，可用如下方法表示
Digits = “0123456789”
Range(Digits, 8, 0, 20000000) 表示digits 8個字母的排列 [0,20000000]
但將一些常用區(qū)段單獨出來之后涉及到和更大范圍字母全排列的重合情況就不大好扣出來，暫時沒有找到較好的表示方法，好在小范圍排列被冗余也問題不是很大，此表示方法待繼續(xù)研究，暫時采用冗余方案。
3、 Master 發(fā)現(xiàn)機制
其實這是一個經(jīng)典的問題，可考慮得很復(fù)雜，也可考慮得很簡單，由于我名下幾個域名都被禁止解析了，所以這個問題變得不是那么方便，不過暫時還是用個域名部署一下最為簡單，存儲空間也是個問題，待我聯(lián)系幾個朋友看看能不能找到一個合適的存儲地點，待找到后第一版就這么部署出去吧。
實現(xiàn)方法：
由于要有一個中心提供調(diào)度方案，因此該系統(tǒng)肯定有一個中心（不管是一個點還是N個點），所以考慮采用c/s模式，第一版采用一個master和N個slave的方案。
master主要實現(xiàn)以下功能：
1、 覆蓋最常用區(qū)段排列，籍此提供最基本的查詢服務(wù)。
2、 支持大量slave接入（暫采用iocp模式接入）。
3、 提供區(qū)段劃分功能，slave接入斷開自動分配區(qū)段，優(yōu)先分配常用區(qū)段，其次分配非常用區(qū)段。
4、 查詢轉(zhuǎn)發(fā)功能，接收slave的查詢請求，轉(zhuǎn)發(fā)給其他slave。
slave實現(xiàn)以下功能：
1、 和master交互，接收分配的區(qū)段，處理區(qū)段內(nèi)的數(shù)據(jù)并提供該區(qū)段數(shù)據(jù)查詢服務(wù)（此功能由一個接口dll實現(xiàn)，可輕易替換）。
2、 支持查詢功能。
3、 在客戶端還計劃支持api，slave是api的proxy，api通過消息向slave發(fā)送查詢請求，slave通過給master發(fā)送查詢請求，在整個群落里面提供查詢服務(wù)，此功能為該體系的一大亮點，暫時沒考慮做什么限制，主要為吸引用戶提供很主動的編程功能，第一版通過一個c的dll提供api調(diào)用功能，在此api基礎(chǔ)上用戶應(yīng)該可以很容易包裝出其他語言的調(diào)用接口，如lua、python的接口等。
進度說明：
由于該項目只是一個即興性項目，沒打算耗費很多時間，計劃在一周內(nèi)完成，已經(jīng)過去了3天，所以在細節(jié)上暫時無法抽出很多時間仔細研究，待整體功能成型后看情況再斟酌算法，易改變部分暫時都用接口dll實現(xiàn)，該項目代碼部分大概完成了一半左右，未來2-3天左右大概可以做完第一版。