IDM 6.40.11.2 弹窗的解决思路
前言
在IDM官方下载了IDM的30天试用版。
装好后，找了一个和谐工具。运行和谐工具后，看IDM关于那里，已经是全功能版本。
美中不足的是，IDM运行一段时间，就会弹出neg窗口，说文件被修改，最好是去官网下载原版的提示。
我这的弹框如下：
文本提示信息如下：
---------------------------
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
---------------------------
确定
---------------------------
虽然是不影响使用，但是不断的要关掉neg窗口会让人疯掉的，弄不好要得强迫症:(
查看IDMan.exe的属性，看到版本为 6.40.11.2
在网上找了一下，好像没有太好的方法去掉neg窗口。
有些方法是针对旧版的，针对这个新版不好使。
实验环境
win10 21H2 + IDA7.7.220118
确定弹窗的所有者
这个neg弹窗通过spy++看，是IDM主程序弹出的，并不是调用的外部exe.
开始调试
那就只能通过无源码调试，学习研究，撸清弹窗的逻辑。
用IDA载入IDMan.exe，看调试信息，可以知道IDM6.40.11是用vs2008中的MFC写的程序。
看到IDM目录下并没有MFCDLL, 知道IDM是静态使用MFC库的。
尝试用IDAx86将IDMan.exe带着跑起来，看看有没有机会将neg窗口搞掉。
IDM并没有做明显的反调试处理，用IDA带着IDM跑起来，功能都是正常的。作者比较温和。
IDM弹出neg窗口是随机的，一天反正要弹那么几次。弹框后，按确定键，还会去IDM官网下载页面. 次数多了，真是不耐其烦啊…
还不如作者不给老百姓用，这样还省心些。
作者为的就是让和谐版的用户心烦，然后买原版省心。
关键是作者忽略了像我这种喜欢DIY的用户，这咋弄?
等了一下午，终于等到IDM弹neg窗口了, 美滋滋。
点击neg窗口的确定按钮，打开了网页，去了IDM站点。url如下：
https://www.internetdownloadmanager.com/download3.html?lng=chn2
在串参考中查找 ?lng=
找到了几个，唯一和这个url符合的字符串如下：
.rdata:00CF7164 aSLngS_0 db '%s?lng=%s',0 ; DATA XREF: sub_AF6E90+D51↑o
.rdata:00CF7164 ; sub_AFA1A0+D51↑o ...
查找 aSLngS_0 的调用者就能找到拼url的地方，这个地方和弹窗是一个逻辑流。
调用点一共有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查找调用点，逐级回溯查找调用点，找到了主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)
根据自己写MFC程序的经验，就在这些虚函数中找，就能看到判断程序损坏的逻辑。
看了一圈，没看到逻辑。我只看了顶层函数，子函数调用没看。应该是在那些子函数中。
换个方法调试 - 在这3处启动网页的地方下断点
这3处下断点(F2), 然后用IDA带着IDM跑起来。
等了3个小时，IDM终于弹框了。点击确认，IDA下的断点断住了。
.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
因为程序是动态装载的，首地址的段不一样。比较地址后面的4个字节，可以知道是debug2处的url.
如果查看代码到了非当前IP处，先回到当前IP处的代码。
选择当前线程
在栈窗口跳到ESP
跟随ESP的反汇编。
这时，就回到了断住的第一现场。如果自己F7单步过，当前现场就在断点下面2，3行。
打开函数调用链窗口
可以看到当前被断住的代码的调用链。
可知，当前代码在sub_50A1A0中。
最近调用过的一个函数是sub_491980
复制保存当前的调用链为文本，用于分析。
.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)
回到当前IP处的代码，用图形方式查看代码实现，逻辑看的清楚。
同一逻辑的代码都用在一个图形框里面，跳转看的清楚。
鼠标左键拖动 + 鼠标中键滚动，向上看代码逻辑。咋走到这里来的？
再看看这个函数的图形调用链。
现在就可以去查fn_msg_proc_sub_B07090中，调用sub_50A1A0的调用点。
顺着调用链看代码时，发现疑似弹窗实现。
.text:0050AE0B call sub_4FDB50
.text:004FDC1E call ds:MessageBoxW
在 MessageBoxW调用处下断点看看。
.idata:006F972C ; int (__stdcall *MessageBoxW)(HWND hWnd, LPCWSTR lpText, LPCWSTR lpCaption, UINT uType)
.idata:006F972C MessageBoxW dd offset user32_MessageBoxW
现在有3个url字符串拼串的断点，剩下断点都是MessageBoxW的断点，已经跑起来了。等弹框。
等到弹框断点断住
晚上本本没关，等到了早上10点钟左右。IDA被弹窗操作断下来了。
等了12+小时，终于等到弹框断点被断住。作者可能不知道我这么有耐心陪他玩。
.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
这个断点在 .text:004FDB50 sub_4FDB50 proc near 函数中
偏移 = 4FDC1E - 4FDB50 = 206 = 0xCE
按x键时，可以看到这个断点为
p sub_4FDB50+CE call ds:MessageBoxW
栈窗口内容
// 栈是向上生长的
// 每多调用一个函数，地址就减少
// 当断下时，栈地址 = 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
// 此时，按F7步入MessageBoxW，栈地址就变为063DF670，栈地址减小了
063DF670 004FDC24 neg_msgbox_sub_4FDB50+D4
063DF674 00010010 // 断下时的栈顶
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
弹窗后，F7/F8 单步，回到了 sub_50A1A0
unsigned int __cdecl fn_show_neg_wnd_sub_50A1A0(void *a1)
{
// 这个函数功能
// 给弹框内容赋值，一个一个字节的赋值，翻译字符串成宽字符串。让调试者在字符串表中，找不到现成的字符串。
// 然后弹框
// ...
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); // 这里疑似打开下载网页
if ( hWnd )
SetTimer(hWnd, 0x26u, 0x36EE80u, 0); // 这个定时器(0x26)应该就是neg窗口检测的定时器。
// 0x36EE80u = 3600000 = 3600秒 = 60分钟 = 1小时
// 这个定时器一个小时的，而且这个定时器1小时时间到后，也不是每次都弹框。
// 可以考虑在1小时定时器中，不干活。
LOBYTE(v27) = 0;
fn_free_sub_492570(&v16);
v27 = -1;
fn_delete_sub_4911F0();
return 0;
}
单步出来，到MFC线程函数操作中了
if ( v6 )
{
v7 = v6(v1[13]); // 执行 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);
}
通过单步，已经知道IDM是用26号定时器（触发时间1个小时）来弹neg窗口和neg URL.
neg线程函数为 fn_show_neg_wnd_sub_50A1A0
停掉IDA调试，回分析状态。
在函数列表中过滤出 fn_show_neg_wnd_sub_50A1A0
查找 fn_show_neg_wnd_sub_50A1A0的调用点
可以看到只有一处，双击过去瞧瞧。
.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
看到了不? 这里起了一个neg线程。
往上拉，看看这个起neg线程的函数的整体含义。
这是一个消息处理函数啊
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); // 这里启动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;
}
已经看到 // 消息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
看看谁发的消息（ID = 0x14EB or 5355）。
在 fn_msg_proc_sub_B07090 看了，只是消息处理。
消息是外部投递进来的。
一般投递消息使用postmessage, 特别是这种neg窗口的消息，咱自己写程序，也不可能用sendmessage.
查看postmessage的调用点，找到 （ID = 0x14EB or 5355）的消息投递点。
.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 的所有调用。
随便去一个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是用参数传进来的。并不是一个立即数。
找找settimer, ID = 0x26
找到一个包装过的设置定时器的函数fn_setimer_sub_4B4B20，在这个函数中的SetTimer处下断点等着。
.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中跳到一个地址或label,按 G 键，在编辑框中输入label名称或地址就行。
不好查，这些断点都不是很快能触发的。
非要从根上找到判断文件被修改的实现也不是不行，不值当，没那么多时间陪作者玩。
我们要的是解决问题(去掉neg弹窗)。
那只能先暴力一点点，将找到的起neg线程的地方nop掉。管他呢，将bug修复了再说。
找到的起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
给这段代码打补丁，前9句都换成nop.
打补丁时，要注意堆栈平衡。否则打过补丁的程序跑起来，过了打补丁的地方就崩了。
打过补丁的代码如下：
保存工程
将原始文件复制一份，改名保存. e.g. test_org.exe
保存补丁
可以看到打补丁成功。
退出IDA, 单独直接运行修改过的同名程序。
开始跑起来，连续跑1天(24小时)，看看会出啥问题不？
neg线程前面单步调试过，除了起neg窗口和开网页去官网下载页，没看到有啥其他功能。
按理说，只是去掉了neg线程的启动，应该没啥不良反应。
等着看疗效。
测试
- 重新下载列表中的程序
启动了安装好的程序建立的快捷方式，程序跑起来了。
重新下载了一个下载好的文件，可以重新下载，非常好，没有不良反应。
-
现在就等着就行了，看看会不会再出neg框。
前几天测试，刚装好，是1，2个小时就会出一次neg框。
这2天，是一天会出个几次neg框。弹窗节奏是越来越慢了，不知道作者是不是害怕了? 还是针对调试者做了特殊处理?(看到程序中有检测调试器的操作，逻辑没细看)
现在将程序直接跑起来(2022_0505_1600)，下载都正常。准备跑12+个小时，看看还出neg窗口不？
现在直接将打过补丁的IDM运行起来了，已经过去了3个小时，期间也下载了新远程文件，功能正常。…
现在已经过了24小时了(2022_0506_1717), IDM一直开着，期间下载了几次几百MB的远程文件，功能正常。感觉是搞定了这个bug，先这样。
END
原版作者做了一些处理，用于隐藏neg窗口的启动流程。
不过用neg窗口这种东西，惹毛了用户，被盯上了，就难看了:) 还不如直接不给用。
如果给用，但是不断骚扰使用者，用户不是愤怒(谁要是老撩拨自己，肯定不爽啊)就是好奇啊。
用户有2种:
- 一种是觉得这软件真好用，离不开啊…，非要死皮赖脸的用，过了一段时间，被neg窗口整疯了，直接跪了，掏钱买原版。
- 另外一种是喜欢DIY的用户，打死都没零钱买原版，这咋整啊?
有动手能力的用户会尝试去调试bug, 这是免不了的。调试个程序，谁还不会啊? 多大点事…
最后能不能将bug搞定，看实力也看运气，啥不会我现学行不? 只要bug是可以重现的，总有解决的那一天，调试者有的是时间和思路。
总的来说，只要有需求，调试者(逆向工程师)比作者(纯正向工程师)更有耐心。
作者要考虑的多，必有疏漏。这是一定的。不是有个成语"百密一疏"么？
调试者只是针对一个bug，可以撒着欢的调试。
