On Software Reverse Engineering - 5

王朝other·作者佚名  2006-01-09
窄屏简体版  字體: |||超大  

On Software Reverse Engineering

Obfuscation Method

Next we research how seeds and keys (yes, vendor keys

too!) are obfuscated in the target. Our weapon is data flow analysis, that is,

to trace the vendor and job structure[10]

all the way from initialization to l_string_key() by

debugging cmath.exe.

VENDORCODE

after calling l_n36_buf():

[004AEA20]

- 00000004 ....

[004AEA24]

- aa3342a8 .B3.

[004AEA28]

- 8d112f1f ./..

[004AEA2C]

- 74df9bc4 ...t obfuscated

VENDOR_KEY1

[004AEA30]

- b19bfb18 .... obfuscated

VENDOR_KEY2

[004AEA34]

- 94011f00 .... obfuscated

VENDOR_KEY3

[004AEA38]

- 054a2ed9 ..J. obfuscated

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 ....

// above are structs after lc_new_job(), then they are passed to

// lc_checkout() ®

l_checkout() ® lm_start_real() ® l_good_lic_key()

VENDORCODE

after calling l_xorname():

[0012EE20]

- 00000004 ....

[0012EE24]

- aa3342a8 .B3.

[0012EE28]

- 8d112f1f ./..

[0012EE2C]

- 7c2adb6a j.*| true

VENDOR_KEY1

[0012EE30]

- b927f5a9 ..'. true

VENDOR_KEY2

[0012EE34]

- 9cf311f8 .... true

VENDOR_KEY3

[0012EE38]

- 0dbf7621 !v.. true

VENDOR_KEY4

[0012EE3C]

- 00020009 ....

[0012EE40]

- 39300020 .09

[0012EE44]

- 0000302e .0..

[0012EE48]

- 00000000 ....

VENDORCODE

after calling l_n36_buff():

[0012EE20]

- 00000004 .... int type;

[0012EE24]

- 52ed15b8 ...R 52xxxxb8, xxxx is random, different at

each run

[0012EE28]

- 75cf780f .x.u 75yyyy0f,

yyyy is random, different at each run

[0012EE2C]

- 7c2adb6a j.*| VENDOR_KEY1

[0012EE30]

- b927f5a9 ..'. VENDOR_KEY2

[0012EE34]

- 9cf311f8 .... VENDOR_KEY3

[0012EE38]

- 0dbf7621 !v.. VENDOR_KEY4

[0012EE3C]

- 00020009 .... FLEXlm

version (here is 9.2)

[0012EE40]

- 39300020 .09

[0012EE44]

- 0000302e .0..

[0012EE48]

- 00000000 ....

job

after calling l_n36_buff():

[00887630]

- 00000066 f... int type;

[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...

// above are structs after l_good_lic_key() ® l_sg(), then they are passed to

// l_good_lic_key() ® l_crypt_private() ®

real_crypt() ® l_string_key()

VENDORCODE and job are changed at 3 functions: l_n36_buf(), l_xorname() and l_n36_buff() (job

initialization in lc_init() is not very interesting for it

only fills zero). The last two are called within 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() would call l_n36_buff() */

... ...

code = l_crypt_private(job, conf, sdate, &vc);

... ...

}

For the 4 vendor keys, it is obvious that they are

obfuscated in l_n36_buf() at initialization and

de-obfuscated in l_xorname(), which does nothing but some

xor operations. We all know the properties of xor: x ^

x = 0, x ^ 0 = x, x ^ 1 = ~x, so the

same xor operations performed twice would cancel each other. This nice property

makes xor perfect for encoding and decoding. If our guess is right, then l_n36_buf() should also

call l_xorname() in the same manner as l_good_lic_key() does.

Since l_n36_buf() resides in lm_new.c, which

is generated by lmnewgen.exe, it’s better to examine lmnewgen.c

directly.

[10] There is

a third structure – config, but it’s not important for our purpose here.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航