DrCom 5.2.1(X) 版协议分析 —— EAP 协议

目录 Linux, 项目探索

通过 Wireshark 抓包可以得到几个重要的包,其中一个包是客户端在启动时向网关 Nearest 发送 Logoff 包:

Clevo_18:5f:14   Nearest   EAPOL   96   Logoff

0000   01 80 c2 00 00 03 80 fa 5b 18 5f 14 88 8e 01 02  ........[._.....
0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

协议类型为 0x888e,即 EAP,可扩展身份验证协议,是 802.1x 认证机制的核心。而 EAPOL 则是基于局域网的 EAP。通过 EAP 包追踪到的IP发现还有 UDP 心跳包,所以可以确定 DrCom 5.2.1(X) 使用 EAP 协议完成内网认证,随后通过 UDP 协议发送心跳包保持登录状态。

另外,在未登录内网前,机器无法 Ping 通网关,在其他同学机器上抓包可推测认证的方式是通过广播的方式来进行的。

由此可见,抓包后可在 Wireshark 中设置以下过滤器:

eth.addr eq 80:fa:5b:18:5f:14 && eapol

(其中 80:fa:5b:18:5f:14 为当前机器的网卡 Mac 地址)

认证登录过程

当客户端开始登录时,首先会向广播地址发出一个 Start 包:

Clevo_18:5f:14   Broadcast   EAPOL   96   Start

0000   ff ff ff ff ff ff 80 fa 5b 18 5f 14 88 8e 01 01  ........[._.....
0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

认证服务器收到 Start 包后会回复 Request, Identity 包到本机:

Hangzhou_56:78:00   Clevo_18:5f:14   EAP   60   Request, Identity

0000   80 fa 5b 18 5f 14 58 6a b1 56 78 00 88 8e 01 00  ..[._.Xj.Vx.....
0010   00 05 01 01 00 05 01 00 00 00 00 00 00 00 00 00  ................
0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0030   00 00 00 00 00 00 00 00 6b 6e fc d0              ........kn..

至此,客户端将不再向广播地址发送数据包,而转为向响应的认证服务器发送包,但实际测试中,继续向广播地址发送也是可以的。从包名上看,这个包是向客户端请求身份信息。客户端收到这个 Request 包后,应该向服务器回应一个 Response, Identity 包:

Clevo_18:5f:14   Hangzhou_56:78:00   EAP   96   Response, Identity

0000   58 6a b1 56 78 00 80 fa 5b 18 5f 14 88 8e 01 00  ........[._.....
0010   00 19 02 01 00 19 01 31 38 31 31 35 30 31 31 30  .......181150110
0020   31 36 00 44 61 00 00 c0 a8 c5 41 00 00 00 00 00  16.Da.....A.....
0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

其中,这个包包含学号(31 38 31 31 35 30 31 31 30 31 36)和IP地址(c0 a8 c5 41),当服务器收到 Response, Identity 包后,开始请求客户端发送 MD5-Challenge:

Hangzhou_56:78:00   Clevo_18:5f:14   EAP   60   Request, MD5-Challenge EAP

0000   80 fa 5b 18 5f 14 58 6a b1 56 78 00 88 8e 01 00  ..[._.Xj.Vx.....
0010   00 1a 01 00 00 1a 04 10 e2 a2 6b 79 c0 a8 7f 81  ..........ky....
0020   c0 a8 7f 81 00 00 00 00 10 82 00 00 00 00 00 00  ................
0030   00 00 00 00 00 00 00 00 b2 1f ab 9d              ............

这个包中包含了一串 AttachKey (e2 a2 6b 79 c0 a8 7f 81 c0 a8 7f 81 00 00 00 00)。客户端收到 AttachKey 后,将其与密码和 Id(第19位) 做 MD5 运算,则可得到 Challenged-Password。由于客户端使用的是标准 EAP 协议,多次抓包后发现这里的 Id 固定为 0,因此可得算法:

Challenged-Password = md5 ( Id + Password + AttachKey )

计算得到 Challenged-Password 后,客户端将其与学号一同发给认证服务器。

Clevo_18:5f:14   Hangzhou_56:78:00   EAP   96   Response, MD5-Challenge EAP

0000   58 6a b1 56 78 00 80 fa 5b 18 5f 14 88 8e 01 00  ........[._.....
0010   00 2a 02 00 00 2a 04 10 06 44 35 8b 1a 68 39 fd  .*...*...D5..h9.
0020   2f 19 55 d2 6a 7b 54 34 31 38 31 31 35 30 31 31  /.U.j{T418115011
0030   30 31 36 00 44 61 26 00 c0 a8 c5 41 00 00 00 00  016.Da&....A....
0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

认证服务器收到 Challenged-Password 后进行验证,如果密码正确,就会返回一个 Success 包,代表内网登录成功:

Hangzhou_56:78:00   Clevo_18:5f:14   EAP   60   Success

0000   80 fa 5b 18 5f 14 58 6a b1 56 78 00 88 8e 01 00  ..[._.Xj.Vx.....
0010   00 04 03 00 00 04 00 00 00 00 00 00 00 00 00 00  ................
0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0030   00 00 00 00 00 00 00 00 a6 c9 f9 35              ...........5

整个认证握手过程到这里就结束了。此时只需要使用原生的 PPPoE 进行拨号,就可以连接到外网。

状态维持(心跳包)

当成功登录内网后,客户端会立即再次请求 Identity:

Hangzhou_56:78:00   Clevo_18:5f:14   EAP   60   Request, Identity

0000   80 fa 5b 18 5f 14 58 6a b1 56 78 00 88 8e 01 00  ..[._.Xj.Vx.....
0010   00 05 01 01 00 05 01 00 00 00 00 00 00 00 00 00  ................
0020   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0030   00 00 00 00 00 00 00 00 6b 6e fc d0              ........kn..

客户端收到请求后,发送 Response, Identity 包回应服务器,而这个包内容与登录过程中的 Response, Identity 包内容一致。实际测试过程中发现,服务器会每 300 秒请求一次 Identity,要求客户端回应心跳包。如果客户端不响应服务器的心跳请求,服务器会每隔 300 秒重发 1 次,共重发 5 次,若 5 次请求客户端均未响应,则会收到 Failure 包,服务器主动要求客户端下线。

另外,我们在编写第三方客户端时,发现使用 EAP 协议内网登录成功后大约 21 分钟,一定会收到服务器发回的 Failure 包,被服务器强制下线。如何解决?请看 DrCom 5.2.1(X) 版协议分析 —— UDP 协议

1 条评论

  • DrCom 5.2.1(X) 版协议分析( 序 ) – Steven's Blog
    2017年7月22日

    […] 5.2.1(X) 版主要所使用的协议分为 EAP 协议 和 UDP […]

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据