翻译第五篇 On Software Reverse Engineering - 5
            Reverse Engineering, FLEXlm, IMSL
模糊方法

    下面，我们将研究在目标程序中种子和密钥是怎样模糊的。我们的武器是数据流分析，也就是说通过调试cmath.exe，从初始化到l_string_kry()全程追踪vendor和job结构[10]。

VENDORCODE after calling l_n36_buf():
[004AEA20] - 00000004 ....
[004AEA24] - aa3342a8 .B3.
[004AEA28] - 8d112f1f ./..
[004AEA2C] - 74df9bc4 ...t 模糊了的 VENDOR_KEY1
[004AEA30] - b19bfb18 .... 模糊了的 VENDOR_KEY2
[004AEA34] - 94011f00 .... 模糊了的 VENDOR_KEY3
[004AEA38] - 054a2ed9 ..J. 模糊了的 VENDOR_KEY4
[004AEA3C] - 00020009 ....
[004AEA40] - 39300020 .09
[004AEA44] - 0000302e .0..
 
job after calling lc_init():
[00887630] - 00000066 f...
[00887634] - 00000000 ....
[00887638] - 00000000 ....
[0088763C] - 00000000 ....
[00887640] - 00000000 ....
 
// 上面是lc_new_job()之后的结构, 然后它们被传递到lc_checkout() ® l_checkout() ® lm_start_real() ® l_good_lic_key()

VENDORCODE 在l_xorname()调用之后:
[0012EE20] - 00000004 ....
[0012EE24] - aa3342a8 .B3.
[0012EE28] - 8d112f1f ./..
[0012EE2C] - 7c2adb6a j.*| 真的 VENDOR_KEY1
[0012EE30] - b927f5a9 ..'. 真的 VENDOR_KEY2
[0012EE34] - 9cf311f8 .... 真的 VENDOR_KEY3
[0012EE38] - 0dbf7621 !v.. 真的 VENDOR_KEY4
[0012EE3C] - 00020009 ....
[0012EE40] - 39300020 .09
[0012EE44] - 0000302e .0..
[0012EE48] - 00000000 ....
 
VENDORCODE after calling l_n36_buff():
[0012EE20] - 00000004 .... 整型;
[0012EE24] - 52ed15b8 ...R 52xxxxb8, xxxx 是随机的，在每次运行时是不同的
[0012EE28] - 75cf780f .x.u 75yyyy0f, yyyy 是随机的，在每次运行时是不同的
[0012EE2C] - 7c2adb6a j.*| VENDOR_KEY1
[0012EE30] - b927f5a9 ..'. VENDOR_KEY2
[0012EE34] - 9cf311f8 .... VENDOR_KEY3
[0012EE38] - 0dbf7621 !v.. VENDOR_KEY4
[0012EE3C] - 00020009 .... FLEXlm 版本(这里是 9.2)
[0012EE40] - 39300020 .09
[0012EE44] - 0000302e .0..
[0012EE48] - 00000000 ....
 
job after calling l_n36_buff():
[00887630] - 00000066 f... 整型;
[00887634] - 0089008e .... char *mem_ptr2;
[00887638] - a06aa84e N.j. unsigned char mem_ptr2_bytes[12];
[0088763C] - 00c3a047 G...
[00887640] - 00660000 ..f.
[00887644] - 00000000 ....
[00887648] - 00000000 ....
[0088764C] - 00000000 ....
[00887650] - 00000000 ....
[00887654] - 54414d43 CMAT
[00887658] - 00000048 H...
 
// 上面是l_good_lic_key() ® l_sg()之后的结构, 然后它们被传递到 l_good_lic_key() ® l_crypt_private() ® real_crypt() ® l_string_key()
 VENDORCODE和job在3个函数中被改变：l_n36_buf()，l_xorname()和l_n36_buff() (在lc_init()中的job初始化并不是很感兴趣的，因为它仅填充O)。在l_good_lic_key()内调用后面的两个：

l_good_lic_key(LM_HANDLE* job, CONFIG* conf, VENDORCODE* key)
{
... ...
memcpy(&vc, key, sizeof(vc));
if (!(job->flags & LM_FLAG_CLEAR_VKEYS))
l_xorname(job->vendor, &vc);
l_sg(job, job->vendor, &vc); /* l_sg() 将调用 l_n36_buff() */
... ...
code = l_crypt_private(job, conf, sdate, &vc);
... ...
}

    对于4个Vendor密钥，很明显它们是初始化时在l_n36_buf()中被模糊的，在l_xorname()中进行模糊逆向，l_xorname()未做别的仅进行了一些与或操作。我们都知道与或的特征：，因此进行两次相同的与或操作将相互取消。该特性将使编码和译码的与或变得美妙。如果我们的猜测是对的话，那么l_n36_buf()将采用与l_good_lic_key()相同的方式调用l_xorname()。因为l_n36_buf()驻留于lm_new.c, 它由lmnewgen.exe产生, 因此直接检查lmnewgen.c更好。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！