這幾天，搜尋Perfect Dark而來的人越來越多，這或許是因為受到「Share使用者被逮捕」事件的影響。雖然如此，和Share相比，Perfect Dark的使用者可以說是少的可憐，各種類型檔案的量都十分的少，下載的速度也很慢。
以下有個簡單的教學，不過在開始之前，有些事你必須要知道：
這個半開連線數限制一直以來困擾著許多P2P的玩家，當然也有好幾位國外的駭客為了這個問題特別去製作修正檔，不過直到最近微軟發佈KB941644 安全性修正，又讓一些問題浮現出來。首先當然就是需要重新製作修正檔，這算是小問題，因為有駭客發佈最新的修正檔 。
然而Vista x64的使用者在安裝此修正之後，會發現和網路相關的系統服務完全沒法啟動，這是因為Vista會檢查驅動程式的雜湊（hash）完整性 ，修改過的tcpip.sys當然無法通過了。過去碰到這種情況會使用bcdedit加入「DDISABLE_INTEGRITY_CHECKS」參數到Windows boot loader裡頭，使Vista不去檢查雜湊完整性。但是如果你裝了KB943899、KB943078、KB932596、B938979、KB941649這些修正檔，這行參數就完全無效了，因為這些修正檔會強制Vista去檢查驅動程式的簽章與雜湊完整性，並忽視「DDISABLE_INTEGRITY_CHECKS」這個選項。如此一來，每次啟動Vista之前，都要先按F8進開機選單，並選擇不要使用驅動程式簽章檢查，這實在很擾人（Vista又多了一個擾人的罪狀了…）。
Vista x32的使用者不會有這個問題，但是對於電腦記憶體裝有4GB以上的人來說，不太可能會去用32位元的版本。 （我就是
參考：Windows Vista tcpip.sys Connection Limit Patch for Event ID 4226
Update: 在我使用的系統上，我發現一個問題，使用這個patch，然後啟動emule或utorrent，大概跑個一到兩天，會發現他們所用的port被封鎖，但這不是防火牆的問題，因為重開機之後又正常。而我之前使用WinXP以及Vista還沒作過patch時，都沒出現過這種情況。看來要安裝此patch的人，可能多加考慮了。看來和autotuninglevel有關，這個功能一定要關掉，修改過的tcpip.sys才能正常運作。
最近重新看了一次英文維基百科上關於Share的文章，才發現許多事情已經不如以往了…
在去年（2006）日本的黑帽大會上，網路安全公司NetAgent的總裁在會場示範，他們有辦法判別Share網路上每一個節點，在下載什麼檔案、使用的埠號以及IP位址。該公司開發的軟體「Retina Sharebot」能夠扮演節點的角色，並且能在幾個小時內，收集完約十萬個節點的相關資訊。這對Share的使用者來說，無非是個很大的警訊。
根據NetAgent在2006年12月的調查，單日在Winny網路上運作著的節點，大約有39萬到45萬個，而Share只有10萬到15萬個。本來在金子勇被捕，Winny的原始碼全盤托出之後，許多人預料Winny的使用者會改為使用Share，不過就結果看來並非如此。我覺得這樣的結果多少跟使用習慣以及Share對於頻寬與硬碟空間的要求較高有關，而且這也證明日本的法務機關其實沒有大刀闊斧的掃蕩那些侵犯著作權與智財權的Winny使用者。
由於Winny與Share都無法保障檔案分享者的個人隱私，在2ch上頭有名叫「会長」的網友便提出自己開發的「Perfect Dark」來代替Share。Perfect Dark在使用上和Winny與Share是很相似的，不過也加入了新的技術與想法：dkt+dht+du（詳情請參考日文維基）。不過我認為有一些因素會阻礙這個軟體的接受度與使用率，Perfect Dark必需的上傳頻寬為100KB，而且暫存所需的硬碟空間為40GB，恐怕許多人看到這兩個數字就會打退堂鼓了。
Winny、Share與Perfect Dark都是採用分散式的架構，所以除非日本的法務機關開始認真的去掃蕩那些違法的檔案分享者，否則這三個軟體的使用率在短期內不會有極大的改變。
eMule在0.47b之後的版本正式加入了模糊協定的功能，這個功能主要是針對ISP的流量限制做出反擊。
在網路上傳輸的封包，大致上可以很簡單的分為兩個部份：標頭與資料。在標頭的部份都含有特定的識別資訊，因此只要透過特定的觀察器，去擷取在網路上傳播的 封包，就可以知道「誰」正在用何種「通訊協定」在傳輸訊息。而eMule所使用的ED2K通訊協定，在每個封包的標頭的部份，自然也包含著特定的識別資 訊。最近幾年，各國的ISP業者因為感受到P2P流量對自身網路所帶來的衝擊，因此紛紛開始研究去限制P2P的流量。而eMule所使用的ED2K通訊協 定，自然是主要的目標之一，因為同時在使用eMule的人可能有數百萬到數千萬人以上。
為了對ISP的流量限制做出反制，eMule的開發團隊，開發出「模糊協定」這項功能。開啟這個功能，eMule傳輸的封包標頭看起來就會變成一群亂數而無意義的資料，因為缺乏固定的特徵，所以沒有辦法被簡單的識別出來，如此一來ISP的流量限制也就變得毫無效果。
「模糊協定」經常在某些地方會被誤解：
目前模糊協定已經在ED2k TCP與UDP、伺服器的TCP與UDP、Kad的TCP上實做，至於Kad的UDP則尚未實做。
開啟這項功能會使CPU的佔用率稍微提高，並且在傳輸資料時，會需要多傳數Bytes的資料，然而這並不是什麼大問題。
L7-filter是針對OSI模型 的第七層－應用層所設計，是Linux防火牆Netfilter的分類器。它可以對每個封包所使用的通訊協定做出分類，進而讓Netfilter對特定的 通訊協定進行阻擋或者是頻寬控管。目前針對ED2K的比對檔只測試到eMule 0.47a的版本，之後的版本因為模糊協定的關係，應該無法對經過模糊化的ED2K封包做出有效的比對。
IPP2P則是Netfilter的模組，專門針對P2P通訊協定來設計。在IPP2P的網站並沒有任何關於成功辨識模糊協定的消息，因此可以認定IPP2P無法對經過模糊化的ED2K封包做出有效的比對。
eMule在8月9日釋出了0.47b版，此版最重要的功能，就是新增了模糊協定(Protocol Obfuscation)，正式對ISP的流量限制措施做出反擊。英文版的Wikipedia對Obfuscation所做的解釋是「透過ㄧ些容易讓人混淆的方式，讓訊息中要傳達的意義被隱藏起來，並且難以被解析」。而模糊協定就是讓eMule所使用的通訊協定難以被辨識出來，如此一來ISP的流量限制就無效了，這跟Azureus的傳輸協定加密技術有著異曲同工之妙。
所以Hilag、Seedlag、So-lag的使用者，快點更新版本，並把這項功能打開吧。:P
UPDATE：新版的介紹請看此
