IDM 6.40.11.2 彈窗的完美解決思路
一個(gè)假冒的序列號(hào)被用來注冊Internet Download Manager,IDM正在退出的解決辦法
IDM 6.40.11.2 彈窗的解決思路
前言
在IDM官方下載了IDM的30天試用版。
裝好后,找了一個(gè)和諧工具。運(yùn)行和諧工具后,看IDM關(guān)于那里,已經(jīng)是全功能版本。
美中不足的是,IDM運(yùn)行一段時(shí)間,就會(huì)彈出neg窗口,說文件被修改,最好是去官網(wǎng)下載原版的提示。
我這的彈框如下:
文本提示信息如下:
---------------------------
IDM is corrupt
---------------------------
The main IDM executive file is damaged. It's possible that it was infected with a virus.Please download the latest version of IDM from our web site, and install it over your current version. Just run downloaded IDM installer, and it will replace the damaged files. Do not worry, because all downloads and IDM settings will not be affected
---------------------------
確定
---------------------------
雖然是不影響使用,但是不斷的要關(guān)掉neg窗口會(huì)讓人瘋掉的,弄不好要得強(qiáng)迫癥:(
查看IDMan.exe的屬性,看到版本為 6.40.11.2
在網(wǎng)上找了一下,好像沒有太好的方法去掉neg窗口。
有些方法是針對舊版的,針對這個(gè)新版不好使。
實(shí)驗(yàn)環(huán)境
win10 21H2 + IDA7.7.220118
確定彈窗的所有者
這個(gè)neg彈窗通過spy++看,是IDM主程序彈出的,并不是調(diào)用的外部exe.
開始調(diào)試
那就只能通過無源碼調(diào)試,學(xué)習(xí)研究,擼清彈窗的邏輯。
用IDA載入IDMan.exe,看調(diào)試信息,可以知道IDM6.40.11是用vs2008中的MFC寫的程序。
看到IDM目錄下并沒有MFCDLL, 知道IDM是靜態(tài)使用MFC庫的。
嘗試用IDAx86將IDMan.exe帶著跑起來,看看有沒有機(jī)會(huì)將neg窗口搞掉。
IDM并沒有做明顯的反調(diào)試處理,用IDA帶著IDM跑起來,功能都是正常的。作者比較溫和。
IDM彈出neg窗口是隨機(jī)的,一天反正要彈那么幾次。彈框后,按確定鍵,還會(huì)去IDM官網(wǎng)下載頁面. 次數(shù)多了,真是不耐其煩啊…
還不如作者不給老百姓用,這樣還省心些。
作者為的就是讓和諧版的用戶心煩,然后買原版省心。
關(guān)鍵是作者忽略了像我這種喜歡DIY的用戶,這咋弄?
等了一下午,終于等到IDM彈neg窗口了, 美滋滋。
點(diǎn)擊neg窗口的確定按鈕,打開了網(wǎng)頁,去了IDM站點(diǎn)。url如下:
https://www.internetdownloadmanager.com/download3.html?lng=chn2
在串參考中查找 ?lng=
找到了幾個(gè),唯一和這個(gè)url符合的字符串如下:
.rdata:00CF7164 aSLngS_0 db '%s?lng=%s',0 ; DATA XREF: sub_AF6E90+D51↑o .rdata:00CF7164 ; sub_AFA1A0+D51↑o ...
查找 aSLngS_0 的調(diào)用者就能找到拼url的地方,這個(gè)地方和彈窗是一個(gè)邏輯流。
調(diào)用點(diǎn)一共有3處
debug1
.text:00AF7BE1 push offset aSLngS_0 ; "%s?lng=%s"
debug2
.text:00AFAEF1 push offset aSLngS_0 ; "%s?lng=%s"
debug3
.text:00C40B0C push offset aSLngS_0 ; "%s?lng=%s"
主dlg虛表位置
由debug1查找調(diào)用點(diǎn),逐級回溯查找調(diào)用點(diǎn),找到了主Dlg的虛表。
.rdata:00CF6719 align 10h .rdata:00CF6720 dd offset ??_R4CDownloaderDlg@@6B@ ; const CDownloaderDlg::`RTTI Complete Object Locator' .rdata:00CF6724 ; const CDownloaderDlg::`vftable' .rdata:00CF6724 ??_7CDownloaderDlg@@6B@ dd offset sub_C689EF .rdata:00CF6724 ; DATA XREF: sub_ADD890+40↑o .rdata:00CF6724 ; CRecordset::~CRecordset(void)+30↑o .rdata:00CF6728 dd offset sub_AE0980 .rdata:00CF672C dd offset nullsub_1 .rdata:00CF6730 dd offset unknown_libname_51 ; MFC 3.1-14.0 32bit .rdata:00CF6734 dd offset ?OnFinalRelease@CWnd@@UAEXXZ ; CWnd::OnFinalRelease(void)
根據(jù)自己寫MFC程序的經(jīng)驗(yàn),就在這些虛函數(shù)中找,就能看到判斷程序損壞的邏輯。
看了一圈,沒看到邏輯。我只看了頂層函數(shù),子函數(shù)調(diào)用沒看。應(yīng)該是在那些子函數(shù)中。
換個(gè)方法調(diào)試 - 在這3處啟動(dòng)網(wǎng)頁的地方下斷點(diǎn)
這3處下斷點(diǎn)(F2), 然后用IDA帶著IDM跑起來。
等了3個(gè)小時(shí),IDM終于彈框了。點(diǎn)擊確認(rèn),IDA下的斷點(diǎn)斷住了。
.text:0050AEEC push ecx ; ArgList .text:0050AEED lea edx, [esp+1F8h+var_1D0] .text:0050AEF1 push offset aSLngS_0 ; "%s?lng=%s" // break here .text:0050AEF6 push edx ; int .text:0050AEF7 call sub_492F80 .text:0050AEFC add esp, 1Ch .text:0050AEFF mov byte ptr [esp+1E4h+var_4], bl .text:0050AF06 lea ecx, [esp+1E4h+var_1CC] ; void * .text:0050AF0A call sub_492570
因?yàn)槌绦蚴莿?dòng)態(tài)裝載的,首地址的段不一樣。比較地址后面的4個(gè)字節(jié),可以知道是debug2處的url.
如果查看代碼到了非當(dāng)前IP處,先回到當(dāng)前IP處的代碼。
選擇當(dāng)前線程
在棧窗口跳到ESP
跟隨ESP的反匯編。
這時(shí),就回到了斷住的第一現(xiàn)場。如果自己F7單步過,當(dāng)前現(xiàn)場就在斷點(diǎn)下面2,3行。
打開函數(shù)調(diào)用鏈窗口
可以看到當(dāng)前被斷住的代碼的調(diào)用鏈。
可知,當(dāng)前代碼在sub_50A1A0中。
最近調(diào)用過的一個(gè)函數(shù)是sub_491980
復(fù)制保存當(dāng)前的調(diào)用鏈為文本,用于分析。
.text:0050AD76 call sub_491980 .text:0050AE08 call esi ; GetDesktopWindow .text:0050AE0B call sub_4FDB50 .text:0050AE2B call sub_4911F0 .text:0050AE43 call sub_4930C0 .text:0050AE8D call sub_4921B0 .text:0050AEA1 call _wcsrchr .text:0050AEC1 call _wcsrchr .text:0050AED6 call sub_492A70 .text:0050AEF7 call sub_492F80 .text:0050AF0A call sub_492570 .text:0050AF1B call sub_4911F0 .text:0050AF25 call esi ; GetDesktopWindow .text:0050AF28 call sub_53BEB0 .text:0050AF42 call ds:SetTimer .text:0050AF54 call sub_492570 .text:0050AF68 call sub_4911F0 .text:0050AF8B call @__security_check_cookie@4; __security_check_cookie(x) .text:006CEBAE call @__security_check_cookie@4; __security_check_cookie(x) .text:006CEBBB call @__security_check_cookie@4; __security_check_cookie(x)
回到當(dāng)前IP處的代碼,用圖形方式查看代碼實(shí)現(xiàn),邏輯看的清楚。
同一邏輯的代碼都用在一個(gè)圖形框里面,跳轉(zhuǎn)看的清楚。
鼠標(biāo)左鍵拖動(dòng) + 鼠標(biāo)中鍵滾動(dòng),向上看代碼邏輯。咋走到這里來的?
再看看這個(gè)函數(shù)的圖形調(diào)用鏈。
現(xiàn)在就可以去查fn_msg_proc_sub_B07090中,調(diào)用sub_50A1A0的調(diào)用點(diǎn)。
順著調(diào)用鏈看代碼時(shí),發(fā)現(xiàn)疑似彈窗實(shí)現(xiàn)。
.text:0050AE0B call sub_4FDB50
.text:004FDC1E call ds:MessageBoxW
在 MessageBoxW調(diào)用處下斷點(diǎn)看看。
.idata:006F972C ; int (__stdcall *MessageBoxW)(HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uType) .idata:006F972C MessageBoxW dd offset user32_MessageBoxW
現(xiàn)在有3個(gè)url字符串拼串的斷點(diǎn),剩下斷點(diǎn)都是MessageBoxW的斷點(diǎn),已經(jīng)跑起來了。等彈框。
等到彈框斷點(diǎn)斷住
晚上本本沒關(guān),等到了早上10點(diǎn)鐘左右。IDA被彈窗操作斷下來了。
等了12+小時(shí),終于等到彈框斷點(diǎn)被斷住。作者可能不知道我這么有耐心陪他玩。
.text:004FDC16 .text:004FDC16 loc_4FDC16: .text:004FDC16 mov edx, [esp+34h+uType] .text:004FDC1A push edx ; uType .text:004FDC1B push eax ; lpCaption .text:004FDC1C push ebp ; lpText .text:004FDC1D push edi ; hWnd .text:004FDC1E call ds:MessageBoxW // break here .text:004FDC24 mov esi, eax .text:004FDC26 mov byte ptr [esp+34h+var_4], bl .text:004FDC2A lea ecx, [esp+34h+var_20] ; void * .text:004FDC2E call sub_492570 .text:004FDC33 jmp short loc_4FDC55
這個(gè)斷點(diǎn)在 .text:004FDB50 sub_4FDB50 proc near 函數(shù)中
偏移 = 4FDC1E - 4FDB50 = 206 = 0xCE
按x鍵時(shí),可以看到這個(gè)斷點(diǎn)為
p sub_4FDB50+CE call ds:MessageBoxW
棧窗口內(nèi)容
// 棧是向上生長的 // 每多調(diào)用一個(gè)函數(shù),地址就減少 // 當(dāng)斷下時(shí),棧地址 = 063DF674 // 代碼為 .text:004FDC16 mov edx, [esp+34h+uType] .text:004FDC1A push edx ; uType .text:004FDC1B push eax ; lpCaption .text:004FDC1C push ebp ; lpText .text:004FDC1D push edi ; hWnd .text:004FDC1E call ds:MessageBoxW // 棧地址 = 063DF674 // 此時(shí),按F7步入MessageBoxW,棧地址就變?yōu)?63DF670,棧地址減小了 063DF670 004FDC24 neg_msgbox_sub_4FDB50+D4 063DF674 00010010 // 斷下時(shí)的棧頂 063DF678 0394E340 debug080:0394E340 063DF67C 03949690 debug080:03949690 063DF680 00041030 063DF684 BB18CB49 063DF688 00000035 063DF68C 76B89F90 USER32:user32_GetDesktopWindow 063DF690 00000000 063DF694 00000C8A 063DF698 0394AF70 debug080:0394AF70 063DF69C 03949690 debug080:03949690 063DF6A0 063D0000 063DF6A4 0000000F 063DF6A8 BB18CB59 063DF6AC 063DF8A4 debug286:063DF8A4 063DF6B0 006E09A0 sub_5CF400:SEH_46DB50 063DF6B4 00000001 063DF6B8 0050AE10 sub_50A1A0+C70 063DF6BC 00010010 063DF6C0 0394E340 debug080:0394E340 063DF6C4 063DF700 debug286:063DF700 063DF6C8 00041030 063DF6CC BB18CB11 063DF6D0 011E7470 debug011:011E7470 063DF6D4 0393BBE0 debug080:0393BBE0 063DF6D8 063DF934 debug286:063DF934 063DF6DC 00000C50 063DF6E0 FFFFFFFE 063DF6E4 012B0000 debug030:012B0000 063DF6E8 4014006A 063DF6EC 00000000 063DF6F0 772A0000 ntdll:772A0000 063DF6F4 0394E340 debug080:0394E340 063DF6F8 00000000 063DF6FC 00000157 063DF700 204D4449 063DF704 63207369 063DF708 7572726F Crypt32:crypt32_I_CryptInstallOssGlobal+546F 063DF70C A2007470 063DF710 70747468 063DF714 772F2F3A ntdll:ntdll_RtlGetThreadPreferredUILanguages+18A 063DF718 692E7777 063DF71C 7265746E 063DF720 6474656E 063DF724 6C6E776F 063DF728 6D64616F 063DF72C 67616E61 dcomp:67616E61 063DF730 632E7265 063DF734 642F6D6F 063DF738 6C6E776F 063DF73C 3264616F 063DF740 6D74682E 063DF744 0000006C 063DF748 20656854 063DF74C 6E69616D 063DF750 4D444920 063DF754 65786520 063DF758 69747563 063DF75C 66206576 063DF760 20656C69 063DF764 64207369 063DF768 67616D61 dcomp:67616D61 063DF76C 202E6465 063DF770 73277449 mswsock:73277449 063DF774 736F7020 063DF778 6C626973 063DF77C 68742065 COMCTL32:comctl32_Ordinal234+BEE5 063DF780 69207461 063DF784 61772074 063DF788 6E692073 063DF78C 74636566 windows.storage:74636566 063DF790 77206465 COMDLG32:77206465 063DF794 20687469 063DF798 69762061 063DF79C 2E737572 063DF7A0 0A0D0A0D 063DF7A4 61656C50 063DF7A8 64206573 063DF7AC 6C6E776F 063DF7B0 2064616F 063DF7B4 20656874 063DF7B8 6574616C 063DF7BC 76207473 SETUPAPI:76207473 063DF7C0 69737265 063DF7C4 6F206E6F 063DF7C8 44492066 063DF7CC 7266204D 063DF7D0 6F206D6F 063DF7D4 77207275 COMDLG32:77207275 063DF7D8 73206265 RASAPI32:73206265 063DF7DC 2C657469 063DF7E0 646E6120 063DF7E4 736E6920 063DF7E8 6C6C6174 063DF7EC 20746920 063DF7F0 7265766F 063DF7F4 756F7920 Crypt32:crypt32_RegCreateHKCUKeyExU+8F20 063DF7F8 75632072 KERNEL32:kernel32_WakeConditionVariable+1E8C 063DF7FC 6E657272 063DF800 65762074 063DF804 6F697372 063DF808 4A202E6E 063DF80C 20747375 063DF810 206E7572 063DF814 6E776F64 063DF818 64616F6C 063DF81C 49206465 063DF820 69204D44 063DF824 6174736E 063DF828 72656C6C 063DF82C 6E61202C 063DF830 74692064 windows.storage:74692064 063DF834 6C697720 063DF838 6572206C 063DF83C 63616C70 schannel:schannel_SpLsaModeInitialize+12420 063DF840 68742065 COMCTL32:comctl32_Ordinal234+BEE5 063DF844 61642065 063DF848 6567616D 063DF84C 69662064 063DF850 2E73656C 063DF854 206F4420 063DF858 20746F6E 063DF85C 72726F77 063DF860 62202C79 063DF864 75616365 KERNEL32:kernel32_Wow64Transition+4331 063DF868 61206573 063DF86C 64206C6C 063DF870 6C6E776F 063DF874 7364616F 063DF878 646E6120 063DF87C 4D444920 063DF880 74657320 windows.storage:74657320 063DF884 676E6974 dcomp:dcomp_DllGetClassObject+31B04 063DF888 69772073 063DF88C 6E206C6C 063DF890 6220746F 063DF894 66612065 063DF898 74636566 windows.storage:74636566 063DF89C 01006465 063DF8A0 BB18CB21 063DF8A4 063DF928 debug286:063DF928 063DF8A8 006CEB9C sub_506E90:SEH_47A1A0 063DF8AC 00000000 063DF8B0 00682640 _AfxThreadEntry(void *)+DA 063DF8B4 00000000 063DF8B8 BB18C4F5 063DF8BC 006AD07B _threadstartex(x) 063DF8C0 0394E930 debug080:0394E930 063DF8C4 0394E930 debug080:0394E930 063DF8C8 00000000 063DF8CC 0078458C .rdata:const CWnd::`vftable' 063DF8D0 00000001 063DF8D4 00000000 063DF8D8 00000000 063DF8DC 00000000 063DF8E0 00000001 063DF8E4 00000000 063DF8E8 012C57D8 debug030:012C57D8 063DF8EC 00000000 063DF8F0 D378BE00 063DF8F4 00000000 063DF8F8 00000000 063DF8FC 007844FC .rdata:const CWnd::XAccessible::`vftable' 063DF900 00784570 .rdata:const CWnd::XAccessibleServer::`vftable' 063DF904 00000000 063DF908 00000000 063DF90C 00000000 063DF910 00000000 063DF914 00000000 063DF918 00000000 063DF91C 00000000 063DF920 0393BBE0 debug080:0393BBE0 063DF924 063DF8B8 debug286:063DF8B8 063DF928 063DF95C debug286:063DF95C 063DF92C 006EAD0D _AfxThreadEntry(void *):loc_6EAD0D 063DF930 00000000 063DF934 063DF96C debug286:063DF96C 063DF938 006AD055 __callthreadstartex+1B 063DF93C 011E7470 debug011:011E7470 063DF940 BB18C4AD 063DF944 006AD07B _threadstartex(x) 063DF948 0394E930 debug080:0394E930 063DF94C 0394E930 debug080:0394E930 063DF950 063DF940 debug286:063DF940 063DF954 063DF940 debug286:063DF940 063DF958 063DF9D4 debug286:063DF9D4 063DF95C 063DF9D4 debug286:063DF9D4 063DF960 006A69B0 SEH_6337D0 063DF964 BD59D039 063DF968 00000000 063DF96C 063DF978 debug286:063DF978 063DF970 006AD0FD .text:006AD0FD 063DF974 006AD07B _threadstartex(x) 063DF978 063DF988 debug286:063DF988 063DF97C 755AFA29 KERNEL32:kernel32_BaseThreadInitThunk+19 063DF980 0394E930 debug080:0394E930 063DF984 755AFA10 KERNEL32:kernel32_BaseThreadInitThunk 063DF988 063DF9E4 debug286:063DF9E4 063DF98C 77307A7E ntdll:ntdll_RtlGetAppContainerNamedObjectPath+11E 063DF990 0394E930 debug080:0394E930 063DF994 D378BF44 063DF998 00000000 063DF99C 00000000 063DF9A0 0394E930 debug080:0394E930 063DF9A4 00000000 063DF9A8 00000000 063DF9AC 00000000 063DF9B0 00000000 063DF9B4 00000000 063DF9B8 00000000 063DF9BC 00000000 063DF9C0 00000000 063DF9C4 00000000 063DF9C8 00000000 063DF9CC 063DF994 debug286:063DF994 063DF9D0 00000000 063DF9D4 063DF9EC debug286:063DF9EC 063DF9D8 7731AD20 ntdll:ntdll_wcstombs+70 063DF9DC A27F8F80 063DF9E0 00000000 063DF9E4 063DF9F4 debug286:063DF9F4 063DF9E8 77307A4E ntdll:ntdll_RtlGetAppContainerNamedObjectPath+EE 063DF9EC FFFFFFFF 063DF9F0 77328A28 ntdll:ntdll_RtlCaptureContext+E8 063DF9F4 00000000 063DF9F8 00000000 063DF9FC 006AD07B _threadstartex(x) 063DFA00 0394E930 debug080:0394E930
彈窗后,F(xiàn)7/F8 單步,回到了 sub_50A1A0
unsigned int __cdecl fn_show_neg_wnd_sub_50A1A0(void *a1) { // 這個(gè)函數(shù)功能 // 給彈框內(nèi)容賦值,一個(gè)一個(gè)字節(jié)的賦值,翻譯字符串成寬字符串。讓調(diào)試者在字符串表中,找不到現(xiàn)成的字符串。 // 然后彈框 // ... v14 = v7; DesktopWindow = GetDesktopWindow(); neg_msgbox_sub_4FDB50(DesktopWindow, v14, v24, 0x41030u); if ( a1 ) { v27 = -1; fn_delete_sub_4911F0(); return 1; } else { sub_4930C0(ArgList); ... v15 = v16; v13 = GetDesktopWindow(); sub_53BEB0(v13, v15); // 這里疑似打開下載網(wǎng)頁 if ( hWnd ) SetTimer(hWnd, 0x26u, 0x36EE80u, 0); // 這個(gè)定時(shí)器(0x26)應(yīng)該就是neg窗口檢測的定時(shí)器。 // 0x36EE80u = 3600000 = 3600秒 = 60分鐘 = 1小時(shí) // 這個(gè)定時(shí)器一個(gè)小時(shí)的,而且這個(gè)定時(shí)器1小時(shí)時(shí)間到后,也不是每次都彈框。 // 可以考慮在1小時(shí)定時(shí)器中,不干活。 LOBYTE(v27) = 0; fn_free_sub_492570(&v16); v27 = -1; fn_delete_sub_4911F0(); return 0; }
單步出來,到MFC線程函數(shù)操作中了
if ( v6 ) { v7 = v6(v1[13]); // 執(zhí)行 fn_show_neg_wnd_sub_50A1A0 } else { v8 = (*(int (__thiscall **)(_DWORD *))(*v1 + 80))(v1) == 0; v9 = *v1; if ( v8 ) v7 = (*(int (__thiscall **)(_DWORD *))(v9 + 104))(v1); else v7 = (*(int (__thiscall **)(_DWORD *))(v9 + 84))(v1); } v10 = v7; CWnd::Detach((CWnd *)v11); AfxEndThread(v10, 1); }
通過單步,已經(jīng)知道IDM是用26號(hào)定時(shí)器(觸發(fā)時(shí)間1個(gè)小時(shí))來彈neg窗口和neg URL.
neg線程函數(shù)為 fn_show_neg_wnd_sub_50A1A0
停掉IDA調(diào)試,回分析狀態(tài)。
在函數(shù)列表中過濾出 fn_show_neg_wnd_sub_50A1A0
查找 fn_show_neg_wnd_sub_50A1A0的調(diào)用點(diǎn)
可以看到只有一處,雙擊過去瞧瞧。
.text:0051D68F .text:0051D68F loc_51D68F: ; CODE XREF: fn_msg_proc_sub_B07090+2A1A↑j .text:0051D68F ; DATA XREF: .text:jpt_519AAA↓o .text:0051D68F push 0 ; jumptable 00519AAA case 5355 .text:0051D691 push 0 ; unsigned int .text:0051D693 push 0 ; StackSize .text:0051D695 push 0 ; int .text:0051D697 push 0 ; void * .text:0051D699 push offset fn_show_neg_wnd_sub_50A1A0 ; unsigned int (__cdecl *)(void *) .text:0051D69E call ?AfxBeginThread@@YGPAVCWinThread@@P6AIPAX@Z0HIKPAU_SECURITY_ATTRIBUTES@@@Z ; AfxBeginThread(uint (*)(void *),void *,int,uint,ulong,_SECURITY_ATTRIBUTES *) .text:0051D6A3 mov eax, 1 .text:0051D6A8 wait .text:0051D6A9 jmp loc_51F405
看到了不? 這里起了一個(gè)neg線程。
往上拉,看看這個(gè)起neg線程的函數(shù)的整體含義。
這是一個(gè)消息處理函數(shù)啊
int __thiscall fn_msg_proc_sub_B07090(int this, UINT wParam, LPARAM a3) { // CWnd::OnCommand 處理 LPARAM v4; // ecx // ... // 消息ID = 0x14EB case 0x14EBu: AfxBeginThread(fn_show_neg_wnd_sub_50A1A0, 0, 0, 0, 0, 0); // 這里啟動(dòng)neg線程 return 1; case 0x14ECu: if ( sub_4E6AE0(v384, v385) ) return 1; v247 = *(WPARAM **)(this + 492); if ( !v247 ) return 1; LABEL_862: sub_4BDBF0(0x111u, *v247, 0); return 1; default: return CWnd::OnCommand((CWnd *)this, wParam, lParam); } // ... LABEL_862: sub_4BDBF0(0x111u, *v247, 0); return 1; default: return CWnd::OnCommand((CWnd *)this, wParam, lParam); } } if ( wParam != 10239 ) return CWnd::OnCommand((CWnd *)this, wParam, lParam); sub_4FB3F0(1); return 1; }
已經(jīng)看到 // 消息ID = 0x14EB 引起建立neg線程
用圖形模式看
loc_51D68F: ; jumptable 00519AAA case 5355 ; 0x14EB is 5355 push 0 push 0 ; unsigned int push 0 ; StackSize push 0 ; int push 0 ; void * push offset fn_show_neg_wnd_sub_50A1A0 ; unsigned int (__cdecl *)(void *) call ?AfxBeginThread@@YGPAVCWinThread@@P6AIPAX@Z0HIKPAU_SECURITY_ATTRIBUTES@@@Z ; AfxBeginThread(uint (*)(void *),void *,int,uint,ulong,_SECURITY_ATTRIBUTES *) mov eax, 1 wait jmp loc_51F405
看看誰發(fā)的消息(ID = 0x14EB or 5355)。
在 fn_msg_proc_sub_B07090 看了,只是消息處理。
消息是外部投遞進(jìn)來的。
一般投遞消息使用postmessage, 特別是這種neg窗口的消息,咱自己寫程序,也不可能用sendmessage.
查看postmessage的調(diào)用點(diǎn),找到 (ID = 0x14EB or 5355)的消息投遞點(diǎn)。
.idata:006F97B0 ; CODE XREF: sub_498BE0+A↑p .idata:006F97B0 ; sub_4B4630+88↑p ... .idata:006F97B4 ; BOOL (__stdcall *PostMessageA)(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam) .idata:006F97B4 extrn PostMessageA:dword .idata:006F97B4 ; CODE XREF: sub_498320+160↑p .idata:006F97B4 ; sub_4AE410+249↑p ...
查看 PostMessageA 的所有調(diào)用。
隨便去一個(gè)postmessage處,看看代碼格式。
.text:0049846F push eax ; lParam .text:00498470 push 14DFh ; wParam .text:00498475 push 111h ; Msg // 這是消息ID .text:0049847A mov eax, hWnd .text:0049847F push eax ; hWnd .text:00498480 call ds:PostMessageA
先找一下文本 push 14EBh
不好找。
將IDA中的反匯編,存成要給.asm, 再來找.
在asm中查找 14EBh,好多都不是。
還得在IDA中找找PostMessageA, 找到一處,就看看上面的MSG ID 是不是 14EBh
這樣找也不行啊,好多ID是用參數(shù)傳進(jìn)來的。并不是一個(gè)立即數(shù)。
找找settimer, ID = 0x26
找到一個(gè)包裝過的設(shè)置定時(shí)器的函數(shù)fn_setimer_sub_4B4B20,在這個(gè)函數(shù)中的SetTimer處下斷點(diǎn)等著。
.text:004B4B20 fn_setimer_sub_4B4B20 proc near ; CODE XREF: sub_4F5860+17D↓p .text:004B4B20 ; sub_4F5860+19C↓p ... .text:004B4B20 .text:004B4B20 nIDEvent= dword ptr 4 .text:004B4B20 uElapse= dword ptr 8 .text:004B4B20 lpTimerFunc= dword ptr 0Ch .text:004B4B20 .text:004B4B20 mov eax, [esp+lpTimerFunc] .text:004B4B24 mov edx, [esp+uElapse] .text:004B4B28 mov ecx, [ecx+20h] .text:004B4B2B push eax ; lpTimerFunc .text:004B4B2C mov eax, [esp+4+nIDEvent] .text:004B4B30 push edx ; uElapse .text:004B4B31 push eax ; nIDEvent .text:004B4B32 push ecx ; hWnd .text:004B4B33 call dword ptr ds:SetTimer // F2 here .text:004B4B39 retn 0Ch .text:004B4B39 fn_setimer_sub_4B4B20 endp
不好使
查找 push 26h 下面是settimer的,找到下面幾處。
loc_507C10: ; CODE XREF: sub_506E90+CBC↑j mov eax, [esp+1E4h+var_1D0] push eax call esi ; GetDesktopWindow push eax call fn_show_dl_url_sub_53BEB0 mov eax, hWnd add esp, 8 cmp eax, ebp jz short loc_507C38 push ebp ; lpTimerFunc push 36EE80h ; uElapse push 26h ; '&' ; nIDEvent push eax ; hWnd call ds:SetTimer
loc_50AF20: ; CODE XREF: fn_show_neg_wnd_sub_50A1A0+CBC↑j mov eax, [esp+1E4h+var_1D0] push eax call esi ; GetDesktopWindow push eax call fn_show_dl_url_sub_53BEB0 mov eax, hWnd add esp, 8 cmp eax, ebp jz short loc_50AF48 push ebp ; lpTimerFunc push 36EE80h ; uElapse push 26h ; '&' ; nIDEvent push eax ; hWnd call ds:SetTimer
; --------------------------------------------------------------------------- loc_5105F3: ; CODE XREF: sub_50FC00+4F↑j ; DATA XREF: .text:jpt_50FC4F↓o ; try { ; jumptable 0050FC4F case 38 mov [ebp+64h+var_68], 14h wait push 26h ; '&' ; uIDEvent mov edx, [esi+20h] push edx ; hWnd call ds:KillTimer push 0 ; lParam push 14BFh ; wParam push 111h ; Msg mov eax, [esi+20h] push eax ; hWnd call ds:PostMessageA wait ; } // starts at 5105F3 mov [ebp+64h+var_68], 0FFFFFFFFh
IDA中跳到一個(gè)地址或label,按 G 鍵,在編輯框中輸入label名稱或地址就行。
不好查,這些斷點(diǎn)都不是很快能觸發(fā)的。
非要從根上找到判斷文件被修改的實(shí)現(xiàn)也不是不行,不值當(dāng),沒那么多時(shí)間陪作者玩。
我們要的是解決問題(去掉neg彈窗)。
那只能先暴力一點(diǎn)點(diǎn),將找到的起neg線程的地方nop掉。管他呢,將bug修復(fù)了再說。
找到的起neg線程的代碼如下:
loc_51D68F: ; jumptable 00519AAA case 5355 ; 0x14EB is 5355 push 0 push 0 ; unsigned int push 0 ; StackSize push 0 ; int push 0 ; void * push offset fn_show_neg_wnd_sub_50A1A0 ; unsigned int (__cdecl *)(void *) call ?AfxBeginThread@@YGPAVCWinThread@@P6AIPAX@Z0HIKPAU_SECURITY_ATTRIBUTES@@@Z ; AfxBeginThread(uint (*)(void *),void *,int,uint,ulong,_SECURITY_ATTRIBUTES *) mov eax, 1 wait jmp loc_51F405
給這段代碼打補(bǔ)丁,前9句都換成nop.
打補(bǔ)丁時(shí),要注意堆棧平衡。否則打過補(bǔ)丁的程序跑起來,過了打補(bǔ)丁的地方就崩了。
打過補(bǔ)丁的代碼如下:
保存工程
將原始文件復(fù)制一份,改名保存. e.g. test_org.exe
保存補(bǔ)丁
可以看到打補(bǔ)丁成功。
退出IDA, 單獨(dú)直接運(yùn)行修改過的同名程序。
開始跑起來,連續(xù)跑1天(24小時(shí)),看看會(huì)出啥問題不?
neg線程前面單步調(diào)試過,除了起neg窗口和開網(wǎng)頁去官網(wǎng)下載頁,沒看到有啥其他功能。
按理說,只是去掉了neg線程的啟動(dòng),應(yīng)該沒啥不良反應(yīng)。
等著看療效。
測試
- 重新下載列表中的程序
啟動(dòng)了安裝好的程序建立的快捷方式,程序跑起來了。
重新下載了一個(gè)下載好的文件,可以重新下載,非常好,沒有不良反應(yīng)。
- 現(xiàn)在就等著就行了,看看會(huì)不會(huì)再出neg框。
前幾天測試,剛裝好,是1,2個(gè)小時(shí)就會(huì)出一次neg框。
這2天,是一天會(huì)出個(gè)幾次neg框。彈窗節(jié)奏是越來越慢了,不知道作者是不是害怕了? 還是針對調(diào)試者做了特殊處理?(看到程序中有檢測調(diào)試器的操作,邏輯沒細(xì)看)
現(xiàn)在將程序直接跑起來(2022_0505_1600),下載都正常。準(zhǔn)備跑12+個(gè)小時(shí),看看還出neg窗口不?
現(xiàn)在直接將打過補(bǔ)丁的IDM運(yùn)行起來了,已經(jīng)過去了3個(gè)小時(shí),期間也下載了新遠(yuǎn)程文件,功能正常。
…
現(xiàn)在已經(jīng)過了24小時(shí)了(2022_0506_1717), IDM一直開著,期間下載了幾次幾百M(fèi)B的遠(yuǎn)程文件,功能正常。
感覺是搞定了這個(gè)bug,先這樣。
END
原版作者做了一些處理,用于隱藏neg窗口的啟動(dòng)流程。
不過用neg窗口這種東西,惹毛了用戶,被盯上了,就難看了:) 還不如直接不給用。
如果給用,但是不斷騷擾使用者,用戶不是憤怒(誰要是老撩撥自己,肯定不爽啊)就是好奇啊。
用戶有2種:
一種是覺得這軟件真好用,離不開啊…,非要死皮賴臉的用,過了一段時(shí)間,被neg窗口整瘋了,直接跪了,掏錢買原版。另外一種是喜歡DIY的用戶,打死都沒零錢買原版,這咋整啊?
有動(dòng)手能力的用戶會(huì)嘗試去調(diào)試bug, 這是免不了的。調(diào)試個(gè)程序,誰還不會(huì)啊? 多大點(diǎn)事…
最后能不能將bug搞定,看實(shí)力也看運(yùn)氣,啥不會(huì)我現(xiàn)學(xué)行不? 只要bug是可以重現(xiàn)的,總有解決的那一天,調(diào)試者有的是時(shí)間和思路。
總的來說,只要有需求,調(diào)試者(逆向工程師)比作者(純正向工程師)更有耐心。
作者要考慮的多,必有疏漏。這是一定的。不是有個(gè)成語"百密一疏"么?
調(diào)試者只是針對一個(gè)bug,可以撒著歡的調(diào)試。
補(bǔ)充 - 2022_0518_1602
現(xiàn)在已經(jīng)用改過的IDM 6.40.11.2 很久了. 效果非常好, 沒有副作用.
看來bug修正思路是正確的.
補(bǔ)充 - 2022_0530_1638
有的同學(xué)非要下載鏈接, 還不是一個(gè)人這樣要求…
鄙人承諾: 此博客文章沒有下載鏈接.
我們都不要做違法的事情, 這是底線啊.
IDM 6.40.11.2 的這個(gè)彈窗bug, 修正的思路和實(shí)現(xiàn)細(xì)節(jié)已經(jīng)描述的很清楚. 僅供有興趣的同學(xué)在DIY時(shí)參考.
只是拋磚引玉, 說不定能引發(fā)您想出更好的思路.
對DIY沒興趣的同學(xué), 只能坐等網(wǎng)上大神們放出新的和諧包了. 請不要在此博客再留言要下載鏈接.
補(bǔ)充 - 2022_1021_2149
今天有同學(xué)留言, 問具體咋解決的.
看到這樣的留言, 整的我好無語. 這文章不是將思路和實(shí)現(xiàn)細(xì)節(jié)都講清楚了么? 言無不盡啊, 不知道再補(bǔ)充些什么才好.
如果看了這篇文章還不知道怎么用DIY的方法來解決IDM彈窗的bug, 那說明您需要補(bǔ)充一些逆向方面的知識(shí).
基本這篇文章對您現(xiàn)階段沒用, 大家不在一個(gè)頻道.
今天這么留言的同學(xué), 后來告訴我, 已經(jīng)找到第三方的工具(e.g. 火絨, 360), 將IDM彈窗攔截了, 不用自己來DIY.
這就對了么!
每個(gè)人遇到問題, 總是要找到適合自己現(xiàn)階段的方法. 別人的解決方案僅供參考. 如果找到的資料對自己沒用, 就繼續(xù)找資料, 做實(shí)驗(yàn).
不斷折騰, 總有能正常使用的那一個(gè)高光時(shí)刻.
這個(gè)補(bǔ)充說明, 不僅僅針對這個(gè)具體bug, 其他事情也是一樣的, 總是要自己不斷折騰, 才能找到適合自己現(xiàn)階段的方法. 這世界上, 現(xiàn)成的事情是很少的, 也有些事情是錢買不來的, 需要自己動(dòng)手才有吃的
到此這篇關(guān)于IDM 6.40.11.2 彈窗的解決思路的文章就介紹到這了,更多相關(guān)IDM 6.40.11.2彈窗內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
selenium IDE自動(dòng)化測試腳本的實(shí)現(xiàn)
本文主要介紹了selenium IDE自動(dòng)化測試腳本的實(shí)現(xiàn),文中通過示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2022-04-04一文教你在現(xiàn)有Vue項(xiàng)目中嵌入Blazor項(xiàng)目
目前官方只提供了angular和react倆種示例,所以本教程將來講解如何在Vue的現(xiàn)有項(xiàng)目中嵌入使用Blazor項(xiàng)目。文中的方法講解詳細(xì),感興趣的小伙伴可以了解一下2023-01-01Notepad++文本比較插件Compare詳解(最新免費(fèi))
Notepad++是一款強(qiáng)大的文本編輯器,它提供了文件對比功能,可以幫助我們快速找出兩個(gè)文件之間的差異點(diǎn),這篇文章主要介紹了Notepad++文本比較插件Compare詳解(最新免費(fèi)),感興趣的朋友一起看看吧2024-01-01