網站與APP抓包分析1 基礎知識與工具
關鍵詞:TCP、HTTP、HTTPS、HTTPDNS、Chrome、tshark、Charles、fidder、VirtalXposed
1、常用通信協定基礎
1.1、TCP/IP協定族簡介
TCP/IP是一個協定族的統稱,裡面包括了TCP(傳輸控制協定)和IP(網際協定/網際網路互聯協定)等一組網絡協定。

上圖來源于網際網路
TCP/IP協定族可分為應用層、傳輸層、網絡層、網絡接口層,即為四層模型(協定)。
TCP/IP協定的發送主機從上自下将資料按照協定封裝,而接收資料的主機則按照協定反向讀取。
由于這種結構非常接近與“棧”的概念,是以也把TCP/IP協定族稱為TCP/IP協定棧。
資料包按照層級由上到下層層封裝依次為:
應用層:為具體傳輸的資料内容,包含HTTP、FTP等協定
傳輸層:包含TCP和UDP協定,負責标記資料序列号和端口等資訊
網絡層:主要為IP協定,負責對資料加上IP位址等資訊
資料鍊路層:為資料包加入一個以太網協定頭,并進行編碼
實體層:負責網絡的傳輸,這個層次的定義包括網線的制式,網卡的定義等。
圖形與名額切換TCP 協定在 IP 協定提供的主機間通信功能的基礎上,完成這兩個主機上程序對程序的通信。同時TCP是面向連接配接的通信協定,通過三次握手建立連接配接,通訊完成時要拆除連接配接,是以隻能用于端到端的通訊(區分于UDP協定)。
TCP資料包中包括序号和确認機制,是以未按照順序收到的包可以被排序,而損壞或者丢失的包将會被重傳,是以TCP協定具有高度的可靠性。
當IP資料包中有已經封好的TCP資料包,那麼IP将把它們向‘上’傳送到TCP層。 TCP将包排序并進行錯誤檢查,同時實作虛電路間的連接配接。TCP将它連接配接建立的資訊送到更高層的應用程式,例如Telnet的服務程式和客戶程式。應用程式輪流将資訊送回TCP層,TCP層便将它們向下傳送到IP層,裝置驅動程式和實體媒體,最後到接收方。
1.2、TCP協定
1.2.1、TCP封包結構
TCP封包結構
上圖來源于網際網路
TCP封包頭部結構:
TCP封包頭部資訊結構說明:
編号 | 名稱 | 說明 |
---|---|---|
1 | 源端口/目的端口 | 辨別封包的傳回位址和接收方計算機上的應用程式接口 |
2 | 序号/确認号 | 序号是本封包段發送的資料組的第一個位元組的序号。在TCP傳送的流中,每一個位元組一個序号。确認号即ACK,指明下一個期待收到的位元組序号,表明該序号之前的所有資料已經正确無誤的收到。 |
3 | 資料偏移/首部長度 | 由于首部可能含有可選項内容,是以TCP報頭的長度是不确定的,報頭不包含任何任選字段則長度為20位元組,最大長度為60位元組。首部長度也叫資料偏移,是因為首部長度實際上訓示了資料區在封包段中的起始偏移值。 |
4 | 保留 | 為将來定義新的用途保留,現在一般置0。 |
5 | 控制位 | 包含:URG ACK PSH RST SYN FIN,共6個标志位,每一個标志位表示一個控制功能。 |
6 | 視窗 | 滑動視窗大小用來告知發送端接受端的緩存大小,以此控制發送端發送資料的速率,進而達到流量控制。滑動視窗大小标記是一個16bit字段(最大為16個1),因而視窗大小最大為65535位元組。 |
7 | 校驗和 | 校驗和(奇偶校驗)是對整個的TCP 封包段,包括 TCP 頭部和TCP 資料,以 16 位字進行計算所得。由發送端計算和存儲,并由接收端進行驗證。 |
8 | 緊急指針 | 隻有當 URG 标志置 1 時緊急指針才有效。緊急指針是一個正的偏移量,和順序号字段中的值相加表示緊急資料最後一個位元組的序号。 TCP 的緊急方式是發送端向另一端發送緊急資料的一種方式。 |
9 | 可選項 | 可選字段包含最長封包大小,時間戳等選項。 |
10 | 資料包 | TCP 封包段中的資料部分是可選的。例如在一個連接配接建立和一個連接配接終止時,雙方交換的封包段僅有TCP 首部;在處理逾時的許多情況中,也會發送不帶任何資料的封包段。 |
TCP封包頭部資訊解析執行個體:
1.2.2、TCP封包控制位
TCP封包控制位資訊結構說明:
URG | 緊急指針标志,為1時表示緊急指針有效,為0則忽略緊急指針。 | |
ACK | 确認序号标志,為1時表示确認号有效,為0表示封包中不含确認資訊,忽略确認号字段。 | |
PSH | push标志,為1表示是帶有push标志的資料,訓示接收方在接收到該封包段以後,應盡快将這個封包段交給應用程式,而不是在緩沖區排隊。 | |
RST | 重置連接配接标志,用于重置由于主機崩潰或其他原因而出現錯誤的連接配接。或者用于拒絕非法的封包段和拒絕連接配接請求。 | |
SYN | 同步序号,用于建立連接配接過程。在連接配接請求中,SYN=1和ACK=0表示該資料段沒有使用捎帶的确認域,而連接配接應答捎帶一個确認,即SYN=1和ACK=1。 | |
FIN | Finish标志,用于釋放連接配接,為1時表示發送方已經沒有資料發送了,即關閉本方資料流。 |
TCP封包控制位資訊結構說明解析執行個體:
注:灰色背景部分為資料流中TCP頭部資訊,藍色标記部分(8002)為标記位内容。
1.2.3、TCP連接配接過程
TCP協定通過三次握手過程建立連接配接後進行資料傳輸,完成後通過四次揮手過程斷開目前會話連接配接。
連接配接建立過程中以SYN值标記請求,以ACK标記響應。
TCP會話建立過程中:
(1)首先由用戶端發送建鍊請求,此時SYN=1(代表請求建立由用戶端到服務端的連接配接),ACK=0(代表無需确認内容);
(2)服務端收到上述資訊後,發送資訊ACK=1(表示已收到上述請求),SYN=1(表示請求建立由服務端到用戶端的連接配接);
(3)用戶端收到服務端響應後,發送ACK=1(表示收到服務端的建鍊請求),此時連接配接建立完成。
1.3、HTTP協定
1.3.1、HTTP協定簡介
超文本傳輸協定是一種用戶端和服務端請求和應答的标準,是應用層面向對象的無狀态通信協定。
HTTP協定在TCP連接配接的基礎上使用統一資源辨別符(URI)來建立連接配接和傳輸資料。
(1)用戶端與服務端:
HTTP用戶端(Client)是一個應用程式(Web浏覽器或其他任何用戶端),通過連接配接到伺服器達到向伺服器發送一個或多個HTTP的請求的目的。
HTTP伺服器(Service)是一個應用程式(通常是一個Web服務,如Apache Web伺服器等),通過接收用戶端的請求并向用戶端發送HTTP響應資料。
(2)請求内容:
HTTP請求是用戶端往服務端發送請求動作,告知伺服器自己的要求;
HTTP請求由狀态行、請求頭、請求正文三部分組成;
狀态行:包括請求方式(Method)、資源路徑(URL)、協定版本(Version);
請求頭:包括一些通路的域名、使用者代理、Cookie等資訊;
請求正文:就是HTTP請求的資料。
(3)響應内容:
HTTP響應是服務端收到了用戶端發來的請求後,根據請求中的要求,做出具體的動作,将結果回應給用戶端的過程;
HTTP響應由三部分組成:狀态行、響應頭、響應正文;
狀态行:包括協定版本Version、狀态碼StatusCode、回應短語;
響應頭:包括搭建伺服器的軟體,發送響應的時間,回應資料的格式等資訊;
響應正文:就是響應的具體資料。
(4)HTTP協定互動執行個體解析:
1.3.2、HTTP協定常用方法
GET | 向特定的資源送出請求,用于請求通路已經被URI(統一資源辨別符)識别的資源,可以通過URL傳參給伺服器。GET中如果出現使用者賬号密碼或MAC等可以唯一标記一個用的資訊,将被視為安全隐患。 | |
POST | 向指定資源送出資料進行處理請求(例如送出表單或者上傳檔案)。資料被包含在請求體中。目前DPI話單無法解析POST中内容,是以POST傳輸賬号密碼等資訊可視為加密方式。 | |
CONNECT | HTTP/1.1 協定中預留給能夠将連接配接改為管道方式的代理伺服器。此方法在抓包分析是可能會經常遇到,某些HTTS協定的内容會以這種格式在Wireshark中顯示。 | |
PUT | 向指定資源位置上傳其最新内容,傳輸檔案、封包主體中包含檔案内容,儲存到對應URI位置。 | |
HEAD | 向伺服器請求擷取封包首部,響應體将不會被傳回。這一方法可以在不必傳輸整個響應内容的情況下,就可以擷取包含在響應消息頭中的元資訊,一般使用者驗證URI是否有效。 | |
DELETE | 請求伺服器删除 Request-URI 所辨別的資源。 | |
OPTIONS | 傳回伺服器針對特定資源所支援的HTTP請求方法。也可以利用向伺服器發送'*'的請求來測試伺服器的功能性。 | |
TRACE | 回顯伺服器收到的請求,主要用于測試或診斷。 |
注:在日常的網頁和APP分析中,除GET、POST、CONNECT之外的方法通常極為少見。
1.3.3、HTTP協定響應碼分類
1** | 資訊,伺服器收到請求,需要請求者繼續執行操作(很少出現) | |
2** | 成功,操作被成功接收并處理 | |
3** | 重定向,需要進一步的操作以完成請求,服務端通常會攜帶一個Location給用戶端用來指向新的URL,此過程經常被稱為排程。 | |
4** | 用戶端錯誤,請求包含文法錯誤或無法完成請求 | |
5** | 伺服器錯誤,伺服器在處理請求的過程中發生了錯誤 | |
(0-5) | 不在标準範圍之内,通常被用于某些特定場景 |
HTTP響應碼執行個體解析:
1.4、HTTPS協定
1.4.1、HTTPS協定簡介
HTTP協定被用于在Web浏覽器和網站伺服器之間傳遞資訊。
HTTP以明文方式發送内容,不提供任何方式的資料加密,如果攻擊者截取了Web浏覽器和網站伺服器之間的傳輸封包,就可以直接讀懂其中的資訊,是以HTTP協定不适合傳輸一些敏感資訊,比如信用卡号、密碼等。(除非在傳輸裝好密碼之前在用戶端直接解密,然後傳輸加密内容,但用戶端可通過破解安裝包的方式擷取原始算法,是以這種方式并不安全)。
TLS協定由:TLS 記錄協定(TLS Record)和 TLS握手協定(TLS Handshake)組成
HTTPS超文本傳輸協定,在HTTP協定基礎上加入了SSL層。即HTTPS存在不同于HTTP的預設端口及一個加密/身份驗證層(在HTTP與TCP之間)。SSL(Secure Sockets Layer 安全套接層)及其繼任者傳輸層安全(Transport Layer Security TLS)是為網絡通信提供安全及資料完整性傳輸的一種安全協定。TLS與SSL在傳輸層對網絡連接配接進行加密。
1.4.2、HTTPS認證流程
用戶端請求:client向server發送請,連接配接到server的443端口。
服務端公鑰證書:服務端須有一套數字證書(可自制或申請,差別為自己頒發的證書需用戶端驗證通過,使用受信任的公司申請的證書則不會彈出提示頁面)這套證書可視為一對公鑰和私鑰。
傳送證書:這個證書其實就是公鑰,隻是包含了很多資訊,如證書的頒發機構,過期時間、服務端的公鑰,第三方證書認證機構(CA)的簽名,服務端的域名資訊等。
用戶端解析證書:這部分工作是由用戶端的TLS來完成的,首先會驗證公鑰是否有效(比如頒發機構,過期時間等等),如證書異常,則會彈出警告,提示證書存在問題。如證書正常,則生成一個随即值(秘鑰)。然後用證書對該随機值進行加密。
傳送加密資訊:傳送的是用證書加密後的秘鑰,服務端得到此秘鑰後,用戶端和服務端的通信将通過這個随機值來進行加密解密。
服務端加密資訊:服務端用私鑰解密秘密秘鑰,得到了用戶端傳過來的私鑰,然後把内容通過該值進行對稱加密。
傳輸加密後的資訊:這部分資訊是服務端用私鑰加密後的資訊,可以在用戶端被還原。
用戶端解密資訊:用戶端用之前生成的私鑰解密服務端傳過來的資訊。
HTTPS認證流程執行個體解析:
1.4.3、HTTPS常用分析工具
1.5、DNS域名解析協定
1.5.1、DNS域名解析協定簡介
域名解析是把域名指向網站空間IP,即通過注冊的域名可以通路到網站,網際網路中的位址是數字的IP位址,域名的作用主要是為了便于記憶。
域名解析服務由DNS伺服器完成,是把域名解析到一個IP位址的過程,然後在此IP位址的主機上将一個子目錄與域名綁定。
DNS域名解析協定執行個體解析:
1.5.2、HttpDNS簡介
HttpDNS域名解析方式即是将域名解析的協定由 DNS協定換成了 Http協定,用于繞過LocalDNS,直接擷取到使用者 IP,以保證将使用者引導的通路最快或者服務端指定的 IDC節點上, 排除域名解析異常的困擾。
實作原理通常為:用戶端通過HTTP協定中的GET請求直接通路服務端的 HttpDNS服務接口,服務端會根據使用者上傳的本地資訊(例如用戶端IP位址等資訊)進行比對或者直接傳回業務在域名配置管理系統上配置的通路延遲最優的 IP位址清單(基于容災考慮,還是保留次選使用營運商 LocalDNS解析方式)。
(1)解決的問題:
Local DNS 劫持:由于 HttpDns 是通過 IP 直接請求 HTTP 擷取伺服器位址,不存在向LocalDNS詢問domain解析過程,是以避免了劫持問題。
平均通路延遲下降:由于是IP直接通路省掉了一次domain解析過程,通過智能算法排序後找到最快節點進行通路。
使用者連接配接失敗率下降:通過算法降低以往失敗率過高的伺服器排序,通過時間近期通路過的資料提高伺服器排序,通過曆史通路成功記錄提高伺服器排序。
(2)過程特征:
使用者上傳本地資訊以及擷取業務IP資訊通常使用GET方式。
服務端傳回的業務IP資訊通常包含在HTTP響應或者其XML文檔中。
IP資訊檔案通常為相關業務伺服器名稱或者域名與IP位址的鍵值對。
用于擷取該資訊的GET請求中通常會包含某些關鍵字如newgetdns或httpdns等。
(2)HttpDns執行個體解析(以今日頭條APP為例):
請求:
http://dm.bytedance.com/get_domains/v4/?abi=arm64-v8a&ac=wifi&channel=xiaomi&aid=13&app_name=news_article&version_code=697&version_name=6.9.7&device_platform=android&ab_feature=94563%2C102749&abflag=1&ssmix=a&device_type=Redmi+6+Pro&device_brand=xiaomi&language=zh&os_api=27&os_version=8.1.0&manifest_version_code=697&resolution=1080*2150&dpi=440&update_version_code=69716&_rticket=1541659893362&plugin=0&rom_version=miui_v10_8.11.1
響應:
1.6、 資料互動常用編碼方式簡介
通常可根據其顯示樣式初步判斷編碼方式,可使用網上的各類線上工具進行嘗試反編譯,例如“站長之家”、“線上工具”等
例如線上工具網站:
https://tool.lu/encdec/1.6.1、urlencode
URL編碼(URL encoding),也稱作百分号編碼(Percent-encoding), 是特定上下文的統一資源定位符 (URL)的編碼機制。
将需要轉碼的字元轉為16進制,然後從右到左,取4位(不足4位直接處理),每2位做一位,前面加上%,編碼成%XY格式。
适用于統一資源辨別符,也用于通過HTTP的請求操作(request)送出HTML表單資料。
1.6.2、Base64encode
Base64編碼是從二進制到字元的過程,可用于在HTTP環境下傳遞較長的辨別資訊。
編碼後内容通常為:小寫字母a-z、大寫字母A-Z、數字0-9、符号”+”、”/”作為基本基礎集的編碼方式。
1.6.3、MD5
MD5消息摘要算法(MD5 Message-Digest Algorithm)為一種被廣泛使用的密碼散列函數,可以産生出一個128位的散列值(hash value),用于確定資訊傳輸完整一緻。
MD5特性:壓縮性:無論資料長度是多少,計算出來的MD5值長度相同;容易計算性:由原資料容易計算出MD5值;抗修改性:即便修改一個位元組,計算出來的MD5值也會巨大差異;抗碰撞性:知道資料和MD5值,很小機率找到相同MD5值相同的原數。
2.内容分發網絡與資源排程
2.1、内容分發網絡與資源排程
(1)内容分發網絡:
内容分發過程通常為通過實作使用者對網站的就近通路及網絡流量的智能分析,将本節點資源庫中的指定内容,根據業務營運商定義的内容分發政策向下層節點或使用者進推送。
内容分發網絡一般采用分布式的架構,根據實際情況,可以構成中心-邊緣層次結構或分布式結構。通常營運商搭建的内容分發網絡為集中式部署,即整個體系集中部署在一個或幾個有限的節點。
國内常見内容分發平台包括:阿裡雲、騰訊雲、華為雲、百度雲等平台。部分網際網路企業也擁有自建雲平台用于業務分發,例如今日頭條(位元組跳動CDN)與美團(美團雲)等。
(2)資源排程方式:
内容分發平台中的資源存儲節點通常分布于各大營運商的各省節點,以期為使用者提供就近服務。
當使用者發起資源方式請求時,内容分發網絡中控制節點(重定向服務節點)将會根據使用者所在位置以及網絡情況和資源分布情況,綜合判斷後向用戶端提供資源所在位置。
資源分發(排程)方式通常通過HTTP協定的302相應過程,或根據既定算法構造URL來實作。
2.2、使用者資源通路流程
根據通路内容不同,使用者資源通路通過不同的路徑去往不同的内容源。其通路的資源位置的控制也稱為排程。
根據ICP的分發政策、資源本身屬性等原因,資源分布于不同節點,其品質将直接影響用使用者感覺。
使用者通路位于本地的資源的感覺品質通常要更好,同時可節約網絡出口帶寬。
資源本地化的實作,可以通過ICP建立資料節點、三方CDN廠商、主動緩存等方式。
2.3、資源排程與分布示例
2.3.1、通過HTTP協定3**過程進行資源排程
以某網站内圖檔請求為例:
其中首次通路圖檔URL為HTTP請求,由于需要使用安全協定,服務端通過301重定向重定義了URL,并要求用戶端重新通路。
資源分發方式與上述過程基本 一緻,僅目的不同。
2.3.2、通過DNS域名解析(不同域名)進行資源排程
以“今日頭條APP”為例:
其中域名“*tt.bytecdn.cn”為“位元組跳動CDN”的域名,其中資源基本上為頁面圖檔圖示,其解析位址部分在四川移動,有部分解析到了重慶移動。
其中域名“.pstatp.com”與“ .swcdn-tos.pstatp.com”為今日頭條的資源下載下傳域名,其中大部分域名解析首位址歸屬為四川移動,有部分解析至其他省份(測試使用寬帶網絡歸屬為四川移動)。
2.4、資源排程與分布示例
2.4.1、通過HTTPDNS進行資源排程
以今日頭條APP為例:
通過HTTP GET加載配置檔案的方式進行HttpDNS解析與請求URL構造。其中包括固定域名與IP位址的DNS映射資訊(示例中紅色部分),以及HTTPS DNS,部分API接口的URL構造方式
2.4.2、通過用戶端構造請求資源排程
在配置檔案中設定資源所在URL
••••action":3,"desc":"","extra":{}},{"action":7,"desc":"","extra":{}},{"action":9,"desc":"","extra":{}}],"aggr_type":1,"allow_download":false,"article_sub_type":0,"article_type":0,"article_url":"
http://toutiao.com/group/6666719190537208334/","article_version":0,"ban_comment":0,"behot_time":1552227319,
3、正常工具安裝與使用
3.1、常用抓包與分析工具
浏覽器内置開發者工具 | 調用快捷鍵F12或Ctrl+Shift+I。浏覽器内置開發者工具,網絡資料互動分析通常使用其中的NetWork子產品。 | |
Wireshark | 網絡封包分析軟體,為通用網絡通信抓包工具。Wireshark技術能夠處理單片封包,支援協定數量多,處理速度快、适用大部分應用的場景。 | |
Fidder | Fiddler代理抓包工具能夠監控檢測點之間的通訊,設定斷點,檢視所有的“進出”Fiddler的資料(指cookie,html,js,css等檔案);支援通過代理方式解析HTTPS協定内容。 | |
charles | 相當于一個在伺服器和用戶端之間的“過濾器”,是與Fidder相同類型的代理抓包工具。與Fidder差別在于其界面很友好、可跨平台(适用windowsLinuxMac)、可以自定義上下行網速、ExternalProxy、反向代理配置簡單、可解析AMF協定資料等。 | |
VirtualXposed | 基于VirtualApp和epic在非ROOT環境下運作Xposed子產品的實作。Xposed架構是一套開源的、在Android高權限模式下運作的架構服務,可以在不修改APK檔案的情況下影響程式運作(修改系統)的架構服務,相當于在手機上安裝一個虛拟空間。 | |
抓包精靈 | 運作于Andiord平台的隻能抓包工具。其支援HTTPS協定的解析(采用代理的方式),應用配置簡單,但功能較弱分析能力有限。 |
3.2、浏覽器内置工具
浏覽器内置開發者工具,網絡資料互動分析通常使用其中的NetWork子產品。
浏覽器F12、Fn+F12或Ctrl+Shift+I快捷鍵打開開發者工具。網絡請求記錄(Network)選項将記錄目前網頁的請求與響應記錄。顯示内容包含有請求、響應、品質、網絡等資訊。
3.3、Wireshark内置tshark指令行工具
(1)tshark工具:
Wireshark安裝目錄下内置指令行工具tshark.exe,通過cmd工具進入對應路徑後,以[tshark –參數 待解析檔案名 –參數]的指令格式調用tshark工具,對檔案包進行解析,已達到結果或過程輸出或統計的目的。
(2)常用tshark指令:
DNS解析結果:
tshark -r ..\XXXX.pcapng -e frame.number -e dns.qry.name -e dns.a -E separator=" " -T fields -2 -R "dns.a" -q
擷取IP清單:
tshark -r ..\XXXX.pcapng -z endpoints,ip -n -q
HTTP請求記錄:
tshark -r ..\XXXX.pcapng -2 -R "http.request" -T fields -e http.host -e ip.dst -e http.request.uri -e http.request.method -e tcp.dstport -q
錯誤HTTP記錄:
tshark -r ..\XXXX.pcapng -2 -R "http.response and not (http.response.code == 200 or http.response.code == 206 or http.response.code == 301 or http.response.code == 302 or http.response.code == 304 or http.response.code == 101)" -z conv,tcp
HTTP視訊請求:
tshark -r ..\XXXX.pcapng -2 -R "http.request" -q -T fields -e http.host -e ip.dst -e http.request.uri -e http.request.method | findstr "\.flv \.f4v \.hlv \.fhv \.letv \.ts \.avi \.mov \.rm \.rmvb \.ram \.wmv \.mkv \.mp3 \.mp4 \.wma \.mid \.asf \.wav \.asx \.m2ts"
3.4、Charles工具配置
3.4.1、Charles工具PC端配置
Charles安裝流程與常用軟體安裝流程一緻,過程中無需特殊配置,按預設步驟執行即可。
Proxy> SSL Proxing Settings:設定SSL代理選擇的域名等(預設為“*”,保持不變即可)。
Proxy> Proxy Settings:設定HTTP代理服務端口(預設的HTTP Proxy 端口号是 8888,可以不做修改)。
Help>SSL Proxying>Install charles Root Certificate:安裝證書。
3.4.2、Charles工具手機端配置
保持手機與PC端處于同一網絡,通過浏覽器通路Charles配置資訊中顯示的位址,如下圖所示,下載下傳證書并正确安裝,完成後通路網絡,charles監控界面會顯示資料互動資訊。
3.4.3、Charles顯示界面内容
3.5、Fidder工具配置
Fidder安裝流程與常用軟體安裝流程一緻,過程中無需特殊配置,按預設步驟執行即可
3.5.1、Fidder工具PC端配置
(1)進行抓取HTTPS設定:
進入HTTPS配置選項:Tools > Options>HTTPS
選中Capture HTTPS CONNECTs (捕捉HTTPS連接配接)
選中Decrypt HTTPS traffic(解密HTTPS通信)
要用Fiddler擷取本機所有程序的HTTPS請求,...from all processes (從所有程序)
選中下方Ignore server certificate errors(忽略伺服器證書錯誤)
Actions>Trust Root Certificate(受信任的根證書)
(2)連接配接設定:
進入Connections設定:Tools>Options>Connections
Fidder listens on port:8888(監聽端口設定為8888)
選中Allow remote computers to connect(允許遠端連接配接)
選中Reuse client connections(重置用戶端連接配接)
選中Reuse server connections(重置服務端連接配接)
選中Act as system proxy on startup(作為系統啟動代理)
3.5.2、Fidder工具手機端配置
PC端配置完成後,打開手機浏覽器,保證手機與PC處于同一區域網路内
在手機浏覽器通路PC端區域網路IP位址加Fidder中設定的端口号,(例如位址欄輸入192.168.1.1:8888),進入證書下載下傳頁面
選擇下載下傳證書,證書下載下傳完成後,點選證書檔案進行安裝(若手機又安全限制,則需要輸入鎖屏密碼,或修改網絡安全限制)
證書名稱可随意輸入,安裝成功後,手機連接配接入PC端開放的熱點,Fidder上可現實抓包資訊
3.5.3、Fiddler顯示界面内容
3.6、VirtualXposed配置
Xposed架構是一套開源的、在Android高權限模式下運作的架構服務,可以在不修改APK檔案的情況下影響程式運作(修改系統)的架構服務,相當于在手機上安裝一個虛拟空間。VirtualXposed是基于VirtualApp和epic在非ROOT環境下運作Xposed子產品的實作。
3.6.1、VirtualXposed安裝與配置
安裝VirtualXposed.apk
安裝JustTrusMe.apk到VirtualXposed
VirtualXposed設定添加插件
添加JustTrusMe子產品
重新開機VirtualXposed工具完成配置
3.6.2、VirtualXposed應用示例
備注:
網站與APP分析優化過程與執行個體待續••••••
本文部分(已标記)圖檔來源于網際網路如有知識産權保護請聯系作者
本文示例内容(資料互動等)均來源于多年之前的版本,僅供參考請勿用于其他用途
Charles下載下傳位址:
https://www.charlesproxy.com/latest-release/download.doFidder下載下傳位址:
https://www.telerik.com/download/fiddlerVirtualXposed.apk下載下傳位址:
https://github.com/android-hacker/VirtualXposed/releases/tag/0.18.0JustTrusMe.apk下載下傳位址:
https://github.com/Fuzion24/JustTrustMe/releases/tag/v.2