從Android 7.0及以上版本開始，安卓系統更改了信任用戶安裝證書的默認行為，默認不信任用戶證書，用戶安裝的證書都是用戶證書，因此不管是filddle還是burp，都是把他們的根證書安裝到了用戶證書。
還有移動app默認只信任系統預裝的CA證書（開發人員可通過定義配置文件的方式，定義哪些證書可以信任），不會信任用戶安裝的CA證書，因此導致我們手動生成的burpsuite證書導入手機后，已經不能攔截App的請求，同時，通過Burp代理訪問https網站，系統會提示"該證書並非來自可信的授權中心"。
移動App的滲透，一般推薦安卓7.0及以下為測試環境，但如今越老越多的APP已經不支持安卓5等舊版本了
所以，就以夜神模擬器為例，記錄下自定義安卓系統級CA證書以方便抓取HTTPS的包，如使用安卓真機，可能在細節上略有差異
整體流程：
1.證書導出
將burp證書導出，把后綴改為.der
2.計算證書HASH
計算證書HASH，我這里使用Linux下的命令
安卓系統CA證書名字都是hash .0 ，文件名是 hash ，后綴名是 0 ，即pem證書文件名組成為：hash值+.0，故先計算出證書 hash 最后重命名證書
ubuntu@VM-16-11-ubuntu:~/Public$ openssl x509 -inform DER -in burpca.der -out burpca.pem
ubuntu@VM-16-11-ubuntu:~/Public$ ls
burpca.der burpca.pem
ubuntu@VM-16-11-ubuntu:~/Public$ openssl x509 -inform PEM -subject_hash_old -in burpca.pem
9a5ba575
-----BEGIN CERTIFICATE-----
MIIDyTCCArGgAwIBAgIEU6k7MzANBgkqhkiG9w0BAQsFADCBijEUMBIGA1UEBhML
UG9ydFN3aWdnZXIxFDASBgNVBAgTC1BvcnRTd2lnZ2VyMRQwEgYDVQQHEwtQb3J0
U3dpZ2dlcjEUMBIGA1UEChMLUG9ydFN3aWdnZXIxFzAVBgNVBAsTDlBvcnRTd2ln
Z2VyIENBMRcwFQYDVQQDEw5Qb3J0U3dpZ2dlciBDQTAeFw0xNDA2MjQwODQ3NDda
Fw00MTA2MjQwODQ3NDdaMIGKMRQwEgYDVQQGEwtQb3J0U3dpZ2dlcjEUMBIGA1UE
CBMLUG9ydFN3aWdnZXIxFDASBgNVBAcTC1BvcnRTd2lnZ2VyMRQwEgYDVQQKEwtQ
b3J0U3dpZ2dlcjEXMBUGA1UECxMOUG9ydFN3aWdnZXIgQ0ExFzAVBgNVBAMTDlBv
cnRTd2lnZ2VyIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAjSEb
Hg/kfMjoj7sh9vQsPpvI1/Bfypwdp8Xm8fTBZEXPwfI7nUZ4Gn8c0P/QFQwZ1xMn
g7Jct+D2C0x6zosMT1Kv0/UsRN7NRQm1R1pv9EMbR//JCGwQU2ORxV9dU1HU9x7m
L/f5hkQcMz680YoUKnfW/kDODnbIIQkUmBTFKSvti4SlPyKkIvaNSskf1ReAxVHi
txbNpl8QiL+xBrvq3Vg4nwh70NpXD40FSplYaxD3ffbVgxYCMzp0ZT+Ud3AaiOAA
9IB/9ZyhS36IlfBZXRcYNoLUBmfYEEE44eX3cFvmOYcewHHAJbqPa2Y79slWeKIp
K5XaWkuHvsPtogyfkwIDAQABozUwMzASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1Ud
DgQWBBS7nfTpuNhzlKzbtuJ8/QTDRkZ7JTANBgkqhkiG9w0BAQsFAAOCAQEAQj4T
PpNBluUkUIRBCr/ATxJGogGDukvolexLGiMU6CKBVbdLwsp0rIxZJojtfvYxSrK/
iz3S9XWKcZFJyY142GALhyClLYhWKw4zLjQVik5tw0r236JKox3oOWhze5QLHnO/
aAjePpYo360N5enuXwCWfDSeb5YLVGx2HH+HNNvfzTf6YVRzYKvQeGHfjUlb5+xU
0DM1nPlDckH5xR0NL0IIbyfzEHA43ZDiEwT9/OjWnXCarOe/IWzh1nu1jem4J9/0
yySuKkg/+xLr3d+n/6kUqplOz4AvyAaYt7ZOTMpTQQo+ykTB82YWdQYr8OXg+6b+
j1Hi/AZ/MAdZhILQ3g==
-----END CERTIFICATE-----
計算證書hash一定要用subject_hash_old，而不是subject_hash
因為subject_hash使用SHA-1算法，subject_hash_old使用OpenSSL 1.0.0之前老算法MD5計算
經過測試在Android 7 64bit上只能使用subject_hash_old系統才能正確識別出證書。
TIPS：
文件名是一個Hash值，而后綴是一個數字。后綴名的數字是為了防止文件名沖突的，比如如果兩個證書算出的Hash值是一樣的話，那么一個證書的后綴名數字可以設置成0，而另一個證書的后綴名數字可以設置成1
3.移動到系統根證書目錄
將剛才生成的pem改名為xxxx.0
ubuntu@VM-16-11-ubuntu:~/Public$ mv burpca.pem 9a5ba575.0
ubuntu@VM-16-11-ubuntu:~/Public$ ls
9a5ba575.0 burpca.der
3.1安裝系統CA證書
-
系統證書路徑：
/system/etc/security/cacerts/ -
用戶證書路徑：
/data/misc/user/0/cacerts-added/通過模擬器自帶的文件共享將自定義證書9a5ba575.0從移動到模擬器下的對應目錄 /system/etc/security/cacerts/ 9a5ba575 .0
注意：雖然到這里自定義證書已導入，但暫時無法被讀取，因為系統證書都是644權限，所以還需將自定義證書權限也改為644，防止普通用戶無權讀取寫入。 /system目錄默認是只讀，這里只需配合本地adb命令以讀寫權限重新掛載 /system ，一般該命令存放在模擬器安裝目錄/bin目錄下
PS D:\Program Files\Nox\bin> .\adb.exe shell
beyond1q:/ # ls
acct default.prop init.qcom.rc mnt seapp_contexts ueventd.qcom.rc
bugreports dev init.rc oem selinux_version ueventd.rc
cache etc init.superuser.rc proc sepolicy vendor
charger file_contexts.bin init.usb.configfs.rc property_contexts service_contexts
config fstab.qcom init.usb.rc root storage
d init init.zygote32.rc sbin sys
data init.environ.rc lib sdcard system
beyond1q:/ # su
beyond1q:/ # whoami
root
beyond1q:/ # cd system/etc/security/cacerts/
beyond1q:/system/etc/security/cacerts # mount -o remount,rw /system
//這里需要以讀寫權限重新掛載/system,否則權限為只讀無法修改
beyond1q:/system/etc/security/cacerts # chmod 644 ./9a5ba575.0
beyond1q:/system/etc/security/cacerts # ll | grep 9a5ba575.0
-rw-r--r-- 1 root root 1375 2021-11-7 22:38 9a5ba575.0
4.查看導入的自定義證書
以上步驟全部完成后，在手機的設置->安全->加密與憑據->信任的憑據 能看到新加入burp的證書已被安裝到系統證書
5.重啟-結束
最后手動重啟設備，這時就可以愉快的抓到安卓7下APP的HTTPS數據包了
這里還有一點就是，模擬器打開手機瀏覽器，可能會提示“該網站的安全證書有問題”，解決辦法：彈出安全警告的提示框中點擊繼續按鈕，直到點擊沒有窗口為止，然后在瀏覽器右上角的設置里，找到隱私和安全下拉框下的“顯示安全警告”選項，取消打勾后返回，這一步之后瀏覽任何https網站都不會跳出證書安全警告了。
總結
寫在最后：以上方法只是最常規的解決辦法，現下各種移動APP也出現越來越多對抗抓包的檢測方法
如APP預埋固定證書：
證書固定（Certificate Pinning）是指Client端內置Server端真正的公鑰證書。表現就是抓包時，無法連接網絡並且也接收不到任何數據（代理日志里 TLS 握手失敗）。這是因為在HTTPS請求時，Server端發給客戶端的公鑰證書必須與Client端內置的公鑰證書一致，請求才會成功。
APP內置了僅接受指定域名的證書，不接受操作系統或者瀏覽器內置的CA根證書對應的任何證書，當服務器返回的證書和代碼中的證書不一致就不進行通信，這使得App只能和服務器進行通信，這樣就保障了APP與服務端通信的唯一性和安全性，這個時候就需要繞過，比如利用Xposed + JustTrustMe + SSLUnpinning
雙向認證：
APP客戶端和服務端都互相驗證對方證書，具體為客戶端先驗服務端證書，通過后就會把本地的證書發給服務器去驗證，成功后才開始正常通信。
關於雙向認證的原理。
首先，雙向認證需Server支持，Client必須內置一套公鑰證書 + 私鑰。在SSL/TLS握手過程中，Server端會向Client端請求證書，Client端必須將內置的公鑰證書發給Server，Server驗證公鑰證書的真實性。
注意：這里的內置的公鑰證書有區別於前面預埋證書(固定)，雙向認證內置的公鑰證書+私鑰是額外的一套，不同於證書固定內置的公鑰證書。如果一個Client既使用證書固定，又使用雙向認證，那么Client端應該內置一套公鑰證書 + 一套公鑰證書和私鑰。第一套與Server端的公鑰證書相同，用於Client端系統校驗與Server發來的證書是否相同，即證書固定；第二套SSL/TLS握手時公鑰證書發給Server端，Server端進行簽名校驗，即雙向認證。
使用了雙向認證的HTTPS請求，同樣無法直接抓包，這種情況需要找證書安裝在抓包軟件，一般證書會在安裝包下，如Assets、Res等目錄下
代理檢測：
當設置手機代理后，APP無法獲取網絡數據，出現無法連接網絡的情況出現。但手機網絡是正常的，但就是抓不到包。這時候可能就是這個原因了。
還有模擬器和Root權限檢測等等，所以你會發現，當千難萬險繞過證書問題后，還會繼續有其他問題導致無法抓包🤣🤣🤣，
就此又會涉及到更多的方法來繞過和流量轉發，這一部分后面遇到會補。