实际上目前所有的OICQ探测方法都一样，发送一个OICQ消息给对方，凭借OICQ的返回信息来判断对方的OICQ号码，具体的DELPHI实现如下：
NMUDP1是ICS控件包的UDP控件。
NMUDP1.ReportLevel := Status_Basic;
NMUDP1.RemoteHost := edit1.Text;
NMUDP1.RemotePort := 4000;
UdpTmpStr :=#$02 +#$03 +#$0a +#$00 +#$78 +#13 +#$A
+ ’88888′ +#$1f +#$30 +#$1f + #$33 + #$39 +#$1f
+FormatDateTime(‘yyyy-mm-dd’,now)
+#$1f
+FormatDateTime(‘hh:mm:ss’,now)
+#$1f
+ ‘你正在被某位朋友查询。他使用了追捕这个工具软件(http://www.zhuibu.com/)进行探测，此OICQ号码已经被反
馈给对方。’
+ ‘信息所提示的OICQ号码为虚假号码，但可以即时回复。’ + #$03;
if OicqCheck.Checked then begin
for SendUdpNum:=1 to 10 do begin
MyStream := TMemoryStream.Create;
try
MyStream.Write(UdpTmpStr[1], Length(UdpTmpStr));
NMUDP1.SendStream(MyStream);
finally
MyStream.Free;
end;
end;
end;
追捕是怎样得到检测结果的呢？下面是具体实现的程序段:
MyStream := TMemoryStream.Create;
try
NMUDP1.ReadStream(MyStream);
SetLength(TmpStr,NumberBytes);
MyStream.Read(TmpStr[1],NumberBytes);
finally
MyStream.Free;
end;
j := Pos( #$02 +#$02 +#$00 +#$00 , TmpStr);
k := Pos( #$02 +#$03 +#$00 +#$00 , TmpStr);
m := Pos( #$02 +#$03 +#$0a +#$00 , TmpStr);
o := Pos( #$02 +#$03 +#$02 +#$00 , TmpStr);
if (j=1) or (k=1) or (m=1) or (o=1) then begin
j := Pos( #$02 +#$02 +#$00 +#$00 + ‘y’, TmpStr);
k := Pos( #$02 +#$03 +#$00 +#$00 + ‘y’, TmpStr);
m := Pos( #$02 +#$03 +#$0a +#$00 + ‘y’, TmpStr);
o := Pos( #$02 +#$03 +#$02 +#$00 + ‘y’, TmpStr);
OicqVer := ‘未知’;
if j=1 then OicqVer := ’425′;
if k=1 then OicqVer := ’725′;
if m=1 then OicqVer := ’820′;
if o=1 then OicqVer := ’810′;
if (j=1) or (k=1) or (m=1) or (o=1) then begin
TmpS := ”;
for j:=1 to length(TmpStr) do begin
if TmpStr[j] in ['0'..'9'] then tmpS := tmpS + TmpStr[j];
end;
if TmpS=’0′ then Label2.Caption := ‘OICQ处于关闭状态，版本:’+ OicqVer
else Label2.Caption :=’OICQ号码为’+ TmpS + ‘,版本:’+ OicqVer;
end;
j := Pos( #$02 +#$02 +#$00 +#$00 + ‘x’, TmpStr);
k := Pos( #$02 +#$03 +#$00 +#$00 + ‘x’, TmpStr);
m := Pos( #$02 +#$03 +#$0a +#$00 + ‘x’, TmpStr);
o := Pos( #$02 +#$03 +#$02 +#$00 + ‘x’, TmpStr);
if (j=1) or (k=1) or (m=1) or (o=1) then begin
J := 8;
TmpOicqNUm := ”;
While TmpStr[J]<>#$1f do begin
TmpOicqNum :=TmpOicqNum + TmpStr[J];
Inc(J);
end;
J := J + 6;
While TmpStr[J]<>#$1f do begin
Inc(J);
end;
J := J + 1;
While TmpStr[J]<>#$1f do begin
Inc(J);
end;
J := J + 1;
TmpOicqMsg := ”;
While TmpStr[J]<>#$03 do begin
TmpOicqMsg := TmpOicqMsg + TmpStr[J];
Inc(J);
end;
if TmpOicqMsg<>LastOicqMessage then begin
LastOicqMessage := TmpOicqMsg;
Messagebox(Form1.handle, Pchar(‘OICQ用户’ + TmpOicqNum + ‘对你的探测作出回应：’
+ #$0D + #$0A + TmpOicqMsg), ‘警告信息’, MB_ICONWARNING +mb_ok);
end;
end;
exit;
end;
附：OICQ原理
Oicq的安全问题
前言:
Oicq 作为Inet实时通讯应该是一个不错的选择，众多的用户群也证明了这点。(按照腾讯主页（www.tencent.com)上的说话,截至目前，Oicq 用户已经突破 450 万，而且以每天30000的速度增加）在安全问题日益突出的今天，一个如此*广泛使用*的产品不去考虑安全方面的问题，显然是不明智的。而且这个考虑应该是在产品规划阶段就提上日程的。Oicq 显然没有把安全放在第一位，几个月前，安安（watchsea@sina.com）就已经指出了 Oicq 存放在本地的用户口令仅仅使用了微弱的加密手段。（ build:220 中，Oicq声称已经将其修正）
经过我们的分析测试，更加严重的问题还在后面。在发现了这些问题后，我们马上通知了腾讯公司，腾讯的反应很快，一夜间，Oicq 的版本就从220 升级到了410 . 在其 whatnew 中，声称解决了这些问题。我们立即对其进行了测试。应该看到，在 Oicq build 410 中，腾讯使用了某种加密协议，从而解决了明文传输的问题。应该说是一个很大的进步。因此本文分为两章，第一章针对 Oicq Build 220 及其以下版本。第二章针对 Oicq Build 410 (截至目前最新版本）应该看到，本文不带有任何地感情色彩，我们也是使用 Oicq 进行日常的联络的.希望腾讯公司能尽快的解决这些问题。
测试报告：
除开安全问题，Oicq 应该是一个很好的选择，其功能实用，不花哨。但作为一个放在互连网上的产品，必须还要考虑到安全性。Oicq 采用的是 server-client 模型，使用的是 UDP 协议。和 TCP 相比，UDP 本身就是不可靠的，可被轻易的伪造。使用 UDP 协议的软件必须自身在两端进行可靠性检测。但和 TCP 相比,UDP 在资源占用上显然要小许多，这也是 Icq,Oicq 选择 UDP 的一个主要原因。经过分析，Oicq 在所有的传输过程中，任何数据都使用了明文发送，也就是说，一个窃听者能直接的偷听到经过其的所有 OICQ 信息。这是一个不大不小的问题，象往常一样，你有两个选择，更低的资源占用率和更高的安全性。很难作出决定在二者之间。显然， Oicq 选择了前者。在Oicq中最常用的消息传送时，Oicq 采用了如下策略： 当二者能直接（点到点）通讯时，消息就直接的发送到对方，否则重试 N 次后通过Oicq 服务器转发。接受方在收到消息后返回一个回应信息，发送方就是通过这个信息来确认消息是否已经收到。
消息的结构是：
（注意：本文中所有的 Oicq 协议结构是通过分析得来，不能保证其正确性）
struct TOicqPtoP
{
char Tag1; // 0×02 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag2; // 0×01 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag3; // 0×07
char Tag4; // 0×00
char Tag5; // 0×78
char Tag6; // 这两个字节相当于 unix 上的进程 ID,
char Tag7; // 随便赋值就可。
char cOicqNub[]; // 发送方的Oicq 号码。 Exp:123456
char cFF; // 0x1f 在所有的Oicq 信息结构中，分割符都是 0x1f
char cR; // ’0′ 固定
char cFF; //
char cE[]; // “75″ ，这一位相对固定，可能是操作方式。
char cFF;
char cDateTime[]; // exp: “2000-4-10″,0x1f,”12:00:12″,0x1f
char OutMsg[]; // 发送的消息内容。
char cEnd; // 0×03 ,所有的 oicq 信息都已 0×03 为标记结束。
};
当接受方收到以上格式的 Udp Packet,就会显示有信息收到，完全没有其他的验证过程。也就是说，如果我从linux上发了个符合上述格式的 Udp packet,在 cOicqNub 处可填写任意的oicq 号码，也就是可以伪造了任何的 oicq 号码。(你看到Oicq 上显示号码为 1 的用户向你发信，不要吃惊。)
例如：有 A, B ,C 三用户，Oicq 分别是：
A: 10000
B: 20000
C: 30000
已知 B 和 C 是好友，则 A 可以发送一个带有 B 号码的Udppacket 给 C, 在 C 处看来，完全就像是 B 亲自发给他的一样，但此时如果 C 点回复的话，信息会回到 B 的地址(IP)上。A 不能收到。也就是说 A 只能冒充B 发消息。如果此时 A 不停地发，就形成了Oicq Flood,注意的是，此时Tag6,Tag7 两处要不停地变化，Oicq 对两个完全一样的信息只显示一次。严重的是，虽然Oicq 本身对发送的消息的长度做了限制，但这种限制是在发送方进行的，一旦发送的长度超过 2000 or >2000 个字节，接受方的 Oicq 就会发生缓冲区溢出，相当严重的远程溢出。接下来就是谈谈怎样让 C 回复伪造消息时直接返回到 A 处。运行 Oicq 时，过程如下：
start oicq.exe-> 上线 -> oicq 把口令发给 oicq server -> oicq server 返回
其好友名单以及其对应的 IP (Oicq 把他存到本地内存中的一张表中)当 Oicq 给相应的好友号码发送消息时，依据的地址就是这个 IP.即首先与该 IP 联系，反复多次没有回音就通过服务器转发。
下面是 Oicq server 通知Oicq 好友上线和下线的消息结构：
struct TOicqUp
{
char Tag1; // 0×02 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag2; // 0×01 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag3; // 0×00
char Tag4; // 0×00
char Tag5; // 0×81
char Tag6; // 这两个字节相当于 unix 上的进程 ID,
char Tag7; // 随便赋值就可。
char cOicqNub[]; // 通知上线的Oicq 号码。 Exp:123456
char cFF; // 0x1f 在所有的Oicq 信息结构中，分割符都是 0x1f
char cIP; // 该号码所在的 IP 地址
char cFF; //
char cE[]; // “8685″ ，这一位相对固定，随便添一个四位数字
char cFF;
char cDD[]; // exp: “10″,0x1f,”107″ 基本固定
char cEnd; // 0×03 ,所有的 oicq 信息都已 0×03 为标记结束。
};
//——————————————————–
struct TOicqDown
{
char Tag1; // 0×02 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag2; // 0×01 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag3; // 0×00
char Tag4; // 0×00
char Tag5; // 0×81
char Tag6; // 这两个字节相当于 unix 上的进程 ID,
char Tag7; // 随便赋值就可。
char cOicqNub[]; // 通知上线的Oicq 号码。 Exp:123456
char cFF; // 0x1f 在所有的Oicq 信息结构中，分割符都是 0x1f
char cIP; // 该号码所在的 IP 地址 // 随便填
char cFF; //
char cE[]; // “8685″ ，这一位相对固定，随便添一个四位数字
char cFF;
char cDD[]; // exp: “20″,0x1f,”107″ 基本固定
char cEnd; // 0×03 ,所有的 oicq 信息都已 0×03 为标记结束。
};
向目标发送一个上述的Udp packet ，可让任意的在其列表上的好友上线或下线。在上线时，IP 可填任意的你所希望的。然后Oicq 就会更据该 IP 来发送消息。这样，上面的例子就改为：
首先， A 发送一个带有 B 上线信号的消息给 C, 但其 IP 添写 A 自己的IP,不管此时 B 在线上没有， C 的 oicq 中就会显示 B 正在线上，此时 C 给 B 发消息，更据的地址(IP) 就是 A 的地址，其所有的消息都会发往 A 处。
但此时有个问题：
如果 C 反复发送多次都没有收到来自 B 的回复时，就会通过Oicq 服务器转发。这样 真正的 B 也会收到。解决方案是 C 在收到消息的同时也给 A 发送一个回复。结构是：
struct TOicqReply
{
char Tag1; // 0×02 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag2; // 0×01 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag3; // 0×07
char Tag4; // 0×00
char Tag5; // 0×79
char Tag6; // 值得注意的是，此时Tag6,Tag7 不能随便了，应该添写发过来的消息中的
char Tag7; // Tag6,Tag7.
char cOicqNub[]; // Oicq 号码。 Exp:123456
char cEnd; // 0×03 ,所有的 oicq 信息都已 0×03 为标记结束。
};
//——————————————————–
值得注意的是，如果此时 A 所指定 C 回复的 IP 处正好有一个 Oicq , C 发给 B 的信息就会直接显示在其上面，不用伪造回复包。至此，完整的一次Oicq 欺骗就完成了。
再来一次：
A 发送一个带有 B 上线信号的消息给 C, 但其 IP 添写 A 自己的IP(或所希望的),这样 C 的 oicq 中就显示了 B 正在线上，当 C 给 B 发消息时，更据的地址却是 A 的地址，其所有的消息都会发往 A 处。A 及时的返回一个表示已收到的消息给 C ，C 处不会感到任何地异常，就仿佛是在和真正的 B 通讯一样，如果当 A 发送消息时 B 已经在 C 的Oicq 线上，此时 C 的 IP 表中关于 B 的ip是其真实的 地址，此时我们有两种方法：
1. 向 c 发送一个 B 已下线的信号，让真正的 B 下线，然后再发送一个假的上线信号
2. 直接发送一个假的 B 上线信号，同样的， C 的IP 表中关于 B 的地址也会更新。
在 Oicq 的所有消息传送过程中，除了上线和下线时向oicq server 效对了口令之外，其余的所有过程中，都没有进行任何的口令效验. 显然这是腾讯公司程序员的疏忽。
-
- II –
-
在我们告知腾讯公司关于 Oicq 的问题之后，腾讯很快的就推出了一个新版。以修正其安全问题。在此之前，我就得知，Oicq 最近会有大的改动，可能是我们的原因，迫使得他们提前将不成熟版推出。在新版中, 腾讯使用了某种新的算法将所有的明文进行加密。算法的强度我们不得而知。但应该会在很大的程度上增强其安全性。
如果其早一周公布，这篇文章也就不会公布了。在新版中，以前能随意使用户上下线的方法不行了，但其他的问题依然存在。首先是缓冲区溢出，问题依然，任何熟悉安全的人士都知道这是个严重问题远不止当掉 Oicq 那么简单。希望腾讯能马上解决。
其次是类似于 build: 220 中那种假冒任意用户的 bug 依然如故。方法一样。这也是个严重的问题，我们应该相信谁？
最后是象 Build 220 中那种完全欺骗 C 的技巧依然存在，即可以在某些情况下截获任何人的对话，然后冒充之。这个问题严重吗？赫赫
老话，希望腾讯马上修正。
总结：
有 ICQ 的前车之鉴， Oicq 本应做得更好。作为一个传递着纵多用户隐私的重要通讯工具，Oicq 应该说在安全方面做得很糟。发展到现在，为了保持向下兼容，Oicq 也很难立即作出大的改动。希望腾讯公司能尽可能修复这些问题，保护好广大用户的利益。
zer9 (zer9@21cn.com)
2000-4-12 15:47 于 I S B A S E 网络安全实验室
声明：我们对该程序不提供技术支持,也不提供任何的保证.
NMUDP1是ICS控件包的UDP控件。
NMUDP1.ReportLevel := Status_Basic;
NMUDP1.RemoteHost := edit1.Text;
NMUDP1.RemotePort := 4000;
UdpTmpStr :=#$02 +#$03 +#$0a +#$00 +#$78 +#13 +#$A
+ ’88888′ +#$1f +#$30 +#$1f + #$33 + #$39 +#$1f
+FormatDateTime(‘yyyy-mm-dd’,now)
+#$1f
+FormatDateTime(‘hh:mm:ss’,now)
+#$1f
+ ‘你正在被某位朋友查询。他使用了追捕这个工具软件(http://www.zhuibu.com/)进行探测，此OICQ号码已经被反
馈给对方。’
+ ‘信息所提示的OICQ号码为虚假号码，但可以即时回复。’ + #$03;
if OicqCheck.Checked then begin
for SendUdpNum:=1 to 10 do begin
MyStream := TMemoryStream.Create;
try
MyStream.Write(UdpTmpStr[1], Length(UdpTmpStr));
NMUDP1.SendStream(MyStream);
finally
MyStream.Free;
end;
end;
end;
追捕是怎样得到检测结果的呢？下面是具体实现的程序段:
MyStream := TMemoryStream.Create;
try
NMUDP1.ReadStream(MyStream);
SetLength(TmpStr,NumberBytes);
MyStream.Read(TmpStr[1],NumberBytes);
finally
MyStream.Free;
end;
j := Pos( #$02 +#$02 +#$00 +#$00 , TmpStr);
k := Pos( #$02 +#$03 +#$00 +#$00 , TmpStr);
m := Pos( #$02 +#$03 +#$0a +#$00 , TmpStr);
o := Pos( #$02 +#$03 +#$02 +#$00 , TmpStr);
if (j=1) or (k=1) or (m=1) or (o=1) then begin
j := Pos( #$02 +#$02 +#$00 +#$00 + ‘y’, TmpStr);
k := Pos( #$02 +#$03 +#$00 +#$00 + ‘y’, TmpStr);
m := Pos( #$02 +#$03 +#$0a +#$00 + ‘y’, TmpStr);
o := Pos( #$02 +#$03 +#$02 +#$00 + ‘y’, TmpStr);
OicqVer := ‘未知’;
if j=1 then OicqVer := ’425′;
if k=1 then OicqVer := ’725′;
if m=1 then OicqVer := ’820′;
if o=1 then OicqVer := ’810′;
if (j=1) or (k=1) or (m=1) or (o=1) then begin
TmpS := ”;
for j:=1 to length(TmpStr) do begin
if TmpStr[j] in ['0'..'9'] then tmpS := tmpS + TmpStr[j];
end;
if TmpS=’0′ then Label2.Caption := ‘OICQ处于关闭状态，版本:’+ OicqVer
else Label2.Caption :=’OICQ号码为’+ TmpS + ‘,版本:’+ OicqVer;
end;
j := Pos( #$02 +#$02 +#$00 +#$00 + ‘x’, TmpStr);
k := Pos( #$02 +#$03 +#$00 +#$00 + ‘x’, TmpStr);
m := Pos( #$02 +#$03 +#$0a +#$00 + ‘x’, TmpStr);
o := Pos( #$02 +#$03 +#$02 +#$00 + ‘x’, TmpStr);
if (j=1) or (k=1) or (m=1) or (o=1) then begin
J := 8;
TmpOicqNUm := ”;
While TmpStr[J]<>#$1f do begin
TmpOicqNum :=TmpOicqNum + TmpStr[J];
Inc(J);
end;
J := J + 6;
While TmpStr[J]<>#$1f do begin
Inc(J);
end;
J := J + 1;
While TmpStr[J]<>#$1f do begin
Inc(J);
end;
J := J + 1;
TmpOicqMsg := ”;
While TmpStr[J]<>#$03 do begin
TmpOicqMsg := TmpOicqMsg + TmpStr[J];
Inc(J);
end;
if TmpOicqMsg<>LastOicqMessage then begin
LastOicqMessage := TmpOicqMsg;
Messagebox(Form1.handle, Pchar(‘OICQ用户’ + TmpOicqNum + ‘对你的探测作出回应：’
+ #$0D + #$0A + TmpOicqMsg), ‘警告信息’, MB_ICONWARNING +mb_ok);
end;
end;
exit;
end;
附：OICQ原理
Oicq的安全问题
前言:
Oicq 作为Inet实时通讯应该是一个不错的选择，众多的用户群也证明了这点。(按照腾讯主页（www.tencent.com)上的说话,截至目前，Oicq 用户已经突破 450 万，而且以每天30000的速度增加）在安全问题日益突出的今天，一个如此*广泛使用*的产品不去考虑安全方面的问题，显然是不明智的。而且这个考虑应该是在产品规划阶段就提上日程的。Oicq 显然没有把安全放在第一位，几个月前，安安（watchsea@sina.com）就已经指出了 Oicq 存放在本地的用户口令仅仅使用了微弱的加密手段。（ build:220 中，Oicq声称已经将其修正）
经过我们的分析测试，更加严重的问题还在后面。在发现了这些问题后，我们马上通知了腾讯公司，腾讯的反应很快，一夜间，Oicq 的版本就从220 升级到了410 . 在其 whatnew 中，声称解决了这些问题。我们立即对其进行了测试。应该看到，在 Oicq build 410 中，腾讯使用了某种加密协议，从而解决了明文传输的问题。应该说是一个很大的进步。因此本文分为两章，第一章针对 Oicq Build 220 及其以下版本。第二章针对 Oicq Build 410 (截至目前最新版本）应该看到，本文不带有任何地感情色彩，我们也是使用 Oicq 进行日常的联络的.希望腾讯公司能尽快的解决这些问题。
测试报告：
除开安全问题，Oicq 应该是一个很好的选择，其功能实用，不花哨。但作为一个放在互连网上的产品，必须还要考虑到安全性。Oicq 采用的是 server-client 模型，使用的是 UDP 协议。和 TCP 相比，UDP 本身就是不可靠的，可被轻易的伪造。使用 UDP 协议的软件必须自身在两端进行可靠性检测。但和 TCP 相比,UDP 在资源占用上显然要小许多，这也是 Icq,Oicq 选择 UDP 的一个主要原因。经过分析，Oicq 在所有的传输过程中，任何数据都使用了明文发送，也就是说，一个窃听者能直接的偷听到经过其的所有 OICQ 信息。这是一个不大不小的问题，象往常一样，你有两个选择，更低的资源占用率和更高的安全性。很难作出决定在二者之间。显然， Oicq 选择了前者。在Oicq中最常用的消息传送时，Oicq 采用了如下策略： 当二者能直接（点到点）通讯时，消息就直接的发送到对方，否则重试 N 次后通过Oicq 服务器转发。接受方在收到消息后返回一个回应信息，发送方就是通过这个信息来确认消息是否已经收到。
消息的结构是：
（注意：本文中所有的 Oicq 协议结构是通过分析得来，不能保证其正确性）
struct TOicqPtoP
{
char Tag1; // 0×02 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag2; // 0×01 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag3; // 0×07
char Tag4; // 0×00
char Tag5; // 0×78
char Tag6; // 这两个字节相当于 unix 上的进程 ID,
char Tag7; // 随便赋值就可。
char cOicqNub[]; // 发送方的Oicq 号码。 Exp:123456
char cFF; // 0x1f 在所有的Oicq 信息结构中，分割符都是 0x1f
char cR; // ’0′ 固定
char cFF; //
char cE[]; // “75″ ，这一位相对固定，可能是操作方式。
char cFF;
char cDateTime[]; // exp: “2000-4-10″,0x1f,”12:00:12″,0x1f
char OutMsg[]; // 发送的消息内容。
char cEnd; // 0×03 ,所有的 oicq 信息都已 0×03 为标记结束。
};
当接受方收到以上格式的 Udp Packet,就会显示有信息收到，完全没有其他的验证过程。也就是说，如果我从linux上发了个符合上述格式的 Udp packet,在 cOicqNub 处可填写任意的oicq 号码，也就是可以伪造了任何的 oicq 号码。(你看到Oicq 上显示号码为 1 的用户向你发信，不要吃惊。)
例如：有 A, B ,C 三用户，Oicq 分别是：
A: 10000
B: 20000
C: 30000
已知 B 和 C 是好友，则 A 可以发送一个带有 B 号码的Udppacket 给 C, 在 C 处看来，完全就像是 B 亲自发给他的一样，但此时如果 C 点回复的话，信息会回到 B 的地址(IP)上。A 不能收到。也就是说 A 只能冒充B 发消息。如果此时 A 不停地发，就形成了Oicq Flood,注意的是，此时Tag6,Tag7 两处要不停地变化，Oicq 对两个完全一样的信息只显示一次。严重的是，虽然Oicq 本身对发送的消息的长度做了限制，但这种限制是在发送方进行的，一旦发送的长度超过 2000 or >2000 个字节，接受方的 Oicq 就会发生缓冲区溢出，相当严重的远程溢出。接下来就是谈谈怎样让 C 回复伪造消息时直接返回到 A 处。运行 Oicq 时，过程如下：
start oicq.exe-> 上线 -> oicq 把口令发给 oicq server -> oicq server 返回
其好友名单以及其对应的 IP (Oicq 把他存到本地内存中的一张表中)当 Oicq 给相应的好友号码发送消息时，依据的地址就是这个 IP.即首先与该 IP 联系，反复多次没有回音就通过服务器转发。
下面是 Oicq server 通知Oicq 好友上线和下线的消息结构：
struct TOicqUp
{
char Tag1; // 0×02 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag2; // 0×01 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag3; // 0×00
char Tag4; // 0×00
char Tag5; // 0×81
char Tag6; // 这两个字节相当于 unix 上的进程 ID,
char Tag7; // 随便赋值就可。
char cOicqNub[]; // 通知上线的Oicq 号码。 Exp:123456
char cFF; // 0x1f 在所有的Oicq 信息结构中，分割符都是 0x1f
char cIP; // 该号码所在的 IP 地址
char cFF; //
char cE[]; // “8685″ ，这一位相对固定，随便添一个四位数字
char cFF;
char cDD[]; // exp: “10″,0x1f,”107″ 基本固定
char cEnd; // 0×03 ,所有的 oicq 信息都已 0×03 为标记结束。
};
//——————————————————–
struct TOicqDown
{
char Tag1; // 0×02 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag2; // 0×01 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag3; // 0×00
char Tag4; // 0×00
char Tag5; // 0×81
char Tag6; // 这两个字节相当于 unix 上的进程 ID,
char Tag7; // 随便赋值就可。
char cOicqNub[]; // 通知上线的Oicq 号码。 Exp:123456
char cFF; // 0x1f 在所有的Oicq 信息结构中，分割符都是 0x1f
char cIP; // 该号码所在的 IP 地址 // 随便填
char cFF; //
char cE[]; // “8685″ ，这一位相对固定，随便添一个四位数字
char cFF;
char cDD[]; // exp: “20″,0x1f,”107″ 基本固定
char cEnd; // 0×03 ,所有的 oicq 信息都已 0×03 为标记结束。
};
向目标发送一个上述的Udp packet ，可让任意的在其列表上的好友上线或下线。在上线时，IP 可填任意的你所希望的。然后Oicq 就会更据该 IP 来发送消息。这样，上面的例子就改为：
首先， A 发送一个带有 B 上线信号的消息给 C, 但其 IP 添写 A 自己的IP,不管此时 B 在线上没有， C 的 oicq 中就会显示 B 正在线上，此时 C 给 B 发消息，更据的地址(IP) 就是 A 的地址，其所有的消息都会发往 A 处。
但此时有个问题：
如果 C 反复发送多次都没有收到来自 B 的回复时，就会通过Oicq 服务器转发。这样 真正的 B 也会收到。解决方案是 C 在收到消息的同时也给 A 发送一个回复。结构是：
struct TOicqReply
{
char Tag1; // 0×02 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag2; // 0×01 // 显然是 Oicq 的协议编号 or 版本，固定
char Tag3; // 0×07
char Tag4; // 0×00
char Tag5; // 0×79
char Tag6; // 值得注意的是，此时Tag6,Tag7 不能随便了，应该添写发过来的消息中的
char Tag7; // Tag6,Tag7.
char cOicqNub[]; // Oicq 号码。 Exp:123456
char cEnd; // 0×03 ,所有的 oicq 信息都已 0×03 为标记结束。
};
//——————————————————–
值得注意的是，如果此时 A 所指定 C 回复的 IP 处正好有一个 Oicq , C 发给 B 的信息就会直接显示在其上面，不用伪造回复包。至此，完整的一次Oicq 欺骗就完成了。
再来一次：
A 发送一个带有 B 上线信号的消息给 C, 但其 IP 添写 A 自己的IP(或所希望的),这样 C 的 oicq 中就显示了 B 正在线上，当 C 给 B 发消息时，更据的地址却是 A 的地址，其所有的消息都会发往 A 处。A 及时的返回一个表示已收到的消息给 C ，C 处不会感到任何地异常，就仿佛是在和真正的 B 通讯一样，如果当 A 发送消息时 B 已经在 C 的Oicq 线上，此时 C 的 IP 表中关于 B 的ip是其真实的 地址，此时我们有两种方法：
1. 向 c 发送一个 B 已下线的信号，让真正的 B 下线，然后再发送一个假的上线信号
2. 直接发送一个假的 B 上线信号，同样的， C 的IP 表中关于 B 的地址也会更新。
在 Oicq 的所有消息传送过程中，除了上线和下线时向oicq server 效对了口令之外，其余的所有过程中，都没有进行任何的口令效验. 显然这是腾讯公司程序员的疏忽。
-
- II –
-
在我们告知腾讯公司关于 Oicq 的问题之后，腾讯很快的就推出了一个新版。以修正其安全问题。在此之前，我就得知，Oicq 最近会有大的改动，可能是我们的原因，迫使得他们提前将不成熟版推出。在新版中, 腾讯使用了某种新的算法将所有的明文进行加密。算法的强度我们不得而知。但应该会在很大的程度上增强其安全性。
如果其早一周公布，这篇文章也就不会公布了。在新版中，以前能随意使用户上下线的方法不行了，但其他的问题依然存在。首先是缓冲区溢出，问题依然，任何熟悉安全的人士都知道这是个严重问题远不止当掉 Oicq 那么简单。希望腾讯能马上解决。
其次是类似于 build: 220 中那种假冒任意用户的 bug 依然如故。方法一样。这也是个严重的问题，我们应该相信谁？
最后是象 Build 220 中那种完全欺骗 C 的技巧依然存在，即可以在某些情况下截获任何人的对话，然后冒充之。这个问题严重吗？赫赫
老话，希望腾讯马上修正。
总结：
有 ICQ 的前车之鉴， Oicq 本应做得更好。作为一个传递着纵多用户隐私的重要通讯工具，Oicq 应该说在安全方面做得很糟。发展到现在，为了保持向下兼容，Oicq 也很难立即作出大的改动。希望腾讯公司能尽可能修复这些问题，保护好广大用户的利益。
zer9 (zer9@21cn.com)
2000-4-12 15:47 于 I S B A S E 网络安全实验室
声明：我们对该程序不提供技术支持,也不提供任何的保证.
>> 本文固定链接: http://www.vcgood.com/archives/791
