翻譯第五篇 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更好。