目录
系统初探
系统程序由java开发的主程序和c++开发组成几个程序(包含数据库系统等等),java开发的主程序编译成native exe。 此程序有通过native验证注册的native dll。
爆破
先考虑爆破这个dll,这个dll存在在system32目录中:OEMStartup.dll,这个爆破比较容易,看到几处弹出报警的地方,修改绕过,但是发现此处的报警信息在打开主程序时,并未有相应报警,所以当时怀疑是在其他进程会被调用到。这边的爆破比较容易,就不再详解了。
打开java主程序,发现程序仍未提示注册
说明修改OEMStartup.dll还是不够的
考虑到:1. 这个主程序是java开发的,逆向java需要再打包回去;2.有其他native程序还会调用OEMStartup.dll。基于以上两点分析,认为逆向注册码算法逻辑,可能比逆向java程序和native程序会来得快与彻底,所以决定选择逆向注册码算法这个方案。
逆向
打开x64dbg,附加注册进程,尝试输入一个容易定位的字符串来注册
反复多次调试,大致梳理出以下的核心流程
btnRegister_Click()
{
Idddreg.RegisterRDB(); //注册方法
}
Idddreg.RegisterRDB()
{
sub_2880();//初始化注册所需要的默认数据,如试用产品名,试用日期等等
sub_2A80();//读取注册key、license记录数据
sub_6970();//读取注册码,并对注册码做验证,此方法看起来有点小复杂,需要再深入研究
sub_3920();//注册码验证核心区域,此方法中含有弹出错误报警,所以先从此方法入手
}
sub_3920()
{
sub_2550();//粗略的看只有个错误检测
sub_6BF0();//主要的验证逻辑
}
根据大致的分析,先重点分析sub_6BF0(),在调用sub_6BF() 时
观察压栈和寄存器,分析esi对应一个结构体指针,内存如下:
内存中可以找到对应输入的注册参数“nAme”和“cOmpany”,但是找不到a1234567-a2222222-a3333333-a4444444-a5555555,和构想的不一样啊,难道输入的sn被转化了?
寄存器eax和ecx的值也是有点奇怪,eax值为167F6CBF,ecx值为6A4A42E5,莫名奇妙的两个值,也许方法体里面不一定用到,只能进入sub_6BF0方法体后再研究。
sub_6BF0代码如下(黄底文字为分析注释):
push ebp
mov ebp,esp
sub esp,14
push ebx
push esi
mov esi,dword ptr ss:[ebp+8]
add eax,ecx //可以看到寄存器eax,ecx有被使用到,所以前面看到那两个奇怪的数是有作用的
push edi
mov edi,edx
mov dword ptr ss:[ebp-C],eax
mov eax,edi
lea ecx,dword ptr ds:[eax+1]
xor ebx,ebx //ebx置0
lea ebx,dword ptr ds:[ebx]
mov dl,byte ptr ds:[eax]
inc eax
cmp dl,bl
jne icddreg.67696C10 //这是一种常见的内联方法,求字符串长度,参考截图,也就是PDF2016
sub eax,ecx
push eax
mov ecx,edi
call icddreg.67696F40 //长度是它的参数
movzx edx,ax
mov eax,dword ptr ss:[ebp+C]
mov dword ptr ss:[ebp-10],edx
add esp,4
lea edx,dword ptr ds:[eax+1]
mov cl,byte ptr ds:[eax]
inc eax
cmp cl,bl
jne icddreg.67696C30 //求字符串长度,是nAme
sub eax,edx
mov edi,eax
mov eax,dword ptr ss:[ebp+10]
lea ecx,dword ptr ds:[eax+1]
mov dl,byte ptr ds:[eax]
inc eax
cmp dl,bl
jne icddreg.67696C41 //求字符串长度,是cOmpany
sub eax,ecx
mov ecx,dword ptr ss:[ebp+10]
push eax
call icddreg.67696F40 //cOmpany长度是它的参数
mov ecx,dword ptr ss:[ebp+C]
push edi
mov word ptr ss:[ebp+12],ax
call icddreg.676