深入淺出SagaECO RPC篇(四) “不滅之握”

以下討論基於SagaECO svn 900版本
源代碼可以從這裡下載

注意: 被分發SagaECO源代碼並不代表你被授權使用、修改、發布衍生的程式
換言之SagaECO團隊仍然保留一切權利(雖然SagaECO團隊早就消失了…

這篇主要覆蓋SagaECO中的NetIO和Encryption類，比較沉悶，是失眠的良藥。

已經去掉無關代碼，但是還是太長了。
要表達的其實是客戶端和伺服器確認連線的流程:

1. 客戶端發送長度為8的封包
2. 伺服器啟動鑰匙交換 ，準備私鑰 ，向客戶端發送含有公鑰、長度為529的封包
3. 客戶端收到伺服器的公鑰，準備私鑰，製作共享鑰匙，並向伺服器發送含有 公鑰、長度為260的封包
4. 伺服器收到客戶端的公鑰製作共享鑰匙
5. 連接成立

想當年我自行斷斷續續去湊關鍵字花了幾個月最後才得出是DH交換
書本和大神的文章是可以省掉以年為單位的時間可謂不誇張…每每醍醐灌頂
每天生活在他們的陰影中實在不要太幸福

具體可以自行參照wiki對應交換所需要的資料。(謎之聲: 再說一次! Ecore是日本的網站非指ECO-Re私服)

DH鑰匙交換的計算 對應的SagaECO中半個Encryption類別(emmm…作者你確定?)

在知道是Diffie–Hellman key exchange之後，其弱點同時暴露:

一個中間人在信道的中央進行兩次迪菲－赫爾曼金鑰交換，一次和Alice另一次和Bob，就能夠成功的向Alice假裝自己是Bob，反之亦然。 攻擊者可以解密（讀取和儲存）任何一個人的資訊並重新加密資訊，然後傳遞給另一個人。

取自wikipedia

幾乎所有ECO封包工具皆基於中間人攻擊。翻查記載，原來曾經有個工具叫作Ecoxy(不用pm我了我也沒有~_~)，具體實現依靠路由表來設置代理，從而作出中間人攻擊。

クライアントからサーバへの接続をecoxyに中継させる
そのため、パケットのIPアドレスを適切に書き換える

クライアント→サーバのあて先IPアドレスをecoxyのアドレスに変換
ecoxy→サーバはそのまま通す
ecoxy→クライアントの送信元IPアドレスをサーバのIPアドレスに変換する

ecoxy代理客戶端與伺服器之間的連接
為此，會替換掉封包中的IP地址
客戶端->伺服器 傳送之前變換成ecoxy的地址
ecoxy->伺服器 就這樣傳遞
ecoxy->客戶端 發包人IP地址變換成伺服器的地址

計算出共享金鑰了，還差最後一步計算: 利用D-H交換中的共享金鑰計算出AES金鑰

通過兩邊一致算法和原料，計算出相等的AES金鑰進行對稱加密。
很多現有機制也是先採用非對稱加密來建立連接，其後進行對稱加密。

這個也是先看了Ecore的注解比較好，否則心臟有危險

對應Encryption.cs的另一半

不得不說這寫法實在是….九陰真經
亂入一下 這是上面基於Ecore思路的實作

謎之聲: C#的版本port到C語言的效率比這段python靠字串不停疊加可能快上50倍…
謎之聲2: C的版本解讀花上100倍時間 甚至沒有了python版的輔助就能入選世界文化遺產了 T_T

完成加解密後近乎通信協議的完全體了，自此封包工具廣泛應用在遊戲中… 例如用作保存遺體XD

想帶出的一點是，一個遊戲的通訊加解密方法被破解也就意味著脫機外掛和私服的基礎，沒有和客戶端的溝通方法的話是不可能實現私服的。(先不要被這篇嚇跑啦，通信層的知識在其他部分幾乎不會用到，它是存在感零同時相當重要的根基。有一天，你會再次回到這裡跟困難打交道，當你有所求之時。

此篇算是勉強完成了ECO RPC通信握手和加密層的解說，特別需要感謝前人的努力，他們鍥而不捨的駭客精神總算是攻破了這一道大關。

後記:
這篇文章沒有修改NetIO。邏輯和線程夾雜在一起，既然能用，又不是犯下滔天大罪，何必處處留難人家。 對於中間人攻擊無效的遊戲客戶端還有DLL注入這一手，只是難度相當大。