編者按：在讀者來信中，經(jīng)常有朋友詢問如何做一名成功的黑客或安全專家，如何才能找到好的安全技術學習方法。其實，除了掌握一些必備的基礎知識和工具外，還要懂得編程等技術；另外攻防思路的養(yǎng)成和培訓也是很重要的。因為技術可以通過努力學習而有所成就，但攻防的思維方式即使苦心鉆研往往也無大的收獲，就得多多借鑒高手的經(jīng)驗了。在本文中，作者通過對NT平臺撥號連接密碼恢復原理的研究，層層索引，步步入微的思維方法就值得推薦。
前段時間我的ADSL密碼忘記了，但幸好還保存在撥號連接里面，于是我到網(wǎng)上找了些星號密碼顯示工具，可惜不起作用。后來找到一種名為Dialupass的工具，這家伙不負我所望，把密碼給我還原出來了 (用的Dialupass v2.42，我的系統(tǒng)是Windows XP) 。抱著濃厚的興趣，我決定深入研究。略有收獲，愿與大家共享。
Dialupass星號密碼顯示之謎
看上去，Dialupass是非普通的星號密碼顯示工具，那它的原理是什么呢？上Google查了一番，沒找到相關資料。一生氣便抄起家伙——Windbg，準備把它大卸八塊。郁悶的是，用Windbg加載后，密碼就不能還原出來了，顯示的是星號。換替補Ollydbg上場，情況依舊。怪了，莫非這小工具有Anti-Debug功能？當時只是一絲懷疑，因為實在不相信這樣的小工具作者會花心思來保護。
小知識：
Windbg工具：
Windbg是微軟開發(fā)的免費源碼級調(diào)試工具。可以用于Kernel模式調(diào)試和用戶模式調(diào)試，還可以調(diào)試Dump文件。
Anti-Debug技術：
Anti-Debug，即反跟蹤技術。防止 Cracker 用 SoftICE 之類的調(diào)試器動態(tài)跟蹤，分析軟件。反跟蹤技術一般是具有針對性的，即針對某種調(diào)試器的反跟蹤，而不能防止所有的調(diào)試器跟蹤。
在用S-ICE跟蹤的過程中，發(fā)現(xiàn)有這么一個調(diào)用：GetProcAddress(xx, “IsDebugPresent”)。原來真的有Anti-Debug功能，好在比較簡單。統(tǒng)計了一下，總共有五處進行了Anti-Debug檢查。
OK，情況查明了，便換回Windbg來調(diào)試。在Windbg里面有這么一個斷點可繞過Anti-Debug檢測：bp KERNEL32!IsDebuggerPresent “g poi(esp);r eax=0;g”。
花了些時間跟蹤了一下，把Dialupass恢復密碼的流程都搞清楚了。這小程序貓膩還挺多的，總結如下：
1. 關鍵函數(shù)不直接調(diào)用，而是用LoadLibraryA和GetProcAddress來獲取函數(shù)地址后再CALL；
2. 函數(shù)名是經(jīng)過編碼的，反匯編后看字符串是看不到的；
3. 關鍵地方一概用花指令來迷惑你和反匯編軟件。
其實原理很簡單，就是用rasapi32.dll里面的一些函數(shù)來獲取撥號連接的一些信息，再用 ADVAPI32!LsaRetrievePrivateData 函數(shù)來獲取密碼。
關鍵字：LsaRetrievePrivateData和RasDialParams
根據(jù)Dialupass的原理，寫了個類似的工具(完整的源代碼x_dialupass.c可以從.net/src/x_dialupass.c">http://security.xici.net/src/x_dialupass.c獲取)。后來用LsaRetrievePrivateData和RasDialParams做關鍵字，重新在Google搜索了一遍，找到一些類似的代碼。
小提示：
參考資源①和②是俄羅斯人公布的演示代碼，沒有對LsaRetrievePrivateData返回的數(shù)據(jù)進行拆分用戶名和密碼。參考資源③是日本人公布的完整的應用程序的代碼，可惜在對LsaRetrievePrivateData返回的數(shù)據(jù)進行拆分處理時存在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/
后來發(fā)現(xiàn)Lsadump2 DUMP出來的數(shù)據(jù)里面包含了“LsaRetrievePrivateData”返回的數(shù)據(jù)。Lsadump2的原理大致如下：
1.插入一個線程到Lsass.exe進程；
2.打開LSA Policy database；
3.從注冊表“HKLM\SECURITY\Policy\Secrets”中枚舉子鍵；
4.LsarOpenSecret；
5.LsarQuerySecret。
進一步跟蹤后發(fā)現(xiàn)，其實ADVAPI32!LsaRetrievePrivateData是通過NdrClientCall2發(fā)送RPC調(diào)用到Lsass.exe進程，Lsass.exe里面再調(diào)用LsarOpenSecret、LsarQuerySecret來完成獲取撥號連接信息過程的(LsarOpenSecret里面有權限判斷，非Admin組用戶是沒有權限來調(diào)用ADVAPI32!LsaRetrievePrivateData的)。
跟蹤了一下LsarQuerySecret，發(fā)現(xiàn)它返回的數(shù)據(jù)其實是從注冊表中讀取。保存撥號連接信息的注冊表鍵值為：“HKLM(HKEY_LOCAL_MACHINE的縮寫)\SECURITY\Policy\Secrets\RasDialParams!SID#0\CurrVal”。
SID對應的是用戶的String SID (“HKLM\SECURITY”這個鍵只有System有權限讀寫)。
LsarQuerySecret從注冊表中讀取出來數(shù)據(jù)后，接著調(diào)用LsapCrDecryptValue函數(shù)來解密，對于同一臺機器來說，解密時用的KEY始終都是固定的，這個KEY在lsasrv.dll里面的變量名為_LsapDbSecretCipherKey。在Windows 2003里面，變量名不一樣，對應的有兩個，分別為LsapDbSecretCipherKeyWrite和LsapDbSecretCipherKeyRead，但這兩個變量里面的數(shù)據(jù)是一樣的。
LsapCrDecryptValue用的似乎是標準DES算法，解密時主要流程如下：
lsasrv!LsapCrDecryptValue→advapi32!SystemFunction005→advapi32!DecryptDataLength→advapi32!SystemFunction002→advapi32!DES_ECB_LM→advapi32!des
解密后，在“<<”標志處還有一個判斷(如圖所示)。
假如[esi+45h]為0的話(esi是LsarOpenSecret函數(shù)返回的Handle)，它會把解密后的數(shù)據(jù)再進行一次加密，不管是Windows 2000還是Windows 2003，這時用的KEY始終都是固定為“SystemLibraryDTC”。
Lsadump2里面調(diào)用LsarOpenSecret得到的Handle，偏移0x45處值為1，所以LsarQuerySecret函數(shù)返回的就是解密后的數(shù)據(jù)了。
而在調(diào)用ADVAPI32!LsaRetrievePrivateData時，LsarOpenSecret返回的Handle偏移0x45處值為0x0，所以LsarQuerySecret返回的是解密后又加密的數(shù)據(jù)，所以在ADVAPI32!LsaRetrievePrivateData里面還有一個對應的解密過程。相應地，LsapCrEncryptValue加密的主要流程如下：
lsasrv!LsapCrEncryptValue→advapi32!SystemFunction004→advapi32!EncryptDataLength→advapi32!SystemFunction001→advapi32!DES_ECB_LM→advapi32!des
_LsapDbSecretCipherKey是如何產(chǎn)生的？
開始我以為在同一版本的Windows里面，_LsapDbSecretCipherKey是固定的，后來發(fā)現(xiàn)我錯了。那么這個
_LsapDbSecretCipherKey是如何產(chǎn)生的？流程如下：
1.調(diào)用ntdll!NtConnectPort打開 L“\Security\WxApiPort”；
2.調(diào)用ntdll!NtRequestWaitReplyPort得到一些數(shù)據(jù)；
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字節(jié)數(shù)據(jù)COPY到lsasrv.dll里面的_LsapDbSysKey變量。
_LsapDbSysKey在不同的機器上面(即使版本相同)都是不一樣的。它是怎么產(chǎn)生的？有幸拜讀了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
跟蹤系統(tǒng)啟動過程，可知道“\Security\WxApiPort”是由Winlogon.exe進程創(chuàng)建的，然后Lsass進程通過這個LPC PORT從Winlogon進程獲取SYSKEY，隨后Winlogon進程會關閉這個LPC PORT。所以在系統(tǒng)啟動完成之后，用Process Explorer等工具是看不到這個LPC PORT存在的，而且在Winlogon和Lsass進程空間都搜索不到上述SYSKEY。
4.從注冊表“HKLM\SECURITY\Policy\PolSecretEncryptionKey”中讀取出來一段數(shù)據(jù)，調(diào)用函數(shù)_LsapDbDecryptKeyWithSyskey，把它用_LsapDbSysKey來解密，_LsapDbSecretCipherKey就在解密完后的數(shù)據(jù)里面(LsapDbDecryptKeyWithSyskey函數(shù)做的其實就是MD5和RC4運算)。
從注冊表中獲取撥號連接密碼
了解原理后，我們就可以直接從注冊表里面來獲取撥號連接中的密碼等數(shù)據(jù)了。但有幾個問題需要解決：
1.原料：“HKLM\SECURITY”鍵只有SYSTEM有權限讀寫。我們可以把代碼插入到SYSTEM進程里面去運行，或者把這個鍵修改為ADMIN有權限讀，或者提升本進程權限。
2.催化劑：如何獲取_LsapDbSysKey解密用的函數(shù)，_LsapDbDecryptKeyWithSyskey為非導出函數(shù)。可以用Flashsky的代碼來獲取SYSKEY，利用公開的MD5和RC4庫函數(shù)來解密。
直接從Lsass.exe進程里面搜索_LsapDbSecretCipherKey，它的結構如下：
typedef struct _LSA_BLOB {
DWORD cbData;
DWORD cbMaxData;
BYTE pbData;
} LSA_BLOB;
pbData指向存儲KEY的地址，KEY長度固定為0x10字節(jié)，即cbData和cbMaxData都是固定為0x10。所以從Lsass進程的空間里面搜索“\x10\x00\x00\x00\x10\x00\x00\x00”即可找到正確的KEY。結果可能會有多個，可以把所有搜索到的KEY都試一下，總有一個正確的。
3.工具：解密函數(shù)LsapCrDecryptValue為非導出函數(shù)，怎么辦？或許可以根據(jù)特征碼來搜索，但總覺得不太可靠。幸好，LsapCrDecryptValue調(diào)用的advapi32!SystemFunction005是導出函數(shù)。或者直接利用公開的DES庫函數(shù)，自己來運算。