写完了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++写过什么实实在在的东西.程序写完了,自己还没有办法测试,这个时候丽丽回家了,我只能在网上找几个有认证环境的兄弟姐妹帮忙测试了,这里要特别感谢山东科技大学的郭梁,在他的热心参与下,测试进行的很顺利,很快就稳定运行了.
接下来的事情,就是到linux平台的移植了,最初我准备用eclipse+CDT进行linux的c++的修改和编译,结果发现还没有gcc简单,因为本来需要修改的东西就不多,这个过程中遇到了一些问题,向如一些头文件在linux下找不到,还有一些winpcap函数没有对应的libpcap函数(比如使用bpf获取mac地址的部分),没有办法,该砍掉的砍掉,该修改的修改.
当g++ main.cpp StateMachine.cpp md5.cpp -lpcap编译成功之后,我真是太兴奋了,马上传到了google论坛上,本来打算让丽丽立刻测试的,不过那是时候时间已经很晚了,明天吧.
第二天,从下午开始,丽丽开始测试linux的神州数码版本,首先从网上下载我发布的linux版本的神州数码,以及libpcap库,然后转到linux下,安装,运行,调试,因为丽丽刚刚接触linux,所以操作有些慢.
19:38分,从电话里传来了丽丽的好消息,我已经打开google的主页了!
至此,神州数码客户端的开发可以告一段落了!
ps:
当前linux版本客户端的不足:没有办法后台运行,只能在终端中运行,在上网过程中终端不能关闭,否则.下一版改进!
