我们学校并没有使用过联想协议的认证系统，而是受了一位网友的邀请才写的，所以我连联想官方客户端的样子都没看到过，一直是由那网友抓包后发送过来，而我猜测地将其套入到此前我写的神州数码的认证程序里面，经过几天的调试，确实能用，虽然并不完全了解认证报文的每个细节。

PT实现的联想Linux客户端项目主页：http://code.google.com/p/zlevoclient/

以下的说明是基于EAP协议过程的补充描述，如果不清楚EAP，可先读深入了解校园网802.1x认证的EAP协议(1)——EAP的总体流程。

认证过程报文的细节描述：

1. EAPOL-Start、EAPOL-Logoff
   设置长度为0的协议包头，然后紧接6个意义不明的字节（可能是版本号之类），直接复制即可：
    {0x00, 0x00, 0x2f, 0xfc, 0x03, 0x00};
2. EAP-RESPONSE-Identity
   长度为5（头部） + username_length，无特别，跟EAP标准一致，
3. EAP-RESPONSE-MD5_Challenge
   长度为6（头部） + 16（MD5值） + username_length，在MD5值之后，先紧接用户名，然后是4字节的本机IP地址，以及9个意义不明的字节，直接复制：{0x00, 0x00, 0x2f, 0xfc, 0x00, 0x03, 0x01, 0x01, 0x00};
4. EAPOL-KEEP-ALIVE
   当认证成功后，需要每60秒发送一次该报文，否则会断线；
   该报文的b:EAPOL 报文类型为0xFC，帧长值为12，其携带信息的前8字节在实际中似乎是随机变化，找不出其规律，不过实际上全部设0也可；后4字节则是本机IP。

在部分版本中，如吉林大学珠海学院，每隔5分钟（可能就在第五个EAPOL-KEEP-ALIVE发出之后）服务器会重新发来EAP-REQUEST-Identity，程序需要正确应答，特别要设置各个应答报文中的e:EAP通信id。

关于服务器返回的数据包，Success和Failure通常包含有中文编码的信息，标志是，EAP报文结束后，紧接0x00002ffc（大概0x18、0x19），其后接着是一个字节的报文长度，再后就是gb2312编码的中文信息。

由于协助我测试的湖南人文科技学院的网友他们的系统是纯手工设置网卡IP的，所以我也不清楚是否有像其他品牌的协议那样有动态静态IP位之类的信息位，如果发现这个版本的程序不能通过认证，可以自己抓包分析，或邮件联系PT。

这就是我们研究这些厂商自定义的EAP协议的意义。

PT实现的神州数码Linux客户端项目主页：http://code.google.com/p/zdcclient/

以下的说明是基于EAP协议过程的补充描述，如果不清楚EAP，可先读深入了解校园网802.1x认证的EAP协议(1)——EAP的总体流程。

神州数码的私有信息尾结构神州数码协议里面最特别的地方是有一段46字节的信息，其位于EAP报文后，属于EAPOL报文的尾端部分，在发往服务器的EAP_RESPONSE_IDENTITY和EAP_RESPONSE_MD5_Challenge两种报文里面都需要附上该46字节的信息以供验证。

在PT的神州数码验证程序zdclient里面，zdclient.h定义了这个信息结构：

struct dcba_tailer {
    bpf_u_int32     local_ip;
    bpf_u_int32     local_mask;
    bpf_u_int32     local_gateway;
    bpf_u_int32     local_dns;
    u_char          username_md5[16];
    u_char          client_ver[13];
};

当然这个结构体只有45字节，实际上在其附到EAP报文时，46字节的首字节用以表示认证所使用的DHCP模式，但由于其加入到上面这个结构体中会引起内存对齐问题，所以暂且让这个DHCP位不属于这个结构。

DHCP位只有0和非0两个状态，前者表示静态，非DHCP模式，后者则是DHCP模式。

这里所谓的DHCP模式并不跟操作系统给网卡获得IP那个DHCP概念等价。在常见的DHCP模式中，完成了认证之后需要重新运行dhclient之类的DHCP客户端来更新网卡的IP，但实际上并不一定如此，实际上是否需要更新得看具体环境，比如广州大学这里，我们需要让程序以DHCP模式认证，但并不需要更新IP，因为系统启动后已经自动获得了。

在不同的验证系统，对信息体的校验的严紧度也不同（估计在服务器可配置）。一般静态IP模式下，需要正确的local_ip段来验证用户是否属于特定子网、端口，但是在动态DHCP模式下，在认证之前网卡是没有合法IP的，因此可以模仿Windows系统发送一个169.254.x.x的伪IP。至于网关和DNS地址，在实际使用中发现填不填影响不大，可留为0。用户名MD5就是用户名字符串的16字节MD5值；剩下的13字节则是包含认证客户端的版本号信息，也是一个普通的字符串，目前已知的版本号包括`3.5.04.1013fk'、`3.5.04.1110fk'、`3.5.04.0324'等……有些网络环境会验证这个字符串，如果客户端版本不合适，就发出相应警告，比如目前武汉大学的认证系统只能使用`3.5.04.1013fk'、`3.5.04.1110fk'两个比较新的版本号来登录，但此前广州大学的神数系统对版本号通吃。

程序里面对这个结构的初始化代码是这样的：

    u_char local_info_tailer[46] = {0};
 
    local_info_tailer[0] = dhcp_on;
 
    struct dcba_tailer *dcba_info_tailer =
                (struct dcba_tailer *)(local_info_tailer + 1);
 
    dcba_info_tailer->local_ip          = local_ip;
    dcba_info_tailer->local_mask        = local_mask;
    dcba_info_tailer->local_gateway     = local_gateway;
    dcba_info_tailer->local_dns         = local_dns;
 
    char* username_md5 = get_md5_digest(username, username_length);
    memcpy (dcba_info_tailer->username_md5, username_md5, 16);
    free (username_md5);
 
    strncpy ((char*)dcba_info_tailer->client_ver, client_ver, 13);

然后我们构建一个IDENTITY报文。帧的目的地址是802.1x标准的多播地址01-80-c2-00-00-03（这里没登出Ether帧头部信息）。

    u_char eap_resp_iden_head[9] = {0x01, 0x00,
                                    0x00, 5 + 46 + username_length,  /* eapol_length */
                                    0x02, 0x01,
                                    0x00, 5 + username_length,       /* eap_length */
                                    0x01};
    eap_response_ident = malloc (14 + 9 + username_length + 46);
 
    data_index = 0;
//以太网帧头
    memcpy (eap_response_ident + data_index, eapol_eth_header, 14);
    data_index += 14;
//EAP帧头
    memcpy (eap_response_ident + data_index, eap_resp_iden_head, 9);
    data_index += 9;
//用户名
    memcpy (eap_response_ident + data_index, username, username_length);
    data_index += username_length;
//尾信息
    memcpy (eap_response_ident + data_index, local_info_tailer, 46);

分别把以太网报文头、EAP头、用户名、信息尾复制到一个数组内，这就是我们最后要发送的报文了。

不过观察神州官方版客户端发出的报文，DCBA信息体并不一定总紧跟eap报文，其在RESPONSE MD5 Challenge 报文里面就基本位于报文的最后，开始于0xa8，中间留空了一大堆0。在zdclient里面没有这样处理，一样紧跟在eap报文后。

注意EAPOL和EAP的长度字段，如果不算46字节的信息尾，它们是相等的，这在解释EAP报文时候提到过。

当成功认证了之后，服务器大概每隔20多秒会重新发来一个REQUEST IDENTITY报文，这个REQUEST IDENTITY和认证过程中的REQUEST IDENTITY只有一个字节的差别，就是eap_id字段，认证时为0x01，保鲜阶段为0x03，zdclient里面对两个报文使用同一个缓冲区，加了个hack，发保鲜报文时候就把这个位置改成0x03。

整个EAP认证过程中需要发出去的报文也只有四种，至于剩下的两个START和OFF，都只有几个字节，不涉及神州数码的信息尾字段，跟标准里面一样。

服务器的反馈信息

我们除了构建这些发出去的报文外，其实对服务器返回的信息兴趣不大，因为只需要判断其中的几个状态位，就知道下一步该干什么了。但是神州数码的反馈报文里面通常除了这些信息尾外，在SUCCESS和FAILURE报文里面通常都会包含一段中文文字，告诉用户是什么问题或者什么通知。

这些信息PT是通过盯着抓来的报文盯出来的，因为其使用GB2312编码的中文，通常使用含高位的ASCII值，看到一堆数值都大于0x80，尝试着放到Python里面按GBK解码，才发现的。

用来搜索报文内的中文信息的python函数：

def searchgbk(byte_array):
    for i in range (len (byte_array)):
        print "[%02x] %s" % (i, byte_array[i:].decode('gbk', 'ignore'))

最后总结出中文信息的规律：
在报文的特定位置出现0x12的首导符，紧跟着一个字节表示该信息的长度，之后便是该信息。0x12出现的位置有：[0x2A]、[0x42]、[0x9A]、[0x120]

最后的完整过程可见print_server_info函数的实现，print_server_info获得字符串的地址后送入转码函数，由iconv的API转换成UTF-8编码的字符串后才由printf输出。

zdclient的报文“驱动式”实现

回顾神州数码协议的整个流程，可知基本上客户端基本上都是在服务器发来了请求报文之后才需要发出应答报文（颇有颠倒了客户-服务角色的意味），其实这样对验证服务器的压力挺大的，不过这不关我们事，而且这也方便了我们对客户端程序的设计。所以zdclient采用了“报文驱动式”的流程，就是说，除了一开始发送一个上线请求，以后接收到什么就应答什么，其他时间一直在无限循环里面loop，睡觉。

libpcap提供了回呼(callback)机制，就是设定了某个回呼函数，只有当网卡接收到特定报文时候才进行中断响应。zdclient里面的get_packet函数就是回呼函数，所有工作都是有它驱动完成的。希望这一点有助于阅读和以后再次开发zdclient的朋友理解代码。

文中出现的术语和名词，基本参考了RFC 3748的相关描述，以及Wireshark软件对相关报文的解释用词。

认证过程简述：

1. 主机向服务器（多播或广播地址）发送EAPOL-Start
2. 服务器向主机发送EAP-REQUEST-Identity要求验证身份的请求
3. 主机向服务器发送EAP-RESPONSE-Identity回应
4. 服务器向主机发送EAP-REQUEST-MD5_Challenge要求验证密码的MD5校验值
5. 主机向服务器发送EAP-RESPONSE-MD5_Challenge回应
6. 服务器向主机发送EAP-Success
7. 保持连接的通信...

当然这只是一般过程，如果在任何时候服务器发来EAP-Failure数据包，都表示整个认证过程终止。

 Supplicant主机                  服务器
 -----------                 -------------
    |------------------------------>|
    | 1.  EAPOL-Start               |
    |                               |
    |<------------------------------|
    | 2. EAP-REQUEST-Identity       |
    |                               |
    |------------------------------>|
    | 3. EAP-RESPONSE-Identity      |
    |                               |
    |<------------------------------|
    | 4. EAP-REQUEST-MD5_Challenge  |
    |                               |
    |------------------------------>|
    | 5. EAP-RESPONSE-MD5_Challenge |
    |                               |
    |<------------------------------|
    | 6.       EAP-Success          |
    |                               |

在以太网中，EAP协议当然也是通过以太网帧的格式来传送，帧类型为0x888e，在基于pcap的抓包程序中，可使用"ether proto 0x888e"来抓取。

Ethernet-Header：
################################################
#  0              5               11       13  #
# +----------------+----------------+--------+ #
# |DST--MAC        |SRC--MAC        |0x888e  | #
# +----------------+----------------+--------+ #
################################################


当用作802.1x应答帧时，常使用802.1x分配的多播地址01-80-c2-00-00-03作为目的地址。

从Wiki的简介得知，EAP协议不仅可用于本文关注的以太网环境中，还可在无线WLAN、令牌环网中应用，而这些链路帧是各不相同的，这就是为什么有EAPOL类型的数据帧，用以抽象EAP协议报文。

EAPOL-报文结构
############################################
#  0                           14 15       #
# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        #
# | Ethernet-Header           |a|b|        #
# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        #
#    17                                    #
# +-+-+-------------                       #
# |c  |Packet Body                         #
# +-+-+-------------                       #
############################################
a:EAPOL 协议版本
b:EAPOL 报文类型
c:EAPOL 帧长度

a类型说明：通常为常量0x01

b类型取值：
EAPOL-Packet :   0x00
EAPOL-Start:     0x01
EAPOL-Logoff:    0x02

各种EAP协议的信息交互，封装在EAPOL-Packet类型的EAPOL报文内。至于EAP报文的格式，基本就是如下所示。

EAP-报文结构
#########################################
#  0                            15      #
# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     #
# |                               |     #
# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     #
#   17 18 19 21 22                      #
# +-+-+-+-+-+-+-+--------------         #
# |   |d|e|f  |g|EAP Body               #
# +-+-+-+-+-+-+-+--------------         #
#########################################

d:EAP通信类型
e:EAP通信id
f:EAP数据长度
g:EAP协商类型

d类型取值：
EAP-Request:  0x01
EAP-Resopnse: 0x02
EAP-Success:  0x03
EAP-Failure:  0x04

e类型说明：
通常由服务器发来的报文指定，在连续的报文内使用这个id来协商或者计算MD5值的数据之一。

g类型取值：
Identity:        0x01
MD5_Challenge:   0x04

一个EAP Supplicant客户端程序主要的任务就是处理服务器发来的数据帧和组织回应服务器的数据帧。除了根据上述的“c:EAP通信类型”和“f:EAP协商类型”位来识别协商类型外，更需要根据这些报文内的其他数据来组织回应数据帧。

下面是需要程序构建的数据包的大概细节：

（需要注意EAPOL帧和EAP帧的两处长度位置，前者的长度是不算EAPOL头的4个字节的，而后者则包含自身头部的5个字节，所以这两个长度的值可能是一致的，但具体可能有扩展信息放在EAPOL帧尾部，则前者比后者大。）

1.EAPOL-Start、EAPOL-Logoff
通常是比较简单的数据包，只需填好相应的位，没有其他附加消息，EAPOL-Start、EAPOL-Logoff两种报文长度为0，通常建立起来两个报文的长度就只有18字节。

2.EAP-REQUEST-Identity
服务器发来的这个报文也比较简单，可能唯一有用的数据是“e:EAP通信id”位，需要给发送回去的报文中把相应位设置为该值，虽然这很可能是常数。

Identity格式
+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP Header      |  Username
+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.EAP-RESPONSE-Identity
只需要设置“d:EAP通信id”位，然后在EAP头后紧接用户名的ASCII码信息。有些品牌的协议中，则顺带在此数据包开始校验客户端的IP、版本号等信息。

4.EAP-REQUEST-MD5_Challenge
服务器请求MD5校验的报文中包含了重要的信息，首先也是“e:EAP通信id”位，后一个报文也需要设置该位；
在EAP报头后紧接一个一位的长度值L（常量0x10），表示紧跟其后的重要数据的长度，其后的16位值则需要用来计算下一个报文中的信息，我们称之为attach-key。

MD5_Challenge格式
+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP Header      |L|MD5-Key/Value
+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.EAP-RESPONSE-MD5_Challenge
首先需要设置“d:EAP通信id”位，然后构建一个这样的字节数组［(e:EAP通信id)(用户密码的ASCII)(attach-key)]，这个字节的长度当然是(1+用户密码长度+16)，然后送入MD5计算函数中，获得16位的计算结果，再把这16位计算结果填入报文。报文格式跟请求的类似，在包头后紧接一位长度值，当然是0x10，然后是16位的计算结果。

一个客户端程序所做的事情通常就是这么多，而因为EAP协议的“Extensible”的特性，几乎我们见到的每个品牌的协议都有所扩展，而且各不相同，所以各个品牌之间的客户端甚至交换机等设备都可能完全不可兼容的，其协议很可能在上述的报文中都添加一个信息尾，用来校验各种信息，具体的情况请留意PT博客的后续文章。

使用起来应该没太大变化，只是让协议更接近官方客户端的过程。现在主页上同时有二进制包和源代码包下载。

项目主页：http://code.google.com/p/zdcclient/

连续一个星期每天一个版本，= .=有点不可思议的说……

经过跟武汉大学的michel同学不断的折腾和测试，终于搞清楚他们学校动态DHCP的流程了，“Windows启动后，提示本地连接受限”，到认证后才开始获取IP，这才是动态DHCP模式，所以使用ZDClient的dhcp后，需要运行系统的DHCP客户端重新获取一次IP（通常是dhclient），这一点功能在启动脚本dhcp_zdc_run.sh内已经包含。

现在在Google Code上面的项目已经正式启动，终于用上svn的服务器了，不用把桌面搞的一团糟。

大家可从项目主页下载最新的源码包：http://code.google.com/p/zdcclient/

之前的网盘链接已经作废。

特别感谢一下刘群同学的关注，给我编译i386的binary，我似乎终于搞定在amd64使用32位的包了！

在姚老大的群里面找到武汉大学的同学micheal帮忙测试了ZDClient，昨天晚上把他们的官方客户端的数据包抓了过来看，原来版本是3.5.04.1013fk，比我们的新！不过奇怪的是广州大学的认证服务器除了用户名密码别的似乎什么都不认证，我怎么乱填都能认证成功 = .=

顺便提醒一下武大的同学，记得在zdcrun里面加上--dhcp参数……

大家可从项目主页下载最新的源码包：http://code.google.com/p/zdcclient/

0.2 更新
-整理代码
-进一步完善包解析、发送过程细节，加入遇到为止包时的提示
-区分EAP_RESPONSE_IDENTITY和EAP_RESPONSE_IDENTITY_KEEP_ALIVE发送的包
-加入自定义客户端版本号的功能参数--ver，并能校验版本号长度
-默认版本号改成3.5.04.0324
-修改--help内About ZDClient的文字
-在认证是提示协议版本信息
-增加可检测root权限的启动脚本

大家可从项目主页下载最新的源码包：http://code.google.com/p/zdcclient/

项目主页：http://code.google.com/p/zdcclient/

开发手记

PT的客户端版本虽然是命令行的版本，但是功能和姚琦的Java版功能没多大差别，目前支持自定义接入网卡、支持DHCP、支持程序运行后自动fork到后台，用户名等通过参数传入程序。

Java版的软件虽然一般使用起来没太大区别，但是当系统中没有jvm虚拟机和软件依赖的库，而且电脑又不能上网的时候，这可是相当棘手的问题，我去年就为此在Ubuntu-cn的Wiki写了一篇教程，如何从源里面抓jvm的一堆包回来安装，再折腾一番才能用。况且Java程序占的资源颇大，就那个0.6.1版的客户端，常驻内存有50M！

姚琦的个人网站上面公布了他的客户端软件的源码，之前有下载回来，不过一直没看，早天兴起把文件重新放到Netbeans里面来编译一次，发现能编译却不能认证！好奇之下跟踪了其代码，把带界面的1500多行的程序删减到只剩400行的命令行程序，然后再根据抓数据包的对比，发现是这个版本获取本机地址的代码有问题，在Linux下获取本机IP是错的，这样组成的数据包去认证，当然不行了，具体在这里有人解释。

摸清楚认证过程的来龙去脉后，就打算自己用C来写一个客户端，虽然我有2G内存，但老被占着几十M也不舒服。Java里面用的jpcap，是Java用JNI对libpcap的封装，之前我弄过编译amd64版时候接触过，发现其功能很强大，使用也不复杂，于是对写个原生C语言版的客户端也有了信心。

为了弄清整个程序的工作流程，我进一步优化了Java版的代码，400多行最后剩下200多了，姚学长的编码好像有点太过那个，呃……而且姚学长好像连jpcap的toturial都没有读完，竟然使用一堆if来过滤抓到的数据包，怪不得之前内网传文件达10M速度的时候，客户端占的CPU狂飙了。为捕捉过程设置了驱动级别的过滤器，使用回呼方式抓包，对一些函数流程进行重构，最后这个版本运行的时候占内存不到10M，CPU占用率也低多了。

这两天对着一个libpcap的抓包示例，一步步地将包分析的功能改了出来，然后就是手动创建的报文，其中一个小插曲是用到的MD5算法，在Java中有个内建的digest功能，但C语言哪来这东西，上网找，连续下了几个版本，测试一下，有些算出来的值是错的，有些每次算出来都不一样，气死我了，看来是因为我现在用的是amd64版本的系统，算法里面的数据类型不兼容所致。最后在MD5 Homepage (unofficial)找到了L. Peter Deutsch's的版本才正常。

对着wireshark满是16进制数的窗口用笔划了两天框框彻底搞清楚了协议包的结构，然后在gvim里面倒腾了代码，终于程序完成了。不知为什么，写这个程序有很亢奋的感觉，昨天晚上是搞到3点钟才睡，然后早上7点多就爬了起来继续coding，不是我不想睡，而是有问题晾在那里没解决就睡觉的话，就只会整晚失眠了。逃了一天课，终于大功告成，本来还想实现配置文件的功能，不过想想还是算了，很容易就能用脚本来记录。