摘要：iNode 协议本是个集成的软件产品，其所设计的校园网认证机制是各项基础协议的组合。本文要谈及的内容有以下几点：（1）介绍构成 iNode 认证框架的一些基本协议；（2）介绍 iNode 逆向工作的研究进展，iNode 客户端的前世今生，哪些人正在做该协议分析研究，有哪些软件或者代码可以成为替代品；（3）根据 iNode 在实际环境下的工作状态与协议内容，并作出逆向实践。

802.1x 认证机制及相关协议

802.1x 认证机制及相关协议 iNode 协议的基础构架实际由802.1x 协议认证机制组成，其中认证过程又采用 EAPOLRADIUS 方式。

缩略语

802.1X 本文专指 IEEE 802.1X 标准
RADIUS 远程用户拨入认证服务 (Remote Authentication Dial In User Service）
PAP 密码验证协议 (Password Authentication Protocol）
CHAP 质询握手验证协议 (Challenge Handshake Authentication Protocol）
EAP 扩展验证协议 (Extensible Authentication Protocol）
EAPOL 基于局域网的 EAP (EAP over LAN）
MD5 消息摘要算法5版本 (Message-Digest Algorithm 5）
PAE 端口认证实体 (Port Authentication Entity）

认证起源和作用

IEEE802 LAN/WAN 委员会为解决无线局域网网络安全问题，提出了802.1X 协议。后来，802.1X 协议作为局域网端口的一个普通接入控制机制在以太网中被广泛应用，主要解决以太网内认证和安全方面的问题。

802.1X 协议是一种基于端口的网络接入控制协议（port based network access control protocol）。“基于端口的网络接入控制”是指在局域网接入设备的端口这一级对所接入的用户设备进行认证和控制。连接在端口上的用户设备如果能通过认证，就可以访问局域网中的资源；如果不能通过认证，则无法访问局域网中的资源。

802.1X 的体系结构

802.1X 系统为典型的 Client/Server 结构，包括三个实体：客户端（Client）、设备端（Device）和认证服务器（Server）。

1.客户端是位于局域网段一端的一个实体，由该链路另一端的设备端对其进行认证。客户端一般为一个用户终端设备，用户可以通过启动客户端软件发起802.1X 认证。客户端必须支持 EAPOL（Extensible Authentication Protocol over LAN，局域网上的可扩展认证协议）。

2.设备端是位于局域网段一端的另一个实体，对所连接的客户端进行认证。设备端通常为支持802.1X 协议的网络设备，它为客户端提供接入局域网的端口，该端口可以是物理端口，也可以是逻辑端口。

3.认证服务器是为设备端提供认证服务的实体。认证服务器用于实现对用户进行认证、授权和计费，通常为 RADIUS（Remote Authentication Dial-In User Service，远程认证拨号用户服务）服务器。

下图为福建农林大学的校园网拓扑图

1.未认证的计算机不分配 IP 地址，可以在局域网内访问校内网站
2.认证的免费校内域可以访问教育网网段
3.认证的收费宿舍网可以访问所有网段

802.1X 的认证方式

802.1X 认证系统使用 EAP（Extensible Authentication Protocol，可扩展认证协议），来实现客户端、设备端和认证服务器之间认证信息的交换。

1.在客户端与设备端之间，EAP 协议报文使用 EAPOL 封装格式，直接承载于 LAN 环境中。

2.在设备端与 RADIUS 服务器之间，可以使用两种方式来交换信息。一种是 EAP 协议报文由设备端进行中继，使用 EAPOR（EAP over RADIUS）封装格式承载于 RADIUS 协议中；另一种是 EAP 协议报文由设备端进行终结，采用包含 PAP（Password Authentication Protocol，密码验证协议）或 CHAP（Challenge Handshake Authentication Protocal，质询握手验证协议）属性的报文与 RADIUS 服务器进行认证交互。

802.1X 的基本概念

受控/非受控端口

设备端为客户端提供接入局域网的端口，这个端口被划分为两个逻辑端口：受控端口和非受控端口。任何到达该端口的帧，在受控端口与非受控端口上均可见。

1.非受控端口始终处于双向连通状态，主要用来传递 EAPOL 协议帧，保证客户端始终能够发出或接收认证报文。

2.受控端口在授权状态下处于双向连通状态，用于传递业务报文；在非授权状态下禁止从客户端接收任何报文。

授权/非授权状态

设备端利用认证服务器对需要接入局域网的客户端执行认证，并根据认证结果（Accept 或 Reject）对受控端口的授权/非授权状态进行相应地控制。

图中显示了受控端口上不同的授权状态对通过该端口报文的影响。图中对比了两个802.1X 认证系统的端口状态。系统1的受控端口处于非授权状态（相当于端口开关打开），系统2的受控端口处于授权状态（相当于端口开关关闭）。

用户可以通过在端口下配置的接入控制的模式来控制端口的授权状态。端口支持以下三种接入控制模式：
1.强制授权模式（authorized-force）：表示端口始终处于授权状态，允许用户不经认证授权即可访问网络资源。
2.强制非授权模式（unauthorized-force）：表示端口始终处于非授权状态，不允许用户进行认证。设备端不对通过该端口接入的客户端提供认证服务。
3.自动识别模式（auto）：表示端口初始状态为非授权状态，仅允许 EAPOL 报文收发，不允许用户访问网络资源；如果认证通过，则端口切换到授权状态，允许用户访问网络资源。这也是最常见的情况。

受控方向

在非授权状态下，受控端口可以被设置成单向受控和双向受控。
1.实行双向受控时，禁止帧的发送和接收；
2.实行单向受控时，禁止从客户端接收帧，但允许向客户端发送帧。

802.1X 的认证触发方式

802.1X 的认证过程可以由客户端主动发起，也可以由设备端发起。设备支持的认证触发方式包括以下两种：
1.客户端主动触发方式
客户端主动向设备端发送 EAPOL-Start 报文来触发认证，该报文目的地址为 IEEE 802.1X 协议分配的一个组播 MAC 地址：01-80-C2-00-00-03。
另外，由于网络中有些设备不支持上述的组播报文，使得认证设备无法收到客户端的认证请求，因此设备端还支持广播触发方式，即，可以接收客户端发送的目的地址为广播 MAC 地址的 EAPOL-Start 报文。这种触发方式需要 H3C iNode 的802.1X 客户端的配合。
2.设备端主动触发方式
设备会每隔 N 秒（例如30秒）主动向客户端发送 EAP-Request/Identity 报文来触发认证，这种触发方式用于支持不能主动发送 EAPOL-Start 报文的客户端，例如 Windows XP 自带的802.1X 客户端。

802.1X 的认证过程

802.1X 系统支持 EAP 中继方式和 EAP 终结方式与远端 RADIUS 服务器交互完成认证。以下关于两种认证方式的过程描述，都以客户端主动发起认证为例。

EAP 中继方式

这种方式是 IEEE 802.1X 标准规定的，将 EAP（可扩展认证协议）承载在其它高层协议中，如 EAP over RADIUS，以便扩展认证协议报文穿越复杂的网络到达认证服务器。一般来说，EAP 中继方式需要 RADIUS 服务器支持 EAP 属性：EAP-Message 和 Message-Authenticator，分别用来封装 EAP 报文及对携带 EAP-Message 的 RADIUS 报文进行保护。

认证过程如下：
(1)当用户有访问网络需求时打开802.1X 客户端程序，输入已经申请、登记过的用户名和密码，发起连接请求（EAPOL-Start 报文）。此时，客户端程序将发出请求认证的报文给设备端，开始启动一次认证过程。
(2)设备端收到请求认证的数据帧后，将发出一个请求帧（EAP-Request/Identity 报文）要求用户的客户端程序发送输入的用户名。
(3)客户端程序响应设备端发出的请求，将用户名信息通过数据帧（EAP-Response/Identity 报文）发送给设备端。设备端将客户端发送的数据帧经过封包处理后（RADIUS Access-Request 报文）送给认证服务器进行处理。
(4)RADIUS 服务器收到设备端转发的用户名信息后，将该信息与数据库中的用户名表对比，找到该用户名对应的密码信息，用随机生成的一个加密字对它进行加密处理，同时也将此加密字通过 RADIUS Access-Challenge 报文发送给设备端，由设备端转发给客户端程序。
(5)客户端程序收到由设备端传来的加密字（EAP-Request/MD5 Challenge 报文）后，用该加密字对密码部分进行加密处理（此种加密算法通常是不可逆的），生成 EAP-Response/MD5 Challenge 报文，并通过设备端传给认证服务器。
(6)RADIUS 服务器将收到的已加密的密码信息（RADIUS Access-Request 报文）和本地经过加密运算后的密码信息进行对比，如果相同，则认为该用户为合法用户，反馈认证通过的消息（RADIUS Access-Accept 报文和 EAP-Success 报文）。
(7)设备收到认证通过消息后将端口改为授权状态，允许用户通过端口访问网络。在此期间，设备端会通过向客户端定期发送握手报文的方法，对用户的在线情况进行监测。缺省情况下，两次握手请求报文都得不到客户端应答，设备端就会让用户下线，防止用户因为异常原因下线而设备无法感知。
(8)客户端也可以发送 EAPOL-Logoff 报文给设备端，主动要求下线。设备端把端口状态从授权状态改变成未授权状态，并向客户端发送 EAP-Failure 报文。

EAP 终结方式

这种方式将 EAP 报文在设备端终结并映射到 RADIUS 报文中，利用标准 RADIUS 协议完成认证、授权和计费。设备端与 RADIUS 服务器之间可以采用 PAP 或者 CHAP 认证方法。

EAP 终结方式与 EAP 中继方式的认证流程相比，不同之处在于用来对用户密码信息进行加密处理的随机加密字由设备端生成，之后设备端会把用户名、随机加密字和客户端加密后的密码信息一起送给 RADIUS 服务器，进行相关的认证处理。

802.1X 的接入控制方式

设备不仅支持协议所规定的基于端口的接入认证方式，还对其进行了扩展、优化，支持基于 MAC 的接入控制方式。

1.当采用基于端口的接入控制方式时，只要该端口下的第一个用户认证成功后，其它接入用户无须认证就可使用网络资源，但是当第一个用户下线后，其它用户也会被拒绝使用网络。

2.采用基于 MAC 的接入控制方式时，该端口下的所有接入用户均需要单独认证，当某个用户下线时，也只有该用户无法使用网络。

802.1X 的定时器

802.1X 认证过程中会启动多个定时器以控制接入用户、设备以及 RADIUS 服务器之间进行合理、有序的交互。802.1X 的定时器主要有以下几种
：
1.用户名请求超时定时器（tx-period）：该定时器定义了两个时间间隔。其一，当设备端向客户端发送 EAP-Request/Identity 请求报文后，设备端启动该定时器，若在 tx-period 设置的时间间隔内，设备端没有收到客户端的响应，则设备端将重发认证请求报文；其二，为了兼容不主动发送 EAPOL-Start 连接请求报文的客户端，设备会定期组播 EAP-Request/Identity 请求报文来检测客户端。tx-period 定义了该组播报文的发送时间间隔。

2.客户端认证超时定时器（supp-timeout）：当设备端向客户端发送了 EAP-Request/MD5 Challenge 请求报文后，设备端启动此定时器，若在该定时器设置的时长内，设备端没有收到客户端的响应，设备端将重发该报文。

3.认证服务器超时定时器（server-timeout）：当设备端向认证服务器发送了 RADIUS Access-Request 请求报文后，设备端启动 server-timeout 定时器，若在该定时器设置的时长内，设备端没有收到认证服务器的响应，设备端将重发认证请求报文。

4.握手定时器（handshake-period）：此定时器是在用户认证成功后启动的，设备端以此间隔为周期发送握手请求报文，以定期检测用户的在线情况。如果配置发送次数为 N，则当设备端连续 N 次没有收到客户端的响应报文，就认为用户已经下线。

5.静默定时器（quiet-period）：对用户认证失败以后，设备端需要静默一段时间（该时间由静默定时器设置），在静默期间，设备端不处理该用户的认证请求。

6.周期性重认证定时器（reauth-period）：如果端口下开启了周期性重认证功能，设备端以此定时器设置的时间间隔为周期对该端口在线用户发起重认证。

EAPOL 消息的封装

1.EAPOL 数据包的格式
EAPOL 是802.1X 协议定义的一种报文封装格式，主要用于在客户端和设备端之间传送 EAP 协议报文，以允许 EAP 协议报文在 LAN 上传送。

PAE Ethernet Type：表示协议类型，为0x888E。
Protocol Version：表示 EAPOL 帧的发送方所支持的协议版本号。
Type：表示 EAPOL 数据帧类型，目前设备上支持的数据类型见下表。

Length：表示数据长度，也就是“Packet Body”字段的长度，单位为字节。如果为0，则表示没有后面的数据域。
Packet Body：表示数据内容，根据不同的 Type 有不同的格式。

2.EAP 数据包的格式
802.1x 定义了接入设备与介入端口间点到点的连接方式，为了建立点与点之间的连接通信，PPP 协议必须要发送 LCP 数据包来对该数据链路进行配置。而 EAPOL 就是 PPP 的一个扩展认证协议。所以该协议的格式规范必须了解，那么 EAPOL 协议的格式规范在下面介绍。
典型的 PPP 协议帧格式为下图：

当 PPP 帧 protocol 字段域填充类型表明 C227类型时，即表明封装的是 PPP EAP 数据包，也应用着扩展认证协议 EAP。所以在 information 字段域内是封装的 EAP 报文格式。一个典型的 EAP 认证报文过程分为 request，response，success 或 failure 阶段。每个阶段报文传送都由 information 域所携带的 EAP 报文来承担。

当 EAPOL 数据包格式 Type 域为 EAP-Packet 时，Packet Body 为 EAP 数据包结构

EAP 报文的格式为：

1.Code：指明 EAP 包的类型，共有4种：Request、Response、Success、Failure。

Code=1和2的情形下，Type 又有多种选择:

Code=3和4的情形下，只回答成功或失败。

2.Identifier 字段域
主要完成 request 和 response 的匹配，即一对正确配对的 request 和 response 的识别字段域是标号相同的。

3.Length 字段域
Length 域为两个字节，表明 EAP 数据包从头到尾的所有长度，超出 Length 域的字节应视为数据链路层填充，在接受时被忽略到。这个信息很重要！

4.Data 字段域
1.Success 和 Failure 类型的包没有 Data 域，相应的 Length 域的值为4。
2.Request 和 Response 类型数据包的 Data 域的格式如图 所示。Type 为 EAP 的认证类型，Type data 的内容由类型决定。例如，Type 值为1时代表 Identity，用来查询对方的身份；Type 值为4时，代表 MD5-Challenge，类似于 PPP CHAP 协议，包含质询消息。

Identifier：用于匹配 Request 消息和 Response 消息。
Length：EAP 包的长度，包含 Code、Identifier、Length 和 Data 域，单位为字节。
Data：EAP 包的内容，由 Code 类型决定。

EAP 属性的封装

RADIUS 为支持 EAP 认证增加了两个属性：EAP-Message（EAP 消息）和 Message-Authenticator（消息认证码）。

1. EAP-Message
   这个属性用来封装 EAP 数据包，类型代码为79，String 域最长253字节，如果 EAP 数据包长度大于253字节，可以对其进行分片，依次封装在多个 EAP-Message 属性中。

1. Message-Authenticator
   如图 7所示，这个属性用于在使用 EAP、CHAP 等认证方法的过程中，避免接入请求包被窃听。在含有 EAP-Message 属性的数据包中，必须同时也包含 Message-Authenticator，否则该数据包会被认为无效而被丢弃。

各类型 EAPOL 结构

EAPOL-Start

交换机请求用户名（或维持链路请求包，1包/15秒）

响应请求用户名

交换机请求密码

响应请求密码

Success

Failure

响应维持链路包

校园网认证的研究现状

清华的802.1x 校园网认证

802.1x 校园网认证年初，清华大学做了一个校园网运行与管理的相关报告，其中指出该校想采取802.1x 接入，但是选择何种具体实现方式需要考虑。如使用触发方式，但流量不易通过，启动过程比较慢。使用不加修改的阀门端，也正是我上章节所说的，只要搞定了 RADIUS 自动地帮你处理后续事情，也就是阀门端只起到代理传递的作用，没有做安全管理。

北大的802.1x 校园网认证

该校也在2008年初的校园网认证论坛提出基于 IP 控制网关的认证，基于透明网关的思路，北京大学自行开发了千兆的控制网关，简称工作在千兆网络中，年在北大部署，后在中国农业大学和北京地质大学等十多所高校实际运行。虽然该通过软件实现，适应于通用开放平台，但是我在年末在北大登陆账号时，听同学说过有客户端，但也可以通过网页登陆，想必现在的认证方式更加复杂和多元了。

802.1x 系统是两者相结合的，同时运行在校园网内，主要框架结构为下：

两者结合的目的在于用户只需”一次认证”就能够进行802.1x 认证，完成校内资源和校外资源的透明过渡，用户察觉不到内网和外网的分别。

iNode 校园网认证

上述各类认证在吐槽和破解的程度上都不如 iNode，大家搜搜 iNode，就看到百度贴吧里面的题目是有多么恨这个软件了，还有的发了邮件到工信部投诉区投诉去了。也可以认为 iNode 几乎在东南方高校市场很常见，当然了西安电子科大，财经院校也用这个，很多院校都采用 iNode 客户端。想必是这个软件引起了很多同学的不舒服，难怪激起了那么多人的逆向工作，此消彼长的升级和破解对抗，促成了如今的局面。

iNode 智能客户端是一款强大的 windows 多业务接入客户端软件。该软件为用户提供802.1xPortal 等多种认证方式，可以与以太网交换机、路由器、网关等网络设备共同组网，实现对宽带接入、接入和无线接入的用户认证，从而大幅度提高网络的整体安全。

iNode 协议逆向实践

iNode 逆向工作研究现状各校应该联合最广大的程序员阶级，对本校的校园网客户端作出研究分析，同时向他们和它们致敬，他们是攻击者，它们是防御者，没有了对手何来斗争的快乐。现最为著名者，为南京工程学院802.1x 项目，该项目目的为逆向分析 iNode 客户端认证过程，重新编写相关程序，往好了说就是写一个替代品程序，以便实现计算机的其他功能，如双网卡或开等。往坏了说就是做了一个程序欺骗认证服务器。网址参见资料项目引用了 sourceforgegithub 项目分支，其中下图我截屏了 github 上的代码分支，显示了部分人员的参与代码修改工作，大约几十人参与到其中。

iNode 协议的实际过程

在实际情况中，首先我们打开计算机，接通电缆，然后打开 iNode 运行客户端，通过认证之后，服务器授权，最后我们可以连接互联网。此时我们再次把前面的那幅图搬过来，放在了本段落的上面，因为这很重要。根据上面这幅图，虽然为802.1x 的标准体系，华为 iNode 认证过程也遵循着主要流程，但是在具体处理和报文细节上有所不同，有它独特的地方。
抓包分析，对应上面红色区域的包情形如下图所示。

上图红色区域的编号为恰好对应着802.1x 体系的基本流程。那么我们针对这几个流程包作深入分析。我们将此划分为三个部分，第一个部分是55start64success 部分，第二个是56request57response 部分，第三个是编号部分。

StartSuccess 数据包部分

该两个数据包标志着认证开始和结束。这里是本机用广播方式呼叫边缘路由器，即呼叫阀门端，当阀门端听见后，随即响应本机。广播方式的开始包内容如下：

结束成功标志包内容如下：

对照一下上图可以看到，例如 success
START 包，观察红色方框围住的区域，是以太网封装 EAPOL 的类型，后面紧接着的是版本号，再后面的，指的是发起帧，最后两个是长度字段域，指明后面还有没有负载。既然长度字段域为，则表明后面负载没有东西。

success 包，红色框围住的部分前面内容是01 00 00 04就是标志着后面封装内容有个字节。那么红色框围住的部分就是封装的f0 de f1和后面三个字节被红色抹除的六个字节为本机0c da 41及其后面三个字节被红色抹除的六个字节为阀门端的03 02 00 04包的内容。域为成功，编号，最后标志着包长度为个字节。说明整个认证过程内的数据包认为是的数据流，以便同者进行统一处理。而包后还有填充零，可以参看文献资料，以太网协议标准规定对于10Mbps 以太网的一帧最小发送时间必须为51.2us，被称为以太网时隙，转换为最小长度则为字节。因此若包长不足，则填充填充符补齐。

请求认证和认证响应

由于我们本机在呼叫阀门端，阀门端听到后，则阀门端响应本机，响应本机的内容就是阀门端的请求包，该请求包内容细节如下：

上图红色框围住部分是封装的数据包，封装含义可以看上图中含有。该请求帧的发出，标志着我们服务器开始让我们填写”申请表”，准备连接互联网。
我们填写好”申请表”后，则进行响应，这是最为关键和重要的一步。在这里华为作出了他自己的改动和变化，以太网的控制信息细节一般都不敢改动，因为企业设备如果具备良好的市场推广，首先要符合广大协议标准。而后封装的控制信息头也不敢改动，所以改动的文章只能作在后面的有效载荷上，在有效载荷上使用解析重构，匹配是否符合自己的规则，达到认证目的。那么响应包细节如下：

上图蓝色围住的部分就是封装的包，其中控制信息头有02 01 00 32 01，标志着全体从头到尾有个字节的长度。而这个字节的长度包含了控制信息头个字节，剩下的个字节究竟封装了什么？上图看不清，我截了一个清晰的图。

红色框围住部分不清楚，蓝色围住部分也不清楚，黑色围住部分还是不清楚，就是最后个字符很清楚因为那是我的姓名全拼，该死的校园网宁愿对某些东西加密，居然连账户名都不愿加密，竟然明文传输？（当然说句公道话，上网密码还是加密了。）所以这个工作要交给软件逆向工程的童鞋去完成，发现这些字节的含义。当然了观察黑色框围住的编码模式，可以猜出是做了某些编码（黑色框围住部分最后出现的等号或许是一个特征），只不过通过软件逆向工程可以更加清晰和有效地发现编码模式，因为该编码模式与互联网上公开的编码模式还不太一样，是华为自己设计的一些加密模式。这部分内容会在 iNode 逆向分析章节，即小节详细论述，基本是前辈先驱的工作成果，小子只是当个传声筒。

MD5加密请求和响应

上面请求认证和认证响应的称谓不准确，实际上一小节的两个小包是版本查询包（所以上一小节的最后一张图黑色编码是对此类的加密），验证正确后，则进行本 MD5的请求和响应操作，主要验证的是上网密码是否正确。一旦密码正确，则可获得认证授权。

MD5援引百度百科，它是让大容量信息在用数字签名软件签署私人密匙前，被”压缩”成一种保密的格式（就是把一个任意长度的字节串变换成一定长的大整数）。不管是 MD2、MD4还是 MD5，它们都需要获得一个随机长度的信息并产生一个128位的信息摘要。虽然这些算法的结构或多或少有些相似，但 MD2的设计与 MD4和 MD5完全不同，那是因为 MD2是为8位机器做过设计优化的，而 MD4和 MD5却是面向32位的电脑。

MD5是一个安全的散列算法。通过输入两个不同的明文，经过 MD5算法处理后，不会得到相同的输出值，并且输出值不能返回头得到原始的明文，即其过程不可逆；所以要解密 MD5没有现成的算法，只能用穷举法，把可能出现的明文，用 MD5算法散列之后，把得到的散列值和原始的数据形成一个一对一的映射表，通过比在表中比破解密码的 MD5算法散列值，通过匹配从映射表中找出破解密码所对应的原始明文。这是目前的穷举法。

下图为阀门端向本机的请求 MD5验证的请求包。

为后续 iNode 的逆向分析做准备，首先我们要了解 MD5加密算法的原理，其原理过程为：

（1）算法输入：是一个字节串，即每8bit 的串。

（2）算法第一步：先对输入数据补位，使得数据长度对64字节求余结果是56个字节。补位方法是先补一个置位为1的单比特内容，然后继续填充置位为0的比特序列。

（3）算法第二步：在完成上述数据补位操作后满足第一步的数据求余标准，再对该数据附加一个额外序列，即还要在补一些东西。该额外序列的长度为64bit 长。

小结：经过第一步和第二步，我们可以发现最终的数据长度可以被表达为：

数据长度 = (N 64Bytes) + 56Bytes + 8Bytes = (N + 1) 64Bytes

即长度最终是64字节的整数倍，这样做的原因时满足后续处理的需要和要求。

（4）算法第三步：定义算法的四个条件变量，分别为 A，B，C，D 四个字变量。其中四个变量为：

A = 0x01234567 B = 0x89abcedf C = 0xfedcba98 D = 0x76543210

看到这里是不是有一些 iNode（或称华为公司）在版本号上处理的影子？也是正反双序的初始化。

部分文章提醒注意这里的变量是低位在前，高位在后。故在写程序的时候不是上面这样的写法。

（5）算法第四步：定义算法的四个转换函数，分别为 F 函数，G 函数，H 函数，I 函数，XYZ 分别为三个4字节整数。下面是四个非线性的转换函数，可能是造成不可逆的重要原因。

（6）算法第五步：主要是做变换。我们输入的数据通过我们补齐成为(N+1)64Bytes 长度，所以一定是64个字节的倍数。我们将补齐后的数据以64字节为单位划分为组，肯定有 N+1组。每组做一次循环，每次循环做四轮操作。我们先讨论第一组，因为后面第二组，直到 N+1组处理方式是一样的。

第一组64字节内容，分成16个4字节的数组 M[0]到 M[15]表示，每个 M 单元存储4个字节，即存着输入后被补齐的数据的第一组32bit 内容。然后定义常数 T，如何取常数，算法定义为 T[i]=2^32 * abs(sin(i))，其中前面是2的32次方，后面是正弦函数的取值，i 是弧度，取值从1到64选择。最后的 T[i]取32bit 长度的整数部分，去掉小数。定义变换算子如下：

以第一组的16个4字节 M 组为例，做第一轮变换，变换步骤如下：

第二轮变换步骤如下：

第三轮变换步骤如下：

第四轮变换步骤如下：

最后做合并操作如下：

在以第一组得到了 AA，BB，CC，DD 内容（请注意 AA 不是指 A 与 A 连接，它只是个变量名称而已），以 DD’CC’BB’AA 的顺序连接起来，输出的则为第一组的结果内容，显然长度为32bit×4=128bit。以上部分递归细节由于网络上有些不清楚，我自己重新写了一些，细节上可能不同，但是意思本质是一样的。

版本查询包的解密工作

上节已提及，版本查询包黑色方框围住的部分，产生了如下的编码和我的上网帐户名：
bGBeTUpXN3cuTEgycQV5foKo5pw=’\space\space’t*sy*
观察等号猜测可能为 base64编码，具体如何编码可能与公开标准不同，这里 thorqqAGanNo2做了大量的反编译工作，没有他们在反编译层次的观察和解析，是不可能分析加密编码的，并且两位先驱在不同版本号的情形下做了大量工作，bitdust 则他们的工作后发现了版本下的版本号加密密钥。
观察等号猜测可能为 base64编码，具体如何编码可能与公开标准不同，这里 thorqq 和 AGanNo2做了大量的反编译工作，没有他们在反编译层次的观察和解析，是不可能分析加密编码的，并且两位先驱在不同版本号的情形下做了大量工作，bitdust 则他们的工作后发现了 v5版本下的版本号加密密钥。

有前辈做了反编译工作，分析了两类数据包的大概结构，一个是 response 的版本号加密，还有一个是心跳包在线检测结构。心跳包为检测用户是否在线，时不时来一个包探测一下，PC 再答复以表明在线。

下面为 response 版本号查询包结构

1
2
3
4
5
6
7
8
9

typedef struct UsernameFrm
{
PKTHDR Hdr;
u_char8 Unknown1[2]; //0x15,0x04
u_char8 Ip[4];
u_char8 Unknown2[2]; //0x06,0x07
u_char8 Base64[30];
u_char8 Username[20];//假定用户名不会超过
}USERNAMEFRM, *PUSERNAMEFRM;

对照下面的 response 查询包内部细节图

由前辈的反编译工作可知红色框围住的部分为15 04 0a 68 7e 3c，其中15 04是固定字段，说明是华为自定义设计的，该指令污点执行也没能获得其语义。0a 68 7e 3c则是 ip 地址，也就是我们打开 iNode 运行连接，通过验证之后，iNode 提示你的：您当前地址是多少多少。如果是0a 68 7e 3c 则表明当时抓包 ip 地址为局域网10.104.126.60。于是陷入了一个新的问题，也和 bitdust 讨论了，ip 怎么会在接入认证就已经有了的问题，果然是我没有学好计算机网络知识，通过请教 M 老师，DHCP 进程自设备启动便可以启动服务，如果要抓这个 DHCP，时机和骨干节点镜像很重要。

蓝色方框围住的部分为06 07，根据结构体可知为固定字节，语义则也未知，猜测有两种情况，一是反编译得到了结果，但是前辈不敢发，否则侵权，界限很微妙，不允许提供反编译细节，可以提供作明显公开工具可以获得的信息，二是反编译没有得到语义信息结果。随后有30字节的 base64编码，20字节的账户名字。先来吐槽一下30字节的 base64编码，抓了几次包，发现都是28字节，然后两个空格补齐凑成30字节。看来还是要学习反编译的研究成果。再吐槽一下账户名20个字节一般是够用，他算准了双字复姓的每个字拼音也不会超过5个字母，不过在脑洞大开的时候，取个”仲长霜庄”这名字不行吗？拼音超过20字节了(=。=)(←_←) 查询一下12306的真实姓名填充，使用国内字符标准，以字符集表达姓名，12306提供20字节应该对于中国人是够了，20个汉字的中国名字毕竟是少之又少，但没有考虑到国外友人英文名字的感受[5]，那这就是你12306的字符边界不足了。既然被加密的部分是 base64编码，则重点放在 base64编码的解析上。

Base64

上节已指出由 AGanNo2等众多前辈反编译工作，发现了 base64编码，有必要涉及到 base64编码的基础引入。

首先什么是 base64编码，为什么要用这个编码？在七角 WB 老师的课程上曾经讲到过 Base64的编码知识，该编码使用64个明文来编码任意的二进制文件。在链路层或物理层等比特流透明传输特点下，部分二进制流内的填充序列因与控制信息命令内容重复，可能会导致解包冲突，因此此类协议要么使用透明传输方法，即硬件上只要发现5个连续1，则立即填入一个0。或在软件上控制信息使用独立编码，并在有效载荷上作转义字符处理。早期的问题已经不是现在的问题，base64编码可以认为是历史的产物。早期处理透明传输的方式就有 base64编码，既能够实现加密处理，当然了防君子不防小人，只是看不出内容，base64编码仍是可解的；又能够在早期 Email 处理问题上解决传输及效率问题，早期 Email 允许传送 ASCII 字符，但只是低七位，如果带有非 ASCII 字符，很有可能被网关强制置最高为0，导致解包产生问题。

综上所述正是如此，才引入了 base64编码加密，既能够很好保护邮件内容，又能够处理好控制信息与邮件内容不被设备的误处理。其主要原理为将每三个8bit 字节转换为四个6bit 字节，最后添加两位高位0补齐成为四个8bit 字节内容。举个例子：

1
2
3
4
5

转换前：aaaaaabb ccccdddd eeffffff 
转换后：00aaaaaa 00bbcccc 00ddddee 00ffffff
转换前的三个字节是原文，下面四个字节是转换后的内容。这里的 abcdef 请看成未知数，看成比特值，不是字符的意思。下面就做一个真实的表达（援引百度百科例子）：
转换前：10101101 10111010 01110110
转换后：00101011 00011011 00101001 00110110 （r b q 2）

请注意转换前的原文内容不一定是字符，可以是二进制文件，反复讲明的。Base64编码有自己的一套码表，转换后独立编码即可，根据独立编码可知转换后为的字符时 rbq2。独立编码表如下：

当每三个字节补成四个字节，肯定是每三个去数，若三个一组不够的时候，余数肯定剩下一个或两个字节，如何处理？如果剩下一个字节，则为8bit，一般补上4个0即可，凑成了两个6bit。如果剩下两个字节，则为16bit，一般补上2个0即可，凑成了三个6bit。为表明是补齐的0，前者在翻译完独立码表后补上两个等号”=”，后者在翻译完独立码表后补上一个等号”=”表明自身的特殊情况。所以等号”=”一度成为 base64的招牌动作。

最后介绍 iNode 使用哪些要素参数来进行 base64编码加密，iNode Base64编码过程如下图所示：

iNodebase64编码使用了几个要素（根据前人反编译工作得出，一开始时是不知道的）：
（1）随机数
（2）版本号
运算是异或逻辑运算。而异或运算的细节如下图所示：

那么认证服务器是怎么解码的呢？如下图所示进行解码：

首先要感谢 A，T，刘群等几位前辈的反汇编工作才能得到这样的解密过程。然后要声明随机数由程序生成，我们实际使用的版本号肯定也不会是 V2.40，因为每一个学校使用的客户端版本都可能不太一样，至少我们使用的 iNode 客户端是定制版的，连某某序号都要认证，看来是完整版，因为很多地方不需要某某序号认证。在我们软件版本号未知下，bitdust 率先开辟地解出我校版本号密文，在他的指导下那么根据我自己的抓包结果，或许可以试试，我们既然已经获得我们的 base64编码，则为 bGBeTUpXN3cuTEgycQV5foKo5pw=，那么我们先做解码工作，看看版本号是多少，考虑该版本号已在网络上公开且流传很广，只是我们不知道恰恰是这个版本号成为了我们的使用版本，其中部分其他研究者都已经出具软件产品，甚至 iNode 的最新版已经高出我们使用版本很多了版次了，故可以公开讨论。下面我仅作解码工作，以验证和挖掘真正的固定密钥是什么，我使用的是 python 编程语言验证。

在 bitdust 的多次建议下使用 python 做一下解码工作，正好加强 python 的学习。通过 import base64的 python 模块得到了初步解码的序列，如下图所示（没截取完整，保证十六进制序列是完整的）：

我们可以通过两个方面简单验证一下：

（1）头三个\x6c \x60 \x5e 的二进制序列如下：

01101100``01100000``01011110

转换为 base64的头4个字节内容为：

00011011``00000110``00000001``00011110

翻译成 base64独立码表字符为 b G B e

（2）按照每三个字节数，剩下0xe6，0x9c，故补齐一个等号即可。

然后进行与公共密钥”HuaWei3COM1X”异或（此处正式声明 HuaWei3COM1X 密钥适用版本2.4，而非其他版本密钥，这里我使用的是符合我实际情况的版本号密钥，此密钥如何得来，也是反编译工作所得，本文考虑到某些因素，确实不便公开，网上实际上是有的，大神 bitdust 在其 github 源代码中给出了具体密钥，若想要可进入 github。其他论坛中可以通过百度关键词搜索得到，本文也没有必要提供。），根据实际密钥做三次异或得到下面序列，如下图所示第[4]个输出，最后使用竖线隔开的最后四个字节是随机数。

根据解密过程可知最后四个字节是生成的随机数，即0xce 0x 某某 0xce 0x 某某。

为了验证正确性，只要做最后一步，与随机数作异或就可以得到版本号字符串了。首先提取出随机数，然后注意随机数转成字符，此时的转化与一般意义不同，具体细节可自行体会，编程过程中我绕了一个小时在这里，最后想明白了。

待转随机数是十六进制序列，但是需要将十六进制下的表达符号一模一样地转化为字符，我的 python 编程方式是设置了字典，将0到 f 的十六进制一一对应转化。观察了大神的写法以后，python 一句话格式化操作解决，佩服佩服！最后做完异或就得到了符合我实际使用的版本号，如下图所示。

上述图片做了一些处理，若想知道全部版本号请参看 github 代码托管网站，liuqun 及 bitdust 的分支，本博文因某些问题，不予提供，本文通过编写 python 脚本，验证版本号为 CH V5.20-0407。通过查看软件帮助可知，恰好为版本号。（当然在逆向破解之前，不知道这个是版本查询包，直到破解出这个序列才明白原来 response 是为了加密版本号，以便查询之用。我在前面一节就引用了这个术语，是不妥的，有些误导，有些先入为主。）

4.3.3MD5验证的解密工作

若版本号查询包的交互状态结果，后面是进行 MD5的验证工作，里面有什么参数，在一开始逆向分析时不清楚的。根据802.1x 认证体系（不是实际情况，这里介绍一般情形），接下来出现的 MD5过程主要是：

认证服务器收到交换机转发上来的用户名信息后，将该信息与数据库中的用户名表相比对，找到该用户名对应的口令信息，认证服务器使用随机生成的加密字段对口令进行加密处理，返回 MD5密文。

我们的客户端收到后，使用加密字对口令部分进行 MD5加密，响应认证服务器。服务器收到我们客户端的响应后，将送上来的加密后口令和服务器自己经过加密运算后的口令信息相比较，判断用户是否合法，回应认证成功或失败报文到接入设备。

可以看到 MD5加密使用的参数大致有：

（1）口令信息（注：这里的口令不仅有上网账户名，也有上网密码）

（2）随机数

MD5先由认证服务器及阀门端发起请求 request，然后我们个人客户端发起响应，过程如下图所示。

然后我们查看服务器那边过来的请求包具体内容，如下图：

根据网上802.1x 体系说明，按照一般情形是需要 MD5加密，并携带加密密钥，以便对比。而实际情形援引前辈的文章总结，EAP-MD5是一种单向认证机制，即认证过程没有加密密钥的生成，则 request 数据包既是要求我们认证密码，并且里面的 challenge 字段是接头的暗号，我们使用上网和密码和 challenge 一起做 MD5后响应即可。

还有一张图是我们客户端响应服务器的数据包，由下图可见，我的上网账户名是明文传输，附在了密文后面，说明上网密码是被 MD5加密了。

在具体的逆向工作上，此时较为幸运，因为我们没有必要去破解 MD5密钥，（因为我们没有必要偷别人的上网账号和密码），我们只要自己正常自制 MD5包，完成与服务器的认证即可，这样替代品客户端既完成了上网连接的任务，又避免了占用大量内存和不能开 wifi 的问题（iNode 原客户端占用内存较大，根据各位前辈写的替代品软件一般大小就只有1兆左右，而且还可以开 wifi）。

所以我们验证 iNode 的 MD5过程是否可以有效复制，只需要把 challenge 的字段和我的上网密码做一下 MD5，看得到的是不是这个 MD5的 response 数据包里数值即可。下面是两串密文：

request EAP-MD5 Value: 754865596e324163060723c8640a3b23

response EAP-MD5 Value: 7795dd505a42740888e45866f438c8d4

验证过程则应该将上行密文与上网密码结合，通过 MD5则可得到下行密文，若成功得到，则说明可以成功复制数据包。通过 Python 编程，可以实现 HASH 库调用，支持 MD5加密操作。通过提取 request 数据包内 value，然后将我的上网密码在前，value 在后连在一起做 md5，生成了7795开头的加密序列，对照 response 数据包，发现加密密文是一致的，说明该数据包可以仿制。如下图所示。

由上图可知，数据包 MD5验证成功，所以 iNode 的逆向编写工作接近尾声，可以开始逆写了。还有最后一个”鸡肋”的部分，就是心跳包部分。

4.3.3心跳包的协议分析

心跳包主要为检测用户是否在线，在2.1.3节或4.2节的经典流程图中的蓝色线框围住的部分，可以观察到心跳包实际上就是一个出出声，讲讲话，透透气的过程。为什么说鸡肋，在于认证服务器可能不管你出的什么声，不管你讲的什么话，没有管你透的什么气。只要是一句话，是一口气，就认为你是在线的。也就是说心跳包的制作可以随便填充什么序列，不管协议机制都可能通过验证。没有验证某某编号的时候，要么一开始就上不了线，要么上线后一直提示验证某某编号。后者现象证明心跳包即使没有验证某某编号也不会踢你下线。即只要通过两道 Base64和 MD5验证，就基本具备上网资格认定。

当然，心跳包若认真的做认证，还是非常重要的一环节，就看各高校对校园网的认证程度有怎样的政策和态度了。如下图为一个心跳包，当然了服务器向个人 PC 发过来请求心跳包检测的请求报文我就没有截图了，那个包和 success 包很像。重点说一下我们 iNode 客户端如何回复心跳包请求的，即我们是如何发心跳包的。实际上还是做了一个 base64编码，只不过有了新的密钥做成，还是相当于验证了一个版本号，没有难度。至于如何验证某某编号的，大家抓一下包就知道了，是否融入到心跳包中也可以做一个简单验证，这里限于已经到了近30页（太长则无法上传博客）的篇幅，就不给编程结果了。

引用文献及网页

1.本文修改至 iNode 协议逆向研究初步入门 by tsy(http://www.cnblogs.com/bitpeach/p/4092806.html),作者为 Bitpeach

2.802.1x 协议解析，作者未知，猜测为 thorqq 前辈
华为802.1x 技术白皮书或参看 H3C 802.1x 技术介绍的官方主页
http://www.h3c.com.cn/Products___Technology/Technology/Security_Encrypt/Other_technology/Technology_recommend/200812/624138_30003_0.htm

3.南京工程学院802.1x 客户端
http://wiki.ubuntu.org.cn/%E5%8D%97%E4%BA%AC%E5%B7%A5%E7%A8%8B%E5%AD%A6%E9%99%A2802.1X%E5%AE%A2%E6%88%B7%E7%AB%AF# .E5.BC.80.E5.8F.91.E5.9B.A2.E9.98.9F

4.CSDN 博客，为什么以太网帧的长度最短64字节，最长1518字节。
http://blog.csdn.net/rainertop/article/details/3020315

5.老外12306网站购票遇麻烦：名字超20个字符不能有空格
http://www.yongshenme.com/zixun/0310/756.html

6.使用 xClient 代替 iNode 突破网卡限制自由分享 Wi-Fi – 王谦 I just play 主页
http://www.ijustplay.cn/xclient/

7.工具及文档
链接: http://pan.baidu.com/s/1bnwdztH 密码: qpuk