安卓客戶端通信協(xié)議分析報告

1、百度貼吧安卓客戶端網(wǎng)絡(luò)通信行為分析目 錄一、實驗環(huán)境與結(jié)果概述11.1 實驗環(huán)境11.2 結(jié)果概述1二、登錄行為分析32.1 登錄請求32.2 登錄結(jié)果3三、“進吧”相關(guān)操作分析53.1 選擇“進吧”功能區(qū)53.2 進入某一個吧63.3 看帖73.4 回帖93.5 發(fā)帖93.6 簽到10四、“個人中心”相關(guān)操作分析114.1 查看“我喜歡的吧”114.2 查看“我的關(guān)注”124.3 查看“我的粉絲”124.4 查看“我的收藏”124.5 查看“我的消息”134.6 查看“我的帖子”144.7 查看“我的微貼”154.8 查看“設(shè)置-個人資料”164.9 修改“設(shè)置-個人資料”17五、其他操作及

2、行為分析185.1 首頁185.2 身邊185.2.1 定位185.2.2 查看“身邊的微貼”205.2.3 查看“身邊的吧”205.3 注銷21- 25 - / 28文檔可自由編輯打印一、實驗環(huán)境與結(jié)果概述1.1 實驗環(huán)境手機型號：HUAWEI C8812操作系統(tǒng)：Android 4.0.3應(yīng)用版本：百度貼吧4.0.0分析工具：Tcpdump for Android，WireShark 1.10.0rc21.2 結(jié)果概述百度貼吧客戶端的所有重要通信行為都使用了HTTP協(xié)議。貼吧客戶端發(fā)出的HTTP請求一般采用POST方法，表1-1對比展示了不同操作對應(yīng)的請求報文。其中application/

3、x-格式將請求正文分成多個元素，各元素本身由名和值（可能使用URL編碼）組成，各元素之間使用&符號隔開；multipart/form-data格式被用在使用POST方法發(fā)送HTML表單時，請求正文被分隔符（由boundary定義）分割成很多子段，每個子段可以自定義子段名稱和值，從而實現(xiàn)在單個消息實體中封裝多個主體的功能。表1-1 不同操作對應(yīng)的POST請求對比操作請求行URIHost正文格式正文特殊元素個人中心查看“我喜歡的吧”/c/f/forum/application/x-www- form-urlencodedBDUSS查看“我的收藏”/c/f/

4、post/threadstoreBDUSS,user_id查看“我的關(guān)注”/c/u/follow/pageBDUSS查看“我的粉絲”/c/u/fans/pageBDUSS查看“回復(fù)我的”消息/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/promultipart/form-data; bou

5、ndary=BDUSS,intro,sex進吧點擊“進吧”/c/f/forum/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發(fā)帖/c/c/thread/addBDUSS,content,kw,title身邊點擊“身邊”【定位1】/appl

6、ication/x-www- form-urlencodedqt,req點擊“身邊”【定位2】/sdk.phpbloc獲取“身邊的微貼”/c/f/lbs/BDUSS,guide,height,ispv,lat,lng,pn獲取“身邊的吧”/c/f/lbs/forumBDUSS,ispv,lat,lng首頁登錄/c/s/application/x-www- form-urlencodedpasswd,un注銷/c/s/loginoutbduss退出【未注銷】后重啟/c/s/msgBDUSS點擊“首頁”/c/

7、s/tag/allthreadBDUSS服務(wù)器返回的響應(yīng)有著類似的頭部，如圖1-1所示。圖1-1 貼吧服務(wù)器返回的響應(yīng)頭部狀態(tài)行一般為HTTP/1.1 200 OK，正文的類型一般純文本文件，正文本身一般經(jīng)過gzip編碼壓縮，且在傳輸過程中一般使用了chunked編碼進行分塊傳輸。后文在說到響應(yīng)正文時，一般是指重組解壓后的正文，后文中不再特別指出這一點。一個簡單的正文示例如圖1-2所示。圖1-2 一個最簡單的響應(yīng)正文示例如上圖，還原出來的完整響應(yīng)正文普遍使用了JSON格式，該數(shù)據(jù)格式的特征是所有數(shù)據(jù)處于一對大括號 內(nèi)。正文一般分成多個段，每個段由名和值組成，段與段之間用逗號隔開。有些段的值會由

8、多個子段構(gòu)成，一個段的所有子段也會用一對方括號 或是大括號 括起來。大部分情況下，有四個一級段在正文是都存在的，包括：error_code（操作成功時值為0，操作失敗時為對應(yīng)錯誤代碼）、time、ctime，以及l(fā)ogid?！居捎谧髡咴谕瓿煞治龅臅r候還不知道JSON，所以后文的相關(guān)描述沒有用到JSON格式的特點，顯得不否簡練。但要表達的東西還是完整的，所以不再更改?！俊疚覀兗s定，與error_code處在同一層次的稱為一級段，一級段的子段為二級段，以此類推。】下面就各行為做具體分析。二、登錄行為分析2.1 登錄請求登錄時，貼吧客戶端使用一個POST請求來提交認證信息。該登錄請求的請求行使用固定

9、的URI：/c/s/login。由請求行的特征和Host頭域的值可以確定一個登錄行為。圖2-1展示了當?shù)卿浻脩裘麨閤inhua0123，登錄口令為fengping888時，該請求報文的具體形式。圖2-1 一個登錄請求報文示例請求報文的正文中存在變化過的登錄口令和明文的用戶名，其特征分別如下：u 變化后的口令前綴特征：passwd=u 用戶名前綴特征：un=口令與用戶名的結(jié)束標志均為&。貼吧客戶端在發(fā)送登錄請求前先對明文口令fengping888進行了Base64編碼，得到中間結(jié)果ZmVuZ3Bpbmc4ODg=，接著再對中間結(jié)果進行了URL編碼，由此得到最終結(jié)果ZmVuZ3Bpbmc4ODg%

10、3d。2.2 登錄結(jié)果登錄的結(jié)果在前述請求所對應(yīng)的響應(yīng)報文中。該響應(yīng)報文的頭部類似于圖1-1所示的范例，其響應(yīng)正文根據(jù)登錄的結(jié)果不同而格式不同。圖2-2分別展示了登錄成功和失敗時，所對應(yīng)的響應(yīng)正文。(a)登錄失敗后響應(yīng)正文(b)登錄成功后響應(yīng)正文圖2-2 登錄請求的響應(yīng)正文如上圖，登錄成功與否可以根據(jù)error_code的值來判定，若為0，則成功。登錄失敗后的響應(yīng)正文里存在名為error_msg的一級段，其值為服務(wù)器返回的錯誤提示信息的Unicode編碼，如上圖(a)，將u5bc6u7801u9519u8befuff0cu8bf7u91cdu65b0u8f93u5165轉(zhuǎn)換為對應(yīng)的Unicod

11、e字符，為：密碼錯誤，請重新輸入。這個錯誤信息將會顯示在貼吧客戶端，如圖2-3.所示。圖2-3 登錄失敗后貼吧客戶端給出錯誤提示“密碼錯誤，請重新輸入”登錄成功后，服務(wù)器所給響應(yīng)正文中一個比較重要的段是user，其子段中包含一些重要信息，一是登錄用戶的id和用戶名，另一個是BDUSS。BDUSS是貼吧服務(wù)器在用戶每次登錄成功后所給出的一個通行證，以后用戶在進行一些非匿名的操作時，就不用每次都重復(fù)登錄，只需在請求正文中包含BDUSS即可。BDUSS在用戶注銷登錄后失效，再次登錄獲得的BDUSS和上次不同。但尚不清楚BDUSS是否存在最長有效期（即在超過某個時限后不論用戶是否注銷登錄，均強制失效）

12、。推測在有效期內(nèi)，通過BDUSS應(yīng)該可以冒充登錄用戶進行操作，尚未進行驗證。在貼吧客戶端上有“首頁”、“進吧”、“身邊”、“個人中心”四大功能區(qū)，下面按使用頻率依次進行分析。三、“進吧”相關(guān)操作分析3.1 選擇“進吧”功能區(qū)點擊“進吧”后，客戶端發(fā)出一個POST請求，其請求行URI固定為/c/f/forum/favocommend，Host頭域的值為。請求正文以BDUSS=開始，其值與登陸成功后服務(wù)器所返回的響應(yīng)中一致。請求正文中另外還有的信息包括：客戶端類型、版本，時間戳等，如圖3-1。圖3-1 點擊“進吧”后發(fā)出的請求報文服務(wù)器返回的響應(yīng)頭部與圖1-1基本

13、一致，解壓后的響應(yīng)正文如圖3-2所示。圖3-2 點擊“進吧”后服務(wù)器的響應(yīng)正文正文以error_code段開始，其值為0，表明本次操作成功。正文中最重要的是一個名為forum_list的一級段，這其實是一個貼吧列表。列表的每一個表項都用一對大括號 括起來，一個表項里的子段包括：name（貼吧名，使用Unicode編碼）、id（貼吧的標識號）、is_like（是否喜歡，由于百度貼吧現(xiàn)在點擊“喜歡”自動成為一級會員，故此等價于用戶是否為該吧會員）、favo_type、level_id（用戶在該吧的等級）、member_count、avatar以及slogan。對比點擊“進吧”后貼吧客戶端所顯示的內(nèi)

14、容（如圖3-3所示），我們發(fā)現(xiàn)forum_list這個貼吧列表正是客戶端進入“進吧”后所顯示的貼吧列表。圖3-3 點擊“進吧”以后3.2 進入某一個吧在“進吧”選擇列表中某一個吧點擊后，客戶端發(fā)出一個POST請求，其請求行URI固定為/c/f/frs/page，Host頭域的值為。請求正文以BDUSS=開始，其值與登陸成功后服務(wù)器所返回的響應(yīng)中一致。正文中特征串kw=后是本次請求所要進入的貼吧名，其結(jié)束標志是&。當進入linux吧時，請求報文如圖3-4所示。圖3-4 進入linux吧時客戶端發(fā)出的請求服務(wù)器給出的響應(yīng)頭部類似于圖1-1，正文以error_cod

15、e段開始，其值為0，表明本次操作成功。后面的一級段中比較重要的包括user（用戶信息）、forum（貼吧信息）、managers（貼吧管理員信息）以及thread_list（貼吧首頁的帖子列表）。前面幾個段都很簡單，直接就能找到特征，表3-1對一些信息的特征做了匯總。表3-1 進入某一個吧服務(wù)器所給響應(yīng)中的一些信息特征段名含義所屬父段示例id用戶IDuser288130111name用戶名/昵稱xinhua0123is_manager用戶是否為貼吧管理員0【不是管理員】id貼吧IDforum3171name貼吧名linuxfirst_class貼吧所屬一級分類u79d1u5b66u6280u6

16、72f【科學技術(shù)】second_class貼吧所屬二級分類u8ba1u7b97u673au8f6fu4ef6【計算機軟件】is_like用戶是否為貼吧會員1【是會員】user_level用戶在貼吧的會員等級3level_name用戶在貼吧的稱號-wxmember_num貼吧會員總數(shù)26274thread_num貼吧帖子總數(shù)61346post_num貼吧發(fā)言數(shù)751557current_rank_info貼吧簽到數(shù)當前排名forum/sign_in_info/forum_infosign_count:1532,sign_rank:18,member_count:25625,dir_rate:0.

17、1yesterday_rank_info貼吧簽到數(shù)昨日排名weekly_rank_info貼吧簽到數(shù)上周排名sign_count:2629,sign_rank:19,member_count:25610monthly_rank_info貼吧簽到數(shù)上月排名id貼吧管理員IDmanagersname貼吧管理員昵稱typhoon_wolf下面詳細解說相對復(fù)雜的thread_list一級段。前文說過這是一個帖子列表，圖3-5是列表中某一個具體的表項，它處于一對大括號 內(nèi)。圖3-5 thread_list列表中某表項的數(shù)據(jù)如上圖，幾個子段的含義為：id是帖子的ID，title是帖子的標題【使用了Unic

18、ode編碼】，reply_num是回復(fù)數(shù)，view_num是點擊數(shù)，last_time是最后回復(fù)日期，last_time_int是最后回復(fù)時間，is_top表示是否置頂【為1置頂】，author里是作者信息，last_replyer里時最后回復(fù)人的信息，abstract是帖子的摘要信息。3.3 看帖用戶在貼吧里點擊某篇帖子之后，客戶端發(fā)出一個POST請求，其請求行URI固定為/c/f/pb/page，Host頭域的值為。請求正文以BDUSS=開始，其值與登陸成功后服務(wù)器所返回的響應(yīng)中一致。正文中特征串kz=后是本次請求所要閱讀的帖子ID，請求報文如圖3-6所示

19、。圖3-6 點擊某篇帖子之后發(fā)出的請求示例服務(wù)器給出的響應(yīng)頭部類似于圖1-1，正文以error_code段開始，其值為0，表明本次操作成功。后面的一級段中比較重要的包括user（所看帖子的作者信息）、forum（貼吧信息）以及post_list（帖子的具體內(nèi)容）。其中user與forum兩個一級段的分析大致與前文一致或類似，下面詳細分析一下post_list這個段。post_list其實是一個帖子【稱為主貼】的正文，所有對它的回復(fù)【為了便于區(qū)分，后文以“樓層”代稱】，以及所有對它回復(fù)的回復(fù)【為了表達簡介，后文以“回復(fù)”代稱】。我們知道在貼吧中，帖子的正文往往稱為一樓，對帖子本身的回復(fù)稱為按照先

20、后順序分別稱為二樓、三樓而且這些樓層本身也算發(fā)帖，會有帖子ID。post_list的所有內(nèi)容用一對方括號 括起來，里面的每個子段（我們稱為二級段）對應(yīng)帖子里面的一層樓。圖3-7是post_list的某一個二級段示例。圖3-7 post_list列表中某表項的數(shù)據(jù) 如上圖，幾個二級段的含義為：id是該樓層的ID，title是樓層的標題（使用了Unicode編碼，一樓的標題是整個主貼的標題，二樓及以后的標題是主貼的標題前加上“回復(fù)：”），floor是樓層編號，content是樓層的正文，author是建樓者的信息， sub_post_list是本樓層里的所有回復(fù)信息的綜述，他也有一個叫sub_po

21、st_list的子段（我稱之為三級段），里面是對本樓層的回復(fù)列表，這個列表的每個表項對應(yīng)本樓層每條回復(fù)的詳細信息，包括：author（回復(fù)者的信息）、id（回復(fù)的ID）、content（回復(fù)的正文），以及floor（相當于子樓層數(shù)）。3.4 回帖當我們點擊“回復(fù)”后，客戶端發(fā)出一個POST請求，其請求行URI固定為/c/c/post/add，Host頭域的值為。請求正文以BDUSS=開始，其值與登陸成功后服務(wù)器所返回的響應(yīng)中一致。正文中還有三處重要的信息，分別是回復(fù)的內(nèi)容（中文使用url編碼）、被回復(fù)貼所在的貼吧的名字（中文使用url編碼）、被回復(fù)貼子的ID。

22、他們的前綴特征分別為content=、kw=、tid=，后綴特征為&。當在四川大學吧回復(fù)一個ID為2404920336的帖子，回復(fù)內(nèi)容為”too bad !”時，請求報文如圖3-8所示。圖3-8 回帖時客戶端發(fā)送的請求示例服務(wù)器返回的響應(yīng)比較簡單，頭部和正文分別和圖1-1、1-2類似。響應(yīng)正文中比較重要的是error_code的值，為0的時候說明回復(fù)成功。3.5 發(fā)帖當我們點擊“發(fā)帖”后，客戶端發(fā)出一個POST請求，其請求行URI固定為/c/c/thread/add，Host頭域的值為。請求正文則如圖3-9所示。圖3-9 發(fā)帖時客戶端發(fā)送的請求正文示例如上圖，

23、請求正文以BDUSS=開始，其值與登陸成功后服務(wù)器所返回的響應(yīng)中一致。正文中還有三處重要的信息，分別是所發(fā)帖子的內(nèi)容（中文使用url編碼）、發(fā)貼所在貼吧的名字（中文使用url編碼）、所發(fā)貼子的標題（中文使用url編碼）。他們的前綴特征分別為content=、kw=、title=，后綴特征為&。 服務(wù)器返回的響應(yīng)比較簡單，頭部和正文分別和圖1-1、1-2類似。響應(yīng)正文中比較重要的是error_code的值，為0的時候說明回復(fù)成功。3.6 簽到用戶在某貼吧里點擊“簽到”后，客戶端發(fā)出一個POST請求，其請求行URI固定為/c/c/forum/sign，Host頭域的值為c.tieba.baidu.

24、com。請求正文以BDUSS=開始，其值與登陸成功后服務(wù)器所返回的響應(yīng)中一致。正文中特征串kw=后是本次所要簽到的的貼吧名（中文使用url編碼），其結(jié)束標志是&。當在三國殺吧簽到時，請求報文如圖3-10所示。圖3-10 在“三國殺”吧點擊“簽到”后客戶端發(fā)出的請求報文示例 服務(wù)器返回的響應(yīng)頭部與圖1-1基本一致，解壓后的響應(yīng)正文如圖3-11所示。圖3-11 點擊“簽到”后服務(wù)器的響應(yīng)正文如上圖，正文以user_info一級段開始，其值由多個子段構(gòu)成，含義分別為：is_sign_in表示簽到是否成功，user_sign_rank的值表示用戶第幾個簽到，sign_time表示用戶簽到時間，cont

25、_sign_num表示用戶本月連續(xù)簽到數(shù)，cont_total_sign_num表示用戶本月累計簽到數(shù)。在整個user_info一級段之后是在1.2節(jié)中提到的四個常見一級段。四、“個人中心”相關(guān)操作分析 如圖4-1所示，“個人中心”中進行的會引起網(wǎng)絡(luò)通信行為的常見操作包括查看“我喜歡的吧”、“我的關(guān)注”、“我的粉絲”、“我的收藏”、“我的消息”、“我的帖子”、“我的微貼”，以及在“設(shè)置”里查看和修改個人資料。下面分別進行分析。圖4-1 貼吧客戶端-個人中心4.1 查看“我喜歡的吧”當用戶在“個人中心”點擊“我喜歡的吧”后，客戶端發(fā)出一個POST請求，其請求行URI固定為/c/f/forum/l

26、ike，除此之外，整個請求的構(gòu)造與點擊“進吧”后（見圖3-1）基本一致。服務(wù)器返回的響應(yīng)頭部與圖1-1基本一致，解壓后的響應(yīng)正文也與點擊“進吧”后類似，以error_code段開始，其值為0，表明本次操作成功。正文中最重要的也是一個名為forum_list的貼吧列表。不同的是，此處forum_list列表中是用戶已經(jīng)成為會員的貼吧（4.1節(jié)中返回的列表是用戶常逛的貼吧），排列順序依照用戶的等級由高到低（4.1節(jié)中返回的列表按照用戶近期訪問頻率排列）。這個列表中每個表項的構(gòu)成也與4.1節(jié)中不同，圖4-2是這個列表中的一個表項示例。圖4-2 forum_list中某表項的數(shù)據(jù) 該表項中幾個重要的子

27、段包括：id（貼吧ID）、name（貼吧名，使用Unicode編碼）、level_id（用戶在本吧的等級）、level_name（用戶在本吧的稱號，使用Unicode編碼）。4.2 查看“我的關(guān)注”當用戶在“個人中心”點擊“我的關(guān)注”后，客戶端發(fā)出一個POST請求，其請求行URI固定為/c/u/follow/page，除此之外，整個請求的構(gòu)造與點擊“進吧”后（見圖3-1）基本一致。服務(wù)器返回的響應(yīng)頭部與圖1-1基本一致，解壓后的響應(yīng)正文如圖4-3所示。圖4-3 點擊“我的關(guān)注”后服務(wù)器返回的響應(yīng)正文如上圖，正文以error_code段開始，其值為0，表明本次操作成功。在page一級段中有一個t

28、otal_count子段，其值為用戶所關(guān)注的用戶數(shù)。正文中最重要的一級段是user_list，是用戶所關(guān)注用戶的列表。與前文提到的一些列表類似，列表的所有表項處于一對方括號內(nèi)，表項之間用逗號隔開，每個表項的所有子段都用一個大括號 括起來。每個表項中幾個重要的二級段包括：id（所關(guān)注用戶的ID）、name（所關(guān)注用戶的昵稱，使用Unicode編碼）、intro（所關(guān)注用戶的自我簡介，使用Unicode編碼）。4.3 查看“我的粉絲”當用戶在“個人中心”點擊“我的粉絲”后，客戶端所發(fā)出請求的結(jié)構(gòu)與點擊“我的關(guān)注”后完全一致，但其請求行URI固定為/c/u/fans/page。服務(wù)器給出的響應(yīng)報文的

29、結(jié)構(gòu)也與點擊“我的關(guān)注”后完全一致4.4 查看“我的收藏” 當用戶在“個人中心”點擊“我的收藏”后，客戶端發(fā)出一個POST請求，其請求行URI固定為/c/f/post/threadstore，Host頭域的值為。如圖4-4所示，請求正文以BDUSS=開始，其值與登陸成功后服務(wù)器所返回的響應(yīng)中一致。正文中特征串user_id=后客戶端用戶的ID，其結(jié)束標志是&。圖4-4點擊“我的收藏”后客戶端發(fā)出的請求正文示例服務(wù)器返回的響應(yīng)頭部與圖1-1基本一致，解壓后的響應(yīng)正文如圖4-5所示。圖4-5點擊“我的收藏”后服務(wù)器返回的響應(yīng)正文從上圖可以看到，此處的響應(yīng)正文與其他

30、操作的一個很大不同在于，它的第一個一級段不再是error_code，而是store_thread。這是一個收藏的帖子列表，和前文提到的一些列表相同，這個列表的所有表項處于一對方括號內(nèi)，表項之間用逗號隔開，每個表項的所有子段都用一個大括號 括起來。每個表項中幾個重要的二級段包括：thread_id（帖子的ID）、title（帖子的標題）、forum_name（帖子所在的貼吧）、author（帖子的作者信息）、reply_num（帖子的回復(fù)數(shù)）。error_code這個一級段并非不存在了，只是移到了倒數(shù)第四個。在它的前面還有一個名為error的一級段，似乎和error_code所表達的信息一致。4

31、.5 查看“我的消息”“我的消息”分為“回復(fù)我的”和“我的”兩種。要完整取回這兩類消息，客戶端會發(fā)出兩個POST請求。以查看“回復(fù)我的”消息為例，報文范例如圖4-6所示。圖4-6 查看“回復(fù)我的”消息時客戶端發(fā)出的請求從上圖可以看到，請求行的URI固定為/c/u/feed/replyme，Host頭域的值為。請求正文以BDUSS=開始，其值與登陸成功后服務(wù)器所返回的響應(yīng)中一致。和點擊“進吧”后所發(fā)請求不同的是，多了名為pn和uid的元素。前者含義未知，后者是請求用戶的ID。服務(wù)器返回的響應(yīng)頭部與圖1-1基本一致，解壓后的響應(yīng)正文以error_code段開始，其

32、值為0，表明本次操作成功。正文中最重要的一級段是reply_list，是回復(fù)消息的列表。與前文提到的一些列表類似，列表的所有表項處于一對方括號內(nèi)，表項之間用逗號隔開，每個表項的所有子段都用一個大括號 括起來。圖4-7是一個具體的表項示例。圖4-7 reply_list中某表項的數(shù)據(jù) 該表項中幾個重要的子段包括：is_floor（為0表示是對一個帖子的直接回復(fù)，為1表示是對一個帖子中某一樓層的回復(fù)）、unread（為1表示用戶尚未閱讀本消息，為0表示已閱讀）、replyer（回復(fù)者的信息）、title（主貼的標題）、content（回復(fù)的內(nèi)容）、thread_id（所在主貼的ID）、post_i

33、d（樓層的ID），以及fname（回復(fù)所在貼吧的名字，中文用Unicode編碼）。查看“我的”消息時，客戶端所發(fā)請求報文的結(jié)構(gòu)與查看“回復(fù)我的”消息時完全一致，只是請求行的URI不同，固定為/c/u/feed/atme。服務(wù)器所返回響應(yīng)也與查看“回復(fù)我的”消息時基本一致，只不過在reply_list一級段對應(yīng)的位置變成了at_list，這是客戶端用戶的消息列表，表項的結(jié)構(gòu)如圖4-8所示。圖4-8 at_list中某表項的數(shù)據(jù)該表項中幾個重要的子段包括： replyer（發(fā)出者的信息）、title（主貼的標題）、content（含有的帖子/回復(fù)內(nèi)容）、thread_id（所在主貼的ID）、pos

34、t_id（樓層的ID），以及fname（主貼所在貼吧的名字，中文用Unicode編碼）。4.6 查看“我的帖子”當用戶在“個人中心”點擊“我的帖子”后，客戶端發(fā)出一個POST請求，其請求行URI固定為/c/u/feed/mypost。如圖4-9所示，整個請求報文的結(jié)構(gòu)與點擊“進吧”后類似，不同的是正文中多了名為pn的元素，含義未知。圖4-9點擊“我的帖子”后客戶端發(fā)出的請求報文示例服務(wù)器返回的響應(yīng)頭部與圖1-1基本一致，解壓后的響應(yīng)正文以error_code段開始，其值為0，表明本次操作成功。正文中最重要的一級段是post_list，是客戶端使用者所發(fā)帖子的列表。與前文提到的一些列表類似，列表

35、的所有表項處于一對方括號內(nèi)，表項之間用逗號隔開，每個表項的所有子段都用一個大括號 括起來。圖4-10是一個具體的表項示例。圖4-10 post_list中某表項的數(shù)據(jù) 該表項中幾個重要的子段包括：author（發(fā)帖者信息）、title（主貼的標題，中文使用Unicode編碼）、fname（發(fā)帖所在貼吧，中文使用Unicode編碼）、reply_time（發(fā)帖日期）、reply_num（主貼的回復(fù)數(shù)）、pid（用戶所發(fā)帖子的ID）、tid（主貼的ID），以及is_floor（為1表明這是回復(fù)貼，為0表示這是發(fā)表貼）。4.7 查看“我的微貼”當用戶在“個人中心”點擊“我的微帖”后，客戶端發(fā)出一個P

36、OST請求，其請求行URI固定為/c/u/feed/ssf。如圖4-11所示，正文中多了名為rn的元素，含義未知。除此之外，整個報文的結(jié)構(gòu)與查看“回復(fù)我的”消息時基本一致。圖4-11點擊“我的微貼”后客戶端發(fā)出的請求正文示例服務(wù)器返回的響應(yīng)頭部與圖1-1基本一致。如圖4-12所示，解壓后的響應(yīng)正文以error_code段開始，其值為0，表明本次操作成功。正文中最重要的一級段是thread_list，是客戶端使用者所發(fā)微貼的列表。由于當前為空，所有列表內(nèi)部結(jié)構(gòu)尚未分析。圖4-12點擊“我的微貼”后服務(wù)器返回的響應(yīng)正文4.8 查看“設(shè)置-個人資料”在“個人中心”的右上角有“設(shè)置”，點進去后的第二項

37、叫“個人資料”，點擊后即可查看個人資料，如圖4-13所示。圖4-13 查看個人資料在這個過程中，客戶端也會發(fā)送一個POST請求，其請求行URI固定為/c/u/user/pro頭域的值為。如圖4-14，請求正文以BDUSS=開始，其值與登陸成功后服務(wù)器所返回的響應(yīng)中一致。正文中有uid元素，值為客戶端用戶的ID。圖4-14 查看個人資料時客戶端發(fā)出的請求正文示例服務(wù)器返回的響應(yīng)頭部與圖1-1基本一致。如圖4-12所示圖4-15 查看個人資料時服務(wù)器返回的響應(yīng)正文 如上圖，響應(yīng)正文中最重要的是user這個一級段。組成其值的幾個重要子段分別為： id（用戶ID）、n

38、ame（用戶名，客戶端上有顯示）、intro（用戶個人簡介，中文使用Unicode編碼，客戶端上有顯示）、sex（用戶性別，客戶端上有顯示）、like_forum_num（用戶喜歡的貼吧數(shù)，即用戶已成為會員的貼吧數(shù)）、concern_num（用戶關(guān)注的用戶數(shù)）、fans_num（用戶擁有的粉絲數(shù)）。4.9 修改“設(shè)置-個人資料”在“個人資料”的右上角有“保存”按鈕，點擊后即可完成修改個人資料。在這個過程中，客戶端會發(fā)出一個POST請求，其請求行URI固定為/c/c/pro，Content-Type頭域的值為multipart/form-data ; boundary=-7da3d8152081

39、0*，表明正文采用了multipart/form-data格式，正文各子段之間使用“-7da3d81520810*”作為分隔符。請求正文如圖4-16所示（由于報文過長，部分不重要的子段被省略，用代替）。圖4-16 修改“個人資料”時客戶端發(fā)出的請求正文如上圖，正文以“-7da3d81520810*”標志開始，以“-7da3d81520810*-”標志結(jié)束。正文中比較重要的子段的name分別為：BDUSS（登錄憑證）、intro（個人簡介）和sex（性別）。BDUSS子段的值與登陸成功后服務(wù)器所返回的響應(yīng)中一致；intro子段的值是圖4-13中“個人簡介”的信息（中文使用UTF-8字符集）；se

40、x子段的值對應(yīng)圖4-13中的“性別”信息，男為1，女為2。服務(wù)器返回的響應(yīng)比較簡單，頭部和正文分別和圖1-1、1-2類似。響應(yīng)正文中比較重要的是error_code的值，為0的時候說明修改成功。五、其他操作及行為分析5.1 首頁點擊“首頁”后，客戶端發(fā)出一個POST請求，其請求行URI固定為/c/s/tag/allthread，Host頭域的值為。請求正文以BDUSS=開始，其值與登陸成功后服務(wù)器所返回的響應(yīng)中一致。請求正文中另外還有的信息包括：客戶端類型、版本，時間戳等，如圖5-1。圖5-1點擊“首頁”后發(fā)出的請求報文 服務(wù)器返回的響應(yīng)頭部與圖1-1基本一致

41、。與其他操作返回的正文格式為純文本文件不同，此處的響應(yīng)正文是一個標準html文件。由于正文里沒什么重要信息，在此不作具體分析。5.2 身邊點擊“身邊”后，客戶端和服務(wù)端會進行四次重要的HTTP會話，前兩個會話用于客戶端用戶的定位，后兩個會話分別用于查看“身邊的微貼”和“身邊的吧”。下面分別進行分析。5.2.1 定位在定位過程進行的兩次HTTP會話中，客戶端使用的都是POST請求，兩個請求頭部的結(jié)構(gòu)類似，但與其他操作發(fā)出的請求報文結(jié)構(gòu)有極大不同。首先，兩個POST的請求行URI都固定為/sdk.php；其次，請求的服務(wù)器（由請求頭部Host頭域的值指定）都變?yōu)榱?/p>

42、，而不再是其他請求中所用的。請求正文的格式（由請求頭部Content-Type頭域的值指定）依舊是application/x-。兩個請求報文的頭部、正文分別如圖5-2【a】、【b】、【c】所示?！綼】定位請求的頭部示例【b】第一個定位請求的正文【c】第二個定位請求的正文圖5-2進行定位時客戶端發(fā)出的請求報文示例請求正文的含義尚未分析出來。服務(wù)器所給兩個響應(yīng)的報文結(jié)構(gòu)基本一致，但正文的內(nèi)容有很大不同，如圖5-3所示。【a】第一個定位請求對應(yīng)的響應(yīng)【b】第二個定位請求對應(yīng)的響應(yīng)正文圖5-3 進行定位時服務(wù)器返回的響應(yīng)報文示例服務(wù)器對第一個定位請求返回響應(yīng)的含義尚未分析出來，但是在第二個定位請求所對應(yīng)的響應(yīng)正文中，我們可以還原出一些感興趣的東西。它分為content和result兩個一級段，在co