破解神州數位

神州數位的技術特性：
1、採用二層協議
2、每個連接埠綁定一個帳號進行登陸
3、用戶端每隔一定的時間掃描一次區域網路
4、服務端每隔24秒向客戶短髮送查詢資訊，用戶端把帶有當前資訊的資料包發送給伺服器端。如果正常則繼續，不正常就回強迫下線
5、登陸時採用MD5加密效驗
昨天採用winpcap的開發包，每隔30毫秒向服務端發送一次資訊，還好沒有問題，就是機器給掛了（這個發包法不掛才怪呢！）。區域網路中的另一台電腦在這期間很正常的上網。這樣犧牲可就大啦。^_^
今天重新寫了代碼，直接寫登陸的程式。
發送登陸請求－>服務端回覆並要求發送本機狀態－>發送原生狀態->服務端要求MD5效驗－>發送正常用戶端發送的封包，值此服務端相應MD5效驗失敗。
後來把幾次截獲的封包進行比較，MD5的效驗碼是根據伺服器端發送的資料來決定的。鬱悶～～
沒時間去分析它啦。
現在該其它方式，用正常用戶端登陸，截獲伺服器端要求發送狀態的封包後，發送正常封包。
現在進行中中，不過一直沒法截獲服務端的包。
（用其他的封包截獲軟體也是沒有辦法截獲神州數位的包的，並且採用winpcap的高版本會和神州數位有記憶體的衝突，把我氣得要命，還好弄了個低版本的來用）
也夠鬱悶的，神州數位採用了upx加殼，本來向脫殼後逆向一下，把我的flyodbg給kill了，鬱悶。沒法單步啟動並執行，設定flyodbg忽略所有斷點，給kill。把int3的斷點給取消。好了，一直運行到popad，脫殼成功。不過修複時還是出了點問題，這個只有後面解決啦。
現在先解決封包截獲的問題吧。哈哈
把神州數位的工作方式給分析出來了：
1． 點擊認證按鈕，用戶端發送EAPOL-START包，請求認證。
2． 交換器發送請求使用者名稱包
3．用戶端發送含使用者名稱和本機IP的包
4．  交換器發送含MD5-Challenge的包。
5． 用戶端發送含經MD5加密後的密碼和使用者名稱的包。
6． 如果帳號、IP合法，交換器發送成功認證包，和失敗包（這個失敗包可能和檢查代理、多網卡有關，可以不考慮）；如果不合法，交換器發送失敗離線包，此包包含失敗原因。
9． 若成功認證，每隔24秒服務端重複第2，3步，以確認用戶端是否線上。
10． 如果點擊用戶端下線按鈕，用戶端發送EAPOL-LOGOFF包。
11． 交換器發送成功下線包。
源地址 目標地址 協議類型 版本 包類型 包長度 code 標識 長度 類型 資料
6位元組 6位元組 2位元組 1位元組 1位元組 2位元組 1位元組 1位元組 2位元組 1位元組 

包結構為：（1）6位元組 目標MAC
（2）6位元組 源MAC
（3）2位元組 協議（88 8e）
（4）1位元組 版本（01）
（5）1位元組 包類型（01表示請求串連，02表示請求斷開，00表示已串連）
（6）2位元組 包長度（從一下位元組開始計算，到最後一個位元組）
（7）1位元組 code（01：請求，02：回複，03：成功，04：失敗）
（8）1位元組 標識（從01開始，每成功收發一次，自動加一，到FF後清零重新開始）
（9）2位元組 包長度
（10）類型
（11）資料

今天實現了封包截獲的功能，現在對封包分析出現問題，取的明明是他的類型卻出了他的包的長度鬱悶到家啦。不過還好根據封包分析交換器的請求包都是60位元組，根據抓包看了（現在為止）也只有這個認證包是60個位元組的。比較大小吧，當接受包長度為60時，發送資訊包。
實現了對神州數位對代理的限制。現在正在對他的包進行深入的分析，我不能明明是類型，偏偏騙自己是長度吧。神州數位包的頭結構
struct my_802_1x_hdr
{
u_int8_t M_s_host[6];//源地址
u_int8_t M_d_host[6];//目的地址
u_int8_t M_802[2];//協議認證
u_int8_t M_ver;//版本
u_int8_t M_type;//類型
u_int8_t M_length[2];//包長度
u_int8_t M_code;//code
u_int8_t M_inter;//標誌
u_int8_t M_length2[2];//包長度
u_int8_t M_type2;//類型
};

神州數位定義的這個頭中有兩個包長度和類型，他們是一樣的。