破解神州数码

神州数码的技术特性：
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;//类型
};

神州数码定义的这个头中有两个包长度和类型，他们是一样的。