协议分析TMP

最近闲来有事, 分析了一个非常低端(非常低端的意思是说你不应该对她是否能取代你现有的QQ客户端作任何可能的奢望,她只是一个实验性的东西)的手机QQ的协议, 是手机QQ3.0, 
     所用到的TCP/HTTP通信协议版本是1.4, 也不知道是哪一年release的了, 至少有七八年的历久了吧, 反正就是: 功能非常弱!

主要的分析原因是想学学网络方面的编程经验(这是我第2次弄socket编程 :-) ), 以及学学怎么抓包分析.

主要用到的工具软件

手机QQ3.0: http://www.ruan8.com/soft_5872.html

kEmulator(Java模拟器):http://gamevina.us/kemulator-vh/

Wireshark(协议分析):http://www.wireshark.org/download.html

Java Decompiler(Java查看(和谐)工具):http://jd.benow.ca/

分析流程简要介绍

1.获取服务器信息

网上分析这个版本手机QQ的用户不在少数, 我也了解到这个版本比较容易分析, 协议简单, 所以...

首先, 打开这个网址:http://conf.3g.qq.com/newConf/kjava/aubin2.jsp

(注意使用unicode编码查看, 否则可能乱码) 然后你就会看到类似下面的东西:

SERERCONFIG_NUM=5& SERVERCONFIG_TYPE=KQQTCP,KQQTCP,KQQHTTP,KQQHTTP,KQQHTTP& SERVERCONFIG_URL=socket://58.60.12.177:14000,socket: //211.136.236.88:14000,http://tqq.tencent.com:8000,http: //mconn.tencent.com:14000,http: //kconn.tencent.com:21001&UPDATAECONFIG_NUM=1& UPDATECONFIG_VERSION=2.4.2&UPDATECONFIG_MUST=N& UPDATECONFIG_URL=http://mq.3g.qq.com/g/s?aid=mqq& UPDATECONFIG_HELPTXT=请升级到2.4.3版QQ2005(Java 版)&SMSSERVICE_NUM=2&SMSSERVICE_NAME=24小时在线,关注好友& SMSSERVICE_ADDRESS=10661700,1066170056& SMSSERVICE_TEXT=HQ,SQKJ%2c||QQNO||&SMSSERVICE_HELPTXT=不用手机上网，通过短信就能登陆QQ，累积在线时间真是方便，让你QQ等级不停增长!%0a当前操作需要通过短信操作完成，选择取定将发送一条短信，请根据收到的短信提示完成操作！, 关注此QQ好友，好友一上QQ马上就会有短信通知你手机！随时随地和TA在QQ上“偶遇”，资费10元/月。%0a当前操作需要通过短信操作完成，选择确定将发送一条短信，请根据收到的短信提示完成操作。

其中:

SERERCONFIG_NUM表示目前可以使用的服务器的个数 
        SERVERCONFIG_TYPE表示服务器类型:KQQTCP表示TCP服务器,KQQHTTP表示HTTP服务器 
        SERVERCONFIG_URL:服务器地址 
        ......(不重要)

注意:各值以逗号分隔; 键值对间使用&符号连接.

至于手机QQ要使用哪个服务器, 现在还不知道, 反正是其中一个, 过滤试一下就知道了.

2.过滤通信协议

先打开Wireshark进行网络封包过滤: 选择一张活动网卡, 然后start.

应该马上就可以看到,  wireshark已经显示了很多数据包... 数据太多, 不便查看, 于是过滤显示一下,

以QQ的第一个tcp服务器为例: 在Wireshark的Filter Expression里面输入过滤表达式, 并点击Apply应用:

用kEmulator运行手机QQ并登录:

接下来, 如果QQ使用了第一个服务器的话, 那么Wireshark将会显示以下信息:

没错, 你没有看错, 协议可以说全部是明文的, 完全就像是HTTP那样的...

比如VER=1.4代表版本号为1.4, CMD=Login表示命令为登录, UIN=***表示QQ...............

3.协议分析

好了, QQ和服务器的所有通信都是基于这种HTTP的键值对方式, 下面列出一些常见的键值对:

VER=1.4 表示当前使用的协议版本, 不过服务器返回的版本可能有所不一致
CON=1 这个不知道是什么意思, 通过查看QQ的代码可见其貌似是固定值1
CMD=*** 当前的命令, 有Login, Logout, Query_Stat2等等.
SEQ=*** 当前命令的序列号, 以此来标识不同的命令序号, 每下一次发送时, 在上一次的基础上加1
UIN=*** 当前登录的QQ号, 不变

命令的规定: 
                   每个命令以\r\n结束, 这就意味着命令字段中不能再出现其它的\r\n, 还有,要把\n换成%0D,\r换成%0D 
                   每条命令都使用UTF-8编码, 同时命令中出现的逗号,&等要转换url编码, 不然要误解释命令.

1.    登录命令: VER=1.4&CON=1&CMD=Login&SEQ={seq}&UIN={qq}&PS={ps}&M5=1&LG=0&LC={lc}&GD={gd}&CKE=\r\n 
       服务器响应:VER=1.1&CMD=Login&SEQ={seq}&UIN=2933278370&RES=0&RS=0&HI=60&LI=300&SG=***&SSG=207390864\r\n 
                   SEQ序号应该和你发送时一样, 不然就是错的. 
                   RES=0代表服务器成功响应 
                   RS=0代表登录成功,其它均为失败; 若失败:则有相应的RA字段标识错误信息, 比如Password Error!

如果有SID或者COMP字段, 记得保存起来, 因为后面的某些搞不懂的命令还要用它们. 其它的比如什么HI和LI就不知道是什么东西了. 
                  如果出现了VC字段, 则说明需要验证码信息, 我测试了很久, 一直没遇到, 暂时不说这个...

2.取得所有QQ好友及其基本信息 
            命令:VER=1.4&CON=1&CMD=SimpleInfo2&SEQ={seq}&UIN={qq}&SID={sid}&XP={xp}&UN=0&TO=0\r\n 
            回复:VER=1.1&CMD=SIMPLEINFO2&SEQ={seq}&&UIN={qq}&RES=0&NP=65535&SN=0&UN=&FC=&NK=\r\n 
                       XP是前面根据login命令计算出来的, 具体可以看我后面的代码. 
                      RES=0同样代表服务器正确响应. 
                      NP=65535表示当前返回了所有的好友信息, 如不是, 需要多次查询, 你应该没有那么多好友吧? 
                      SN表示当前返回的好友基础信息的个数, (注:我全没有写出来) 
                      UN表示好友QQ号, 以逗号分隔(我没列出) 
                      FC表示头像ID 
                      NK表示昵称, 以逗号分隔

3.取得好友状态 
             命令:VER=1.4&CON=1&CMD=Query_Stat2&SEQ={seq}&UIN={qq}&SID=&XP={xp}&CM=2&UN=0\r\n 
            回复:VER=1.1&CMD=QUERY_STAT2&SEQ={seq}&UIN={qq}&RES=0&FN=1&SN=2&ST=10,30&UN=..\r\n 
                        FN是不是finish的意思? 不知道. 
                        SN返回信息的个数 
                        ST状态:10-在线,20-离线,30-离开,40-隐身 
                        UN:QQ号, 与状态一一对应

4.发送消息给好友 
            命令:VER=1.4&CON=1&CMD=CLTMSG&SEQ={seq}&UIN={qq}&SID={sid]&XP={xp}&UN={qq2}&MG={mg}\r\n 
            回复:VER=1.1&CMD=CLTMSG&SEQ={seq}&UIN={qq}&RES=0 
                            UN代表好友的QQ 
                            MG表示消息, 必须是部分url编码的 
5. ............. 
还有几条命令, 比如加好友, 删除好友, 我就不写了 , 加上有些也没做测试.

4.模拟登录

1. 可以先用GET方式获取到服务器IP信息

GET  /newConf/kjava/aubin2.jsp HTTP/1.1 
Accept: text/html, application/xhtml+xml,*/* 
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/6.0) 
Accept-Encoding: utf8 
Host: conf.3g.qq.com 
Connection: Keep-Alive 
[blankline]

2. 然后建立socket并连接到服务器

3.向服务器发送命令

4.处理服务器返回

5...............

5.效果展示

3.完结

文章里面只是简要介绍了一些协议方面的东西, 细节处理, 以及完全的命令列表(我也不全知道)也没有完全列出来,若 
需要参考, 还请查看下面的源代码.

参考文章: 
                                 手机QQ协议分析 （一）登陆 
                                 HTTP/1.1 Request - w3school

未完结的源代码: http://pan.baidu.com/s/1c0iYYDa

作者:女孩不哭 
时间:2014年4月6日 
联系:QQ-191035066 
地址:http://www.cnblogs.com/memset

分类: Socket/套接字

标签: 套接字, socket, 手机QQ, 协议


参考：

微信协议简单调研笔记

微信破解研究总结

Sync协议

　　道听途说，加上上面参考中都是提到微信使用Sync协议。去年项目中做过参考Microsoft Exchange ActiveSync 协议来优化消息协议的方案，虽经过长时间讨论定稿，但由于一些原因最终没有实现；也从中深知Sync并不是表面上那么简单、那么好用。

　　Sync 有啥问题呢？

　　1. SyncKey 生成维护成本

　　　　SyncKey 在ActiveSync中为字符串，客户端不需要解析，但服务端实现要用数字自增，需要强一致性，且不能回退。

　　2. 消息的订阅模式 采用类似Zookeeper的One time triggler 还是每条消息都推送一条通知能

　　　　One time trigger能够避免并发通知时，获取消息时重复问题，但增加了交互成本，和客户端实现复杂性。

　　3. 自己发的消息，SyncKey怎么获取

　　　　尤其要支持多端同步发消息，保证消息同步；也只好消息发完在给自己同步一遍(自己设备发的可以不带消息体）

　　4. 消息推送延时加重

　　　　Sync 消息体获取方式：Notify - Ack - get - Mssage, 也就是至少第四个应用包才能返回消息，在移动网络下成本很高。文中提到消息通过单独https请求，那么延时更为严重了（嗯，实测新版本并非如此）。

手机客户端不再Sync协议

抓包分析版本：Android 微信6.0, 抓包分析可参考：android 移动网络实时抓包

在wifi、gprs网络状况下都相同，客户端会依次尝试使用80、8080、443 端口连接服务器；消息发送、接收都使用长连接进行.

协议格式：

4byte Packet Len(包含4字节本身)

2byte Head Len(包含2字节本身) + 2byte Version(1) + 4byte Operation + 4byte SeqId + ….

(Packet Len - Head Len)  Body

协议交互方式：

- 客户端请求（一应一答，通过seqid匹配）：

seqid = 1 开始，依次递增，服务器回复相同的seqid 作为应答

- 服务器推送通知（单向）：

seqid = 0，Operation = 7a,  客户端不需要应答

主要业务：

-心跳包：

发起客户端请求，Operation = 0c，长度为16字节，算是最小的包

-发消息：

发起客户端请求，Operation = ed

　　单点在线时发完消息后，应答携带SyncKey，不再同步，多点在线时，通过通知同步SyncKey，将随后文章分析。

-收消息：

1. 服务器推送消息， Operation = 7a,  Body 中携带消息内容

　　　　抓包分析时，通过改变消息体大小，可能到接收方第一个包length 也会随之变化，可确认消息是push的。

2. 发起客户端单向请求，即消息的应答Ack

-加密：

未分析，一般来说像whatsapp那样，使用 hash(密码/OTP + 长连接第一个请求获取RandomCode) 做RC4 的密钥

总结：

现在版本的微信消息推送，并非Sync方式，而是推送+ack方式；

从他们协议设计来看，应该最开始用的是Notify + Sync Req + Sync Rsp 方式，因为协议上是不支持服务器发起请求的；

现在改成 Sync 消息+ 单向 Ack Req 的push方式，虽然协议上怪异， 相比Sync 消息接收会更加及时。从以前看到的文章都是说用的Sync协议，应该是是后期版本做了修改，push方式更为高效、而且通过顺序的SyncKey也能够修复丢失的消息。

下面一个通知包示例：

4 byte: 265 PacketLen

2 byte: 16   Head Length

2 byte: 1     Protocol Version

4 byte: 7a   Operation

4 byte: 0   SeqId 这是一个通知性消息

4 byte: unknow header

……. Body

Web客户端

　　web微信客户端使用比较标准的Sync协议，Sync协议也比较适合web长轮询模型。

　　移动客户端模式下，协议是二进制的而且有加密，很难分析；微信侧重手机端，web端主体协议应该保持与移动端一致，可通过web端推测整体协议实现，json也比较好分析。

　　接收一条消息后SyncKey变化：　

　　synckey:1_624161340|2_624162225|3_624162051|11_624161867|201_1420112604|1000_1420104656
　　synckey:1_624161340|2_624162226|3_624162051|11_624161867|201_1420112631|1000_1420104656

　　可以看出：

　　- Synckey 有多个，应该是应对不同业务，其中2为为所有个人消息、讨论组消息，其他可能是联系人、朋友圈、订阅号等，201 为当前时间戳。

　　- SyncKey 的值为数字自增，不是从0开始，应该有个固定的初始值。　　

　　- 发消息时，发完需要自己给再自己同步回一下SyncKey。

- 下面是一条消息增量同步结构，一堆要同步字段+是否修改FlagMask，同步协议变得很简洁。

{
"BaseResponse": {
"Ret": 0,
"ErrMsg": ""
}
,
"AddMsgCount": 1,
"AddMsgList": [{
"MsgId": 1625734358,
"FromUserName": "@sssss",
"ToUserName": "@ssssssss2",
"MsgType": 1,
"Content": "捶地笑……",
"Status": 3,
"ImgStatus": 1,
"CreateTime": 1420109883,
"VoiceLength": 0,
"PlayLength": 0,
"FileName": "",
"FileSize": "",
"MediaId": "",
"Url": "",
"AppMsgType": 0,
"StatusNotifyCode": 0,
"StatusNotifyUserName": "",
"RecommendInfo": {
"UserName": "",
"NickName": "",
"QQNum": 0,
"Province": "",
"City": "",
"Content": "",
"Signature": "",
"Alias": "",
"Scene": 0,
"VerifyFlag": 0,
"AttrStatus": 0,
"Sex": 0,
"Ticket": "",
"OpCode": 0
}
,
"ForwardFlag": 0,
"AppInfo": {
"AppID": "",
"Type": 0
}
,
"HasProductId": 0,
"Ticket": ""
}
],
"ModContactCount": 0,
"ModContactList": [],
"DelContactCount": 0,
"DelContactList": [],
"ModChatRoomMemberCount": 0,
"ModChatRoomMemberList": [],
"Profile": {
"BitFlag": 0,
"UserName": {
"Buff": ""
}
,
"NickName": {
"Buff": ""
}
,
"BindUin": 0,
"BindEmail": {
"Buff": ""
}
,
"BindMobile": {
"Buff": ""
}
,
"Status": 0,
"Sex": 0,
"PersonalCard": 0,
"Alias": "",
"HeadImgUpdateFlag": 0,
"HeadImgUrl": "",
"Signature": ""
}
,
"ContinueFlag": 0,
"SyncKey": {
"Count": 6,
"List": [{
"Key": 1,
"Val": 624161340
}
,{
"Key": 2,
"Val": 624162166
}
,{
"Key": 3,
"Val": 624162051
}
,{
"Key": 11,
"Val": 624161867
}
,{
"Key": 201,
"Val": 1420109883
}
,{
"Key": 1000,
"Val": 1420104656
}
]
}
,
"SKey": ""
}


最初，QQ通信协议并没有加密，而是直接采取明文的方式进行传输，到了后来才使用了加密传输，加密算法一直没有变过，使用的是blowfish算法，但是密钥的交换协议变得比较频繁。其实TX也是被逼的，现在的互联网用户比前几年更加注重隐私安全，这么大用户量的通信软件，如果用户与对方之间的聊天信息可以轻易的被第三方破译获取，那么用户量肯定会离开她，而去选择那些能够更加保护好个人隐私的人通信软件。因此，随着时间的推移和技术的发展，以前设计的协议可能会被研发者发现一些弱点，“图谋不轨”者加以利用，会对TX造成一些潜在的风险，他不得不对协议进行修改（QQ2011正式版中的密钥交换中对密码的MD5计算就加入了salt的概念，这个salt就是对应的QQ号码，后面会有详细的描叙）。

QQ协议首选的传输层是UDP，如果UDP不可登陆，那么会再尝试使用TCP进行传输。UDP使用的端口是8000，TCP使用的端口是443，应用协议基本一样，只是在通过TCP进行传输时，前两个字节为协议内容的长度（包括2个字节）。

QQ协议中每个通信内容都带有一个协议头部，如下图：

其中标识1一个字节，版本号、命令字和序号都是2个字节，QQ号码有4个字节，接下来是数据部分（已加密），最后是一个尾部标识1个字节。

在进行协议还原的时候，最关心的就是协议头部的命令字，需要根据不同的命令字，来进行相应的处理，最终获取密钥解密聊天内容。

QQ登陆协议密钥交换过程，首先我们使用Wireshark抓报文分析，观察主要用到的命令字（见上一篇Header部分的介绍）。

QQ2011登陆过程分析
命令字 含义
1、Touch Information(0×0091) 根服务器SAY HELLO，如果对该报文做一些小动作，可以让QQ认为，TX的服务器或网络不能访问…
2、Login Request(0x00ba) 未知，可以不进行处理。
3、Login Verify(0x00dd) 向服务器发送登陆请求，需要使用密码进行运算作为密钥才能机密该报文，解密的报文中包含对第4步的解密密钥。
4、Login get Information(0x00e5) 未知，但是服务器返回的报文你必须得知道，因为这个报文中包含解密会话密钥报文（第6步）的密钥。
5、Login verify E3(0x00e3) 未知，可以不进行处理。
6、Login send Information(0×0030) 客户端向服务器发送sessionKey，使用第4步获取的密钥进行解密。

1、Touch Information(0×0091)

这个报文无需关心，是客户端向服务器在SAY HELLO…

2、Login Request(0x00ba)

未知，在此处并不重要。

3、Login Verify(0x00dd)

非常重要！！获取会话密钥首先得解密该报文。但是要解密该报文，必须得知道该登陆QQ用户的密码，而用户密码只有用户和TX知道，第三方是不知道的（也有可能存在“不可思议”的第三方…）。数据传输过程中使用的加密算法是blowfish，这个算法目前从公开的资料上来说，还没有发现漏洞。因此，要实时获取用户的聊天信息，除非已经知道密码了，或者已经暴力破解了密码（这里简单介绍一下怎么进行暴力破解，这里的暴力破解，当然不是模拟一个QQ客户端不停的向TX服务器发送登陆请求，这样太慢了，而且TX那边也会有记录。首先，得分析出这个报文的密钥生成算法[不是简单的直接使用密码作为密钥]，加密算法（这个已知，是blowfish），第二，需要将对方的登陆报文截取保存到文件，然后写一个程序，不停拼接字符串、数字、标点符号进行组合，根据第一步分析它密钥的生成方法生成出密钥，然后作为blowfish算法的密钥，去解密报文，如果解密成功，恭喜你，你暴力破解到了一个QQ密码。但是这种概率比较小，即使有一些，这些号码的价值不大，扯远了…)。

LoginVerify报文的解密密钥生成方法，在QQ2011版本之前，是MD5(MD5(PWD))，对QQ的密码做了两次MD5运算。但是QQ2011版本（包括2011版本）之后，这个算法做了一点修改，就是：MD5(MD5(PWD+QQ_NUM))，这个修改其实是非常有必要的，为什么呢？因为随着硬件技术的发展，以及前些年MD5彩虹表的推出，简单密码的MD5值非常容易就能从彩虹表中找出对应MD5值，从而得到原始字符串密码，即使TX做了两次的MD5运算。在彩虹表的推出或以前（因为我也不知道是在这以前还是以后，呵呵），在执行MD5运算时，就有了加SALT的说法，很形象！加盐，在这里，QQ_NUM就是盐，这样就加大了使用彩虹表破解的难度。

使用密码根据以上的算法得出解密密钥，解密Login Verify报文后，会得到一个新的密钥，这个密钥暂且就叫做verify_key。

Login Verify Reply(0x00dd)

服务器对客户端Login Verify报文的响应，这个报文需要verify_key作为密钥进行解密，得出一个新的密钥-verify_reply_key。

4、Login get information(0x00e5)

客户端接收到服务器的Login Verify Reply报文后，会使用verify_reply_key加密数据发送到服务器，而这里面又包含了一个key – get_info_key。

5、Login verify E3(0x00e3)

未知，此处可以不进行处理。

6、Login send Information(0×0030)

使用get_info_key解密该报文，得到会话KEY – session key。

回想一下：密码是关键，有了密码才能解密Login Verify(0x00dd)报文，解密了Login Verify(0x00dd)，才能解密后续的的报文。其步骤是：passwd -> verify_key -> verify_reply_key -> get_info_key -> session_key。

前面两篇简单的介绍了QQ登陆协议密钥交换过程以及所使用的加密算法，知道了这两点，就可以对它的协议进行还原了。

QQDecrypt，通过winpcap抓包，实时对QQ聊天协议进行还原。

除了聊天协议之外，我们还可以对QQ相关的协议进行还原，包括但不限于：

1、QQ文件传输

2、QQ音频传输

3、QQ视频传输

4、QQ密码验证程序

5、QQ密码获取，是的，你没有看错，有一种主动的方法（用户登录时）就可以获得QQ的密码。在网络出口获取，而不是在客户端进行HOOK的方式获取。

时间： 2024-11-07 08:15:00

协议分析TMP的相关文章

编译2.6.35内核安装L7-filter2.23实现七层过滤及QQ协议分析

一.前言 本文,接着上篇<Linux下Netfilter/IPTables防火墙案例分析>来说说七层过滤. iptables等防火墙工作在四层及四层以下,都是通过数据包过滤或能够基于传输层状态检测的. 但是一般企业应用的时候,很多场景下,需要提供屏蔽不良内容.封堵某些应用层软件的功能. QQ是一款最常用的即时通讯软件,但是很多情况下,它的使用会影响工作效率,所以有需求要把QQ屏蔽掉. 如果识别QQ的特征? IP检查,不行.因为它的服务器IP地址段有可能变化. 端口检查,不行.局域网必须放行向外

MySQL协议分析2

MySQL协议分析 议程 协议头 协议类型 网络协议相关函数 NET缓冲 VIO缓冲 MySQL API 协议头 ● 数据变成在网络里传输的数据,需要额外的在头部添加4 个字节的包头. . packet length(3字节), 包体的长度 . packet number(1字节), 从0开始的递增的 ● sql “select 1” 的网络协议是? 协议头 ● packet length三个字节意味着MySQL packet最大16M大于16M则被分包(net_write_command, m

Sybase TDS协议分析

TDS版本比较老,可能与当前版本有所不同. Sybase与Sql Server部份版本 都采用TDS协议,但包大小等有所不同. import java.util.LinkedList; /**  * TDS协议分析适用于Sybase<br/>  * TDS版本4.2应用Sybase SQL Server < 10 and Microsoft SQL Server 6.5<br/>  * TDS版本5.0应用于Sybase SQL Server >= 10  * @aut

蓝牙协议分析(7)_BLE连接有关的技术分析

转自:http://www.wowotech.net/bluetooth/ble_connection.html#comments 1. 前言 了解蓝牙的人都知道,在经典蓝牙中,保持连接(Connection)是一个相当消耗资源(power和带宽)的过程.特别是当没有数据传输的时候,所消耗的资源完全被浪费了.因而,对很多蓝牙设备来说(特别是功耗敏感的设备),希望在无数可传的时候,能够断开连接.但是,由于跳频(hopping)以及物理通道(Physical Channel)划分的缘故,经典蓝牙连接

BT协议分析(1)&mdash;1.0协议

简述 BT下载是采用P2P的下载方式,下载的大致形式采用如下图所示,处于图示中心的称为Tracker服务器,其余称为Peer.   缺点 1.资源的安全性 2.资源的实效性(没有上传者则BT也将失效) 3.版权 协议分析 对BT协议(1.0)的分析主要包含4个部分: 1.种子文件的分析 2.同Tracker服务器的通讯(采用HTTP协议) 3.同其他peer(配合/协同者)的通讯(采用TCP协议) 4.总结 分析前的了解 在这些分析之前,需要先了解两点BT协议采用的基础: 1.BT协议中采用的单

物联网MQTT协议分析和开源Mosquitto部署验证

在<物联网核心协议—消息推送技术演进>一文中已向读者介绍了多种消息推送技术的情况,包括HTTP单向通信.Ajax轮询.Websocket.MQTT.CoAP等,其中MQTT协议为IBM制定并力推,其具有开放.简单.轻量级以及易于实现的特点使得其即便在资源受限的环境中也能得到很好的使用,比如运行在资源紧缺型的嵌入式系统中或网络带宽非常昂贵的环境中,除此之外,它也被广泛用于遥感勘测.智能家居.能源监测和医疗应用程序等各个领域,是物联网的重要组成部分,将来可能会成为物联网的事实标准. 本篇文章将帮助

协议分析 － DHCP协议解码详解

协议分析 - DHCP协议解码详解 [DHCP协议简介] DHCP,全称是 Dynamic Host Configuration Protocol﹐中文名为动态主机配置协议,它的前身是 BOOTP,它工作在OSI的应用层,是一种帮助计算机从指定的DHCP服务器获取它们的配置信息的自举协议. DHCP使用客户端/服务器模式,请求配置信息的计算机叫做DHCP客户端,而提供信息的叫做DHCP的服务器.DHCP为客户端分配地址的方法有三种:手工配置.自动配置.动态配置. DHCP最重要的功能就是动态分配

linux 网络协议分析---3

本章节主要介绍linxu网络模型.以及常用的网络协议分析以太网协议.IP协议.TCP协议.UDP协议 一.网络模型 TCP/IP分层模型的四个协议层分别完成以下的功能: 第一层 网络接口层 网络接口层包括用于协作IP数据在已有网络介质上传输的协议.实际上TCP/IP标准并不定义与ISO数据链路层和物理层相对应的功能.相反,它定义像 地址解析协议(Address Resolution Protocol,ARP)这样的协议,提供TCP/IP协议的数据结构和实际物理硬件之间的接口. 第二层 网间层 网

网络协议分析

1. 网络模型 2. 协议分析 2.1协议架构 2. 2 以太网协议格式 2. 3 IP协议格式 2. 4 TCP协议格式 2. 5 UDP协议格式