给定一本英语单词词典，请找出所有的变位词集。
所谓的变位词是指，组成各个单词的字母完全相同，只是字母排列的顺序不同。
首先应该对每个单词进行编码，使互为变位词的单词获得相同编码。所以将单词内部进行排序，排序出来完全相同的单词自然便互为变位词。当然还需要保留原有的单词，所以用一个结构体来保存编码前和编码后的两个字符串。
|
|
为了使互为变位词的单词可以被输出，最好的办法就是将他们聚拢在一起，然后到时输出时只需要在编码相同的情况下平移一段距离便可。所以将这些结构体按照上述编码后的字符串进行排序，最后得到的序列中，互为变位词的单词会被聚拢在一起。
最后只需要遍历一次编码、排序后的结构体，在有重复编码时将原始字符串输出，没有便略过。
|
|
本文仅适用韶关学院Drcom客户端。
因为自己需要经常用到Linux的缘故，所以打算把Linux上的网络问题搞定。学校使用的是Drcom认证客户端，在学校MIS系统上也提供了对应的Linux版本。可惜的是把一切依赖都弄好终于能运行后却总是秒断。这个程序并没有提供源码，我也无法获知是什么问题，所以打算干脆自己写一个，也就刚好分析一下Drcom的协议。
简单的实验可以发现，在没有登陆内网前，机器并不能Ping通网关，也就是说认证的方式应该是通过广播的方式来进行的。通过Wireshark抓包可以得到几个重要的包：
|
|
协议的类型为0x888e，也即EAP，可扩展身份验证协议，是802.1x认证机制的核心。而EAPOL则是基于局域网的EAP。当我们的机器开始登录时，首先会向广播地址发出一个Start包，同在一个局域网的网关便会收到这个Start包并回复：
|
|
这个包即是向客户端请求一个Identity，也即身份信息。客户端收到这个request后，就应该向网关回应一个Identity：
|
|
这个包已经开始包含学号和IP地址，当网关收到这个Identity后，网关开始请求一个MD5-Challenge：
|
|
这个包中包含了一串Challenge值(19 54 6c 79 c0 a8 7f 81 c0 a8 7f 81 00 00 00 00)。客户端收到这个值后，将其与密码做MD5运算，则可得到Challenged-Password。$$
C = md5(Id+Challenge+Password)
$$在Drcom中Id固定为0。
得到这串Challenged-Password后，客户端将其与学号一同发给网关
|
|
网关收到这串Challenged-Password后进行验证，如果加密后的密码无误，则原密码也无误，就会发出一个Success包：
|
|
整个认证握手过程到这里就结束了。此时使用PPPoE进行连接，发现已经可以连接到外网，也就表示认证已经成功。
Go语言中可以使用第三方包gopacket对数据包进行捕获和发送。但原版的gopacket在这个情景下使用会有些许问题，所以做了少许修改，并在文末附件给出。
|
|
首选封装两个函数分别用来发送EAPOL包和EAP包，gopacket的用法请参考GoDoc。
readNewPacket将从认证一开始就以一个协程运行，直至程序终止。在程序main函数中，有如下语句：123456789handle, err = pcap.OpenLive(devName, 1024, false, 5*time.Second)defer handle.Close()if err != nil { fmt.Print(err) os.Exit(0)}packetSrc := gopacket.NewPacketSource(handle, handle.LinkType())go readNewPacket(packetSrc)
readNewPacket()会根据Code和Type分别进行处理。
|
|
|
|
按照前文所说的认证方法分别对各种回应包进行构造，然后调用EAPAuth()函数即可。readNewPacket()函数将收到来自网关的request，并交由不同的response函数处理。
至此，可以构造出一个可用的认证程序，使用系统自带的PPPoE拨号程序即可。
使用这种认证方式虽然可以成功拨上号，但会发现隔一段时间就会自己掉线。通过Wireshark查看，发现网关主动发送了Failure包，也就是说网关注销了我们的账户。这种情况可以联想到使用官方客户端经常碰到的一个错误：
获取用户属性超时！请检查防火墙配置允许 UDP 61440 端口。
当客户端出现这个错误时，一般也可以上网，但一段时间后就会发现已经断开。所以我们重新打开校方提供的客户端，通过内网认证，并用wireshark筛选出UDP协议，端口为61440的所有数据包。
通过仔细查看会发现，客户端每隔一段时间会向一个服务器192.168.127.129:61440发送UDP报文，而服务器也会做出响应。也就是说，客户端应该是通过定时发送数据包来保持自己的在线状态，也就是所谓的心跳包。
（以下出现的数据仅为UDP数据部分，而非完整的数据包）
当客户端与网关完成认证流程后，客户端便开始向服务器192.168.127.129:61440发送报文：10000 07 00 08 00 01 00 00 00 ........
一共只有八个字节，这部分是固定的，大部分Drcom心跳包都以07开头，其他部分含义未知。
然后服务器方面会回应一个报文：120000 07 00 10 00 02 00 00 00 01 72 96 00 c0 a8 c3 5f .........r....._0010 a8 ac 00 00 4f e4 16 c1 00 00 00 00 dc 02 00 00 ....O...........
具体含义我们暂且不管。收到这样的数据包后，客户端即发送一个数据包，包含用户的若干信息：123456789101112131415160000 07 01 f4 00 03 0b 28 d2 44 2d 90 69 c0 a8 c3 5f ......(.D-.i..._0010 02 22 00 24 01 72 96 00 4a 6a 72 32 00 00 00 00 .".$.r..Jjr2....0020 31 34 31 31 35 30 36 31 30 32 34 6c 7a 79 2d 70 14115061024lzy-p0030 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c...............0040 00 00 00 00 00 00 00 00 00 00 00 df 05 05 05 00 ................0050 00 00 00 df 06 06 06 00 00 00 00 00 00 00 00 94 ................0060 00 00 00 06 00 00 00 02 00 00 00 f0 23 00 00 02 ............#...0070 00 00 00 44 72 43 4f 4d 05 b8 01 04 00 00 00 00 ...DrCOM........0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00b0 00 00 00 33 39 31 35 31 35 66 64 33 33 39 66 36 ...391515fd339f600c0 32 62 35 33 30 63 64 36 33 61 30 32 37 63 64 34 2b530cd63a027cd400d0 65 66 39 35 31 33 39 30 36 39 66 00 00 00 00 00 ef95139069f.....00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00f0 00 00 00 00 ....
具体分析如下12345678910111213141507 //固定头01 //计数器，这里固定为0100 f4 //报文长度，这个长度是不定的，原因是用户名不定长03 //未知0b //用户名长度28 d2 44 2d 90 69 //本机MACc0 a8 c3 5f //本机IP02 22 00 24 //这个是固定值01 72 96 00 //这个来源于第一个回应包的第8到第11个字节4a 6a 72 32 //校验值，具体方法下面会讲到31 34 31 31 35 30 36 31 30 32 34 //用户名6c 7a 79 2d 70 63 //主机名df 05 05 05 //DNS-1df 06 06 06 //DNS-2...
判断字段固不固定的主要方法还是多次登录，多账号登录，然后判断哪些部分是一致的，哪些部分每次都不同。该数据包有四个字节4a 6a 72 32每次捕获到的都不一样，也猜不出是什么含义，故使用反汇编工具IDA Pro进行逆向工程，文件为DrAuthSvr.dll。
首先找到一个开口：输入表里面的sendto函数。每次发送报文肯定都需要经过sendto函数，然后再通过交叉参考，最后找到发送数据的函数。我将其命名为send_udp_packet(char *buf,int len)。123456int __cdecl send_udp_packet(char *buf, int len){ ... if ( sendto(dword_1057E9C4, buf, len, 0, &to, 16) < 0 ) ...}
再次通过交叉参考，可以得知所有调用该函数的语句。其中有几个调用处写着:1send_udp_packet(buf, *(unsigned __int16 *)&buf[2])
这与该数据包正好吻合（长度为buf[2]）。该数据包还有一个特征点即是buf[4]为3，最终可以确定发送这个包的函数。我们需要找的四个字节是[24:28]，函数比较靠前的位置有：12*(_DWORD *)&buf[24] = 20000711;*(_DWORD *)&buf[28] = 126;
也即是说函数直接对buf[24:32]的进行赋值。在比较靠后的位置还发现了：123456789v4 = 4 * ((*(unsigned __int16 *)&buf[2] + 3) / 4);*(_WORD *)&buf[2] = v4;v5 = (unsigned int)v4 >> 2;v6 = 0;for ( i = 0; i < (signed int)v5; ++i ) v6 ^= *(_DWORD *)&buf[4 * i];*(_DWORD *)&buf[24] = 19680126 * v6;*(_DWORD *)&buf[28] = 0;dword_1057F5BC = 19680126 * v6;
也就是说变量v5为长度的1/4，然后做下面的运算，最后把19680126*v6回填到buf[24:28]中，并将buf[28]置零。需要注意的是这里采用的都是小端法。最后还将计算的值保存起来，后面会用到。Go语言实现如下：123456789101112131415/* 信息包校验码计算 */func putCode1(buf []byte) { v5 := len(buf) >> 2 var v6 uint32 var tmp uint32 var b_tmp *bytes.Buffer for i := 0; i < v5; i++ { b_tmp = bytes.NewBuffer(buf[4*i : 4*i+4]) binary.Read(b_tmp, binary.LittleEndian, &tmp) v6 ^= tmp } binary.LittleEndian.PutUint32(buf[24:28], v6*19680126) fmt.Println(v6 * 19680126) binary.LittleEndian.PutUint32(globalCheck[:], v6*19680126)}
将这个二百余个字节的信息包发送出去后，服务器会发出第二个响应包。1230000 07 01 30 00 04 0b 20 00 92 9a 9c 8c 01 00 00 00 ..0... .........0010 44 39 d8 ed 0c 45 fd 03 af 85 30 15 3c fa 04 68 D9...E....0.<..h0020 b0 82 00 60 00 00 00 00 00 00 00 00 00 00 00 00 ...`............
按照捕获到的数据包，客户端开始每隔一定时间发送两种不同的心跳包。
第一种心跳包有40个字节，正常情况下每次都会接连出现四个包。
|
|
这四个数据包中，第1个和第3个为客户端发送，第2个和第4个则为服务器端响应。以最复杂的Ping-3作为例子进行分析：
|
|
跟上面分析方法相同，可以发现37 87 84 02基本没什么规律，应该也是一种校验值。继续使用IDA Pro进行静态分析，可以找到一个函数带有语句buf[2]=40，即是我们要找的发包函数。手动将buf类型改为char[40]后，可以找到这样一个代码片段：1234567891011121314if ( buf[5] == 3 ){ v5 = 0; v14 = 0; v6 = 0; do { v7 = *(_WORD *)&buf[2 * v6++]; v5 ^= v7; } while ( v6 < 20 ); v8 = (unsigned int)(dword_10077544 + 1) < 3; v9 = dword_10077544 == 2; *(_DWORD *)&buf[24] = 711 * v5;
Go语言实现如下：1234567891011/* 40字节心跳包校验码计算 */func putCode2(buf []byte) { var tmp, v5 uint16 var b_tmp *bytes.Buffer for i := 0; i < 20; i++ { b_tmp = bytes.NewBuffer(buf[2*i : 2*i+2]) binary.Read(b_tmp, binary.LittleEndian, &tmp) v5 ^= tmp } binary.LittleEndian.PutUint32(buf[24:28], uint32(v5)*711)}
第二种心跳包是38个字节，在第一种心跳包发出后大约10秒发出。1230000 ff 4a 6a 72 32 45 c7 d8 6d 18 38 24 c0 20 91 2b .Jjr2E..m.8$. .+0010 6c 00 00 00 44 72 63 6f c0 a8 7f 81 af 0b c0 a8 l...Drco........0020 c3 5f 01 34 33 9b ._.43.
对这个数据包做分析：123456789ff //固定头4a 6a 72 32 //发送信息包时的校验值45 c7 d8 6d 18 38 24 c0 20 91 2b 6c //Challenged-Password的后12位44 72 63 6f //字符串Drcoc0 a8 7f 81 //服务器IPaf 0b //下面会讲到c0 a8 c3 5f //客户端IP01 34 //下面会讲到3e 9b //取当前时间的最后两个字节
第1个字节开始往后16个字节，通过与早前的数据包做比对即可推出；而最后的36、37个字节，则是通过IDA Pro得知：123v0 = _time64(0);...*(_WORD *)&buf[36] = v0;
而服务器IP和客户端IP后面分别带的两个字节，却始终未能使用逆向工程分析出来，Github上的代码也只是与反汇编出来的代码一致，跟我拿到的数据并不相符，最后只能通过慢慢比对，寻找线索。
首先可以发现的是，第34个字节固定为01，然后比对其他历史数据包，最终在服务器第二次响应的数据包中，找到了每次登陆都不同的三个字节：1230000 07 01 30 00 04 0b 20 00 92 9a 9c 8c 01 00 00 00 ..0... .........0010 44 39 d8 ed 0c 45 fd 03 af 85 30 15 3c fa 04 68 D9...E....0.<..h0020 b0 82 00 60 00 00 00 00 00 00 00 00 00 00 00 00 ...`............
其中第24、25个字节af 85，第31个字节68每次登陆都会有所变化，而第24个字节总是与上述心跳包第28个字节相同，第25个字节和心跳包第29个字节则存在以下关系：
$$
H_{29}=\left\{
\begin{array}{rcl}
R_{25}{\scriptstyle<<}1&&{R_{25}<128}\\
(R_{25}{\scriptstyle<<}1)|1&&{R_{25}\geq128}
\end{array} \right.
$$
同理可以得知第30个字节总是与心跳包第35个字节存在以下关系：
$$
H_{35}=\left\{
\begin{array}{rcl}
R_{30} {\scriptstyle >>}1&&{R_{30}为偶数}\\
(R_{30} {\scriptstyle >>}1)|128&&{R_{30}为奇数}
\end{array} \right.
$$
|
|
用内置的net.DialUDP建立一个UDP对话到 192.168.127.129:61440，这里注意客户端的端口并不要求一定是61440，前面提到的那个关于UDP61440的错误，就是因为偶尔启动时61440端口由于各种原因被占用，其实只需要让系统自动分配一个端口即可。
然后启动一个协程，负责UDP回应的接受，对各种形式的回应做出处理。123456789101112131415161718192021222324252627/* 接收服务器的UDP回应 */func recvPing() { data := [4096]byte{} for { n, _, err := udpConn.ReadFromUDP(data[0:]) if err != nil { fmt.Println(err) } if n > 0 { if data[0] == 0x07 { //应答包 if data[2] == 0x10 && n == 32 { //第一次应答 sendPingInfo(data[8:12]) //发送用户信息包 } else if data[2] == 0x30 { //第二次应答 UknCode_1 = data[24] UknCode_2 = data[25] UknCode_3 = data[30] UknCode_3 = data[31] go pingCycle() //发送Ping-1 } else if data[2] == 0x28 { //Ping应答 if data[5] == 0x02 { //收到Ping-2 sendPing40(3) //发送Ping-3 } } } } }}
还有一个协程则负责两种心跳包的交替发送。这里注意发送心跳包是定时发送的，因为并不是每个心跳包都会收到回应，不能依赖于收到回应后再继续发送。12345678910/* 两种心跳包循环发送 */func pingCycle() { time.Sleep(1 * time.Second) for { sendPing40(1) time.Sleep(10 * time.Second) sendPing38() time.Sleep(5 * time.Second) }}
其他包的发送函数就只是简单的对数据进行封装，这里就不再一一给出。