程序介绍
画画程序
演示版保护机制
程序启动后弹窗提示“The program is started in the restricted mode because a valid license certificate is not installed.”
单击确定后提示窗口消失转而进入主窗口,但是主窗口很多菜单都是灰色的不可用状态
这里大致猜测程序是调用WindowsAPI的
EnableMenuItem()
函数设置菜单不可用,等下可以考虑给这个函数下断点,或者直接禁用这些函数实现爆破。
我之前在网上了解过SAI是使用证书进行激活的,尚且不知道激活过程是否联网。
但是软件启动的时候并未有输入激活码的选项,说以证书可能是以文件形式存储或者是存在注册表里。
SAI2的最新发行版是便携版,不需要安装。
观察文件目录发现除了启动程序并未存在其他动态链接库(dll文件),因此可以肯定程序的验证流程就在启动文件里。
逆向过程
使用IDA打开启动程序,IDA成功识别到了软件的WinMain
函数,一个是程序没有加壳,还省了我再去找main函数入口了。
可以观察到函数有很多简单的返回分支和一个很复杂的分支。
经过观察,这些分支程序都是打印错误消息的
全部掠过,再来看主分支,这里调用了两个函数。进入观察后每发现个函数都很复杂,直接看是看不出来的。所以我打算去字符串窗口中找找,看看能不能找到弹窗字符串,然后根据字符串反向查找调用。但是理想很丰满,现实很骨感:(根本查不到字符串。
所以现在有两种可能摆在面前:
1.程序的字符串是保存在文件里的,程序在运行的时候才能访问。(查过了,没有本地字符串文件)
2.程序对字符串加密了,所以看不到。
当然这是我刚开始调试的想法,其实字符串一直就摆在程序里,只是用来UTF-16LE编码。所以只要给IDA设置好了就能正确看到字符串了。直接右键字符窗口任意位置选择Setup,然后给所有字符串类型全打勾就可以了。
正确设置了以后就能查到字符串了。但是这个程序使用了通过一段整形+转换函数来动态获取字符串地址,这样就没办法直接用交叉引用来逆向寻找调用函数。
动态字符串获取函数:
所以这个方法不能用了。
这里就先略过我当时的无用尝试过程了。
在那之后我改变思路想先找到是哪个函数调用让程序产生第一张图里的弹窗,所以果断开启调试。
程序报错了?提示内存读取读取越界??难道有反调试吗?
先把问题放一下,看看到底怎么回事,单击ok让程序停在报错的指令上。
看到是
.text:000000014019F09D mov rsi, [rdi+rbx*8]
这一句访问越界了,不是严重错误,看样子好像并不会让程序直接退出。头铁直接回去下断点然后把异常给程序处理执行试试。
好像并没有发生什么,程序备用报演示版提示弹窗,也没有退出,然后还断在我设的断点上。
经过我后面的调试发现这个貌似是个bug,老版本的SAI2也有这个问题。
然后我们
步过执行程序,突然调试器在上图中标红的函数处停下了,弹窗出来了。
这里我试了单步追踪,但是函数太多了,不好操作。不如换一个思路。
演示版提示弹窗是==第一个==被显示的窗口,所以只要给
ShowWindow()
函数下断,然后找到
第一个调用该API的地方就行了。
这里就是程序第一次调用显示窗口API的地方。然后一直运行到返回,我们找到了显示弹窗的关键函数。我在这里对函数也做了重命名。见下图。
在函数体内下断点,重启程序,我们看到堆栈内有弹窗中对应的字符串。这里可以推测这个函数不只是用来显示演示版弹窗的。程序所有的报错消息应该都会交由这个函数显示。而且我们也能根据堆栈内字符串知道字符串指针的获取不在该函数的代码范围内。
这里依旧运行到返回。 ^1b953a
我们发现在该函数上方存在两个的关键判断语句(地址0x14000B380)。箭头是我们的弹窗函数,波浪线画的是判断是指令上的第一个函数,而且这两个函数相同。
同时根据函数的第二个参数可以看出,它是个路径字符串,而且程序是有两个验证过程的。
流程如下:
1.检查C盘文档下是否有合格证书。是->成功 否->转到2.
2.检查程序文件夹下是否有合格证书。是->成功 否->转到3.
3.显示演示版弹窗并启动限制版程序。
细心的你一定也发现了判断是根据bHasLicense这个变量判断是否是正版软件的。
看一下这个变量的交叉引用。果然!只有一个写入,其他全是读取,还是判断它是不是非零。而且唯一的写入也是在验证函数里。那么思路一下就明朗了起来。只需要修改无论如何都会写入true到这个变量就可以了。
这里我在函数进入后直接对bHasLicense写入1。然后无条件跳转到下面的
return 0
语句。然后将改动直接写入到原文件。
修改后代码如下:
演示版程序不能保存,如下。
修改后程序如下,可以正常保存。
我本以为这样就可以开开心心地爆破,但是在程序保存和读取文件时报错了,起初我还以为是SAI2的bug,还去浏览器上查了半天🥲。兜兜转转调试了很多次后发现并不是bug引起的错误,而是程序还有暗桩。
报错如下:
经过我对
CreateFileW()
API下条件断点调试得出程序
只读取了一次证书文件。
过程如下
给
CreateFileW()
API设置条件断点,条件为
msg("Filename: %s\n", get_strlit_contents(RCX, 180, "UTF-16LE")), 0
这样IDA会在调试的时候自动输出CreateFileW()第一个参数,也就是
读取的文件目录到控制台,180是字符串长度。我们知道字符串长度肯定会不一样,但是IDA这个函数对UTF-16编码的识别不是很智能只能先设置个180显示。后面的0是布尔参数,1的时候断点会中断,0则不会,两种情况都会执行
msg()
函数。
我们就可以很清楚的看到程序只读取了
一次证书文件。
既然证书只被读取了一次,那么问题出在哪里呢?目前有以下几种可能的解释:
- 程序内部有多次验证,比如证书的内容或根据证书计算出的注册码被保存到了内存中,每次保存或者读取的时候都会调用验证函数验证。
- 证书被保存在了设置文件中,每次运行的时候在这里读取。
至于修改了验证函数还是会验证失败:
- 有好几个不同实现方式的验证函数
- 验证关键函数在我之前改的函数的子调用中,其他函数仍可调用该未修改过的函数进行验证。
对于证书被保存在其他地方的情况我试过删除证书源文件,程序提示证书文件未安装。说明证书可能安装在其他文件里的,但是这不能下定论。接下来我把证书内容==设置为从a到z的小写字母==,运行程序然后去设置文件里找,发现并==没有相同内容==,所以这种可能性排除。
那么就只剩第一种情况了。
对于第二个问题,我们只能通过调试和分析寻找答案。
这里我选择跟进验证函数,分析如下。
紫色箭头为正常流程,如果不存在证书文件则会在第一个跳转处直接走红色路径。
所以接下来的调试最好准备一个.slc
文件放到程序根目录下,文件内容随便。
汇编流程分析:
反编译:
__int64 __fastcall VerifyLicenseFunc(Sai_Storage *tlsStorageStruct, const wchar_t *lpFilePath)
{
unsigned int v4;
unsigned int aSlcSuffixPath;
unsigned int i;
unsigned int result;
void *bTemp;
__int64 a1[2];
wchar_t lpFullPath[264];
_BYTE FindFileData[44];
wchar_t FullPath[274];
wchar_t String1[256];
wchar_t Filename[264];
unsigned int contentSize;
void *content;
v4 = -1;
a1[0] = 0LL;
aSlcSuffixPath = sub_1401C9250(
(__int64)a1,
::aSlcSuffixPath,
lpFilePath);
if ( aSlcSuffixPath )
{
if ( aSlcSuffixPath == 2 )
return 0LL;
sub_1401A5DC0(aSlcSuffixPath);
}
else
{
for ( i = sub_1401C8330(a1[0], FindFileData); !i; i = sub_1401C8330(a1[0], FindFileData) )
{
if ( (FindFileData[0] & 0x10) == 0 )
{
wsplitpath(FullPath, 0LL, 0LL, Filename, String1);
if ( !wcsicmp(String1, L".slc") )
{
wmakepath(lpFullPath, 0LL, lpFilePath, Filename, String1);
result = readFIleToContent(&content, &contentSize, lpFullPath);
if ( result )
{
sub_14000AF10(tlsStorageStruct, 0x2003Du, 0x20504u, lpFullPath, result);
}
else
{
if ( sub_14000B010(tlsStorageStruct, content, lpFullPath) == 1 )
{
bTemp = content;
content = 0LL;
bHasLicense = bTemp;
LABEL_18:
v4 = 0;
goto LABEL_15;
}
free(content);
}
}
}
}
if ( i == 18 )
goto LABEL_18;
sub_1401A5DC0(i);
LABEL_15:
sub_1401C82C0((HANDLE **)a1);
}
return v4;
}
这里我选择去查看content
变量内容的来源
根据上面判断readFIleToContent()
是可能的读取文件的函数,而下面的sub_14000B010()
可能是用来验证或者对content
进行证书计算来取得一个注册码。
那么进入readFIleToContent()
先看看有哪些关键函数调用,我们首先看到了malloc()
然后是标准的对内存申请结果的判断。
我们转到反汇编,一眼就能看出内存申请后的地址,内存申请的大小和一个奇怪的变量(
buffer
)传入了
SomeReadFileUpper()
函数。那么他就是可能的文件读取函数。
继续跟进
SomeReadFileUpper()
函数分析:
发现该函数内部有两个调用。
我们先看第一个调用,其内部
非常复杂,但是三次调用的上图的第二个函数(
ReadFileByHandle()
)。
如下如图粉色标记
既然如此,我们先分析第二个函数调用,函数内部调用非常简单,直接上反编译。
函数内部直接调用
ReadFile()
API对文件进行读取,而文件句柄来自
buffer
,又根据下面对
buffer
地址的赋值。这里合理推测
buffer
指向的是一个
存着文件信息的结构体,这一层函数调用根据这个结构体传递消息。
第二个函数的调用我也顺带分析了,里面是一个
GetLastError()
的错误处理函数。
那么这个函数的功能就明了了,==读取文件内容至dest,将读取字节数存到第四个参数中。==
那么再来看前面
sub_1401C6A00()
的函数调用,函数里面有两个循环,根据上层(
buffer
结构中的变量)消息的不同进行两种不同的读取方式,但是最终字符串保存的位置
是一样的,都是存储在dest中。那么可以确定
SomeReadFileUpper()
函数就是根据
第一个参数地址+5
处存储的
文件句柄进行读取操作。
那么接下来就是看看
newBuffer
从哪来的
进入
readFileAndPutHandleInBuffer()
函数,根据上面对buffer的判断这里的分析过程非常简单,我直接放结果了。
经过调试知道
buffer+16
处的值在这里始终为
0
,以此为根据我们可以很简单地判断出
函数正确执行时的返回值是
0
。
下面的函数是检查文件句柄是否关闭成功的,与验证关系不大,略过。
然后再去查看
sub_14000B010()
第一个参数的来源
先回到上层查看
LicenseCheck()
是如何调用
VerifyLicenseFunc()
的。这里IDA的识别是非常乱的,这是我调整后的结果。反汇编如下
根据后面代码的判断,传入
sub_14000B010()
的第一个参数,也就是传入
VerifyLicenseFunc()
函数的第一个参数是一个
结构体指针,并在
InitSaiStorageStruct()
函数处初始化。我直接在IDA中添加了该结构体的声明,其内部结构如下。
StoragePtr
存储的是一个指向存储空间的指针,
Value01
通常用来存储存第一个变量指向的储空间的字节大小。
InitSaiTlsStruct()
函数内容如下
根据
LicenseCheck()
反编译的
前两句知道函数将
threadStoragePtr
中的指针指向
线程存储空间中的一个指针。
再回来看
threadStoragePtr
具体是干什么的。
在上面两次
VerifyLicenseFunc()
的验证都失败的时候调用了
OnAlertWindowFunc()
函数(==我这里将函数重命名了,之前是OnFailedFunc()==)根据上文可知这是弹窗函数,这时候
threadStoragePtr
存储着上面验证函数失败时的提示字符串,并调用弹窗显示。
那么接下来一切都明朗了起来,
sub_14000B010()
函数就是验证的关键,当它返回
1
时我们认定程序为
正版。那么我们看看有哪些程序调用了这个函数。
很遗憾,只有一处调用,只有可能是这个函数调用了关键验证函数。
我们进入函数寻找返回值为
1
的情况。
图中黄色圆圈处为程序返回
1
是的分支。根据流程图我们一眼就能看出只有经过
四次正确跳转后才能返回
1
,其他分支都是不行的。
然后我们再看看程序其他分支都干了什么事。
那么反编译后结果就一目了然了。
这边我也一并把其他分支看了,其他分支都是通过
getcodeAddress()
来动态获取字符串和
sub_1401BEFE0()
来将字符串复制到
threadStoragePtr
中指针指向的空间,再回到这里使用弹窗显示字符串。
这里的反汇编是我调整过的。IDA并没有把
calculatedValue
识别成数组。我通过调试大概知道了变量结构。声明如下:
VerifyFunc()
调用后面紧跟着一个大!判!断!和一个小判断,对应于流程中的四个判断。那么这四个条件就
必须满足。很显然判断用的这四个值就是上面这个函数算出来的。
看看这个函数交叉引用
很可疑,下断点调试。
让程序在这里停下
然后通过IDA修改先后绕过四个判断后继续运行程序。
回到
bHasLicense
赋值的地方,惊讶的发现赋值给它的是一个
指针,内容是我
证书的内容。
那么先前对于它是布尔变量的判断就是错的。直接把它重命名成
lpSAILicense
。
继续运行程序,并没有出现演示版提示弹窗。
我们在菜单选择打开文件然后确定,然后程序和我预料的一样在
VerifyFunc()
处断下来了。
根据
栈顶知道调用来自0x14010E143的上一条语句
很明显,第二个问题的正解是上面提到的第二个情况。
该处调用
VerifiyFunc()
的参数如下
好了,接下来就是用哪种方法爆破了,
第一个是把每一个调用
VerifiyFunc()
语句后的判断修改成无条件跳转;
第二个就是直接改
VerifiyFunc()
函数。
这里我选择第二个方法爆破。
通过观察上面四个调用发现所有验证判断的条件都是一样的,与下图一致
即
MustBeOne
的三个变量必须为
1
,
HardwareCodeFromLicense
必须与全局变量
HardwareCodeFromLicense
一致。
C++源码:
void __fastcall VerifiyFunc(unsigned __int16 **a1, const void *content, Sai_License_Info *licenseInfo)
{
licenseInfo->MustBeOne01 = 1;
licenseInfo->MustBeOne02 = 1;
licenseInfo->MustBeOne03 = 1;
licenseInfo->HardwareCodeFromLicense = HardwareCodeFromLicense;
}
修改后的汇编码
mov [rsp+0x8], rbx
mov [rsp+0x10], rsi
push rdi
sub rsp,0x860
mov dword ptr [r8], 0x1
mov dword ptr [r8+0x14], 0x1
mov dword ptr [r8+0x1c], 0x1
mov eax, dword ptr cs:[HardwareCodeFromLicense]
mov dword ptr [r8+0x4], eax
lea r11, [rsp+0x868+0x8]
mov rbx, [r11+0x10]
mov rsi, [r11+0x18]
mov rsp, r11
pop rdi
retn
修改前:
修改后程序如下:
爆破成功,可以随便打开、保存文件。