破解神州数码

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

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