麗麗的redhat終於可以上網了

寫完了linux下的客戶端,第一件事情就是讓麗麗可以上網

這也是我開發神州數碼客戶端的初衷啊

晚上19:38分,麗麗開啟了google的首頁

然後就找火狐2.0,去換瀏覽器去了

她用的redhat 9.2 上面帶著的瀏覽器有些醜啊,換個firefox2.0回來,工具賞心悅目了,幹活以也有勁,

在linux下使用神州數碼上網的問題,從大一下學期剛買電腦的時候就困擾著我,那時候只知道linux下不能直接執行windows下的認證客戶端(似乎用wine可以間接執行),而linux下的客戶端,神州數碼公司又沒有提供,後來在網上查到的乙個比較確切的答案是:神州數碼有linux下的版本,但是相關的限制功能做的不是很健全,所以除非運營商主動提出要求,神州數碼一般是不會提供linux版本的認證客戶端的.

從那時候起,就有些灰心了,認為linux下沒有辦法上校園網了.偶爾搞個win下的虛擬機器,配好了,結果虛擬機器裡的linux一上網,外面的神州數碼就煩毛病,每個3秒鐘左右就跳出來乙個提示,搞得我頭都打了.有事沒事的研究研究神州數碼,慢慢的知道了神州數碼使用的是802.1x認證協議,但是有自己定義的私有報文部分,所以使用通用的802.1x認證客戶端並不能通過神州數碼的認證.

本來我以為協議是很神秘的東西來著,可是我用ethereal 監聽資料報後發現,神州數碼的驗證過程不過幾個包,再複雜的話,我乙個位元組乙個位元組分析,也沒有什麼難度啊,所以我當時就認為:不久我就可以寫乙個神州數碼客戶端了.可是在真正開始收集資料和分析了神州數碼的報文之後,我發現編寫客戶端的關鍵在於了解神州數碼eap-response-challenge資料報中32個位元組的合成方法,其中16位元組是經過md5加密後的帳戶資訊,還有16位元組在802.1x標準協議中並沒有出現,顯然是屬於神州數碼私有報文的部分,猜了半天沒有猜出來.

於是我就考慮,如果分析神州數碼本身,動態跟蹤他,看看他是怎麼合成這32個位元組的.說幹就幹,找來了各種破解工具,反彙編的啦,動態跟蹤的,還有探測加密殼的,會用不會用的都搞回來了.探測一下加密殼,暈了,是ultraprotect 1.x 我怎麼這麼倒霉啊,第一次破解就遇到這麼難纏的殼,雖然有一篇神州數碼小區寬頻客戶端的破解文章作為參考,還有看雪論壇的眾多

ultraprotect 1.x可以檢視,但是最終,對破解一無所知的我,還是沒有成功!

過了一段時間,看雪上出現了一篇帖子是討論神州數碼破解的,他們是為了通過修改神州數碼突破各種限制,帖子上發了乙個沒有加密的3.4版,我如獲至寶,當初我費了九牛二虎之力而沒有成功的,今天竟然毫不費力的拿到手了,網路確實是個好地方啊.

其實這個時候,因為搬宿舍,我所在的宿舍轉而使用網通寬頻,用不著神州數碼客戶端了,而關於客戶端的程式設計還是乙個零,我都快要放棄了,專心研究js,用js寫了乙個樹,正在改進效能,目標是載入1-5萬節點耗費時間為1-10毫秒,幾乎可以忽略.前期的一些工作已經完成,比如跨瀏覽器之類的,可以說那個樹已經基本完成了,馬上要修改修改發布了.但是我和我女朋友已經快畢業了,所以我得為兩個人的以後想想啊,左思右想,如果讓麗麗從事計算機相關行業的話,找個不是太累的工作為好,程式設計師肯定不行,那就做linux系統管理員吧,雖然有些難學,但是入門之後,如果成長的比較好的話,工作不成問題,而且也不會太累,比較適合女孩子做的.

好了現在問題又回到了起點,麗麗在校園網裡面,需要使用linux下的神州數碼版本才能上網,所以,對於神州數碼客戶端的研究再次開始.

這次我有決心,也有耐心,所需的資料經過了這麼長時間的積累,已經足夠了,雖然我現在不在校園網內,沒有認證環境,好在我有以前從校園網中截獲的資料報,憑著這些資料報,我自己寫了乙個簡單的認證服務端,負責對客戶端的認證要求發出響應(這樣我才可以跟蹤到自己想到的位置啊!).

11月1日開始跟蹤神州數碼客戶端,用自己寫的認證服務端忽悠客戶端,讓客戶端的認證步驟向前推進,在一天半的時間裡,除了吃飯,所有的時間都在研究這個,跟蹤神州數碼,把經過的函式段,已經理解的部分加上注釋,沒有理解的在紙上記下來,繼續跟蹤,結果平時沒怎麼使用的試驗報告紙有了用武之地,成了神州數碼跟蹤報告了.

一開始跟蹤的時候毫無頭緒,從程式開始,一點一點的跟蹤,一路f7,結果是時間費了不少,成果卻沒有,後來我在檢視她的參考的時候,突然想起來神州數碼是用winpcap網路庫的,我自己的神州數碼認證伺服器寫的時候也是用的winpcap庫,我知道他應該先接受資料報,然後分析,根據分析結果,進入不同的響應函式,合成資料報,並傳送的,那我從他接受到資料報開始分析不就可以了......哈哈,終於找到入口了,pcap_next_ex()函式!!!

其實神州數碼客戶端內部用於接受資料報的,似乎不只這乙個函式,還有乙個是用的pcap_loop(),但是我斷了半天沒有斷下來,但是認證還在繼續,因此我斷定,神州數碼在我所需要了解的範圍內,並沒有使用這個pcap_loop()進行資料報的捕獲,所以我轉而斷pcap_next_ex(),一下就斷下來了.高興ing,繼續.

但是現在雖然我已經跟到了收包函式了,但是面對整螢幕的彙編**,我實在是沒有頭緒,雖然一點一點的分析,我可以了解一些小函式的用處,但是畢竟沒有源**,這樣讀**不是辦法,所以我就想,我到底想要什麼?我想知道神州數碼是怎麼合成資料的,那資料在什麼地方呢?對啊,資料在什麼地方呢?資料已經接受下來了,肯定在記憶體裡啊?好,我就先找到資料!

好在自己的彙編還算是過得去,慢慢的發現了不少函式在進入之前的傳參過程中,都把edi給push了,所以我就在資料跟蹤視窗中跟了一下edi,結果不出所料,就是收到的資料報,雖然資料跟蹤視窗顯示的是十六進製制的串碼,但我還是一眼就看出來了,那就是我苦苦尋覓的802.1x認證資料報,因為分析這個協議的資料報也不是一兩天了,不說每個位元組我可以跟你說出她的含義來,也差不多了(畢竟eap本身就不是很負責).

這裡還有乙個小插曲,在一開始還沒有頭緒的時候,我胡亂的在程序裡跟來跟去,累了的時候,就到處看看,無意中見到了一段**,我點著向下的箭頭很久還在她的函式體內,並且這個函式有個特點:跳轉語句很少,似乎都是數值運算,我想在神州數碼中能用到負責數值運算的是什麼地方?md5,嘻嘻,那md5初始話的時候不是有幾個引數嗎?我回去看看有沒有,不好意思沒有.

怎麼會沒有呢?md5沒有那幾個引數怎麼執行啊?這個時候想起了前幾天用來拼湊response-challenge時使用到的那個md5程式,在md5加密過程中有這麼幾個步驟:

1.建立md5物件

2.md5_update

3.md5_final

如果初始化的話,那幾個初始化引數應該在第一步才對,所以在剛才的函式中沒有我想看到的東西,而這段複雜的數值運算最有可能對應的應該時md5_final

按照這個思路,我在乙個小地方找到了那四個引數,然後在另乙個地方找到了一片將傳入的字串連線到乙個指定位置的函式,嗯算我猜對了,繼續!

就在我跟蹤神州數碼客戶端對於request-identity的處理時,突然發現程序已經進入md5_final了,這個是為什麼?那個地方用到md5了?我看了看原先截獲的資料報中客戶端對於request-identity的回應資料,裡面只有16個附加位元組我沒有看清楚,慢著16,16個位元組,這個數字比較特殊啊,慢慢跟,發現程序把username傳遞到md5類的儲存空間中去了,我用自己的那個md5工具把username進行了一次md5,檢視結果,哇噻,這不就是那附加的16位元組嗎?

好,趁勝追擊,繼續分析了對request-challenge的處理.在跟蹤完這個處理過程之後,神州數碼的私有報文中的主要部分已經理解了,所不了解的是一些細節部分,比如認證成功後的返回資訊,認證失敗時的資訊,以及成功後返回的資料中的一部分被我懷疑為是計費以及認證裝置相關的部分位元組......無所謂了,就算是沒有這些資訊,照樣認證成功!先把擁有基本認證功能的客戶端寫出來,解決燃眉之急.

根據已經獲得的這些資訊,開始編寫神州數碼客戶端.考慮到自己的基礎,不大算一開始就在linux下開發,想著寫乙個在windows下可以執行,然後可以比較輕鬆的移植到linux下去的程式.那就只能c++和跨平台的庫來配合開發了.一開始的時候,我打算在windows平台下使用winpcap來實現,然後在linux移植的時候,用libpcap+libnet來實現,因為當時我認為libpcap還不能發包.後來在乙個偶然的機會,我發現最新版的libpcap已經擁有了發包功能(關於這段經歷,已經寫為:libpcap讓我再次驚奇)那我就沒有必要自己重新實現pcap_sendpacket()了.

程式的編寫花了我不少時間,並不是說程式有多少難度(最終**不過1k),而是自己基礎比較差,沒有用c/c++寫過什麼實實在在的東西.程式寫完了,自己還沒有辦法測試,這個時候麗麗回家了,我只能在網上找幾個有認證環境的兄弟姐妹幫忙測試了,這裡要特別感謝山東科技大學的郭梁,

麗麗的redhat終於可以上網了

終於可以上網了

終於可以上網了

我的Debian終於可以上網了

相關推薦