始于一次兴起，想对学校的签到软件进行抓包试试，在一次英语课的签到上尝试了一下，偶然发现:

手势签到破解思路#

使用的签到方式是手势签到，以下是本次签到的手势

签到手势

然后使用手机抓包软件HttpCanary抓了一下响应发现，在没有完成签到的情况下，响应内容竟然有手势密码??!

以下是抓包的响应

1
HTTP/1.1 200
2
Date: Tue, 05 Nov 2024 02:43:42 GMT
3
Content-Type: application/json
4
Transfer-Encoding: chunked
27 collapsed lines
5
Connection: keep-alive
6
Vary: Origin
7
Vary: Access-Control-Request-Method
8
Vary: Access-Control-Request-Headers
9
Access-Control-Allow-Origin: *
10
Access-Control-Allow-Credentials: true
11
Access-Control-Allow-Methods: PUT, GET, POST, OPTIONS
12
Access-Control-Allow-Headers: DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization
13
Access-Control-Max-Age: 1728000
14

15
238
16
{
17
  "code": 0,
18
  "msg": null,
19
  "intercepted": true,
20
  "data": [
21
    {
22
      "calendarId": "1840326648611450882",
23
      "calendarName": "Mini project 2 - A child’s clutter awaits an adult’s return",
24
      "calendarOrder": 7,
25
      "businessList": [
26
        {
27
          "collegeId": "2263",
28
          "termId": "1832946583942795266",
29
          "calendarId": "1840326648611450882",
30
          "teachClassId": "1839557950615138356",
31
          "courseId": "1711200736744427521",
32
          "teachingArrangementId": "1839557950581583956",
33
          "type": "1",
34
          "businessId": "1853629118787575810",
35
          "attendanceType": 1,
36
          "insCountDown": 571,
37
          "attendanceCode": "1,2,3",
38
          "createTime": "2024-11-05 10:43:15",
39
          "isAnonymous": null
4 collapsed lines
40
        }
41
      ]
42
    }
43
  ]
44
}

可以看到attendanceCode的值为*1,2,3*，这样似乎不太明显，如果像下图这样编号一下呢:

编号图

是不是一下就清楚了，这个接口竟然在没有签完到的情况下将数据库的完整信息返回了，理论这个数据不应该返回出来

然后再来看一下签到的请求是怎样的

1
POST /se-tool-gateway/biz/attendance/studentAttendanceBiz/save HTTP/1.1
2
token: 66bad09b-edad-4e64-a80c-7c1c1db994c4
3
Referer: http://sep.study.neuedu.com/
4
Content-Type: application/json; charset=utf-8
9 collapsed lines
5
Content-Length: 186
6
Host: sep.study.neuedu.com
7
Connection: Keep-Alive
8
Accept-Encoding: gzip
9
User-Agent: okhttp/3.10.0
10

11
{
12
  "access_token": "66bad09b-edad-4e64-a80c-7c1c1db994c4",
13
  "termId": "1832946583942795266",
14
  "attendanceType": "1",
15
  "instanceId": "1853629118787575810",
16
  "collegeId": "2263",
17
  "attendanceCode": "1,2,3"
18
}

不出所料，attendanceCode的值被原样传递，甚至不需要更改，直接就可以发送签到的请求

那这样的话签到就简单了，只需要把获取的响应里面的字段拿出来直接放在请求里面理论上就可以实现签到了

扫码签到破解#

经过实操，以上的猜测没有问题，于是我有了一个想法，是不是扫码签到也是同样的原理，也就可以做到无须二维码即可签到

虽然是扫码签到，但是可以用二维码扫描软件看出，二维码本质只是在传递13位的随机数字，同样抓包可得attendanceCode字段，和前面一样，直接传递即可，其中需要把"attendanceType": "2"赋值为2

1
{
2
  "access_token": "d4b82353-17d2-449c-893e-e58f7c088c26",
3
  "termId": "1832946583942795266",
4
  "attendanceType": "2",
5
  "instanceId": "1854401114356383746",
6
  "collegeId": "2263",
7
  "attendanceCode": "1730958814553"
8
}

登录破解#

于是有了这些想法和猜测，接下来便是从登录到签到的请求全部扒干净即可

以下是登录的请求

1
POST /se-tool-gateway/data/user/systemUser/userLoginPost HTTP/1.1
2
token: ed8ff7ca-2aeb-43e3-b446-20e61f09fea7
3
Referer: http://sep.study.neuedu.com/
4
Content-Type: application/json; charset=utf-8
5
Content-Length: 87
6
Host: sep.study.neuedu.com
7
Connection: Keep-Alive
8
Accept-Encoding: gzip
9
User-Agent: okhttp/3.10.0
10

11
{
12
  "p": "YEhIr8eIyWw4mt7Ax61sTA\u003d\u003d",
13
  "collegeId": "2263",
14
  "loginCode": "24*********"
15
}

以及响应

1
HTTP/1.1 200
2
Date: Wed, 06 Nov 2024 01:59:12 GMT
3
Content-Type: application/json
37 collapsed lines
4
Transfer-Encoding: chunked
5
Connection: keep-alive
6
Vary: Origin
7
Vary: Access-Control-Request-Method
8
Vary: Access-Control-Request-Headers
9
Access-Control-Allow-Origin: *
10
Access-Control-Allow-Credentials: true
11
Access-Control-Allow-Methods: PUT, GET, POST, OPTIONS
12
Access-Control-Allow-Headers: DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization
13
Access-Control-Max-Age: 1728000
14

15
36e
16
{
17
  "createTime": "2024-09-10 10:28:31",
18
  "createUser": "oshwk1ab5f9e1bc7d4d838b55**********",
19
  "updateTime": "2024-11-05 19:41:28",
20
  "updateUser": "system",
21
  "userId": "2518290",
22
  "collegeId": "2263",
23
  "collegeDisplayName": "成都东软学院",
24
  "mobile": "17200********",
25
  "realName": "***",
26
  "roles": "4",
27
  "sysCode": "24*************",
28
  "departmentName": "计算机与软件学院",
29
  "majorName": "计算机类",
30
  "adminClassName": "计算机类***",
31
  "enrollmentYear": 2024,
32
  "email": "************",
33
  "password": "*****************",
34
  "state": 1,
35
  "sex": "男",
36
  "cardType": "0",
37
  "isTeaching": 1,
38
  "stuState": 1,
39
  "departmentId": "620",
40
  "majorId": "702",
41
  "adminClassId": "203*****4",
42
  "userName": "***********************",
43
  "accessToken": "d320bdf2-20aa-4f99-a63b-7*************",
44
  "coorperativeType": 1,
45
  "teachingType": 1,
46
  "roleList": [
47
    {
48
      "roleId": "4",
49
      "roleName": "学生",
50
      "roleCode": "STUDENT"
51
    }
52
  ]
53
}

然后拿到accessToken作为后续身份验证的依据，不过发现了一个问题，请求负载里面的password并不是我所输入的密码，既然没有响应那么就是在本地做了加密

如果要做登录页面的话那就要想办法把登录的加密手段给破解出来，否则使用的用户需要自己抓一次自己的密码加密后的密文，这并不优雅也提高了门槛

于是我尝试试试常用加密算法里面如何将TLgkg96~加密为Xp5R2yTnBP+nBTEIZhdJ+A\u003d\u003d，在各种在线网站上试了各种方法都未能复原这个密文，但是我有了一个思路便是这个加密似乎是需要一个key来进行加密的，这个key是在本地的一个字符串常量，所以我想法是在MT资源管理器里面搜字符串常量有没有结果，不过无功而返，难道要放弃这个功能吗？

几天后…这时我突然想到了一个软件：算法助手，于是我打开了虚拟机试一试

算法助手