翻譯FLEXlm9.2的破解教學三

翻譯第三篇 On Software Reverse Engineering - 3
            Reverse Engineering, FLEXlm, IMSL

揭示加金鑰和加密種子

   從實際的觀點出發我們現在可以止步不前了，因為有了許可的複製我們可以自由的使用目標程式了。但是，軟體破解的最終目的是反向（逆向）工程的所有相關演算法並重新建立它們，那就好像我們是原始作者一樣。在我們的例項中，最低限度的要求是揭示VNI的5個vendor金鑰和3個隨機種子。不用說，這要求我們更仔細的閱讀FLEXLM SDK原始碼，因此我們簡單的回顧一下它是怎樣組織的。下面的列表顯示了包含最關鍵檔案的資料夾。

src        lmgr.lib或lmgr9a.dll的原始檔
app        lmgras.lib的原始檔
server     lmgrs.lib的原始檔
master     lmgrd.exe的原始檔
utils      實用工具的原始檔
machind    機器獨立檔案(源 & 頭)
i86_n3     對於x86 平臺的最終的二進位制檔案
h          標頭檔案
certicom   來自Certicom公司的庫和標頭檔案
ulite      FLEXLM的ultralite版本
  
    此外，檔案和函式根據其角色被指定了不同的字首。例如，目錄app, server和master以ls_開始，而在utils中是以lm為字首。

l_     許可證, 用於內部函式
lc_    許可證客戶端, 用於客戶端API
ls_    許可證伺服器, 用於伺服器API
lm_    許可證管理器, 用於實用工具和一般的程式（原為材料）

    現在，我們回到文獻[2]和[3]中關於Vendor怎樣實用FLEXLM SDK的指導中。基本地，Vendor需要將許多FLEXLM二進位制與其自己的產品結合並建立若干實用工具－一些作為內部使用，一些用於終端使用者釋出。在這些Vendor－所產生的檔案之間有很親密的聯絡，下面是其關係表：

檔案                              由...產生                              #include
lmrand1.exe                       lmrand1.c + lmgr.lib
lmcode.c, lsrvend.c               lmrand1.exe + lsvendor.c               lm_code.h
lmappfil.c, lmkeyfil.c            lmrand1.exe
lmnewgen.exe                      lmnewgen.c + lmcode.c + lmgr.lib       lm_code.h
lm_new.c                          lmnewgen.exe                           seeds & pubkey
lmseeds.h                         lmnewgen.exe
lmprikey.h, lmpubkey.h            lmnewgen.exe
lmcrypt.exe                       lmcrypt.c + lmgr.lib                   lm_code.h,
                                                                         lmseeds.h,
                                                                         lmprikey.h
makekey.exe                       makekey.c + lmgr.lib                   lm_code.h,
                                                                         lmseeds.h, 
                                                                         lmprikey.h
vendor application               vendor code + lm_new.obj + lmgr.lib +   seeds & pubkey

                                 libsb.lib + libcrvs.lib
vendor daemon                    lsvendor.obj + lm_new.obj + lmgr.lib +  lm_code.h, 
                                                                         lsserver.h, 
                                 lmgras.lib + lmgrs.lib + libsb.lib +   seeds & pubkey
                                 libcrvs.lib

    注意，並非上述的所有檔案都對我們是重要的。lmappfil.c和lmkeyfil.c是Vendor確定的濾波器，它們是附加的安全測試但通常未用。類似的，lmprikey.h 和lmpubkey.h僅用於CRO金鑰，在我們的例子中可以忽略。透過編輯lsrvend.c 或lsvendor.c，Vendor可定製後臺程式，但很少有人那樣做。
有一件值得討論的事情是Certicom產品，也即libsb.lib和libcrvs.lib 。它們幾乎涵蓋了從SHA到DSA的整個加密領域，而且FLEXLM採用的API幾乎為ECC（橢圓曲線加密技術）和RGN（隨機數字產生）。ECC用於在CRO中的公開/專用金鑰對，但在我們的目標程式中關閉了；而RGN用於Vendor種子的轉換，我們不可忽略。
正如先前宣告的，Vendor選擇了3個隨機種子（LM_SEED1, LM_SEED2, LM_SEED3），但並不直接使用它們。實際上，基於前3個，lmnewgen.c!main()®l_prikey.c!l_genrand()®libsb.lib!sb_rngFIPS186Session()產生了4個新種子[8]（ENCRYPTION_SEED1, … ENCRYPTION_SEED4）輸出到lmseeds.h。種子3和4專門用於公開/專用金鑰對，因此我們僅需要考慮種子1和2。
    儘管FLEXLM在l_rand.h和lm_rand3.c中有其自己的RGN，但它在此仍然使用了在DSS標準中確定的演算法(c.f. [8])。該演算法是決定性的（沒有讀取時間、暫存器值等），因此對給定的LM_SEED，那麼ENCRYTION_SEED（的值）將是固定的。它也是一個單向的函式，這意味著在實踐中不可能從已知的ENCRYPTION_SEED來解決LM_SEED。因為是ENCRYPTION_SEED被程式設計到Vendor釋出版本中，而LM_SEED除了在l_genrand()中出現外別處都不出現，因此我們最好恢復前者。但是，恰巧出於相同的原因，我們假定恢復LM_SEED是同樣的好。
    在FLEXLM的內部基本上是C/S模型，結合Vendor應用程式的是客戶端，Vendor後臺程式（這裡是vni.exe ）是伺服器。注意，Vendor後臺程式不同於FLEXLM許可證管理器lmgrd.exe，後者僅重定向客戶端請求到相應的做實際工作的Vendor後臺程式。令一個因素是許可證檔案格式。FLEXLM提供了豐富的許可選項，在計數與不計數上是很重要的。不計數的許可證對於（使用者）數量的檢查沒有限制並且不需要Vendor後臺程式－其有效性僅在Vendor軟體同時作為客戶端和伺服器時發生。計數的許可證通常用於網路（浮點許可證必須被計數），在大公司通常可以看到這樣的情景：中心節點執行伺服器，所有工作站連線到它上面進行許可證的輸入輸出檢查。因此，我們可以推斷Vendor後臺程式的主要任務是計數、管理和調節受限許可證的使用。
    看我們的許可證，它是 “permanent uncounted HOSTID=ANY”, 它表明沒有任何條件限制。這一定是每個破解者的夢想（無後臺程式處理也使追蹤更容易）。實際上在許可證檔案中，“SERVER"和"DAEMON"行是不必要的，兩個“FEATURE"足以保證cmath.exe能無限制的執行。後面我們將有主題討論許可證型別。
現在，我們已有了具有Vendor金鑰和加密種子的cmath.exe作為客戶段和伺服器。有個好訊息是CRO不起作用，因此僅要一套金鑰。如果我們挖掘出它們，我們將可以用lmcrypt.exe或makekey.exe製作任何許可證檔案，與Visual Numerics的方式一樣。在我們著手進行時，我們總結了在金鑰檔案中的一些金鑰。

lm_code.h: /* \machind\lm_code.h and \h\lm_code.h must be identical */
VENDOR_KEY1, VENDOR_KEY2, VENDOR_KEY3, VENDOR_KEY4, VENDOR_KEY5
LM_SEED1, LM_SEED2, LM_SEED3
lmcode.c:
#include "lm_code.h"
#include "lmclient.h"
VENDORCODE vendorkeys[] = { /* 錯誤的名字，需使用vendorcodes[]代替*/
{ VENDORCODE_7,
ENCRYPTION_SEED1 ^ VENDOR_KEY5, ENCRYPTION_SEED2 ^ VENDOR_KEY5,
VENDOR_KEY1, VENDOR_KEY2, VENDOR_KEY3, VENDOR_KEY4,
FLEXLM_VERSION, FLEXLM_REVISION, FLEXLM_PATCH,
LM_BEHAVIOR_CURRENT, {CRO_KEY1, CRO_KEY2},
LM_STRENGTH, LM_SIGN_LEVEL, 0
},
};
lmseeds.h: 
ENCRYPTION_SEED1, ENCRYPTION_SEED2, ENCRYPTION_SEED3, ENCRYPTION_SEED4
lm_new.c: 
x = 0x3d73db2e; /* 在lmnewgen.c中產生的隨機數key5_uniqx */
VENDORCODE.data /* 由key5()模糊 */
VENDORCODE.keys /* 由l_xorname()模糊 */
l_getattr.c:
#define VENDORMAGIC_V7 0x08BC0EF8 /* 不重要, 僅用於xor（與或）取消*/
lmclient.h:
#define L_NEW_JOB l_n36_buf
l_privat.h:
#define L_UNIQ_KEY5_FUNC l_n36_buff
#define L_SET_KEY5_FUNC l_x77_buf
#define SEEDS_XOR mem_ptr2_bytes /* 這裡seeds 隱藏在job */
#define SEEDS_XOR_NUM 12
 
    此外，這裡有三個數字被嵌入到二進位制中（比如VENDORMAGIC_V7），但好像從來沒有使用（至少在cmath.exe）中。也許它們僅用於某個版本或某個許可證型別，當我們訪問這些函式時，我們將會看到它們。
Besides, there are three numbers that are hard-coded into the binaries (just like VENDORMAGIC_V7) but seems never used (at least in the case of cmath.exe). Maybe they are  solely  for certain versions or license types, we’ll see that when we visit those functions.
 
lm_ckout.c!l_sg():
x = 0x6f7330b8; /* v8.x */
lmnewgen.c!VKEY5():
x = 0x6f7330b8; /* v8.x */
l_key.c!l_zinit():
z = crokey_flag ? 0x62586954 : 0x72346B53; /* v9.x */