📄 248.htm
字号:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>CTerm非常精华下载</title>
</head>
<body bgcolor="#FFFFFF">
<table border="0" width="100%" cellspacing="0" cellpadding="0" height="577">
<tr><td width="32%" rowspan="3" height="123"><img src="DDl_back.jpg" width="300" height="129" alt="DDl_back.jpg"></td><td width="30%" background="DDl_back2.jpg" height="35"><p align="center"><a href="http://apue.dhs.org"><font face="黑体"><big><big>apue</big></big></font></a></td></tr>
<tr>
<td width="68%" background="DDl_back2.jpg" height="44"><big><big><font face="黑体"><p align="center"> ● UNIX网络编程 (BM: clown) </font></big></big></td></tr>
<tr>
<td width="68%" height="44" bgcolor="#000000"><font face="黑体"><big><big><p align="center"></big></big><a href="http://cterm.163.net"><img src="banner.gif" width="400" height="60" alt="banner.gif"border="0"></a></font></td>
</tr>
<tr><td width="100%" colspan="2" height="100" align="center" valign="top"><br><p align="center">[<a href="index.htm">回到开始</a>][<a href="245.htm">上一层</a>][<a href="249.htm">下一篇</a>]
<hr><p align="left"><small>发信人: guru (好读书，不求甚解), 信区: UNP <br>
标 题: Oicq 协议结构(转) <br>
发信站: UNIX编程 (2001年09月22日19:19:21 星期六), 站内信件 <br>
<br>
>>http://c58.xiloo.com/new_page_5.htm <br>
Oicq安全问题 <br>
前言： <br>
Oicq 作为Inet实时通讯应该是一个不错的选择，其众多的用户群也证明了这点。( <br>
按照腾讯主页（www.tencent.com)上的说话,截至目前，Oicq 用户已经突破 450 万，而 <br>
且以每天30000的速度增加） <br>
在安全问题日益突出的今天，一个如此*广泛使用*的产品不去考虑安全方面的问题 <br>
，显然是不明智的。而且这个考虑应该是在产品规划阶段就提上日程的。Oicq 显然没有 <br>
把安全放在第一位，几个月前，安安（watchsea@sina.com）就已经指出了 Oicq 存放在 <br>
本地的用户口令仅仅使用了微弱的加密手段。 （ build:220 中，Oicq声称已经将其修 <br>
正） <br>
经过我们的分析测试，更加严重的问题还在后面。在发现了这些问题后，我们马上 <br>
通知了腾讯公司，腾讯的反应很快，一夜间，Oicq 的版本就从220 升级到了 410 . 在 <br>
其 whatnew 中，声称解决了这些问题。 <br>
我们立即对其进行了测试。应该看到，在 Oicq build 410 中，腾讯使用了某种加 <br>
密协议，从而解决了明文传输的问题。应该说是一个很大的进步。 <br>
因此本文分为两章，第一章针对 Oicq Build 220 及其以下版本。 <br>
第二章针对 Oicq Build 410 (截至目前最新版本） <br>
应该看到，本文不带有任何地感情色彩，我们也是使用 Oicq 进行日常的联络的.希 <br>
望腾讯公司能尽快的解决这些问题。 <br>
- I - <br>
- <br>
测试报告： <br>
除开安全问题，Oicq 应该是一个很好的选择，其功能实用，不花哨。但作为一个放 <br>
在互连网上的产品，必须还要考虑到安全性。Oicq 采用的是 server-client 模型，使 <br>
用的是 UDP 协议。和 TCP 相比，UDP 本身就是不可靠的，可被轻易的伪造。使用 UDP <br>
协议的软件必须自身在两端进行可靠性检测。但和 TCP 相比,UDP 在资源占用上显然要 <br>
小许多，这也是 Icq,Oicq 选择 UDP 的一个主要原因。 <br>
经过分析，Oicq 在所有的传输过程中，任何数据都使用了明文发送，也就是说，一 <br>
个窃听者能直接的偷听到经过其的所有 OICQ 信息。这是一个不大不小的问题，象往常 <br>
一样，你有两个选择，更低的资源占用率和更高的安全性。很难作出决定在二者之间。 <br>
显然， Oicq 选择了前者。 <br>
在Oicq中最常用的消息传送时，Oicq 采用了如下策略： 当二者能直接（点到点） <br>
通讯时，消息就直接的发送到对方，否则重试 N 次后通过Oicq 服务器转发。接受方在 <br>
收到消息后返回一个回应信息，发送方就是通过这个信息来确认消息是否已经收到。 <br>
消息的结构是： <br>
:（注意：本文中所有的 Oicq 协议结构是通过分析得来，不能保证其正确性） <br>
struct TOicqPtoP <br>
{ <br>
char Tag1; // 0x02 // 显然是 Oicq 的协议编号 or 版本，固定 <br>
char Tag2; // 0x01 // 显然是 Oicq 的协议编号 or 版本，固定 <br>
char Tag3; // 0x07 <br>
char Tag4; // 0x00 <br>
char Tag5; // 0x78 <br>
char Tag6; // 这两个字节相当于 unix 上的进程 ID, <br>
char Tag7; // 随便赋值就可。 <br>
char cOicqNub[]; // 发送方的Oicq 号码。 exp:123456 <br>
char cFF; // 0x1f 在所有的Oicq 信息结构中，分割符都是 0x1f <br>
char cR; // '0' 固定 <br>
char cFF; // <br>
char cE[]; // "75" ，这一位相对固定，可能是操作方式。 <br>
char cFF; <br>
char cDateTime[]; // exp: "2000-4-10",0x1f,"12:00:12",0x1f <br>
char OutMsg[]; // 发送的消息内容。 <br>
char cEnd; // 0x03 ,所有的 oicq 信息都已 0x03 为标记结束。 <br>
}; <br>
当接受方收到以上格式的 Udp Packet,就会显示有信息收到，完全没有其他的验证 <br>
过程。也就是说，如果我从 linux 上发了个符合上述格式的 Udp packet,在 cOicqNub <br>
处可填写任意的oicq 号码，也就是可以伪造了任何的 oicq 号码。(你看到Oicq 上显 <br>
示号码为 1 的用户向你发信，不要吃惊。) <br>
例如：有 A, B ,C 三用户，Oicq 分别是： <br>
A: 10000 <br>
B: 20000 <br>
B: 20000 <br>
C: 30000 <br>
已知 B 和 C 是好友，则 A 可以发送一个带有 B 号码的Udppacket 给 C, 在C 处 <br>
看来，完全就像是 B 亲自发给他的一样，但此时如果 C 点回复的话，信息会回到 B 的 <br>
地址(IP)上。A 不能收到。也就是说 A 只能冒充B 发消息。如果此时 A 不停地发，就 <br>
形成了 Oicq Flood,注意的是，此时Tag6,Tag7 两处要不停地变化，Oicq 对两个完全一 <br>
样的信息只显示一次。 <br>
严重的是，虽然Oicq 本身对发送的消息的长度做了限制，但这种限制是在发送方进 <br>
行的，一旦发送的长度超过 2000 or >2000 个字节，接受方的 Oicq 就会发生缓冲区溢 <br>
出，相当严重的远程溢出。 <br>
接下来就是谈谈怎样让 C 回复伪造消息时直接返回到 A 处。 <br>
运行 Oicq 时，过程如下： <br>
start oicq.exe-> 上线 -> oicq 把口令发给 oicq server -> oicq server 返回 <br>
其好友名单以及其对应的 IP (Oicq 把他存到本地内存中的一张表中) <br>
当 Oicq 给相应的好友号码发送消息时，依据的地址就是这个 IP.即首先与该 IP <br>
联系，反复多次没有回音就通过服务器转发。 <br>
下面是 Oicq server 通知Oicq 好友上线和下线的消息结构： <br>
struct TOicqUp <br>
{ <br>
char Tag1; // 0x02 // 显然是 Oicq 的协议编号 or 版本，固定 <br>
char Tag2; // 0x01 // 显然是 Oicq 的协议编号 or 版本，固定 <br>
char Tag3; // 0x00 <br>
char Tag4; // 0x00 <br>
char Tag5; // 0x81 <br>
char Tag6; // 这两个字节相当于 unix 上的进程 ID, <br>
char Tag7; // 随便赋值就可。 <br>
char cOicqNub[]; // 通知上线的Oicq 号码。 exp:123456 <br>
char cFF; // 0x1f 在所有的Oicq 信息结构中，分割符都是 0x1f <br>
char cIP; // 该号码所在的 IP 地址 <br>
char cFF; // <br>
char cE[]; // "8685" ，这一位相对固定，随便添一个四位数字 <br>
char cFF; <br>
char cDD[]; // exp: "10",0x1f,"107" 基本固定 <br>
char cEnd; // 0x03 ,所有的 oicq 信息都已 0x03 为标记结束。 <br>
}; <br>
//-------------------------------------------------------- <br>
struct TOicqDown <br>
{ <br>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -