基本手机抓包环境

1 抓包工具分类

全局抓包工具 Http v7、Http debugger pro 代理抓包工具 Charles、Fiddler VPN抓包工具 HttpCanary 网卡抓包工具 WireShark 手机抓包工具 tcpdump Hook抓包工具 r0Capture

2. Charles的安装与配置

前置环境配置 配置JDK 启用超级管理员 关闭防火墙 下载 Download a Free Trial of Charles • Charles Web Debugging Proxy 注册 Charles破解工具 抓包的开启、停止、清除 代理端口设置 Proxy -> Proxy Settings->Windows Proxy

3 charles抓包配置

1 去掉window勾选，打开proxy-setting

2 设置个端口号，ok退出。

3 ssl proxy

4 添加Location。Host和Port均设为*，这样可以匹配所有host和port

ok退出

5 access Control settings

6 输入虚拟机IP地址

4 设置手机系统证书

因为安卓7.0以上的版本，app不再信任用户层的证书，所以要将证书安装包系统层

1 在help->ssl proxying->save charles root certificate

2 选择桌面->命名为123->保存

3 桌面上就一个charles的证书

4 使用adb把movecert-1.9-4.zip推送到/storage/self/primary目录下：

adb push D:\安卓逆向环境\movecert-1.9-4.zip /storage/self/primary

5 打开Magisk->模块->点击底部“+”号->点击movecert-1.9-4.zip安装->根据提示重启系统

6 使用adb把123.pem推送到/storage/self/primary目录下

adb push C:\Users\Administrator\Desktop\123.pem /storage/self/primary

7 设置->安全->加密与凭据

8 从存储设配安装

9 点击charles证书

10输入证书名字并点击确定

11 点击新人的凭据

12 查看证书是否安装成功

13 重启手机并查看证书是否移动到证书目录内

5 socksdroid的安装与配置

Connection这一栏填入本机ip和Charles上设置的代理port 右上角打开VPN Charles会弹出对话框，是否允许设备连接，点击 Allow

6 抓某奇艺

7 上述抓包配置的注意事项

7.1 手机和电脑同在一个网段下

7.2 电脑能够ping通手机

7.3 手机能够ping通电脑

7.4 电脑和手机ping不通，可以查看下路由器的一些设置 比如ap隔离，错连到访客网络等

8 HttpCanary的安装、配置与使用

9 r0capture介绍

一个Hook抓包脚本，主要原理就是Hook了一些SSL相关的系统函数 GitHub地址 https://github.com/r0ysue/r0capture

9.1 r0capture的使用方式 先安装依赖 pip install hexdump pip install frida pip install frida-tools

启动frida

attach模式，抓包内容可以保存成pcap文件供后续分析

python r0capture.py -U com.qiyi.video -v -p iqiyi.pcap

spawn模式

python r0capture.py -U -f com.qiyi.video -v

10WireShark

如果保存成了pcap文件，可以使用这个工具来打开

11 抓包原理详解

1 为什么Charles要配合socksdroid来使用 VPN的开关比全局代理的配置要方便 有些app不走HTTP代理，有些机型http代理不生效(雷电4) 能抓到更全的流量 OSI七层模型：IP协议、UDP协议、TCP协议、SSL协议、HTTP协议

2 对称加密算法、RSA算法、数字签名算法介绍

对称加密算法、RSA算法和数字签名算法是三种不同的加密算法，每种都有其独特的特点和应用场景。
​
对称加密算法是一种较早且技术成熟的加密算法。在这种算法中，加密和解密使用的是相同的密钥。通信双方需要在安全通信之前商定一个密钥，然后使用该密钥对数据进行加密和解密。对称加密算法的典型代表是DES算法，它采用单一密钥进行加解密操作。然而，由于密钥的单一性，如何确保密钥的安全传输和存储成为了一个重要的问题。
​
RSA算法则是一种非对称加密算法，它采用了公钥和私钥两个密钥。公钥用于加密数据，而私钥则用于解密数据。每个用户都拥有自己的公钥和私钥，公钥可以公开，而私钥则需要严格保密。RSA算法的安全性基于大数分解问题的困难性，使得在没有私钥的情况下，几乎无法解密由公钥加密的数据。RSA算法不仅用于数据加密，还广泛应用于数字签名等领域。
​
数字签名算法是一种结合了非对称加密算法和消息摘要算法的技术。它使用私钥对数据进行签名，而使用公钥对签名进行验证。数字签名算法的主要目的是验证数据的完整性、认证数据的来源，并起到抗否认的作用。常见的数字签名算法包括RSA、DSA和ECDSA等。通过数字签名，接收方可以确认数据在传输过程中没有被篡改，并且可以确认数据的发送方身份。
​
总的来说，对称加密算法、RSA算法和数字签名算法各有其特点和适用场景。对称加密算法适用于密钥管理和安全通信较为简单的场景；RSA算法则适用于需要更高安全性的数据加密和数字签名场景；而数字签名算法则更多地应用于需要验证数据完整性和来源的场景。这些算法在实际应用中常常相互结合，以实现更为复杂和安全的加密需求。

3 图解浏览器访问HTTPS网页的密钥交换过程

4 图上的服务端变成抓包工具内置的代理服务端，能正常通信么？中间人攻击

当服务端被配置为抓包工具（如Wireshark、tcpdump等）内置的代理服务端时，其原始的服务功能将被暂时替代，而承担起代理和转发通信数据的角色。这种配置通常用于监控和分析网络通信，而不是用于正常提供业务服务。

关于能否正常通信，这取决于抓包工具的配置和网络环境。如果抓包工具被正确配置为代理服务端，并且客户端也被配置为通过该代理进行通信，那么理论上通信是可以正常进行的。抓包工具会捕获经过它的数据包，进行分析，然后再将数据包转发到目标服务器或客户端。

5 浏览器能否识别出是网页真实服务端，还是抓包工具的代理服务端？

浏览器本身通常不能直接识别出它正在与网页的真实服务端通信，还是与抓包工具的代理服务端通信。浏览器依赖于底层的网络通信机制，如TCP/IP和HTTP/HTTPS协议，来与服务器建立连接和交换数据。在这个过程中，浏览器并不直接了解网络路径中的具体细节，比如是否存在代理服务器。
​
然而，当使用HTTPS协议时，浏览器会验证服务器的SSL/TLS证书，以确保与服务器的安全连接。如果抓包工具的代理服务端正确配置了证书，并且浏览器信任该证书，那么浏览器会认为它正在与一个安全的服务器通信。这意味着，即使代理服务端在通信路径中，只要证书验证成功，浏览器就不会直接识别出代理的存在。
​
但是，有一些方法可以帮助用户或管理员识别是否存在代理服务器：
​
    检查代理设置：浏览器通常允许用户查看和修改其代理设置。通过检查这些设置，用户可以确定是否配置了代理服务器。
​
    观察网络流量：使用网络抓包工具（如Wireshark）可以观察浏览器的网络流量。如果看到流量首先发送到某个中间节点（如代理服务器），然后再转发到目标服务器，那么可以推断出代理的存在。
​
    检查SSL证书：如果怀疑通信被代理服务器拦截，可以检查SSL证书的信息。通常，真实的服务端会有自己的证书，而代理服务器可能会使用自己的证书或转发原始服务器的证书。通过比较证书的详细信息（如颁发机构、有效期、域名等），可以识别出是否存在不一致之处。
​
    使用安全指示器：现代浏览器通常会在地址栏中显示安全指示器（如绿色锁图标），以表示当前连接是安全的。然而，这并不意味着连接一定没有通过代理。它只是表示浏览器与某个服务器之间的连接是加密的。
​
总的来说，浏览器本身并不直接识别出通信路径中是否存在代理服务器。但是，通过检查代理设置、观察网络流量、检查SSL证书以及使用安全指示器等方法，用户可以间接地推断出是否存在代理服务器。

6 那么浏览器检验证书的过程是怎样的？证书路径/证书链又是什么？

浏览器检验证书的过程是一个确保与服务端安全通信的重要步骤。以下是浏览器检验证书的基本过程：
​
    获取证书：当用户尝试访问一个HTTPS站点时，浏览器会向该站点的服务器请求其SSL/TLS证书。
    验证证书颁发机构：浏览器会检查该证书是否由受信任的证书颁发机构（CA）签发。这涉及到检查证书链中的所有证书是否都是有效的，确保它们没有被撤销或过期。
    检查证书有效期：浏览器会核实证书的有效期，确保它没有被用于过期的通信。
    验证域名匹配：浏览器会检查证书中的主题名称字段，确保它与服务端正在使用的域名相匹配。
    验证公钥的有效性：浏览器会验证证书中的公钥，以确保能够安全地将数据传输给服务器。
    防止虚假证书攻击：浏览器还会检查是否存在被劫持或伪造的证书。如果证书在验证过程中出现问题，浏览器会向用户发出警告，防止用户继续与不安全的站点进行通信。
​
关于证书路径或证书链，它是用于在公钥基础结构（PKI）的证书颁发机构（CA）之间建立信任关系的一种机制。证书链由根证书、中间证书和用户证书组成，形成一个完整的证书信任链。每个证书都由其上一级证书签发，并最终追溯到受信任的根证书。这种层次结构确保了证书的可信性，因为只有当整个证书链上的每个证书都有效时，浏览器才会认为最终用户证书是有效和受信任的。
​
证书链文件通常指的是除了用户证书以外的中间证书和根证书组成的文件。在证书部署和验证过程中，证书链文件是验证证书是否可信的关键组成部分。
​
总的来说，浏览器通过这一系列的验证步骤来确保与服务端之间的通信是安全且可信的。同时，证书链的存在为这种信任关系提供了坚实的基础。

7 安卓系统为什么需要把根证书放到系统证书目录

因为安卓7.0以上的版本，app不再信任用户层的证书，所以要将证书安装包系统层

8 APP端和服务端都是同一团队开发的，APP端可以识别真实服务端

如果APP端和服务端都是同一团队开发的，那么APP端确实有能力识别出与其通信的是否是真实的服务端。这通常可以通过以下几种方式实现：
​
    预置的服务器信息：APP端可以预置真实的服务端地址和相关信息。在通信时，APP端可以比较实际连接的服务端地址与预置的地址是否一致，从而判断是否为真实的服务端。
​
    双向认证：APP端和服务端之间可以实施双向认证机制。这意味着不仅服务端需要验证APP端的身份，APP端也需要验证服务端的身份。这通常通过交换密钥对或证书来实现，确保双方都能确认对方的身份。
​
    自定义协议或标记：团队可以设计一种自定义的通信协议或在通信中加入特定的标记。APP端在通信时可以检查这些协议细节或标记，以确认是否与真实的服务端通信。
​
    加密和签名：所有通信数据都可以使用特定的加密算法和密钥进行加密，并使用数字签名来验证数据的完整性和来源。如果APP端能够成功解密和验证签名，那么它就可以认为通信是安全的，并且与真实的服务端通信。
​
    更新机制：如果服务端地址发生变化，APP端需要有一种安全的更新机制来获取新的服务端地址。这种更新机制应该能够防止中间人攻击，确保APP端只从可信的来源获取更新。
​
    调试和日志：在开发和测试阶段，团队可以添加详细的调试和日志记录功能，以记录APP端与服务端的通信过程。这有助于在出现问题时迅速定位问题，并确认是否存在中间人攻击。
​
需要注意的是，即使实施了上述措施，也不能完全排除中间人攻击的可能性。攻击者可能会使用高级技术来伪造服务端或拦截通信。因此，安全性的提升应该是一个持续的过程，需要不断更新和改进安全措施以应对新的威胁。同时，对开发人员进行安全教育和培训也是非常重要的，以确保他们在开发过程中始终关注安全性。

9 数字证书 使用者、颁发者、有效期、公钥、指纹、签名信息

12 HTTP协议

1. URL统一资源定位符
a) URL的结构
https://www.xxxxx.com:443/login/login.php?user=123&pass=456
https           使用https协议
www.xxxxx.com:443   主机名(Host):端口
login/login.php     资源路径
?           文件名与GET参数之间用?分隔
user=123            GET方式向服务器发送一个参数名为user，值为123
&           多个参数之间用&分隔
b) 相对URL与绝对URL
c) URL编码
​
2. 协议头
a) 请求头、响应头
b) 起始行、首部字段、包体
c) 常规协议头、自定义协议头
//访问方式 资源路径和GET参数 协议/版本号
POST /v2/api/?login HTTP/1.1
Host: passport.xxxxx.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
Origin: https://www.xxxxx.com/
Referer: https://www.xxxxx.com/
Cookie: XXXXXID=4A89DBBC382B25D9A43D12C4AB0151FD:FG=1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
//提交的数据包的长度 不能多也不能少一个字节 winhttp自动生成 可以不附加
Content-Length: 22
//提交数据的类型
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
//POST提交的数据和协议头之间有一个空行
user=123456&pwd=654321
​

1. POST与GET的区别
POST与GET是HTTP请求的两种主要方法，它们在多个方面存在显著的区别：
​
    语义和用途：GET主要用于从指定的资源请求数据，而POST主要用于向指定的资源提交数据。简单来说，GET是数据查询，而POST主要用于数据的增删改操作。
    安全性：HTTP规定GET比POST更安全，因为GET只作读取，不会改变服务器中的数据。然而，这只是规范，并不能保证请求方法的实现也是安全的。实际上，POST方法的安全性也取决于其实现方式。
    数据可见性：GET请求通过URL（请求行）提交数据，所传参数在URL中可见。而POST通过“请求体”传递数据，参数不会在URL中显示。因此，GET请求提交的数据长度有限，因为URL的长度会受到浏览器和服务器的限制。而POST请求没有这样的限制，可以传输大量数据。
    缓存机制：GET请求返回的内容可以被浏览器缓存起来，以便下次访问时快速显示。而POST请求则不会被浏览器缓存，每次提交都会被视为新的请求。
    幂等性：HTTP规定GET是幂等的，即多次请求返回相同的结果。尽管实际应用中可能存在例外，但GET请求的幂等性通常更强。而POST不是幂等的，每次请求都可能产生不同的结果。
    请求过程：在请求过程中，GET产生一个TCP数据包，而POST可能产生两个TCP数据包（尽管并非所有浏览器都会如此）。
​
2. 响应头
Set-Cookie、Location、状态码
​
3. 状态码 101 200 302 404 500
301或302等有重定向时，想获取当前链接的响应头或数据，访问时要禁止重定向
​
4. 协议头可以自定义
有些网站会在协议头里传递重要数据，并且一般是会变化的。如果网站检测，你就要找到来源，附加协议头提交
​

1. cookie的分类
服务器返回	Set-Cookie
本地代码生成

2. cookie的作用
识别身份(验证码)
判断是否登录状态

3. cookie的结构
名1=值1; 名2=值2; 名3=值3

4. 合并更新步骤
a) 新cookie, 去除无效cookie
b) 在新cookie里，寻找是否存在旧cookie里的名字, 存在就用新的，丢掉旧的
c) 两cookie组合到一个文本型变量中

5. 前端会用JS生成很多cookie，但是并非所有cookie都会检测
   比如Hm_lvt开头的一般没啥用