亲宝软件园·资讯

展开

IDM 6.40.11.2 弹窗的完美解决思路

LostSpeed 人气:0

一个假冒的序列号被用来注册Internet Download Manager,IDM正在退出的解决办法

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线程的启动,应该没啥不良反应。

等着看疗效。

测试

启动了安装好的程序建立的快捷方式,程序跑起来了。

重新下载了一个下载好的文件,可以重新下载,非常好,没有不良反应。

前几天测试,刚装好,是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,可以撒着欢的调试。

补充 - 2022_0518_1602

现在已经用改过的IDM 6.40.11.2 很久了. 效果非常好, 没有副作用.
看来bug修正思路是正确的.

补充 - 2022_0530_1638

有的同学非要下载链接, 还不是一个人这样要求…
鄙人承诺: 此博客文章没有下载链接.
我们都不要做违法的事情, 这是底线啊.
IDM 6.40.11.2 的这个弹窗bug, 修正的思路和实现细节已经描述的很清楚. 仅供有兴趣的同学在DIY时参考.
只是抛砖引玉, 说不定能引发您想出更好的思路.
对DIY没兴趣的同学, 只能坐等网上大神们放出新的和谐包了. 请不要在此博客再留言要下载链接.

补充 - 2022_1021_2149

今天有同学留言, 问具体咋解决的.
看到这样的留言, 整的我好无语. 这文章不是将思路和实现细节都讲清楚了么? 言无不尽啊, 不知道再补充些什么才好.

如果看了这篇文章还不知道怎么用DIY的方法来解决IDM弹窗的bug, 那说明您需要补充一些逆向方面的知识.
基本这篇文章对您现阶段没用, 大家不在一个频道.

今天这么留言的同学, 后来告诉我, 已经找到第三方的工具(e.g. 火绒, 360), 将IDM弹窗拦截了, 不用自己来DIY.
这就对了么!

每个人遇到问题, 总是要找到适合自己现阶段的方法. 别人的解决方案仅供参考. 如果找到的资料对自己没用, 就继续找资料, 做实验.
不断折腾, 总有能正常使用的那一个高光时刻.

这个补充说明, 不仅仅针对这个具体bug, 其他事情也是一样的, 总是要自己不断折腾, 才能找到适合自己现阶段的方法. 这世界上, 现成的事情是很少的, 也有些事情是钱买不来的, 需要自己动手才有吃的

加载全部内容

相关教程
猜你喜欢
用户评论