左右滾動banner代碼(左右滾動圖片html)
安卓進階漲薪訓練營，讓一部分人先進大廠
大家好，我是皇叔，最近開了一個安卓進階漲薪訓練營，可以幫助大家突破技術職場瓶頸，從而度過難關，進入心儀的公司。
詳情見文章： 沒錯！皇叔開了個訓練營
1.整體概述介紹
1.1 項目背景
通訊安全是App安全檢測過程中非常重要的一項。
針對該項的主要檢測手段就是使用中間人代理機制對網絡傳輸數(shù)據(jù)進行抓包、攔截和篡改，以檢驗App在核心鏈路上是否有安全漏洞。
保證數(shù)據(jù)安全。
通過charles等工具可以對app的網絡請求進行抓包，這樣這些信息就會被清除的提取出來，會被不法分子進行利用。
不想被競爭對手逆向抓包。
不想自身App的數(shù)據(jù)被別人輕而易舉地抓包獲取到，從而進行類似業(yè)務或數(shù)據(jù)分析、爬蟲或網絡攻擊等破壞性行為。
通訊安全是App安全檢測過程中非常重要的一項。
針對該項的主要檢測手段就是使用中間人代理機制對網絡傳輸數(shù)據(jù)進行抓包、攔截和篡改，以檢驗App在核心鏈路上是否有安全漏洞。
針對該項的主要檢測手段就是使用中間人代理機制對網絡傳輸數(shù)據(jù)進行抓包、攔截和篡改，以檢驗App在核心鏈路上是否有安全漏洞。
保證數(shù)據(jù)安全。
通過charles等工具可以對app的網絡請求進行抓包，這樣這些信息就會被清除的提取出來，會被不法分子進行利用。
通過charles等工具可以對app的網絡請求進行抓包，這樣這些信息就會被清除的提取出來，會被不法分子進行利用。
不想被競爭對手逆向抓包。
不想自身App的數(shù)據(jù)被別人輕而易舉地抓包獲取到，從而進行類似業(yè)務或數(shù)據(jù)分析、爬蟲或網絡攻擊等破壞性行為。
不想自身App的數(shù)據(jù)被別人輕而易舉地抓包獲取到，從而進行類似業(yè)務或數(shù)據(jù)分析、爬蟲或網絡攻擊等破壞性行為。
開發(fā)項目的時候，都需要抓包，很多情況下即使是Https也能正常抓包正常。那么問題來了：
抓包的原理是？任何Https的 app 都能抓的到嗎？如果不能，哪些情況下可以抓取，哪些情況下抓取不到？
什么叫做中間人攻擊？
使用HTTPS協(xié)議進行通信時，客戶端需要對服務器身份進行完整性校驗，以確認服務器是真實合法的目標服務器。
如果沒有校驗，客戶端可能與仿冒的服務器建立通信鏈接，即“中間人攻擊”。
展開全文
開發(fā)項目的時候，都需要抓包，很多情況下即使是Https也能正常抓包正常。那么問題來了：
抓包的原理是？任何Https的 app 都能抓的到嗎？如果不能，哪些情況下可以抓取，哪些情況下抓取不到？
抓包的原理是？任何Https的 app 都能抓的到嗎？如果不能，哪些情況下可以抓取，哪些情況下抓取不到？
什么叫做中間人攻擊？
使用HTTPS協(xié)議進行通信時，客戶端需要對服務器身份進行完整性校驗，以確認服務器是真實合法的目標服務器。
如果沒有校驗，客戶端可能與仿冒的服務器建立通信鏈接，即“中間人攻擊”。
使用HTTPS協(xié)議進行通信時，客戶端需要對服務器身份進行完整性校驗，以確認服務器是真實合法的目標服務器。
如果沒有校驗，客戶端可能與仿冒的服務器建立通信鏈接，即“中間人攻擊”。
防止App被各種方式抓包。
做好各種防抓包安全措施，避免各種黑科技抓包。
沉淀為技術庫復用。
目前只是針對App端有需要做防抓包措施，后期其他業(yè)務線可能也有這個需要。因此下沉為工具庫，傻瓜式調用很有必要。
該庫終極設計目標如下所示。
第一點：必須是低入侵性，對原有代碼改動少，最簡單的加入是一行代碼設置即可。完全解耦合。
第二點：可以動態(tài)靈活配置，支持配置禁止代理，支持配置是否證書校驗，支持配置域名合法性過濾，支持攔截器加解密數(shù)據(jù)。
第三點：可以檢測App是否在雙開，掛載，Xposed攻擊環(huán)境。
第四點：可以靈活設置加解密的key，可以靈活替換加解密方式，比如目前采用RC4，另一個項目想用DES，可以靈活更換。
防止App被各種方式抓包。
做好各種防抓包安全措施，避免各種黑科技抓包。
做好各種防抓包安全措施，避免各種黑科技抓包。
沉淀為技術庫復用。
目前只是針對App端有需要做防抓包措施，后期其他業(yè)務線可能也有這個需要。因此下沉為工具庫，傻瓜式調用很有必要。
目前只是針對App端有需要做防抓包措施，后期其他業(yè)務線可能也有這個需要。因此下沉為工具庫，傻瓜式調用很有必要。
該庫終極設計目標如下所示。
第一點：必須是低入侵性，對原有代碼改動少，最簡單的加入是一行代碼設置即可。完全解耦合。
第二點：可以動態(tài)靈活配置，支持配置禁止代理，支持配置是否證書校驗，支持配置域名合法性過濾，支持攔截器加解密數(shù)據(jù)。
第三點：可以檢測App是否在雙開，掛載，Xposed攻擊環(huán)境。
第四點：可以靈活設置加解密的key，可以靈活替換加解密方式，比如目前采用RC4，另一個項目想用DES，可以靈活更換。
第一點：必須是低入侵性，對原有代碼改動少，最簡單的加入是一行代碼設置即可。完全解耦合。
第二點：可以動態(tài)靈活配置，支持配置禁止代理，支持配置是否證書校驗，支持配置域名合法性過濾，支持攔截器加解密數(shù)據(jù)。
第三點：可以檢測App是否在雙開，掛載，Xposed攻擊環(huán)境。
第四點：可以靈活設置加解密的key，可以靈活替換加解密方式，比如目前采用RC4，另一個項目想用DES，可以靈活更換。
抓包庫收益。
提高產品App的數(shù)據(jù)安全，必須對數(shù)據(jù)傳輸做好安全保護措施和完整性校驗，以防止自身數(shù)據(jù)在網絡傳輸中裸奔，甚至是被三方惡意利用或攻擊。
技能的收益。
下沉為功能基礎庫，可以方便各個產品線使用，提高開發(fā)的效率。避免跟業(yè)務解耦合。傻瓜式調用，低成本接入！
抓包庫收益。
提高產品App的數(shù)據(jù)安全，必須對數(shù)據(jù)傳輸做好安全保護措施和完整性校驗，以防止自身數(shù)據(jù)在網絡傳輸中裸奔，甚至是被三方惡意利用或攻擊。
提高產品App的數(shù)據(jù)安全，必須對數(shù)據(jù)傳輸做好安全保護措施和完整性校驗，以防止自身數(shù)據(jù)在網絡傳輸中裸奔，甚至是被三方惡意利用或攻擊。
技能的收益。
下沉為功能基礎庫，可以方便各個產品線使用，提高開發(fā)的效率。避免跟業(yè)務解耦合。傻瓜式調用，低成本接入！
2.市面抓包的分析
2.1 Https三要素
要清楚HTTPS抓包的原理，首先需要先說清楚 HTTPS 實現(xiàn)數(shù)據(jù)安全傳輸?shù)墓ぷ髟?，主要分為三要素和三階段。
Http傳輸數(shù)據(jù)目前存在的問題：
1.通信使用明文，內容可能被竊聽；
2.不驗證通信方的身份，因此可能遭遇偽裝；
3.無法證明報文的完整性，所以有可能遭到篡改。
Https三要素分別是：
1. 加密：通過對稱加密算法實現(xiàn)。
2. 認證：通過數(shù)字簽名實現(xiàn)。（因為私鑰只有 “合法的發(fā)送方” 持有，其他人偽造的數(shù)字簽名無法通過驗證）
3. 報文完整性：通過數(shù)字簽名實現(xiàn)。（因為數(shù)字簽名中使用了消息摘要，其他人篡改的消息無法通過驗證）
Https三階段分別是：
1. CA 證書校驗：CA 證書校驗發(fā)生在 TLS 的前兩次握手，客戶端和服務端通過報文獲得服務端 CA 證書，客戶端驗證 CA 證書合法性，從而確認 CA 證書中的公鑰合法性（大多數(shù)場景不會做雙向認證，即服務端不會認證客戶端合法性，這里先不考慮）。
2. 密鑰協(xié)商：密鑰協(xié)商發(fā)生在 TLS 的后兩次握手，客戶端和服務端分別基于公鑰和私鑰進行非對稱加密通信，協(xié)商獲得 Master Secret 對稱加密私鑰（不同算法的協(xié)商過程細節(jié)略有不同）。
3. 數(shù)據(jù)傳輸：數(shù)據(jù)傳輸發(fā)生在 TLS 握手之后，客戶端和服務端基于協(xié)商的對稱密鑰進行對稱加密通信。
Https流程圖如下：
2.2 抓包核心原理
HTTPS抓包原理。
Fiddler、Charles等抓包工具，其實都是采用了中間人攻擊的方案：將客戶端的網絡流量代理到MITM(中間人)主機，再通過一系列的面板或工具將網絡請求結構化地呈現(xiàn)出來。
抓包Https有兩個突破點。
CA證書校驗是否合法；數(shù)據(jù)傳遞過程中的加密和解密。如果是要抓包，則需要突破這兩點的技術，無非就是MITM(中間人)偽造證書和使用自己的加解密方式。
抓包的工作流程如下：
中間人截獲客戶端向發(fā)起的HTTPS請求，佯裝客戶端，向真實的服務器發(fā)起請求；
中間人截獲真實服務器的返回，佯裝真實服務器，向客戶端發(fā)送數(shù)據(jù)；
中間人獲取了用來加密服務器公鑰的非對稱秘鑰和用來加密數(shù)據(jù)的對稱秘鑰，處理數(shù)據(jù)加解密。
HTTPS抓包原理。
Fiddler、Charles等抓包工具，其實都是采用了中間人攻擊的方案：將客戶端的網絡流量代理到MITM(中間人)主機，再通過一系列的面板或工具將網絡請求結構化地呈現(xiàn)出來。
Fiddler、Charles等抓包工具，其實都是采用了中間人攻擊的方案：將客戶端的網絡流量代理到MITM(中間人)主機，再通過一系列的面板或工具將網絡請求結構化地呈現(xiàn)出來。
抓包Https有兩個突破點。
CA證書校驗是否合法；數(shù)據(jù)傳遞過程中的加密和解密。如果是要抓包，則需要突破這兩點的技術，無非就是MITM(中間人)偽造證書和使用自己的加解密方式。
CA證書校驗是否合法；數(shù)據(jù)傳遞過程中的加密和解密。如果是要抓包，則需要突破這兩點的技術，無非就是MITM(中間人)偽造證書和使用自己的加解密方式。
抓包的工作流程如下：
中間人截獲客戶端向發(fā)起的HTTPS請求，佯裝客戶端，向真實的服務器發(fā)起請求；
中間人截獲真實服務器的返回，佯裝真實服務器，向客戶端發(fā)送數(shù)據(jù)；
中間人獲取了用來加密服務器公鑰的非對稱秘鑰和用來加密數(shù)據(jù)的對稱秘鑰，處理數(shù)據(jù)加解密。
中間人截獲客戶端向發(fā)起的HTTPS請求，佯裝客戶端，向真實的服務器發(fā)起請求；
中間人截獲真實服務器的返回，佯裝真實服務器，向客戶端發(fā)送數(shù)據(jù)；
中間人獲取了用來加密服務器公鑰的非對稱秘鑰和用來加密數(shù)據(jù)的對稱秘鑰，處理數(shù)據(jù)加解密。
Https抓包核心CA證書。
HTTPS抓包的原理還是挺簡單的，簡單來說，就是Charles作為“中間人代理”，拿到了服務器證書公鑰和HTTPS連接的對稱密鑰。
前提是客戶端選擇信任并安裝Charles的CA證書，否則客戶端就會“報警”并中止連接。這樣看來，HTTPS還是很安全的。
安裝CA證書到手機中必須洗白。
抓包應用內置的 CA 證書要洗白，必須安裝到系統(tǒng)中。而 Android 系統(tǒng)將 CA 證書又分為兩種：用戶 CA 證書和系統(tǒng) CA 證書(必要Root權限)。
Android從7.0開始限制CA證書。
只有系統(tǒng)(system)證書才會被信任。用戶(user)導入的Charles根證書是不被信任的。相當于可以理解Android系統(tǒng)增加了安全校驗！
如何繞過CA證書這種限制呢？已知有以下四種方式：
第一種方式： AndroidManifest 中配置 networkSecurityConfig，App 信任用戶 CA 證書，讓系統(tǒng)對用戶 CA 證書的校驗給予通過。
第二種方式：調低 targetSdkVersion 24，不過這種方式谷歌市場有限制，意味著抓 HTTPS 的包越來越難操作。
第三種方式：掛載App抓包，VirtualApp 這種多開應用可以作為宿主系統(tǒng)來運行其它應用，利用xposed避開CA證書校驗。
第四種方式：Root手機，把 CA 證書安裝到系統(tǒng) CA 證書目錄中，那這個假 CA 證書就是真正洗白了，難度較大。
Https抓包核心CA證書。
HTTPS抓包的原理還是挺簡單的，簡單來說，就是Charles作為“中間人代理”，拿到了服務器證書公鑰和HTTPS連接的對稱密鑰。
前提是客戶端選擇信任并安裝Charles的CA證書，否則客戶端就會“報警”并中止連接。這樣看來，HTTPS還是很安全的。
HTTPS抓包的原理還是挺簡單的，簡單來說，就是Charles作為“中間人代理”，拿到了服務器證書公鑰和HTTPS連接的對稱密鑰。
前提是客戶端選擇信任并安裝Charles的CA證書，否則客戶端就會“報警”并中止連接。這樣看來，HTTPS還是很安全的。
安裝CA證書到手機中必須洗白。
抓包應用內置的 CA 證書要洗白，必須安裝到系統(tǒng)中。而 Android 系統(tǒng)將 CA 證書又分為兩種：用戶 CA 證書和系統(tǒng) CA 證書(必要Root權限)。
抓包應用內置的 CA 證書要洗白，必須安裝到系統(tǒng)中。而 Android 系統(tǒng)將 CA 證書又分為兩種：用戶 CA 證書和系統(tǒng) CA 證書(必要Root權限)。
Android從7.0開始限制CA證書。
只有系統(tǒng)(system)證書才會被信任。用戶(user)導入的Charles根證書是不被信任的。相當于可以理解Android系統(tǒng)增加了安全校驗！
只有系統(tǒng)(system)證書才會被信任。用戶(user)導入的Charles根證書是不被信任的。相當于可以理解Android系統(tǒng)增加了安全校驗！
如何繞過CA證書這種限制呢？已知有以下四種方式：
第一種方式： AndroidManifest 中配置 networkSecurityConfig，App 信任用戶 CA 證書，讓系統(tǒng)對用戶 CA 證書的校驗給予通過。
第二種方式：調低 targetSdkVersion 24，不過這種方式谷歌市場有限制，意味著抓 HTTPS 的包越來越難操作。
第三種方式：掛載App抓包，VirtualApp 這種多開應用可以作為宿主系統(tǒng)來運行其它應用，利用xposed避開CA證書校驗。
第四種方式：Root手機，把 CA 證書安裝到系統(tǒng) CA 證書目錄中，那這個假 CA 證書就是真正洗白了，難度較大。
第一種方式： AndroidManifest 中配置 networkSecurityConfig，App 信任用戶 CA 證書，讓系統(tǒng)對用戶 CA 證書的校驗給予通過。
第二種方式：調低 targetSdkVersion 24，不過這種方式谷歌市場有限制，意味著抓 HTTPS 的包越來越難操作。
第三種方式：掛載App抓包，VirtualApp 這種多開應用可以作為宿主系統(tǒng)來運行其它應用，利用xposed避開CA證書校驗。
第四種方式：Root手機，把 CA 證書安裝到系統(tǒng) CA 證書目錄中，那這個假 CA 證書就是真正洗白了，難度較大。
App版本如何讓證書校驗安全。
1.設置targetSdkVersion大于24，去掉清單文件中networkSecurityConfig文件中的system和user配置，設置不信任用戶證書。
2.公鑰證書固定。指 Client 端內置 Server 端真正的公鑰證書。在 HTTPS 請求時，Server 端發(fā)給客戶端的公鑰證書必須與 Client 端內置的公鑰證書一致，請求才會成功。
? 證書固定的一般做法是，將公鑰證書（.crt 或者 .cer 等格式）內置到 App 中，然后創(chuàng)建TrustManager 時將公鑰證書加進去。
那么如何突破CA證書校驗。
第一種：JustTrustMe破解證書固定。Xposed 和 Magisk 都有相應的模塊，用來破解證書固定，實現(xiàn)正常抓包。破解的原理大致是，Hook 創(chuàng)建 SSLContext 等涉及 TrustManager相關的方法，將固定的證書移除。
第二種：基于 VirtualApp 的 Hook 機制破解證書固定。在 VirtualApp 中加入 Hook 代碼，然后利用 VirtualApp 打開目標應用進行抓包。具體看:VirtualHook。
https://github.com/PAGalaxyLab/VirtualHook
2.5 如何搞定加解密
? 目前使用對稱加密和解密請求和響應數(shù)據(jù)。
加密和解密都是用相同密鑰。只有一把密鑰，如果密鑰暴露，內容就會暴露。但是這一塊逆向破解有些難度。而破解解密方式就是用密鑰逆向解密，或者中間人冒充使用自己的加解密方式！
? 加密后數(shù)據(jù)鎮(zhèn)兼顧了安全性嗎？
不一定安全。中間人偽造自己的公鑰和私鑰，然后攔截信息，進行篡改。
2.6 Charles原理
? Charles類似代理服務器
Charles 通過將軟件本身設置成系統(tǒng)的網絡訪問代理服務器，使得所有的網絡請求都會走一遍 Charles 代理，從而 Charles 可以截取經過它的請求，然后我們就可以對其進行網絡包的分析。
? 截取設備網絡封包數(shù)據(jù)
Charles對應設置：將代理功能打開，并設置一個固定的端口。默認情況下，端口號為：8888 。
移動設備設置：在手機上設置 WIFI 的 HTTP 代理。注意這里的前提是，Phone 和 Charles 代理設備鏈接的是同一網絡(同一個ip地址和端口號)。
? 截取Https的網絡封包
正常情況下，Charles 是不能截取Https的網絡包的，這涉及到 Https 的證書問題。
2.7 抓包原理圖
Charles抓包原理圖:
Android上的網絡抓包原來是這樣工作的:
Charles抓包:
https://mp.weixin.qq.com/s/kqMUbHl59V75w8xBxHbXkA
2.8 抓包核心流程
? 抓包核心流程關鍵節(jié)點:
第一步，客戶端向服務器發(fā)起HTTPS請求，charles截獲客戶端發(fā)送給服務器的HTTPS請求，charles偽裝成客戶端向服務器發(fā)送請求進行握手 。
第二步，服務器發(fā)回相應，charles獲取到服務器的CA證書，用根證書（這里的根證書是CA認證中心給自己頒發(fā)的證書）公鑰進行解密，驗證服務器數(shù)據(jù)簽名，獲取到服務器CA證書公鑰。然后charles偽造自己的CA證書（這里的CA證書，也是根證書，只不過是charles偽造的根證書），冒充服務器證書傳遞給客戶端瀏覽器。
第三步，與普通過程中客戶端的操作相同，客戶端根據(jù)返回的數(shù)據(jù)進行證書校驗、生成密碼Pre_master、用charles偽造的證書公鑰加密，并生成HTTPS通信用的對稱密鑰enc_key。
第四步，客戶端將重要信息傳遞給服務器，又被charles截獲。charles將截獲的密文用自己偽造證書的私鑰解開，獲得并計算得到HTTPS通信用的對稱密鑰enc_key。charles將對稱密鑰用服務器證書公鑰加密傳遞給服務器。
第五步，與普通過程中服務器端的操作相同，服務器用私鑰解開后建立信任，然后再發(fā)送加密的握手消息給客戶端。
第六步，charles截獲服務器發(fā)送的密文，用對稱密鑰解開，再用自己偽造證書的私鑰加密傳給客戶端。
第七步，客戶端拿到加密信息后，用公鑰解開，驗證HASH。握手過程正式完成，客戶端與服務器端就這樣建立了”信任“。
? 在之后的正常加密通信過程中，charles如何在服務器與客戶端之間充當?shù)谌吣兀?/p>
服務器—客戶端：charles接收到服務器發(fā)送的密文，用對稱密鑰解開，獲得服務器發(fā)送的明文。再次加密， 發(fā)送給客戶端。
客戶端—服務端：客戶端用對稱密鑰加密，被charles截獲后，解密獲得明文。再次加密，發(fā)送給服務器端。由于charles一直擁有通信用對稱密鑰enc_key，所以在整個HTTPS通信過程中信息對其透明。
3.防止抓包思路
3.1 先看如何抓包
使用Charles需要做哪些操作:
1. 電腦上需要安裝證書。這個主要是讓Charles充當中間人，頒布自己的CA證書。
2. 手機上需要安裝證書。這個是訪問Charles獲取手機證書，然后安裝即可。
3. Android項目代碼設置兼容。Google 推出更加嚴格的安全機制，應用默認不信任用戶證書（手機里自己安裝證書），自己的app可以通過配置解決，相當于信任證書的一種操作！
尤其可知抓包的突破口集中以下幾點:
第一點：必須鏈接代理，且跟Charles要具有相同ip。 思路：客戶端是否可以判斷網絡是否被代理了。
第二點：CA證書，這一塊避免使用黑科技hook證書校驗代碼，或者擁有修改CA證書權限。 思路：集中在可以判斷是否掛載。
第三點：冒充中間人CA證書，在客戶端client和服務端server之間篡改攔截數(shù)據(jù)。 思路：可以做CA證書校驗。
第四點：為了可以在7.0上抓包，App往往配置清單文件 networkSecurityConfig。 思路：線上環(huán)境去掉該配置。
使用Charles需要做哪些操作:
1. 電腦上需要安裝證書。這個主要是讓Charles充當中間人，頒布自己的CA證書。
2. 手機上需要安裝證書。這個是訪問Charles獲取手機證書，然后安裝即可。
3. Android項目代碼設置兼容。Google 推出更加嚴格的安全機制，應用默認不信任用戶證書（手機里自己安裝證書），自己的app可以通過配置解決，相當于信任證書的一種操作！
1. 電腦上需要安裝證書。這個主要是讓Charles充當中間人，頒布自己的CA證書。
2. 手機上需要安裝證書。這個是訪問Charles獲取手機證書，然后安裝即可。
3. Android項目代碼設置兼容。Google 推出更加嚴格的安全機制，應用默認不信任用戶證書（手機里自己安裝證書），自己的app可以通過配置解決，相當于信任證書的一種操作！
尤其可知抓包的突破口集中以下幾點:
第一點：必須鏈接代理，且跟Charles要具有相同ip。 思路：客戶端是否可以判斷網絡是否被代理了。
第二點：CA證書，這一塊避免使用黑科技hook證書校驗代碼，或者擁有修改CA證書權限。 思路：集中在可以判斷是否掛載。
第三點：冒充中間人CA證書，在客戶端client和服務端server之間篡改攔截數(shù)據(jù)。 思路：可以做CA證書校驗。
第四點：為了可以在7.0上抓包，App往往配置清單文件 networkSecurityConfig。 思路：線上環(huán)境去掉該配置。
第一點：必須鏈接代理，且跟Charles要具有相同ip。 思路：客戶端是否可以判斷網絡是否被代理了。
第二點：CA證書，這一塊避免使用黑科技hook證書校驗代碼，或者擁有修改CA證書權限。 思路：集中在可以判斷是否掛載。
第三點：冒充中間人CA證書，在客戶端client和服務端server之間篡改攔截數(shù)據(jù)。 思路：可以做CA證書校驗。
第四點：為了可以在7.0上抓包，App往往配置清單文件 networkSecurityConfig。 思路：線上環(huán)境去掉該配置。
一個是CA證書配置文件
debug包為了能夠抓包，需要配置 networkSecurityConfig清單文件的system和user權限，只有這樣才會信任用戶證書。
一個是檢驗證書配置
不論是權威機構頒發(fā)的證書還是自簽名的，打包一份到 app 內部，比如存放在 asset 里。然后用這個KeyStore去引導生成的 TrustManager來提供證書驗證。
一個是檢驗域名合法性
Android允許開發(fā)者重定義證書驗證方法，使用 HostnameVerifier類檢查證書中的主機名與使用該證書的服務器的主機名是否一致。
如果重寫的 HostnameVerifier不對服務器的主機名進行驗證，即驗證失敗時也繼續(xù)與服務器建立通信鏈接，存在發(fā)生“中間人攻擊”的風險。
如何查看CA證書的數(shù)據(jù)
證書驗證網站 ；SSL配置檢查網站
一個是CA證書配置文件
debug包為了能夠抓包，需要配置 networkSecurityConfig清單文件的system和user權限，只有這樣才會信任用戶證書。
debug包為了能夠抓包，需要配置 networkSecurityConfig清單文件的system和user權限，只有這樣才會信任用戶證書。
一個是檢驗證書配置
不論是權威機構頒發(fā)的證書還是自簽名的，打包一份到 app 內部，比如存放在 asset 里。然后用這個KeyStore去引導生成的 TrustManager來提供證書驗證。
不論是權威機構頒發(fā)的證書還是自簽名的，打包一份到 app 內部，比如存放在 asset 里。然后用這個KeyStore去引導生成的 TrustManager來提供證書驗證。
一個是檢驗域名合法性
Android允許開發(fā)者重定義證書驗證方法，使用 HostnameVerifier類檢查證書中的主機名與使用該證書的服務器的主機名是否一致。
如果重寫的 HostnameVerifier不對服務器的主機名進行驗證，即驗證失敗時也繼續(xù)與服務器建立通信鏈接，存在發(fā)生“中間人攻擊”的風險。
Android允許開發(fā)者重定義證書驗證方法，使用 HostnameVerifier類檢查證書中的主機名與使用該證書的服務器的主機名是否一致。
如果重寫的 HostnameVerifier不對服務器的主機名進行驗證，即驗證失敗時也繼續(xù)與服務器建立通信鏈接，存在發(fā)生“中間人攻擊”的風險。
如何查看CA證書的數(shù)據(jù)
證書驗證網站 ；SSL配置檢查網站
證書驗證網站 ；SSL配置檢查網站
網絡數(shù)據(jù)加密的需求
為了項目數(shù)據(jù)安全性，對請求體和響應體加密，那肯定要知道請求體或響應體在哪里，然后才能加密，其實都一樣不論是加密url里面的query內容還是加密body體里面的都一樣。
對數(shù)據(jù)哪里進行加密和解密
目前對數(shù)據(jù)返回的data進行加解密。那么如何做數(shù)據(jù)加密呢？目前項目中采用RC4加密和解密數(shù)據(jù)。
抓取到的內容為亂碼
有的APP為了防止抓取，在返回的內容上做了層加密，所以從Charles上看到的內容是亂碼。這種情況下也只能反編譯APP，研究其加密解密算法進行解密。難度極大！
網絡數(shù)據(jù)加密的需求
為了項目數(shù)據(jù)安全性，對請求體和響應體加密，那肯定要知道請求體或響應體在哪里，然后才能加密，其實都一樣不論是加密url里面的query內容還是加密body體里面的都一樣。
為了項目數(shù)據(jù)安全性，對請求體和響應體加密，那肯定要知道請求體或響應體在哪里，然后才能加密，其實都一樣不論是加密url里面的query內容還是加密body體里面的都一樣。
對數(shù)據(jù)哪里進行加密和解密
目前對數(shù)據(jù)返回的data進行加解密。那么如何做數(shù)據(jù)加密呢？目前項目中采用RC4加密和解密數(shù)據(jù)。
目前對數(shù)據(jù)返回的data進行加解密。那么如何做數(shù)據(jù)加密呢？目前項目中采用RC4加密和解密數(shù)據(jù)。
抓取到的內容為亂碼
有的APP為了防止抓取，在返回的內容上做了層加密，所以從Charles上看到的內容是亂碼。這種情況下也只能反編譯APP，研究其加密解密算法進行解密。難度極大！
有的APP為了防止抓取，在返回的內容上做了層加密，所以從Charles上看到的內容是亂碼。這種情況下也只能反編譯APP，研究其加密解密算法進行解密。難度極大！
基于Xposed(或者)黑科技破解證書校驗
這種方式可以檢查是否有Xposed環(huán)境，大概的思路是使用ClassLoader去加載固定包名的xp類，或者手動拋出異常然后捕獲去判斷是否包含Xposed環(huán)境。
基于VirtualApp掛載App突破證書訪問權限
這個VirtualApp相當于是一個宿主App(可以把它想像成桌面級App)，它突破證書校驗。然后再實現(xiàn)掛載App的抓包。判斷是否是雙開環(huán)境！
基于Xposed(或者)黑科技破解證書校驗
這種方式可以檢查是否有Xposed環(huán)境，大概的思路是使用ClassLoader去加載固定包名的xp類，或者手動拋出異常然后捕獲去判斷是否包含Xposed環(huán)境。
這種方式可以檢查是否有Xposed環(huán)境，大概的思路是使用ClassLoader去加載固定包名的xp類，或者手動拋出異常然后捕獲去判斷是否包含Xposed環(huán)境。
基于VirtualApp掛載App突破證書訪問權限
這個VirtualApp相當于是一個宿主App(可以把它想像成桌面級App)，它突破證書校驗。然后再實現(xiàn)掛載App的抓包。判斷是否是雙開環(huán)境！
4.防抓包實踐開發(fā)
4.1 App安全配置
添加配置文件：
android:networkSecurityConfig="@xml/network_security_config"
配置 networkSecurityConfig抓包說明：
中間人代理之所有能夠獲取到加密密鑰就是因為我們手機上安裝并信任了其代理證書，這類證書安裝后都會被歸結到用戶證書一類，而不是系統(tǒng)證書。
那我們可以選擇只信任系統(tǒng)內置的系統(tǒng)證書，而屏蔽掉用戶證書（Android7.0以后就默認是只信任系統(tǒng)證書了），就可以防止數(shù)據(jù)被解密了。
實現(xiàn)App防抓包安全配置方式有兩種：
一種是Android官方提供的網絡安全配置；另一種也可以通過設置網絡框架實現(xiàn)（以okhttp為例）。
第一種：具體可以看清單配置文件，相當于 base-config標簽下去掉 這組標簽。
第二種：需要給 okhttpClient配置 X509TrustManager 來監(jiān)聽校驗服務端證書有效性。遍歷設備上信任的證書，通過證書別名將用戶證書（別名中含有user字段）過濾掉，只將系統(tǒng)證書添加到驗證列表中。
該方案優(yōu)點和缺點分析說明：
優(yōu)點： network_security_config配置簡單，對整個app網絡生效，無需修改代碼；代碼實現(xiàn)對通過該網絡框架請求的生效，能兼容7.0以前系統(tǒng)。
缺陷： network_security_config配置方式，7.0以前的系統(tǒng)配置不生效，依然可以通過代理工具進行抓包。okhttp配置的方式只能對使用該網絡框架進行數(shù)據(jù)傳輸?shù)慕涌谏В⒉荒軐φ麄€app生效。
破解：將手機進行root，然后將代理證書放置到系統(tǒng)證書列表內，就可以繞過代碼或配置檢查了。
添加配置文件：
android:networkSecurityConfig="@xml/network_security_config"
android:networkSecurityConfig="@xml/network_security_config"
配置 networkSecurityConfig抓包說明：
中間人代理之所有能夠獲取到加密密鑰就是因為我們手機上安裝并信任了其代理證書，這類證書安裝后都會被歸結到用戶證書一類，而不是系統(tǒng)證書。
那我們可以選擇只信任系統(tǒng)內置的系統(tǒng)證書，而屏蔽掉用戶證書（Android7.0以后就默認是只信任系統(tǒng)證書了），就可以防止數(shù)據(jù)被解密了。
中間人代理之所有能夠獲取到加密密鑰就是因為我們手機上安裝并信任了其代理證書，這類證書安裝后都會被歸結到用戶證書一類，而不是系統(tǒng)證書。
那我們可以選擇只信任系統(tǒng)內置的系統(tǒng)證書，而屏蔽掉用戶證書（Android7.0以后就默認是只信任系統(tǒng)證書了），就可以防止數(shù)據(jù)被解密了。
實現(xiàn)App防抓包安全配置方式有兩種：
一種是Android官方提供的網絡安全配置；另一種也可以通過設置網絡框架實現(xiàn)（以okhttp為例）。
第一種：具體可以看清單配置文件，相當于 base-config標簽下去掉 這組標簽。
第二種：需要給 okhttpClient配置 X509TrustManager 來監(jiān)聽校驗服務端證書有效性。遍歷設備上信任的證書，通過證書別名將用戶證書（別名中含有user字段）過濾掉，只將系統(tǒng)證書添加到驗證列表中。
一種是Android官方提供的網絡安全配置；另一種也可以通過設置網絡框架實現(xiàn)（以okhttp為例）。
第一種：具體可以看清單配置文件，相當于 base-config標簽下去掉 這組標簽。
第二種：需要給 okhttpClient配置 X509TrustManager 來監(jiān)聽校驗服務端證書有效性。遍歷設備上信任的證書，通過證書別名將用戶證書（別名中含有user字段）過濾掉，只將系統(tǒng)證書添加到驗證列表中。
該方案優(yōu)點和缺點分析說明：
優(yōu)點： network_security_config配置簡單，對整個app網絡生效，無需修改代碼；代碼實現(xiàn)對通過該網絡框架請求的生效，能兼容7.0以前系統(tǒng)。
缺陷： network_security_config配置方式，7.0以前的系統(tǒng)配置不生效，依然可以通過代理工具進行抓包。okhttp配置的方式只能對使用該網絡框架進行數(shù)據(jù)傳輸?shù)慕涌谏?，并不能對整個app生效。
破解：將手機進行root，然后將代理證書放置到系統(tǒng)證書列表內，就可以繞過代碼或配置檢查了。
優(yōu)點： network_security_config配置簡單，對整個app網絡生效，無需修改代碼；代碼實現(xiàn)對通過該網絡框架請求的生效，能兼容7.0以前系統(tǒng)。
缺陷： network_security_config配置方式，7.0以前的系統(tǒng)配置不生效，依然可以通過代理工具進行抓包。okhttp配置的方式只能對使用該網絡框架進行數(shù)據(jù)傳輸?shù)慕涌谏?，并不能對整個app生效。
破解：將手機進行root，然后將代理證書放置到系統(tǒng)證書列表內，就可以繞過代碼或配置檢查了。
charles 和 fiddler 都使用代理來進行抓包，對網絡客戶端使用無代理模式即可防止抓包，如：
OkHttpClient.Builder
.proxy( Proxy.NO_PROXY)
.build
no_proxy實際上就是type屬性為direct的一個proxy對象，這個type有三種：
direct，http，socks。這樣因為是直連，所以不走代理。所以charles等工具就抓不到包了，這樣一定程度上保證了數(shù)據(jù)的安全，這種方式只是通過代理抓不到包。
通常情況下上述的辦法有用，但是無法防住使用 VPN 導流進行的抓包：
使用VPN抓包的原理是，先將手機請求導到VPN，再對VPN的網絡進行Charles的代理，繞過了對App的代理。
該方案優(yōu)點和缺點分析說明：
優(yōu)點：實現(xiàn)簡單方便，無系統(tǒng)版本兼容問題。
缺陷：該方案比較粗暴，將一切代理都切斷了，對于有合理訴求需要使用網絡代理的場景無法滿足。
破解：使用ProxyDroid全局代理工具通過iptables對請求進行強制轉發(fā)，可以有效繞過代理檢測。
no_proxy實際上就是type屬性為direct的一個proxy對象，這個type有三種：
direct，http，socks。這樣因為是直連，所以不走代理。所以charles等工具就抓不到包了，這樣一定程度上保證了數(shù)據(jù)的安全，這種方式只是通過代理抓不到包。
direct，http，socks。這樣因為是直連，所以不走代理。所以charles等工具就抓不到包了，這樣一定程度上保證了數(shù)據(jù)的安全，這種方式只是通過代理抓不到包。
通常情況下上述的辦法有用，但是無法防住使用 VPN 導流進行的抓包：
使用VPN抓包的原理是，先將手機請求導到VPN，再對VPN的網絡進行Charles的代理，繞過了對App的代理。
使用VPN抓包的原理是，先將手機請求導到VPN，再對VPN的網絡進行Charles的代理，繞過了對App的代理。
該方案優(yōu)點和缺點分析說明：
優(yōu)點：實現(xiàn)簡單方便，無系統(tǒng)版本兼容問題。
缺陷：該方案比較粗暴，將一切代理都切斷了，對于有合理訴求需要使用網絡代理的場景無法滿足。
破解：使用ProxyDroid全局代理工具通過iptables對請求進行強制轉發(fā)，可以有效繞過代理檢測。
優(yōu)點：實現(xiàn)簡單方便，無系統(tǒng)版本兼容問題。
缺陷：該方案比較粗暴，將一切代理都切斷了，對于有合理訴求需要使用網絡代理的場景無法滿足。
破解：使用ProxyDroid全局代理工具通過iptables對請求進行強制轉發(fā)，可以有效繞過代理檢測。
下載服務器端公鑰證書：
為了防止上面方案可能導致的“中間人攻擊”，可以下載服務器端公鑰證書，然后將公鑰證書編譯到Android應用中一般在assets文件夾保存，由應用在交互過程中去驗證證書的合法性。
如何設置證書校驗：
通過OkHttp的API方法 sslSocketFactory(sslSocketFactory,trustManager) 設置SSL證書校驗。
如何設置域名合法性校驗：
通過OkHttp的API方法 hostnameVerifier(hostnameVerifier)設置域名合法性校驗。
證書校驗的原理分析
按CA證書去驗證的，若不是CA可信任的證書，則無法通過驗證。
單向認證流程圖：
該方案優(yōu)點和缺點分析說明：
優(yōu)點：安全性比較高，單向認證校驗證書在代碼中是方便的，安全性相對較高。
缺陷：CA證書存在過期的問題，證書升級。
破解：證書鎖定破解比較復雜，比如老牌的JustTrustMe插件，通過hook各網絡框架的證書校驗方法，替換原有邏輯，使校驗失效。
下載服務器端公鑰證書：
為了防止上面方案可能導致的“中間人攻擊”，可以下載服務器端公鑰證書，然后將公鑰證書編譯到Android應用中一般在assets文件夾保存，由應用在交互過程中去驗證證書的合法性。
為了防止上面方案可能導致的“中間人攻擊”，可以下載服務器端公鑰證書，然后將公鑰證書編譯到Android應用中一般在assets文件夾保存，由應用在交互過程中去驗證證書的合法性。
如何設置證書校驗：
通過OkHttp的API方法 sslSocketFactory(sslSocketFactory,trustManager) 設置SSL證書校驗。
通過OkHttp的API方法 sslSocketFactory(sslSocketFactory,trustManager) 設置SSL證書校驗。
如何設置域名合法性校驗：
通過OkHttp的API方法 hostnameVerifier(hostnameVerifier)設置域名合法性校驗。
通過OkHttp的API方法 hostnameVerifier(hostnameVerifier)設置域名合法性校驗。
證書校驗的原理分析
按CA證書去驗證的，若不是CA可信任的證書，則無法通過驗證。
按CA證書去驗證的，若不是CA可信任的證書，則無法通過驗證。
單向認證流程圖：
該方案優(yōu)點和缺點分析說明：
優(yōu)點：安全性比較高，單向認證校驗證書在代碼中是方便的，安全性相對較高。
缺陷：CA證書存在過期的問題，證書升級。
破解：證書鎖定破解比較復雜，比如老牌的JustTrustMe插件，通過hook各網絡框架的證書校驗方法，替換原有邏輯，使校驗失效。
優(yōu)點：安全性比較高，單向認證校驗證書在代碼中是方便的，安全性相對較高。
缺陷：CA證書存在過期的問題，證書升級。
破解：證書鎖定破解比較復雜，比如老牌的JustTrustMe插件，通過hook各網絡框架的證書校驗方法，替換原有邏輯，使校驗失效。
什么叫做雙向認證:
SSL/TLS 協(xié)議提供了雙向認證的功能，即除了 Client 需要校驗 Server 的真實性，Server 也需要校驗 Client 的真實性。
雙向認證的原理：
雙向認證需要 Server 支持，Client 必須內置一套公鑰證書 + 私鑰。在 SSL/TLS 握手過程中，Server 端會向 Client 端請求證書，Client 端必須將內置的公鑰證書發(fā)給 Server，Server 驗證公鑰證書的真實性。
用于雙向認證的公鑰證書和私鑰代表了 Client 端身份，所以其是隱秘的，一般都是用 .p12 或者 .bks 文件 + 密鑰進行存放。
代碼層面如何做雙向認證：
雙向校驗就是自定義生成客戶端證書，保存在服務端和客戶端，當客戶端發(fā)起請求時在服務端也校驗客戶端的證書合法性，如果不是可信任的客戶端發(fā)送的請求，則拒絕響應。
服務端根據(jù)自身使用語言和網絡框架配置相應證書校驗機制即可。
雙向認證流程圖：
該方案優(yōu)點和缺點分析說明:
優(yōu)點：安全性非常高，使用三方工具不易破解。
缺陷：服務端需要存儲客戶端證書，一般服務端會對應多個客戶端，就需要分別存儲和校驗客戶端證書，增加校驗成本，降低響應速度。該方案比較適合對安全等級要求比較高的業(yè)務（如金融類業(yè)務）。
破解：由于在服務端也做校驗，在服務端安全的情況下很難被攻破。
什么叫做雙向認證:
SSL/TLS 協(xié)議提供了雙向認證的功能，即除了 Client 需要校驗 Server 的真實性，Server 也需要校驗 Client 的真實性。
SSL/TLS 協(xié)議提供了雙向認證的功能，即除了 Client 需要校驗 Server 的真實性，Server 也需要校驗 Client 的真實性。
雙向認證的原理：
雙向認證需要 Server 支持，Client 必須內置一套公鑰證書 + 私鑰。在 SSL/TLS 握手過程中，Server 端會向 Client 端請求證書，Client 端必須將內置的公鑰證書發(fā)給 Server，Server 驗證公鑰證書的真實性。
用于雙向認證的公鑰證書和私鑰代表了 Client 端身份，所以其是隱秘的，一般都是用 .p12 或者 .bks 文件 + 密鑰進行存放。
雙向認證需要 Server 支持，Client 必須內置一套公鑰證書 + 私鑰。在 SSL/TLS 握手過程中，Server 端會向 Client 端請求證書，Client 端必須將內置的公鑰證書發(fā)給 Server，Server 驗證公鑰證書的真實性。
用于雙向認證的公鑰證書和私鑰代表了 Client 端身份，所以其是隱秘的，一般都是用 .p12 或者 .bks 文件 + 密鑰進行存放。
代碼層面如何做雙向認證：
雙向校驗就是自定義生成客戶端證書，保存在服務端和客戶端，當客戶端發(fā)起請求時在服務端也校驗客戶端的證書合法性，如果不是可信任的客戶端發(fā)送的請求，則拒絕響應。
服務端根據(jù)自身使用語言和網絡框架配置相應證書校驗機制即可。
雙向校驗就是自定義生成客戶端證書，保存在服務端和客戶端，當客戶端發(fā)起請求時在服務端也校驗客戶端的證書合法性，如果不是可信任的客戶端發(fā)送的請求，則拒絕響應。
服務端根據(jù)自身使用語言和網絡框架配置相應證書校驗機制即可。
雙向認證流程圖：
該方案優(yōu)點和缺點分析說明:
優(yōu)點：安全性非常高，使用三方工具不易破解。
缺陷：服務端需要存儲客戶端證書，一般服務端會對應多個客戶端，就需要分別存儲和校驗客戶端證書，增加校驗成本，降低響應速度。該方案比較適合對安全等級要求比較高的業(yè)務（如金融類業(yè)務）。
破解：由于在服務端也做校驗，在服務端安全的情況下很難被攻破。
優(yōu)點：安全性非常高，使用三方工具不易破解。
缺陷：服務端需要存儲客戶端證書，一般服務端會對應多個客戶端，就需要分別存儲和校驗客戶端證書，增加校驗成本，降低響應速度。該方案比較適合對安全等級要求比較高的業(yè)務（如金融類業(yè)務）。
破解：由于在服務端也做校驗，在服務端安全的情況下很難被攻破。
Xposed是一個牛逼的黑科技:
Xposed + JustTrustMe 可以破解繞過校驗CA證書。那么這樣CA證書的校驗就形同虛設了，對App的危險性也很大。
App多開運行在多個環(huán)境上:
多開App的原理類似，都是以新進程運行被多開的App，并hook各類系統(tǒng)函數(shù)，使被多開的App認為自己是一個正常的App在運行。
一種是從多開App中直接加載被多開的App，如平行空間、VirtualApp等，另一種是讓用戶新安裝一個App，但這個App本質上就是一個殼，用來加載被多開的App。
VirtualApp是一個牛逼的黑科技:
它破壞了Android 系統(tǒng)本身的隔離措施，可以進行免root hook和其他黑科技操作，你可以用這個做很多在原來APP里做不到事情，于此同時Virtual App的安全威脅也不言而喻。
如何判斷是否具有Xposed環(huán)境:
第一種方式：獲取當前設備所有運行的APP，根據(jù)安裝包名對應用進行檢測判斷是否有Xposed環(huán)境。
第二種方式：通過自造異常來檢測堆棧信息，判斷異常堆棧中是否包含Xposed等字符串。
第三種方式：通過 ClassLoader檢查是否已經加載了 XposedBridge類和 XposedHelpers類來檢測。
第四種方式：獲取DEX加載列表，判斷其中是否包含 XposedBridge.jar等字符串。
第五種方式：檢測Xposed相關文件，通過讀取 /proc/self/maps文件，查找Xposed相關jar或者so文件來檢測。
如何判斷是否是雙開環(huán)境:
第一種方式：通過檢測app私有目錄，多開后的應用路徑會包含多開軟件的包名。還有一種思路遍歷應用列表如果出現(xiàn)同樣的包名，則被認為雙開了。
第二種方式：如果同一uid下有兩個進程對應的包名，在"/data/data"下有兩個私有目錄，則該應用被多開了。
判斷了具有xposed或者多開環(huán)境怎么處理App:
目前使用VirtualApp掛載，或者Xposed黑科技去hook，前期可以先用埋點統(tǒng)計。測試學而思App發(fā)現(xiàn)掛載在VA上是推出App。
Xposed是一個牛逼的黑科技:
Xposed + JustTrustMe 可以破解繞過校驗CA證書。那么這樣CA證書的校驗就形同虛設了，對App的危險性也很大。
Xposed + JustTrustMe 可以破解繞過校驗CA證書。那么這樣CA證書的校驗就形同虛設了，對App的危險性也很大。
App多開運行在多個環(huán)境上:
多開App的原理類似，都是以新進程運行被多開的App，并hook各類系統(tǒng)函數(shù)，使被多開的App認為自己是一個正常的App在運行。
一種是從多開App中直接加載被多開的App，如平行空間、VirtualApp等，另一種是讓用戶新安裝一個App，但這個App本質上就是一個殼，用來加載被多開的App。
多開App的原理類似，都是以新進程運行被多開的App，并hook各類系統(tǒng)函數(shù)，使被多開的App認為自己是一個正常的App在運行。
一種是從多開App中直接加載被多開的App，如平行空間、VirtualApp等，另一種是讓用戶新安裝一個App，但這個App本質上就是一個殼，用來加載被多開的App。
VirtualApp是一個牛逼的黑科技:
它破壞了Android 系統(tǒng)本身的隔離措施，可以進行免root hook和其他黑科技操作，你可以用這個做很多在原來APP里做不到事情，于此同時Virtual App的安全威脅也不言而喻。
它破壞了Android 系統(tǒng)本身的隔離措施，可以進行免root hook和其他黑科技操作，你可以用這個做很多在原來APP里做不到事情，于此同時Virtual App的安全威脅也不言而喻。
如何判斷是否具有Xposed環(huán)境:
第一種方式：獲取當前設備所有運行的APP，根據(jù)安裝包名對應用進行檢測判斷是否有Xposed環(huán)境。
第二種方式：通過自造異常來檢測堆棧信息，判斷異常堆棧中是否包含Xposed等字符串。
第三種方式：通過 ClassLoader檢查是否已經加載了 XposedBridge類和 XposedHelpers類來檢測。
第四種方式：獲取DEX加載列表，判斷其中是否包含 XposedBridge.jar等字符串。
第五種方式：檢測Xposed相關文件，通過讀取 /proc/self/maps文件，查找Xposed相關jar或者so文件來檢測。
第一種方式：獲取當前設備所有運行的APP，根據(jù)安裝包名對應用進行檢測判斷是否有Xposed環(huán)境。
第二種方式：通過自造異常來檢測堆棧信息，判斷異常堆棧中是否包含Xposed等字符串。
第三種方式：通過 ClassLoader檢查是否已經加載了 XposedBridge類和 XposedHelpers類來檢測。
第四種方式：獲取DEX加載列表，判斷其中是否包含 XposedBridge.jar等字符串。
第五種方式：檢測Xposed相關文件，通過讀取 /proc/self/maps文件，查找Xposed相關jar或者so文件來檢測。
如何判斷是否是雙開環(huán)境:
第一種方式：通過檢測app私有目錄，多開后的應用路徑會包含多開軟件的包名。還有一種思路遍歷應用列表如果出現(xiàn)同樣的包名，則被認為雙開了。
第二種方式：如果同一uid下有兩個進程對應的包名，在"/data/data"下有兩個私有目錄，則該應用被多開了。
第一種方式：通過檢測app私有目錄，多開后的應用路徑會包含多開軟件的包名。還有一種思路遍歷應用列表如果出現(xiàn)同樣的包名，則被認為雙開了。
第二種方式：如果同一uid下有兩個進程對應的包名，在"/data/data"下有兩個私有目錄，則該應用被多開了。
判斷了具有xposed或者多開環(huán)境怎么處理App:
目前使用VirtualApp掛載，或者Xposed黑科技去hook，前期可以先用埋點統(tǒng)計。測試學而思App發(fā)現(xiàn)掛載在VA上是推出App。
目前使用VirtualApp掛載，或者Xposed黑科技去hook，前期可以先用埋點統(tǒng)計。測試學而思App發(fā)現(xiàn)掛載在VA上是推出App。
針對數(shù)據(jù)加解密入口：
目前在網絡請求類里添加攔截器，然后在攔截器中處理request請求和response響應數(shù)據(jù)的加密和解密操作。
主要是加密什么數(shù)據(jù)：
在request請求數(shù)據(jù)階段，如果是get請求加密url數(shù)據(jù)，如果是post請求則加密url數(shù)據(jù)和requestBody數(shù)據(jù)。
在response響應數(shù)據(jù)階段。
如何進行加密：發(fā)起請求(加密)
第一步：獲取請求的數(shù)據(jù)。主要是獲取請求url和requestBody，這一塊需要對數(shù)據(jù)一塊處理。
第二步：對請求數(shù)據(jù)進行加密。采用RC4加密數(shù)據(jù)。
第三步：根據(jù)不同的請求方式構造新的request。使用 key 和 result 生成新的 RequestBody 發(fā)起網絡請求。
如何進行解密：接收返回(解密)
第一步：常規(guī)解析得到 result ，然后使用RC4工具，傳入key去解密數(shù)據(jù)得到解密后的字符串。
第二步：將解密的字符串組裝成ResponseBody數(shù)據(jù)傳入到body對象中。
第三步：利用response對象去構造新的response，然后最后返回給App。
針對數(shù)據(jù)加解密入口：
目前在網絡請求類里添加攔截器，然后在攔截器中處理request請求和response響應數(shù)據(jù)的加密和解密操作。
目前在網絡請求類里添加攔截器，然后在攔截器中處理request請求和response響應數(shù)據(jù)的加密和解密操作。
主要是加密什么數(shù)據(jù)：
在request請求數(shù)據(jù)階段，如果是get請求加密url數(shù)據(jù)，如果是post請求則加密url數(shù)據(jù)和requestBody數(shù)據(jù)。
在response響應數(shù)據(jù)階段。
在request請求數(shù)據(jù)階段，如果是get請求加密url數(shù)據(jù)，如果是post請求則加密url數(shù)據(jù)和requestBody數(shù)據(jù)。
在response響應數(shù)據(jù)階段。
如何進行加密：發(fā)起請求(加密)
第一步：獲取請求的數(shù)據(jù)。主要是獲取請求url和requestBody，這一塊需要對數(shù)據(jù)一塊處理。
第二步：對請求數(shù)據(jù)進行加密。采用RC4加密數(shù)據(jù)。
第三步：根據(jù)不同的請求方式構造新的request。使用 key 和 result 生成新的 RequestBody 發(fā)起網絡請求。
第一步：獲取請求的數(shù)據(jù)。主要是獲取請求url和requestBody，這一塊需要對數(shù)據(jù)一塊處理。
第二步：對請求數(shù)據(jù)進行加密。采用RC4加密數(shù)據(jù)。
第三步：根據(jù)不同的請求方式構造新的request。使用 key 和 result 生成新的 RequestBody 發(fā)起網絡請求。
如何進行解密：接收返回(解密)
第一步：常規(guī)解析得到 result ，然后使用RC4工具，傳入key去解密數(shù)據(jù)得到解密后的字符串。
第二步：將解密的字符串組裝成ResponseBody數(shù)據(jù)傳入到body對象中。
第三步：利用response對象去構造新的response，然后最后返回給App。
第一步：常規(guī)解析得到 result ，然后使用RC4工具，傳入key去解密數(shù)據(jù)得到解密后的字符串。
第二步：將解密的字符串組裝成ResponseBody數(shù)據(jù)傳入到body對象中。
第三步：利用response對象去構造新的response，然后最后返回給App。
證書鎖定是Google官方比較推薦的一種校驗方式：
原理是在客戶端中預先設置好證書信息，握手時與服務端返回的證書進行比較，以確保證書的真實性和有效性。
如何實現(xiàn)證書鎖定：
有兩種實現(xiàn)方式：一種通過network_security_config.xml配置，另一種通過代碼設置；
//第一種方式：配置文件
api.zuoyebang.cn
38JpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhK90=
9k1a0LRMXouZHRC8Ei+ 4PyuldPDcf3UKgO/ 04cDM90K=
//第二種方式：代碼設置
funsslPinning: OkHttpClient {
valbuilder = OkHttpClient.Builder
valpinners = CertificatePinner.Builder
.add( "api.zuoyebang.cn", "sha256//89KpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRh00L=")
.add( "api.zuoyebang.com", "sha256//a8za0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1o=09")
.build
builder.apply {
certificatePinner(pinners)
}
returnbuilder.build
}
該方案優(yōu)點和缺點分析說明：
優(yōu)點：安全性高，配置方式也比較簡單，并能實現(xiàn)動態(tài)更新配置。
缺陷：網絡安全配置無法實現(xiàn)證書證書的動態(tài)更新，另外該配置也受Android系統(tǒng)影響，對7.0以前的系統(tǒng)不支持。代碼配置相對靈活些。
破解：證書鎖定破解比較復雜，比如老牌的JustTrustMe插件，通過hook各網絡框架的證書校驗方法，替換原有邏輯，使校驗失效
證書鎖定是Google官方比較推薦的一種校驗方式：
原理是在客戶端中預先設置好證書信息，握手時與服務端返回的證書進行比較，以確保證書的真實性和有效性。
原理是在客戶端中預先設置好證書信息，握手時與服務端返回的證書進行比較，以確保證書的真實性和有效性。
如何實現(xiàn)證書鎖定：
有兩種實現(xiàn)方式：一種通過network_security_config.xml配置，另一種通過代碼設置；
有兩種實現(xiàn)方式：一種通過network_security_config.xml配置，另一種通過代碼設置；
//第一種方式：配置文件
api.zuoyebang.cn
38JpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhK90=
9k1a0LRMXouZHRC8Ei+ 4PyuldPDcf3UKgO/ 04cDM90K=
//第二種方式：代碼設置
funsslPinning: OkHttpClient {
valbuilder = OkHttpClient.Builder
valpinners = CertificatePinner.Builder
.add( "api.zuoyebang.cn", "sha256//89KpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRh00L=")
.add( "api.zuoyebang.com", "sha256//a8za0LRMXouZHRC8Ei+4PyuldPDcf3UKgO/04cDM1o=09")
.build
builder.apply {
certificatePinner(pinners)
}
returnbuilder.build
}
該方案優(yōu)點和缺點分析說明：
優(yōu)點：安全性高，配置方式也比較簡單，并能實現(xiàn)動態(tài)更新配置。
缺陷：網絡安全配置無法實現(xiàn)證書證書的動態(tài)更新，另外該配置也受Android系統(tǒng)影響，對7.0以前的系統(tǒng)不支持。代碼配置相對靈活些。
破解：證書鎖定破解比較復雜，比如老牌的JustTrustMe插件，通過hook各網絡框架的證書校驗方法，替換原有邏輯，使校驗失效
優(yōu)點：安全性高，配置方式也比較簡單，并能實現(xiàn)動態(tài)更新配置。
缺陷：網絡安全配置無法實現(xiàn)證書證書的動態(tài)更新，另外該配置也受Android系統(tǒng)影響，對7.0以前的系統(tǒng)不支持。代碼配置相對靈活些。
破解：證書鎖定破解比較復雜，比如老牌的JustTrustMe插件，通過hook各網絡框架的證書校驗方法，替換原有邏輯，使校驗失效
先說一下背景和問題：
api.test.com/getbanner?k… http://api.test.com/getbanner?key1=value1key2=value2key3=value3
這種方式簡單粗暴，通過調用 getbanner方法即可獲取輪播圖列表信息，但是這樣的方式會存在很嚴重的安全性問題，沒有進行任何的驗證，大家都可以通過這個方法獲取到數(shù)據(jù)，導致產品信息泄露。
在寫開放的API接口時是如何保證數(shù)據(jù)的安全性的？
請求來源(身份)是否合法？請求參數(shù)被篡改？請求的唯一性(不可復制)？
問題的解決方案設想：
解決方案：為了保證數(shù)據(jù)在通信時的安全性，我們可以采用參數(shù)簽名的方式來進行相關驗證。
最終決定的解決方案：
調用接口之前需要驗證簽名和有效時間，要生成一個sign簽名。先拼接-后轉碼-再加密-再發(fā)請求！
sign簽名校驗實踐：
需要對請求參數(shù)進行簽名驗證，簽名方式如下：key1=value1key2=value2key3=value3secret=yc 。對這個字符串進行md5一下。
然后被sign后的接口就變成了： api.test.com/getbanner?k… http://api.test.com/getbanner?key1=value1key2=value2key3=value3sign=xxx
為什么在獲取sign的時候建議使用secret參數(shù)？secret僅作加密使用，添加在參數(shù)中主要是md5，為了保證數(shù)據(jù)安全請不要在請求參數(shù)中使用。
服務端對sign校驗：
這樣請求的時候就需要合法正確簽名sign才可以獲取數(shù)據(jù)。這樣就解決了身份驗證和防止參數(shù)篡改問題，如果請求參數(shù)被人拿走，沒事，他們永遠也拿不到secret，因為secret是不傳遞的。再也無法偽造合法的請求。
如何保證請求的唯一性：
api.test.com/getbanner?k…
通過stamp時間戳用來驗證請求是否過期。這樣就算被人拿走完整的請求鏈接也是無效的。
Sign簽名安全性分析：
通過上面的案例，安全的關鍵在于參與簽名的secret，整個過程中secret是不參與通信的，所以只要保證secret不泄露，請求就不會被偽造。
先說一下背景和問題：
api.test.com/getbanner?k… http://api.test.com/getbanner?key1=value1key2=value2key3=value3
這種方式簡單粗暴，通過調用 getbanner方法即可獲取輪播圖列表信息，但是這樣的方式會存在很嚴重的安全性問題，沒有進行任何的驗證，大家都可以通過這個方法獲取到數(shù)據(jù)，導致產品信息泄露。
這種方式簡單粗暴，通過調用 getbanner方法即可獲取輪播圖列表信息，但是這樣的方式會存在很嚴重的安全性問題，沒有進行任何的驗證，大家都可以通過這個方法獲取到數(shù)據(jù)，導致產品信息泄露。
在寫開放的API接口時是如何保證數(shù)據(jù)的安全性的？
請求來源(身份)是否合法？請求參數(shù)被篡改？請求的唯一性(不可復制)？
請求來源(身份)是否合法？請求參數(shù)被篡改？請求的唯一性(不可復制)？
問題的解決方案設想：
解決方案：為了保證數(shù)據(jù)在通信時的安全性，我們可以采用參數(shù)簽名的方式來進行相關驗證。
解決方案：為了保證數(shù)據(jù)在通信時的安全性，我們可以采用參數(shù)簽名的方式來進行相關驗證。
最終決定的解決方案：
調用接口之前需要驗證簽名和有效時間，要生成一個sign簽名。先拼接-后轉碼-再加密-再發(fā)請求！
調用接口之前需要驗證簽名和有效時間，要生成一個sign簽名。先拼接-后轉碼-再加密-再發(fā)請求！
sign簽名校驗實踐：
需要對請求參數(shù)進行簽名驗證，簽名方式如下：key1=value1key2=value2key3=value3secret=yc 。對這個字符串進行md5一下。
然后被sign后的接口就變成了： api.test.com/getbanner?k… http://api.test.com/getbanner?key1=value1key2=value2key3=value3sign=xxx
為什么在獲取sign的時候建議使用secret參數(shù)？secret僅作加密使用，添加在參數(shù)中主要是md5，為了保證數(shù)據(jù)安全請不要在請求參數(shù)中使用。
需要對請求參數(shù)進行簽名驗證，簽名方式如下：key1=value1key2=value2key3=value3secret=yc 。對這個字符串進行md5一下。
為什么在獲取sign的時候建議使用secret參數(shù)？secret僅作加密使用，添加在參數(shù)中主要是md5，為了保證數(shù)據(jù)安全請不要在請求參數(shù)中使用。
服務端對sign校驗：
這樣請求的時候就需要合法正確簽名sign才可以獲取數(shù)據(jù)。這樣就解決了身份驗證和防止參數(shù)篡改問題，如果請求參數(shù)被人拿走，沒事，他們永遠也拿不到secret，因為secret是不傳遞的。再也無法偽造合法的請求。
這樣請求的時候就需要合法正確簽名sign才可以獲取數(shù)據(jù)。這樣就解決了身份驗證和防止參數(shù)篡改問題，如果請求參數(shù)被人拿走，沒事，他們永遠也拿不到secret，因為secret是不傳遞的。再也無法偽造合法的請求。
如何保證請求的唯一性：
api.test.com/getbanner?k…
通過stamp時間戳用來驗證請求是否過期。這樣就算被人拿走完整的請求鏈接也是無效的。
通過stamp時間戳用來驗證請求是否過期。這樣就算被人拿走完整的請求鏈接也是無效的。
Sign簽名安全性分析：
通過上面的案例，安全的關鍵在于參與簽名的secret，整個過程中secret是不參與通信的，所以只要保證secret不泄露，請求就不會被偽造。
5.架構設計說明
5.1 整體架構設計
如下所示：
對于請求和響應的數(shù)據(jù)加解密要注意:
在網絡上交換數(shù)據(jù)(網絡請求數(shù)據(jù))時，可能會遇到不可見字符，不同的設備對字符的處理方式有一些不同。
Base64對數(shù)據(jù)內容進行編碼來適合傳輸。準確說是把一些二進制數(shù)轉成普通字符用于網絡傳輸。統(tǒng)統(tǒng)變成可見字符，這樣出錯的可能性就大降低了。
對于請求和響應的數(shù)據(jù)加解密要注意:
在網絡上交換數(shù)據(jù)(網絡請求數(shù)據(jù))時，可能會遇到不可見字符，不同的設備對字符的處理方式有一些不同。
Base64對數(shù)據(jù)內容進行編碼來適合傳輸。準確說是把一些二進制數(shù)轉成普通字符用于網絡傳輸。統(tǒng)統(tǒng)變成可見字符，這樣出錯的可能性就大降低了。
在網絡上交換數(shù)據(jù)(網絡請求數(shù)據(jù))時，可能會遇到不可見字符，不同的設備對字符的處理方式有一些不同。
Base64對數(shù)據(jù)內容進行編碼來適合傳輸。準確說是把一些二進制數(shù)轉成普通字符用于網絡傳輸。統(tǒng)統(tǒng)變成可見字符，這樣出錯的可能性就大降低了。
可以一鍵配置AB測試開關:
.setMonitorToggle( object: IMonitorToggle {
overridefunisOpen: Boolean{
//todo 是否降級，如果降級，則不使用該功能。留給AB測試開關
returnfalse
}
})
5.4 異常設計說明
base64加密和解密導致錯誤問題:
Android 有自帶的Base64實現(xiàn)，flag要選 Base64.NO_WRAP，不然末尾會有換行影響服務端解碼。導致解碼失敗。
base64加密和解密導致錯誤問題:
Android 有自帶的Base64實現(xiàn)，flag要選 Base64.NO_WRAP，不然末尾會有換行影響服務端解碼。導致解碼失敗。
Android 有自帶的Base64實現(xiàn)，flag要選 Base64.NO_WRAP，不然末尾會有換行影響服務端解碼。導致解碼失敗。
關于初始化配置:
NotCaptureHelper.getInstance.config = CaptureConfig.builder
//設置debug模式
.setDebug( true)
//設置是否禁用代理
.setProxy( false)
//設置是否進行數(shù)據(jù)加密和解密，
.setEncrypt( true)
//設置cer證書路徑
.setCerPath( "")
//設置是否進行CA證書校驗
.setCaVerify( false)
//設置加密和解密key
.setEncryptKey(key)
//設置參數(shù)
.setReservedQueryParam(OkHttpBuilder.RESERVED_QUERY_PARAM_NAMES)
.setMonitorToggle( object: IMonitorToggle {
overridefunisOpen: Boolean{
//todo 是否降級，如果降級，則不使用該功能。留給AB測試開關
returnfalse
}
})
.build
設置okHttp配置:
NotCaptureHelper.getInstance.setOkHttp( app, okHttpBuilder)
如何設置自己的加解密方式:
NotCaptureHelper.getInstance.encryptDecryptListener = object: EncryptDecryptListener {
/**
* 外部實現(xiàn)自定義加密數(shù)據(jù)
*/
overridefunencryptData(key: String, data: String) : String {
LoggerReporter.report( "NotCaptureHelper", "encryptData data : $data" )
valstr = data.encryptWithRC4(key) ?: ""
LoggerReporter.report( "NotCaptureHelper", "encryptData str : $str" )
returnstr
}
/**
* 外部實現(xiàn)自定義解密數(shù)據(jù)
*/
overridefundecryptData(key: String, data: String) : String {
LoggerReporter.report( "NotCaptureHelper", "decryptData data : $data" )
valstr = data.decryptWithRC4(key) ?: ""
LoggerReporter.report( "NotCaptureHelper", "decryptData str : $str" )
returnstr
}
}
5.6 防抓包功能自測
網絡請求測試:
正常請求，測試網絡功能是否正常。
抓包測試：
配置fiddler，charles等工具。
手機上設置代理。
手機上安裝證書。
單向認證測試：進行網絡請求，會提示 SSLHandshakeException即ssl握手失敗的錯誤提示，即表示app端的單向認證成功。
數(shù)據(jù)加解密：進行網絡請求，看一下請求參數(shù)和響應body數(shù)據(jù)是否加密，如果看不到實際json實體則表示加密成功。
網絡請求測試:
正常請求，測試網絡功能是否正常。
正常請求，測試網絡功能是否正常。
抓包測試：
配置fiddler，charles等工具。
手機上設置代理。
手機上安裝證書。
單向認證測試：進行網絡請求，會提示 SSLHandshakeException即ssl握手失敗的錯誤提示，即表示app端的單向認證成功。
數(shù)據(jù)加解密：進行網絡請求，看一下請求參數(shù)和響應body數(shù)據(jù)是否加密，如果看不到實際json實體則表示加密成功。
配置fiddler，charles等工具。
手機上設置代理。
手機上安裝證書。
單向認證測試：進行網絡請求，會提示 SSLHandshakeException即ssl握手失敗的錯誤提示，即表示app端的單向認證成功。
數(shù)據(jù)加解密：進行網絡請求，看一下請求參數(shù)和響應body數(shù)據(jù)是否加密，如果看不到實際json實體則表示加密成功。
https://github.com/yangchong211/YCToolLib
綜合庫：
https://github.com/yangchong211/YCAppTool
視頻播放器：
https://github.com/yangchong211/YCVideoPlayer
為了防止失聯(lián)，歡迎關注我防備的小號
微信改了推送機制，真愛請星標本公號??
掃描二維碼推送至手機訪問。
版權聲明：本文由飛速云SEO網絡優(yōu)化推廣發(fā)布，如需轉載請注明出處。
