編者按：在讀者來信中，經常有朋友詢問如何做一名成功的黑客或安全專家，如何才能找到好的安全技術學習方法。其實，除了掌握一些必備的基礎知識和工具外，還要懂得編程等技術；另外攻防思路的養成和培訓也是很重要的。因為技術可以通過努力學習而有所成就，但攻防的思維方式即使苦心鉆研往往也無大的收獲，就得多多借鑒高手的經驗了。在本文中，作者通過對NT平臺撥號連接密碼恢復原理的研究，層層索引，步步入微的思維方法就值得推薦。

　　前段時間我的ADSL密碼忘記了，但幸好還保存在撥號連接里面，于是我到網上找了些星號密碼顯示工具，可惜不起作用。后來找到一種名為Dialupass的工具，這家伙不負我所望，把密碼給我還原出來了 (用的Dialupass v2.42，我的系統是Windows XP) 。抱著濃厚的興趣，我決定深入研究。略有收獲，愿與大家共享。

　　Dialupass星號密碼顯示之謎

　　看上去，Dialupass是非普通的星號密碼顯示工具，那它的原理是什么呢？上Google查了一番，沒找到相關資料。一生氣便抄起家伙——Windbg，準備把它大卸八塊。郁悶的是，用Windbg加載后，密碼就不能還原出來了，顯示的是星號。換替補Ollydbg上場，情況依舊。怪了，莫非這小工具有Anti-Debug功能？當時只是一絲懷疑，因為實在不相信這樣的小工具作者會花心思來保護。

　　小知識：

　　Windbg工具：

　　Windbg是微軟開發的免費源碼級調試工具。可以用于Kernel模式調試和用戶模式調試，還可以調試Dump文件。

　　Anti-Debug技術：

　　Anti-Debug，即反跟蹤技術。防止 Cracker 用 SoftICE 之類的調試器動態跟蹤，分析軟件。反跟蹤技術一般是具有針對性的，即針對某種調試器的反跟蹤，而不能防止所有的調試器跟蹤。

　　在用S-ICE跟蹤的過程中，發現有這么一個調用：GetProcAddress(xx, “IsDebugPresent”)。原來真的有Anti-Debug功能，好在比較簡單。統計了一下，總共有五處進行了Anti-Debug檢查。

　　OK，情況查明了，便換回Windbg來調試。在Windbg里面有這么一個斷點可繞過Anti-Debug檢測：bp KERNEL32!IsDebuggerPresent “g poi(esp);r eax=0;g”。

　　花了些時間跟蹤了一下，把Dialupass恢復密碼的流程都搞清楚了。這小程序貓膩還挺多的，總結如下：

　　1. 關鍵函數不直接調用，而是用LoadLibraryA和GetProcAddress來獲取函數地址后再CALL；
　　2. 函數名是經過編碼的，反匯編后看字符串是看不到的；
　　3. 關鍵地方一概用花指令來迷惑你和反匯編軟件。

　其實原理很簡單，就是用rasapi32.dll里面的一些函數來獲取撥號連接的一些信息，再用 ADVAPI32!LsaRetrievePrivateData 函數來獲取密碼。

　　關鍵字：LsaRetrievePrivateData和RasDialParams

　　根據Dialupass的原理，寫了個類似的工具(完整的源代碼x_dialupass.c可以從.net/src/x_dialupass.c">http://security.xici.net/src/x_dialupass.c獲取)。后來用LsaRetrievePrivateData和RasDialParams做關鍵字，重新在Google搜索了一遍，找到一些類似的代碼。

　　小提示：

　　參考資源①和②是俄羅斯人公布的演示代碼，沒有對LsaRetrievePrivateData返回的數據進行拆分用戶名和密碼。參考資源③是日本人公布的完整的應用程序的代碼，可惜在對LsaRetrievePrivateData返回的數據進行拆分處理時存在BUG，導致有些情況下用戶名和密碼取得不正確。

　　①http://www.lwteam.ru/modules/ne ws/article.php?storyid=167
　　②http://www.wasm.ru/forum/index.php?action=vthread&forum=12&topic=4873
　　③http://homepage2.nifty.com/spw/software/rtrick/

　　后來發現Lsadump2 DUMP出來的數據里面包含了“LsaRetrievePrivateData”返回的數據。Lsadump2的原理大致如下：

　　1.插入一個線程到Lsass.exe進程；
　　2.打開LSA Policy database；
　　3.從注冊表“HKLM\SECURITY\Policy\Secrets”中枚舉子鍵；
　　4.LsarOpenSecret；
　　5.LsarQuerySecret。

　　進一步跟蹤后發現，其實ADVAPI32!LsaRetrievePrivateData是通過NdrClientCall2發送RPC調用到Lsass.exe進程，Lsass.exe里面再調用LsarOpenSecret、LsarQuerySecret來完成獲取撥號連接信息過程的(LsarOpenSecret里面有權限判斷，非Admin組用戶是沒有權限來調用ADVAPI32!LsaRetrievePrivateData的)。

　　跟蹤了一下LsarQuerySecret，發現它返回的數據其實是從注冊表中讀取。保存撥號連接信息的注冊表鍵值為：“HKLM(HKEY_LOCAL_MACHINE的縮寫)\SECURITY\Policy\Secrets\RasDialParams!SID#0\CurrVal”。

　　SID對應的是用戶的String SID (“HKLM\SECURITY”這個鍵只有System有權限讀寫)。

　　LsarQuerySecret從注冊表中讀取出來數據后，接著調用LsapCrDecryptValue函數來解密，對于同一臺機器來說，解密時用的KEY始終都是固定的，這個KEY在lsasrv.dll里面的變量名為_LsapDbSecretCipherKey。在Windows 2003里面，變量名不一樣，對應的有兩個，分別為LsapDbSecretCipherKeyWrite和LsapDbSecretCipherKeyRead，但這兩個變量里面的數據是一樣的。

　　LsapCrDecryptValue用的似乎是標準DES算法，解密時主要流程如下：

　　lsasrv!LsapCrDecryptValue→advapi32!SystemFunction005→advapi32!DecryptDataLength→advapi32!SystemFunction002→advapi32!DES_ECB_LM→advapi32!des

　　解密后，在“<<”標志處還有一個判斷(如圖所示)。

　　假如[esi+45h]為0的話(esi是LsarOpenSecret函數返回的Handle)，它會把解密后的數據再進行一次加密，不管是Windows 2000還是Windows 2003，這時用的KEY始終都是固定為“SystemLibraryDTC”。

　　Lsadump2里面調用LsarOpenSecret得到的Handle，偏移0x45處值為1，所以LsarQuerySecret函數返回的就是解密后的數據了。

　　而在調用ADVAPI32!LsaRetrievePrivateData時，LsarOpenSecret返回的Handle偏移0x45處值為0x0，所以LsarQuerySecret返回的是解密后又加密的數據，所以在ADVAPI32!LsaRetrievePrivateData里面還有一個對應的解密過程。相應地，LsapCrEncryptValue加密的主要流程如下：
　　lsasrv!LsapCrEncryptValue→advapi32!SystemFunction004→advapi32!EncryptDataLength→advapi32!SystemFunction001→advapi32!DES_ECB_LM→advapi32!des

　　_LsapDbSecretCipherKey是如何產生的？

　　開始我以為在同一版本的Windows里面，_LsapDbSecretCipherKey是固定的，后來發現我錯了。那么這個

_LsapDbSecretCipherKey是如何產生的？流程如下：

　　1.調用ntdll!NtConnectPort打開 L“\Security\WxApiPort”；
　　2.調用ntdll!NtRequestWaitReplyPort得到一些數據；
　　ebp-40處為NtRequestWaitReplyPort返回的LPCMESSAGE：
　　kd> dd ebp-40
　　0006fcb8 00400028 00000002 000000dc 000000d8
　　0006fcc8  00000024 00000000 00000000 00000000
　　0006fcd8  00000001 00000010 00000010 fd317e3e
　　0006fce8  7e24e86d d12503d3 5f7d01a8 7665f528
　　kd> db ebp-14
　　0006fce4  3e 7e 31 fd 6d e8 24 7e-d3 03 25 d1 a8 01 7d 5f

　　3.將上述“ebp-14”處的0x10字節數據COPY到lsasrv.dll里面的_LsapDbSysKey變量。

　　_LsapDbSysKey在不同的機器上面(即使版本相同)都是不一樣的。它是怎么產生的？有幸拜讀了Flashsky的大作后(http://www.xfocus.net/articles/200306/550.html)，我才明白這就是傳說中的“SYSKEY”。用Flashsky的代碼驗證一下：

　　c:\>getsyskey
　　3e 7e 31 fd 6d e8 24 7e d3 03 25 d1 a8 01 7d 5f

　　跟蹤系統啟動過程，可知道“\Security\WxApiPort”是由Winlogon.exe進程創建的，然后Lsass進程通過這個LPC PORT從Winlogon進程獲取SYSKEY，隨后Winlogon進程會關閉這個LPC PORT。所以在系統啟動完成之后，用Process Explorer等工具是看不到這個LPC PORT存在的，而且在Winlogon和Lsass進程空間都搜索不到上述SYSKEY。

　　4.從注冊表“HKLM\SECURITY\Policy\PolSecretEncryptionKey”中讀取出來一段數據，調用函數_LsapDbDecryptKeyWithSyskey，把它用_LsapDbSysKey來解密，_LsapDbSecretCipherKey就在解密完后的數據里面(LsapDbDecryptKeyWithSyskey函數做的其實就是MD5和RC4運算)。

　　從注冊表中獲取撥號連接密碼

　　了解原理后，我們就可以直接從注冊表里面來獲取撥號連接中的密碼等數據了。但有幾個問題需要解決：

　　1.原料：“HKLM\SECURITY”鍵只有SYSTEM有權限讀寫。我們可以把代碼插入到SYSTEM進程里面去運行，或者把這個鍵修改為ADMIN有權限讀，或者提升本進程權限。

　　2.催化劑：如何獲取_LsapDbSysKey解密用的函數，_LsapDbDecryptKeyWithSyskey為非導出函數。可以用Flashsky的代碼來獲取SYSKEY，利用公開的MD5和RC4庫函數來解密。

　　直接從Lsass.exe進程里面搜索_LsapDbSecretCipherKey，它的結構如下：

　　typedef struct _LSA_BLOB {
　　DWORD cbData;
　　DWORD cbMaxData;
　　BYTE  pbData;
　　} LSA_BLOB;

　　pbData指向存儲KEY的地址，KEY長度固定為0x10字節，即cbData和cbMaxData都是固定為0x10。所以從Lsass進程的空間里面搜索“\x10\x00\x00\x00\x10\x00\x00\x00”即可找到正確的KEY。結果可能會有多個，可以把所有搜索到的KEY都試一下，總有一個正確的。

　　3.工具：解密函數LsapCrDecryptValue為非導出函數，怎么辦？或許可以根據特征碼來搜索，但總覺得不太可靠。幸好，LsapCrDecryptValue調用的advapi32!SystemFunction005是導出函數。或者直接利用公開的DES庫函數，自己來運算。