百贴吧安卓客户端通信协议分析报告

1、百度贴吧安卓客户端网络通信行为分析目 录一、实验环境与结果概述11.1 实验环境11.2 结果概述1二、登录行为分析32.1 登录请求32.2 登录结果3三、“进吧”相关操作分析53.1 选择“进吧”功能区53.2 进入某一个吧63.3 看帖73.4 回帖93.5 发帖93.6 签到10四、“个人中心”相关操作分析114.1 查看“我喜欢的吧”114.2 查看“我的关注”124.3 查看“我的粉丝”124.4 查看“我的收藏”124.5 查看“我的消息”134.6 查看“我的帖子”144.7 查看“我的微贴”154.8 查看“设置->个人资料”164.9 修改“设置->个人资料”1

2、7五、其他操作及行为分析185.1 首页185.2 身边18 定位18 查看“身边的微贴”205.2.3 查看“身边的吧”205.3 注销21一、实验环境与结果概述1.1 实验环境手机型号：HUAWEI C8812操作系统：应用版本：百度贴吧分析工具：Tcpdump for Android，WireShark 1.2 结果概述百度贴吧客户端的所有重要通信行为都使用了HTTP协议。贴吧客户端发出的HTTP请求一般采用POST方法，表1-1对比展示了不同操作对应的请求报文。其中application/x-www-form-urlencoded格式将请求正文分成多个元素，各元素本身由名和值（可能使用

3、URL编码）组成，各元素之间使用&符号隔开；multipart/form-data格式被用在使用POST方法发送HTML表单时，请求正文被分隔符（由boundary定义）分割成很多子段，每个子段可以自定义子段名称和值，从而实现在单个消息实体中封装多个主体的功能。表1-1 不同操作对应的POST请求对比操作请求行URIHost正文格式正文特殊元素个人中心查看“我喜欢的吧”/c/f/forum/likec.tieba.application/x-www- form-urlencodedBDUSS查看“我的收藏”/c/f/post/threadstoreBDUSS,user_id查看“我的关

4、注”/c/u/follow/pageBDUSS查看“我的粉丝”/c/u/fans/pageBDUSS查看“回复我的”消息/c/u/feed/replymeBDUSS,pn,uid查看“我的”消息/c/u/feed/atmeBDUSS,pn,uid查看“我的帖子”/c/u/feed/mypostBDUSS,pn查看“我的微贴”/c/u/feed/ssfBDUSS,pn,rn,uid查看“个人资料”/c/u/user/profileBDUSS,uid修改“个人资料”/c/c/profile/modifymultipart/form-data; boundary=BDUSS,intro,sex进吧点

5、击“进吧”/c/f/forum/favocommendc.tieba.application/x-www- form-urlencodedBDUSS进入某吧/c/f/frs/pageBDUSS,kw在某吧“签到”/c/c/forum/signBDUSS,kw看帖/c/f/pb/pageBDUSS,kz回帖/c/c/post/addBDUSS,content,kw,tid发帖/c/c/thread/addBDUSS,content,kw,title身边点击“身边”【定位1】/sdk.phploc.map.application/x-www- form-urlencodedqt,req点击“身边”

6、【定位2】/sdk.phpbloc获取“身边的微贴”/c/f/lbs/threadc.tieba.BDUSS,guide,height,ispv,lat,lng,pn获取“身边的吧”/c/f/lbs/forumBDUSS,ispv,lat,lng首页登录/c/s/loginc.tieba.application/x-www- form-urlencodedpasswd,un注销/c/s/loginoutbduss退出【未注销】后重启/c/s/msgBDUSS点击“首页”/c/s/tag/allthreadBDUSS服务器返回的响应有着类似的头部，如图1-1所示。图1-1 贴吧服务器返回的响应头

7、部状态行一般为HTTP/1.1 200 OK，正文的类型一般纯文本文件，正文本身一般经过gzip编码压缩，且在传输过程中一般使用了chunked编码进行分块传输。后文在说到响应正文时，一般是指重组解压后的正文，后文中不再特别指出这一点。一个简单的正文示例如图1-2所示。图1-2 一个最简单的响应正文示例如上图，还原出来的完整响应正文普遍使用了JSON格式，该数据格式的特征是所有数据处于一对大括号 内。正文一般分成多个段，每个段由名和值组成，段与段之间用逗号隔开。有些段的值会由多个子段构成，一个段的所有子段也会用一对方括号 或是大括号 括起来。大部分情况下，有四个一级段在正文是都存在的，包括：e

8、rror_code（操作成功时值为0，操作失败时为对应错误代码）、time、ctime，以及logid。【由于作者在完成分析的时候还不知道JSON，所以后文的相关描述没有用到JSON格式的特点，显得不否简练。但要表达的东西还是完整的，所以不再更改。】【我们约定，与error_code处在同一层次的称为一级段，一级段的子段为二级段，以此类推。】下面就各行为做具体分析。二、登录行为分析2.1 登录请求登录时，贴吧客户端使用一个POST请求来提交认证信息。该登录请求的请求行使用固定的URI：/c/s/login。由请求行的特征和Host头域的值可以确定一个登录行为。图2-1展示了当登录用户名为xin

9、hua0123，登录口令为fengping888时，该请求报文的具体形式。图2-1 一个登录请求报文示例请求报文的正文中存在变化过的登录口令和明文的用户名，其特征分别如下：u 变化后的口令前缀特征：passwd=u 用户名前缀特征：un=口令与用户名的结束标志均为&。贴吧客户端在发送登录请求前先对明文口令fengping888进行了Base64编码，得到中间结果ZmVuZ3Bpbmc4ODg=，接着再对中间结果进行了URL编码，由此得到最终结果ZmVuZ3Bpbmc4ODg%3d。2.2 登录结果登录的结果在前述请求所对应的响应报文中。该响应报文的头部类似于图1-1所示的范例，其响应正

10、文根据登录的结果不同而格式不同。图2-2分别展示了登录成功和失败时，所对应的响应正文。(a)登录失败后响应正文(b)登录成功后响应正文图2-2 登录请求的响应正文如上图，登录成功与否可以根据error_code的值来判定，若为0，则成功。登录失败后的响应正文里存在名为error_msg的一级段，其值为服务器返回的错误提示信息的Unicode编码，如上图(a)，将u5bc6u7801u9519u8befuff0cu8bf7u91cdu65b0u8f93u5165转换为对应的Unicode字符，为：密码错误，请重新输入。这个错误信息将会显示在贴吧客户端，如图2-3.所示。图2-3 登录失败后贴吧客

11、户端给出错误提示“密码错误，请重新输入”登录成功后，服务器所给响应正文中一个比较重要的段是user，其子段中包含一些重要信息，一是登录用户的id和用户名，另一个是BDUSS。BDUSS是贴吧服务器在用户每次登录成功后所给出的一个通行证，以后用户在进行一些非匿名的操作时，就不用每次都重复登录，只需在请求正文中包含BDUSS即可。BDUSS在用户注销登录后失效，再次登录获得的BDUSS和上次不同。但尚不清楚BDUSS是否存在最长有效期（即在超过某个时限后不论用户是否注销登录，均强制失效）。推测在有效期内，通过BDUSS应该可以冒充登录用户进行操作，尚未进行验证。在贴吧客户端上有“首页”、“进吧”、

12、“身边”、“个人中心”四大功能区，下面按使用频率依次进行分析。三、“进吧”相关操作分析3.1 选择“进吧”功能区点击“进吧”后，客户端发出一个POST请求，其请求行URI固定为/c/f/forum/favocommend，Host头域的值为。请求正文以BDUSS=开始，其值与登陆成功后服务器所返回的响应中一致。请求正文中另外还有的信息包括：客户端类型、版本，时间戳等，如图3-1。图3-1 点击“进吧”后发出的请求报文服务器返回的响应头部与图1-1基本一致，解压后的响应正文如图3-2所示。图3-2 点击“进吧”后服务器的响应正文正文以error_code段开始，其值为0，表明本次操作成功。正文中

13、最重要的是一个名为forum_list的一级段，这其实是一个贴吧列表。列表的每一个表项都用一对大括号 括起来，一个表项里的子段包括：name（贴吧名，使用Unicode编码）、id（贴吧的标识号）、is_like（是否喜欢，由于百度贴吧现在点击“喜欢”自动成为一级会员，故此等价于用户是否为该吧会员）、favo_type、level_id（用户在该吧的等级）、member_count、avatar以及slogan。对比点击“进吧”后贴吧客户端所显示的内容（如图3-3所示），我们发现forum_list这个贴吧列表正是客户端进入“进吧”后所显示的贴吧列表。图3-3 点击“进吧”以后3.2 进入某一

14、个吧在“进吧”选择列表中某一个吧点击后，客户端发出一个POST请求，其请求行URI固定为/c/f/frs/page，Host头域的值为。请求正文以BDUSS=开始，其值与登陆成功后服务器所返回的响应中一致。正文中特征串kw=后是本次请求所要进入的贴吧名，其结束标志是&。当进入linux吧时，请求报文如图3-4所示。图3-4 进入linux吧时客户端发出的请求服务器给出的响应头部类似于图1-1，正文以error_code段开始，其值为0，表明本次操作成功。后面的一级段中比较重要的包括user（用户信息）、forum（贴吧信息）、managers（贴吧管理员信息）以及thread_list

15、（贴吧首页的帖子列表）。前面几个段都很简单，直接就能找到特征，表3-1对一些信息的特征做了汇总。表3-1 进入某一个吧服务器所给响应中的一些信息特征段名含义所属父段示例id用户IDuser288130111name用户名/昵称xinhua0123is_manager用户是否为贴吧管理员0【不是管理员】id贴吧IDforum3171name贴吧名linuxfirst_class贴吧所属一级分类u79d1u5b66u6280u672f【科学技术】second_class贴吧所属二级分类u8ba1u7b97u673au8f6fu4ef6【计算机软件】is_like用户是否为贴吧会员1【是会员】use

16、r_level用户在贴吧的会员等级3level_name用户在贴吧的称号-wxmember_num贴吧会员总数26274thread_num贴吧帖子总数61346post_num贴吧发言数751557current_rank_info贴吧签到数当前排名forum/sign_in_info/forum_info"sign_count":"1532","sign_rank":"18","member_count":"25625","dir_rate":&quo

17、t;0.1"yesterday_rank_info贴吧签到数昨日排名weekly_rank_info贴吧签到数上周排名"sign_count":"2629","sign_rank":"19","member_count":"25610"monthly_rank_info贴吧签到数上月排名id贴吧管理员IDmanagers3943785name贴吧管理员昵称typhoon_wolf下面详细解说相对复杂的thread_list一级段。前文说过这是一个帖子列表，图3-5是

18、列表中某一个具体的表项，它处于一对大括号 内。图3-5 thread_list列表中某表项的数据如上图，几个子段的含义为：id是帖子的ID，title是帖子的标题【使用了Unicode编码】，reply_num是回复数，view_num是点击数，last_time是最后回复日期，last_time_int是最后回复时间，is_top表示是否置顶【为1置顶】，author里是作者信息，last_replyer里时最后回复人的信息，abstract是帖子的摘要信息。3.3 看帖用户在贴吧里点击某篇帖子之后，客户端发出一个POST请求，其请求行URI固定为/c/f/pb/page，Host头域的值为

19、。请求正文以BDUSS=开始，其值与登陆成功后服务器所返回的响应中一致。正文中特征串kz=后是本次请求所要阅读的帖子ID，请求报文如图3-6所示。图3-6 点击某篇帖子之后发出的请求示例服务器给出的响应头部类似于图1-1，正文以error_code段开始，其值为0，表明本次操作成功。后面的一级段中比较重要的包括user（所看帖子的作者信息）、forum（贴吧信息）以及post_list（帖子的具体内容）。其中user与forum两个一级段的分析大致与前文一致或类似，下面详细分析一下post_list这个段。post_list其实是一个帖子【称为主贴】的正文，所有对它的回复【为了便于区分，后文以

20、“楼层”代称】，以及所有对它回复的回复【为了表达简介，后文以“回复”代称】。我们知道在贴吧中，帖子的正文往往称为一楼，对帖子本身的回复称为按照先后顺序分别称为二楼、三楼而且这些楼层本身也算发帖，会有帖子ID。post_list的所有内容用一对方括号 括起来，里面的每个子段（我们称为二级段）对应帖子里面的一层楼。图3-7是post_list的某一个二级段示例。图3-7 post_list列表中某表项的数据 如上图，几个二级段的含义为：id是该楼层的ID，title是楼层的标题（使用了Unicode编码，一楼的标题是整个主贴的标题，二楼及以后的标题是主贴的标题前加上“回复：”），floor是楼层编

21、号，content是楼层的正文，author是建楼者的信息， sub_post_list是本楼层里的所有回复信息的综述，他也有一个叫sub_post_list的子段（我称之为三级段），里面是对本楼层的回复列表，这个列表的每个表项对应本楼层每条回复的详细信息，包括：author（回复者的信息）、id（回复的ID）、content（回复的正文），以及floor（相当于子楼层数）。3.4 回帖当我们点击“回复”后，客户端发出一个POST请求，其请求行URI固定为/c/c/post/add，Host头域的值为。请求正文以BDUSS=开始，其值与登陆成功后服务器所返回的响应中一致。正文中还有三处重要的信

22、息，分别是回复的内容（中文使用url编码）、被回复贴所在的贴吧的名字（中文使用url编码）、被回复贴子的ID。他们的前缀特征分别为content=、kw=、tid=，后缀特征为&。当在四川大学吧回复一个ID为2404920336的帖子，回复内容为”too bad !”时，请求报文如图3-8所示。图3-8 回帖时客户端发送的请求示例服务器返回的响应比较简单，头部和正文分别和图1-1、1-2类似。响应正文中比较重要的是error_code的值，为0的时候说明回复成功。3.5 发帖当我们点击“发帖”后，客户端发出一个POST请求，其请求行URI固定为/c/c/thread/add，Host头

23、域的值为。请求正文则如图3-9所示。图3-9 发帖时客户端发送的请求正文示例如上图，请求正文以BDUSS=开始，其值与登陆成功后服务器所返回的响应中一致。正文中还有三处重要的信息，分别是所发帖子的内容（中文使用url编码）、发贴所在贴吧的名字（中文使用url编码）、所发贴子的标题（中文使用url编码）。他们的前缀特征分别为content=、kw=、title=，后缀特征为&。 服务器返回的响应比较简单，头部和正文分别和图1-1、1-2类似。响应正文中比较重要的是error_code的值，为0的时候说明回复成功。3.6 签到用户在某贴吧里点击“签到”后，客户端发出一个POST请求，其请求

24、行URI固定为/c/c/forum/sign，Host头域的值为。请求正文以BDUSS=开始，其值与登陆成功后服务器所返回的响应中一致。正文中特征串kw=后是本次所要签到的的贴吧名（中文使用url编码），其结束标志是&。当在三国杀吧签到时，请求报文如图3-10所示。图3-10 在“三国杀”吧点击“签到”后客户端发出的请求报文示例 服务器返回的响应头部与图1-1基本一致，解压后的响应正文如图3-11所示。图3-11 点击“签到”后服务器的响应正文如上图，正文以user_info一级段开始，其值由多个子段构成，含义分别为：is_sign_in表示签到是否成功，user_sign_rank的

25、值表示用户第几个签到，sign_time表示用户签到时间，cont_sign_num表示用户本月连续签到数，cont_total_sign_num表示用户本月累计签到数。在整个user_info一级段之后是在1.2节中提到的四个常见一级段。四、“个人中心”相关操作分析 如图4-1所示，“个人中心”中进行的会引起网络通信行为的常见操作包括查看“我喜欢的吧”、“我的关注”、“我的粉丝”、“我的收藏”、“我的消息”、“我的帖子”、“我的微贴”，以及在“设置”里查看和修改个人资料。下面分别进行分析。图4-1 贴吧客户端-个人中心4.1 查看“我喜欢的吧”当用户在“个人中心”点击“我喜欢的吧”后，客户端

26、发出一个POST请求，其请求行URI固定为/c/f/forum/like，除此之外，整个请求的构造与点击“进吧”后（见图3-1）基本一致。服务器返回的响应头部与图1-1基本一致，解压后的响应正文也与点击“进吧”后类似，以error_code段开始，其值为0，表明本次操作成功。正文中最重要的也是一个名为forum_list的贴吧列表。不同的是，此处forum_list列表中是用户已经成为会员的贴吧（4.1节中返回的列表是用户常逛的贴吧），排列顺序依照用户的等级由高到低（4.1节中返回的列表按照用户近期访问频率排列）。这个列表中每个表项的构成也与4.1节中不同，图4-2是这个列表中的一个表项示例。

27、图4-2 forum_list中某表项的数据 该表项中几个重要的子段包括：id（贴吧ID）、name（贴吧名，使用Unicode编码）、level_id（用户在本吧的等级）、level_name（用户在本吧的称号，使用Unicode编码）。4.2 查看“我的关注”当用户在“个人中心”点击“我的关注”后，客户端发出一个POST请求，其请求行URI固定为/c/u/follow/page，除此之外，整个请求的构造与点击“进吧”后（见图3-1）基本一致。服务器返回的响应头部与图1-1基本一致，解压后的响应正文如图4-3所示。图4-3 点击“我的关注”后服务器返回的响应正文如上图，正文以error_co

28、de段开始，其值为0，表明本次操作成功。在page一级段中有一个total_count子段，其值为用户所关注的用户数。正文中最重要的一级段是user_list，是用户所关注用户的列表。与前文提到的一些列表类似，列表的所有表项处于一对方括号内，表项之间用逗号隔开，每个表项的所有子段都用一个大括号 括起来。每个表项中几个重要的二级段包括：id（所关注用户的ID）、name（所关注用户的昵称，使用Unicode编码）、intro（所关注用户的自我简介，使用Unicode编码）。4.3 查看“我的粉丝”当用户在“个人中心”点击“我的粉丝”后，客户端所发出请求的结构与点击“我的关注”后完全一致，但其请求

29、行URI固定为/c/u/fans/page。服务器给出的响应报文的结构也与点击“我的关注”后完全一致4.4 查看“我的收藏” 当用户在“个人中心”点击“我的收藏”后，客户端发出一个POST请求，其请求行URI固定为/c/f/post/threadstore，Host头域的值为。如图4-4所示，请求正文以BDUSS=开始，其值与登陆成功后服务器所返回的响应中一致。正文中特征串user_id=后客户端用户的ID，其结束标志是&。图4-4点击“我的收藏”后客户端发出的请求正文示例服务器返回的响应头部与图1-1基本一致，解压后的响应正文如图4-5所示。图4-5点击“我的收藏”后服务器返回的响应

30、正文从上图可以看到，此处的响应正文与其他操作的一个很大不同在于，它的第一个一级段不再是error_code，而是store_thread。这是一个收藏的帖子列表，和前文提到的一些列表相同，这个列表的所有表项处于一对方括号内，表项之间用逗号隔开，每个表项的所有子段都用一个大括号 括起来。每个表项中几个重要的二级段包括：thread_id（帖子的ID）、title（帖子的标题）、forum_name（帖子所在的贴吧）、author（帖子的作者信息）、reply_num（帖子的回复数）。error_code这个一级段并非不存在了，只是移到了倒数第四个。在它的前面还有一个名为error的一级段，似乎和

31、error_code所表达的信息一致。4.5 查看“我的消息”“我的消息”分为“回复我的”和“我的”两种。要完整取回这两类消息，客户端会发出两个POST请求。以查看“回复我的”消息为例，报文范例如图4-6所示。图4-6 查看“回复我的”消息时客户端发出的请求从上图可以看到，请求行的URI固定为/c/u/feed/replyme，Host头域的值为。请求正文以BDUSS=开始，其值与登陆成功后服务器所返回的响应中一致。和点击“进吧”后所发请求不同的是，多了名为pn和uid的元素。前者含义未知，后者是请求用户的ID。服务器返回的响应头部与图1-1基本一致，解压后的响应正文以error_code段开

32、始，其值为0，表明本次操作成功。正文中最重要的一级段是reply_list，是回复消息的列表。与前文提到的一些列表类似，列表的所有表项处于一对方括号内，表项之间用逗号隔开，每个表项的所有子段都用一个大括号 括起来。图4-7是一个具体的表项示例。图4-7 reply_list中某表项的数据 该表项中几个重要的子段包括：is_floor（为0表示是对一个帖子的直接回复，为1表示是对一个帖子中某一楼层的回复）、unread（为1表示用户尚未阅读本消息，为0表示已阅读）、replyer（回复者的信息）、title（主贴的标题）、content（回复的内容）、thread_id（所在主贴的ID）、pos

33、t_id（楼层的ID），以及fname（回复所在贴吧的名字，中文用Unicode编码）。查看“我的”消息时，客户端所发请求报文的结构与查看“回复我的”消息时完全一致，只是请求行的URI不同，固定为/c/u/feed/atme。服务器所返回响应也与查看“回复我的”消息时基本一致，只不过在reply_list一级段对应的位置变成了at_list，这是客户端用户的消息列表，表项的结构如图4-8所示。图4-8 at_list中某表项的数据该表项中几个重要的子段包括： replyer（发出者的信息）、title（主贴的标题）、content（含有的帖子/回复内容）、thread_id（所在主贴的ID）、

34、post_id（楼层的ID），以及fname（主贴所在贴吧的名字，中文用Unicode编码）。4.6 查看“我的帖子”当用户在“个人中心”点击“我的帖子”后，客户端发出一个POST请求，其请求行URI固定为/c/u/feed/mypost。如图4-9所示，整个请求报文的结构与点击“进吧”后类似，不同的是正文中多了名为pn的元素，含义未知。图4-9点击“我的帖子”后客户端发出的请求报文示例服务器返回的响应头部与图1-1基本一致，解压后的响应正文以error_code段开始，其值为0，表明本次操作成功。正文中最重要的一级段是post_list，是客户端使用者所发帖子的列表。与前文提到的一些列表类似

35、，列表的所有表项处于一对方括号内，表项之间用逗号隔开，每个表项的所有子段都用一个大括号 括起来。图4-10是一个具体的表项示例。图4-10 post_list中某表项的数据 该表项中几个重要的子段包括：author（发帖者信息）、title（主贴的标题，中文使用Unicode编码）、fname（发帖所在贴吧，中文使用Unicode编码）、reply_time（发帖日期）、reply_num（主贴的回复数）、pid（用户所发帖子的ID）、tid（主贴的ID），以及is_floor（为1表明这是回复贴，为0表示这是发表贴）。4.7 查看“我的微贴”当用户在“个人中心”点击“我的微帖”后，客户端发出

36、一个POST请求，其请求行URI固定为/c/u/feed/ssf。如图4-11所示，正文中多了名为rn的元素，含义未知。除此之外，整个报文的结构与查看“回复我的”消息时基本一致。图4-11点击“我的微贴”后客户端发出的请求正文示例服务器返回的响应头部与图1-1基本一致。如图4-12所示，解压后的响应正文以error_code段开始，其值为0，表明本次操作成功。正文中最重要的一级段是thread_list，是客户端使用者所发微贴的列表。由于当前为空，所有列表内部结构尚未分析。图4-12点击“我的微贴”后服务器返回的响应正文4.8 查看“设置->个人资料”在“个人中心”的右上角有“设置”，点

37、进去后的第二项叫“个人资料”，点击后即可查看个人资料，如图4-13所示。图4-13 查看个人资料在这个过程中，客户端也会发送一个POST请求，其请求行URI固定为/c/u/user/profile，Host头域的值为。如图4-14，请求正文以BDUSS=开始，其值与登陆成功后服务器所返回的响应中一致。正文中有uid元素，值为客户端用户的ID。图4-14 查看个人资料时客户端发出的请求正文示例服务器返回的响应头部与图1-1基本一致。如图4-12所示图4-15 查看个人资料时服务器返回的响应正文 如上图，响应正文中最重要的是user这个一级段。组成其值的几个重要子段分别为： id（用户ID）、na

38、me（用户名，客户端上有显示）、intro（用户个人简介，中文使用Unicode编码，客户端上有显示）、sex（用户性别，客户端上有显示）、like_forum_num（用户喜欢的贴吧数，即用户已成为会员的贴吧数）、concern_num（用户关注的用户数）、fans_num（用户拥有的粉丝数）。4.9 修改“设置->个人资料”在“个人资料”的右上角有“保存”按钮，点击后即可完成修改个人资料。在这个过程中，客户端会发出一个POST请求，其请求行URI固定为/c/c/profile/modify，Content-Type头域的值为multipart/form-data ; boundary

39、=-7da3d81520810*，表明正文采用了multipart/form-data格式，正文各子段之间使用“-7da3d81520810*”作为分隔符。请求正文如图4-16所示（由于报文过长，部分不重要的子段被省略，用代替）。图4-16 修改“个人资料”时客户端发出的请求正文如上图，正文以“-7da3d81520810*”标志开始，以“-7da3d81520810*-”标志结束。正文中比较重要的子段的name分别为：BDUSS（登录凭证）、intro（个人简介）和sex（性别）。BDUSS子段的值与登陆成功后服务器所返回的响应中一致；intro子段的值是图4-13中“个人简介”的信息（中文

40、使用UTF-8字符集）；sex子段的值对应图4-13中的“性别”信息，男为1，女为2。服务器返回的响应比较简单，头部和正文分别和图1-1、1-2类似。响应正文中比较重要的是error_code的值，为0的时候说明修改成功。五、其他操作及行为分析5.1 首页点击“首页”后，客户端发出一个POST请求，其请求行URI固定为/c/s/tag/allthread，Host头域的值为。请求正文以BDUSS=开始，其值与登陆成功后服务器所返回的响应中一致。请求正文中另外还有的信息包括：客户端类型、版本，时间戳等，如图5-1。图5-1点击“首页”后发出的请求报文 服务器返回的响应头部与图1-1基本一致。与其

41、他操作返回的正文格式为纯文本文件不同，此处的响应正文是一个标准html文件。由于正文里没什么重要信息，在此不作具体分析。5.2 身边点击“身边”后，客户端和服务端会进行四次重要的HTTP会话，前两个会话用于客户端用户的定位，后两个会话分别用于查看“身边的微贴”和“身边的吧”。下面分别进行分析。 定位在定位过程进行的两次HTTP会话中，客户端使用的都是POST请求，两个请求头部的结构类似，但与其他操作发出的请求报文结构有极大不同。首先，两个POST的请求行URI都固定为/sdk.php；其次，请求的服务器（由请求头部Host头域的值指定）都变为了，而不再是其他请求中所用的。请求正文的格式（由请求

42、头部Content-Type头域的值指定）依旧是application/x-www-form-urlencoded。两个请求报文的头部、正文分别如图5-2【a】、【b】、【c】所示。【a】定位请求的头部示例【b】第一个定位请求的正文【c】第二个定位请求的正文图5-2进行定位时客户端发出的请求报文示例请求正文的含义尚未分析出来。服务器所给两个响应的报文结构基本一致，但正文的内容有很大不同，如图5-3所示。【a】第一个定位请求对应的响应【b】第二个定位请求对应的响应正文图5-3 进行定位时服务器返回的响应报文示例服务器对第一个定位请求返回响应的含义尚未分析出来，但是在第二个定位请求所对应的响应正文中，我们可以还原出一些感兴趣的东西