4.1 IDA对XP SP2/2003 SP1个人防火墙的影响

D: scz & hume 2005-06-29 17:40

IDA启动时向255.255.255.255发送源端口、目标端口均为23945的UDP报文，同时自己
侦听在0.0.0.0的23945/UDP口上。如果局域网内其它主机上运行的IDA收到前面那个
检测报文，将回送相应的响应报文，本机IDA收到响应报文后出现版权方面的提示，
并阻止继续使用IDA。

XP SP1的个人防火墙启用后很好地解决了这个问题，检测报文仍会被发出，但始终收
不到响应报文。

XP SP2/2003 SP1的个人防火墙多了一个所谓"信任应用程序列表"的概念:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\AuthorizedApplications\List

IDA启动时会自动将自身加入该列表，从而绕过个人防火墙。假设从列表中删除IDA或
进行其它等价操作，下次IDA启动时仍会自动将自身加入该列表，十分讨嫌。

今天下午看到IDA安装目录下有一个win_fw.dll。hume唆使我用AspackDie141对
win_fw.dll脱壳，然后用IDA反汇编脱壳后的文件。总共只有两个Public符号:

start(x,x,x)

int __stdcall windows_firewall_enable_app
(
    LPCSTR  lpMultiByteStr,
    int,
    int
)

我们大胆地将win_fw.dll改成_win_fw.dll，其实删除亦可，再将"信任应用程序列表"
中的IDA删除，现在启动IDA，就不会自动将自身加入"信任应用程序列表"。至此以为
问题得到圆满解决，但实测时发现更恶心的事。

"信任应用程序列表"中没有允许IDA，仅仅意味着其它主机上的IDA发送检测报文时本
机收不到，也就不会发送响应报文。但是本机IDA主动发送检测报文引发的响应报文
仍会被本机IDA收到。

在经过一系列烦不胜烦的测试观察之后，我们有如下几点怀疑与结论:

a)

怀疑IDA动用raw socket支持下的sniffer技术收取响应报文。而XP SP2/2003 SP1的
个人防火墙与XP SP1相比，在raw socket问题上有了重大变动，从而产生差异。

b)

怀疑XP SP2/2003 SP1的个人防火墙在这里体现了一种让人无奈的基于状态的"好"特
性，有发就有收。可XP SP1的个人防火墙为什么没让IDA得逞。

c)

确认IDA是用UDP套接字发送检测报文。因为如果基它进程抢先侦听在23945/UDP口上，
Ethereal根本抓不到IDA发送的检测报文，唯一解释是IDA试图调用bind()指定源端口
时失败，检测报文根本没有被发送出去。

d)

确认IDA是用UDP套接字接收检测报文(不是响应报文)，测试方案同上。

一种经过实测的变态解决方案是，抢先侦听0.0.0.0的23945/UDP口，比如:

nc -vv -l -u -p 23945

然后再启动IDA。或者先启动一个IDA引发版权告警，但不要点确定，留在那里，再启
动其它IDA实例，最后在版权告警上点击确定。显然，后面这个办法与nc那个办法是
同一原理。

不想这么变态的话，可以动用其它防火墙机制。

将win_fw.dll改成_win_fw.dll虽然对自己没什么帮助，但可以帮助别人。