帶網(wǎng)絡(luò)驗證的程序的破解技術(shù)解析

1、帶網(wǎng)絡(luò)驗證的程序的破解技術(shù) 文件夾內(nèi)有幾個文件 ，分別是 main.dat,start.exeOD 加載 start.exe 退出 ,彈出軟件窗口 ，0D 下斷 CreateProcesS 發(fā)現(xiàn)其翻開的是 main.dat 用 UE 查看 main.dat 原來是個可執(zhí)行文件被改名了， 于是改名為 main.exePE 查殼 ASPack 2.12 -> Alexey Solodov nikov直接 cooldumper 搞定開始分析點擊登錄,出現(xiàn)MessageboxW 未注冊用戶,竊喜,bp MessageBoxW.果斷斷住 ，看堆棧調(diào)用情況0013F550 0065A066 /CAL

2、L 到 MessageBoxW0013F554 007802CC |hOw ner = 007802CC 巴國哈哈1.17',class='TLogi nF orm',pare nt=018803B20013F558 00C6F33C |Text = "?,B4,"",D7,"",A2,"",B2,"嵊?,BB,"? 0013F55C00C76544 |Title = ""D7,"",A2," 意"0013F560 000

3、00000 Style = MB_OK|MB_APPLMODAL0013F564 0013F93C 指向下一個 SEH 記錄的指針0013F568 00546D1F SE 處理程序0013F56C 0013F5F80013F570 0013F7980013F574 0044E700 dumped_.0044E700 0013F578 00BC67C0 ASCII "pkD"0013F57C 000000000013F580 000000000013F584 000000000013F588 000000000013F58C 000000000013F590 00000000

4、0013F594 000000000013F598 000000000013F59C 000000000013F5A0 00C6F33C ASCII "*g 鑜孮 (u7b"0013F5A4 00C765440013F5A8 000000000013F5AC 000000000013F5B0 00C8AA7C UNICODE "d00b-207dcdd2"0013F5B4 00C8AA1C UNICODE "D00B-207DCDD2"0013F5B8 00C8AA4C UNICODE "d00b-207dcdd2"

5、; 0013F5BC 00C8EC14 UNICODE "D:sg117script"0013F5C0 00000000 0013F5C4 000000000013F5C8 000000000013F5CC 000000000013F5D0 00CA581C UNICODE "D:sg117upup.exe"0013F5D4 000000000013F5D8 00CA57E4 UNICODE "D:sg117start.exe"0013F5DC 00C8EC14 UNICODE "D:sg117script"001

6、3F5E0 000000000013F5E4 00CA5774 UNICODE "D:sg117updata.exe"0013F5E8 000000000013F5EC 000000000013F5F0 00C8A9EC UNICODE "D00B-207DCDD2"看到最后面幾行有 D00b 什么的，是軟件上提示的機器碼。 其他沒什么營養(yǎng) ，先 放 住不管?？赡芪也攀鑼W(xué)淺 ，認為這種外掛一定是網(wǎng)絡(luò)驗證的 ，所以也沒去深究這個 D00B 什 么的 ，既然 MessageBox 沒看出什么端倪 ，換方法。bp send, bp recv 全 部打好斷點點擊

7、登錄。斷下在 bp send 看發(fā)包 data 是明文 ，如下0013F2A8 |00C214F8 ASCII "GETHttp:/88:8000/wglogi n/wglogi n. asp?id=9D1669ADA23091A6F45 4E45991E4EB2258E2B2DF5B591B9EA8330EFCB1E3BCF8E6CA50C8AA1E6B98F7 A78CB1 449ADBF6DC2C2DECE8F09C85&port=8020 HTTP/1.1",CR 丄 F,"Host:88"

8、,CR,LF,"Connection: Ke".好長的一段串啊 ， 不管它查下堆棧很容易發(fā)現(xiàn)它的組包過程。幾個 Unicode 串擺在堆棧里面 ，是由之前的 D00B-207DCDD2+ 我硬盤號 +我MAC 地址+個時間數(shù) ，然后看長度好似將這些參數(shù)組合進行了一次SHA 運算 ，得出的這個串 .當然這只是猜測 ，我認為沒必要去跟組包的算法。畢竟網(wǎng)絡(luò)驗證都是通過 回包 的信息進行各種跳 ， 各種邏輯的。直接 F9 跑到 recv 這里看看 ， 收包明文 ，如下0013F274 |0110A048 ASCII "HTTP/1.1 200 OK",CR 丄

9、F,"Co nn ectio n:keep-alive",CR 丄 F,"Content-Type: text/html",CR,LF,"Content-Length:20",CR, LF,"Server: In dy/9.00.10",CR,LF,CR, LF,"REG:AAEDGWE29AB8C" 恩效勞器回來的包很短 REG:AAEDGWE29AB8C分析一下發(fā)包的包值吧 ， 每次發(fā)包相同值都是9D1669ADA23091A6F454E45991E4EB2258E2B2DF5B591B不同

10、點的地方在于后面 ，如果我每次把不同的值記錄下來 ，發(fā)一樣的 ，效勞器是否 會給我回一樣的包呢 ， 測試一下。使用一次截獲的包進行測試 F7A78CB1449ADBF6DC2C2DECE8F09C85013F2A8 |00C214F8 ASCII "GETHttp:/88:8000/wglogi n/wglogi n. asp?id=9D1669ADA23091A6F45 4E45991E4EB2258E2B2DF5B591B9EA8330EFCB1E3BCF8E6CA50C8AA1E6B98F7 A78CB1 449ADBF6DC2C2DECE8F09C85

11、&port=8020 HTTP/1.1",CR丄 F,"Host:88",CR,LF,"Connection: Ke".效勞器回的結(jié)果兩次完全一致0013F274 |0110A048 ASCII "HTTP/1.1 200 OK",CR 丄 F,"Co nn ectio n:keep-alive",CR 丄 F,"Content-Type: text/html",CR,LF,"Content-Length:20",CR, LF,&qu

12、ot;Server: In dy/9.00.10",CR,LF,CR, LF,"REG:AAED1FAE8829AB8C"0013F274 |0110A048 ASCII "HTTP/1.1 200 OK",CR ,L F,"Co nn ectio n:keep-alive",CR,LF,"Content-Type: text/html",CR,LF,"Content-Length:20",CR, LF,"Server: In dy/9.00.10",CR,LF,C

13、R, LF,"REG:AAED1FAE8829AB8C"由此斷定 ,效勞器那邊并沒有隨機算法。客戶端和效勞器端只有一方進行了隨 機處理 ，外掛并沒有做雙面的隨機同步。那么請各位大牛幫小弟分析一下這樣做是否可行 ？hook 其 Send Api ，修改驗證效勞器地址 ， 改寫為本地購置一個正版 KEY, 截獲正確的發(fā)包收包的數(shù)據(jù) ，記錄然后每次 hook Send 將包重組 ， 發(fā)給本地效勞器 ，本地效勞器返回剛剛截獲到的正確回包值 ， 是否就可以破解追到了一個地方 ，那個地方將 Reg 后面的值 push 進去 ，但是在里面沒進行什么操 作 就 ret 了。不知道是不是關(guān)鍵點00426FB5 85C0 test eax, eax00426FB7 74 05 je short 00426FBE00426FB9 83E8 04 sub eax, 400426FBC 8B00 mov eax, dword ptr eax00426FBE 8BD8 mov ebx, eax00426FC0 85DB test ebx, ebx00426FC2 74 16 je short 00426FDA00426FC4 8BCB mov ec