前言

近日发现Engintime的那套软件更新了,转移到了 CodeCode,以前老版本记得分析过,就是个真demo,这回新版本看它的描述并不是demo,遂打算分析一番。

环境部署

我选择从 Engintime OS Lab 开始分析,实际上他一系列的几款区别并不大并且都没有加壳。
首先,祭出分析工具。
由于此软件是 32位软件,本文使用了动态分析工具 Ollydbg

寻找突破口

运行软件,寻找突破口,看到形如 登录失败:用户名或密码错误
这就是一个天然存在的突破口,只要目标软件没有使用一些奇怪的异步框架就能很快定位到关键点
0.png

OD 附加之,通过查找UNICODE字符串,定位之。
1.png

从上图中,可以得知以下内容

  1. 软件使用了 cpprestsdk 库
  2. 此处是 请求返回的结果处理
  3. 结果包应该是一个 状态码为 200 并且 body 部分是一个json
    其格式为 {"access_token":""}

为什么不尝试爆破?
一般来说,带网络验证的程序,其程序内部可能存在一些全局数据需要初始化 例如 版本号,标题,加解密key等,
如果简单的爆破可能导致这些数据不能被初始化而导致未知错误。

在本软件中,协议相对简单,从协议出发更为合理。

协议分析

此时祭出协议调试套装 Proxifier + Fiddler 4

为何要使用 Proxifier?
cpprestsdk 库中,可以选择代理模式和非代理模式,若只用 Fiddler 4 作为系统代理,在本软件中是抓不到数据包的。

简单配置 Proxifier Fiddler 4
2.png

再次登录,会获得如下数据
3.png

根据之前的分析,需要重新构造一个数据包返回,其构造如下

HTTP/1.1 200
Content-Type: application/json; charset=utf-8
Connection: close

{"access_token": ""}

使用 Fiddler 4AutoResponder 功能对包进行替换
4.png

token.txt 中就是上面的返回内容,再次点击登录
5.png

同时在 Fiddler 4 中能的到一请求地址为 https://www.codecode.net/api/v4/clientauthorizedcode

继续使用 OD 查找 登录失败:获取授权失败
6.png

这里就不贴全了,其逻辑和之前第一个包的逻辑类似。
中间有个稍微特别一点的。
7.png

得到json格式之后,先不管其内容具体意义,构造 Response 如下

HTTP/1.1 200
Content-Type: application/json; charset=utf-8
Connection: close

{
"message":"0",
"number" : 0,
"ban_count":0,
"email":"",
"name":"",
"username":"",
"inforId":"",
"inforContent":"",
"threedeskey":[0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5],
"auth_state":true
}

故技重施,在登录成功之后,出现了加载页面,然后程序就退出了。
8.png
到此为止了么?
真是山穷水尽了。

山穷水尽

此时崩溃的原因可能有很多,

  1. json 内容错误
  2. 是软件自身bug
  3. ...

如果是json内容错误还好说,要是软件本身有bug,可就难受了。

那就先假设是软件bug,他有一系列软件,不可能全都有bug,换一个试一下。

柳暗花明

改装 Engintime CP Lab
运行之,
9.png

成功打开了。
剩下的几个都测了一下,有的能打开有的打不开。

不可能这些全部都存在bug,
那么就需要回到json内容错误继续分析了。

总结

通过字符打开突破口,通过Response替换,成功运行该系列的部分软件。

下一篇中,我将继续分析 json内容错误。