文章目录
抓包的本质是一种中间人攻击，攻击者插入到两方通信过程中，未经授权的第三方既可以拦截、监视、篡改传输中的数据，也可以冒充其中一方与另一方通信。以下是有关MITM攻击的几个关键点：
实施方式：
- 拦截通信:
攻击者在数据传输路径上拦截来自客户端和服务器之间的通信。例如，攻击者可能控制了路由器或交换机，或者设置了虚假的无线接入点。 - 会话劫持:
攻击者窃取或伪造会话cookie来接管用户的已登录会话，通常在Web应用中见到。 - DNS欺骗:
攻击者篡改DNS服务器响应，使得用户在访问一个网站时，实际上是被引导到了攻击者设定的服务器上。 - SSL劫持:
攻击者在客户端与服务器建立SSL连接的握手过程中介入，然后与客户端和服务器各创建一个加密连接。 - ARP欺骗:
在局域网中，攻击者通过发送伪造的ARP消息，使网络中的其他设备误以为攻击者的计算机是网关，流量便会通过攻击者的计算机。
在自动化测试或者逆向开发过程中，一般只涉及SSL劫持，通过SSL劫持对目标app进行抓包。安装证书为其必要环节，以下提供一个在网上找到的脚本 ，亲测可行。
脚本代码
# 删除之前可能创建的临时目录
rm -rf /data/local/tmp/tmp-ca-copy
# 创建一个单独的临时目录，用来存放当前的证书
# 否则，当我们添加挂载点时将无法再读取当前证书
mkdir -p -m 700 /data/local/tmp/tmp-ca-copy
# 复制现有的证书
# Android 9 之后
cp /apex/com.android.conscrypt/cacerts/* /data/local/tmp/tmp-ca-copy/
# 系统证书
cp /system/etc/security/cacerts/* /data/local/tmp/tmp-ca-copy/
# 在系统证书文件夹上创建内存挂载点
mount -t tmpfs tmpfs /system/etc/security/cacerts
# 将已有的证书复制回内存文件系统，以保持对它们的信任
mv /data/local/tmp/tmp-ca-copy/* /system/etc/security/cacerts/
# 复制我们的Charles证书进去，以便我们也信任它，7c2c2971.0是从charles中导出的证书加工而来
cp /data/local/tmp/7c2c2971.0 /system/etc/security/cacerts/
# 更新权限和SELinux上下文标签
chown root:root /system/etc/security/cacerts/*
chmod 644 /system/etc/security/cacerts/*
chcon u:object_r:system_file:s0 /system/etc/security/cacerts/*
# 处理APEX覆盖，需要注入到每个命名空间：
# 首先我们获取Zygote进程（它们启动每个应用程序）
ZYGOTE_PID=$(pidof zygote || true)
ZYGOTE64_PID=$(pidof zygote64 || true)
# 注意，有些设备两个都有！
# 应用程序在启动时会继承Zygote的挂载点，因此我们在这里注入，以确保
# 所有新启动的应用程序立即可以看到这些证书：
for Z_PID in "$ZYGOTE_PID" "$ZYGOTE64_PID"; do
if [ -n "$Z_PID" ]; then
nsenter --mount=/proc/$Z_PID/ns/mnt -- \
/bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
fi
done
# 然后我们将挂载点注入到所有已经运行的应用中，这样它们
# 也可以立即看到这些CA证书：
# 获取每个其父进程是Zygote之一的进程的PID：
APP_PIDS=$(
echo "$ZYGOTE_PID $ZYGOTE64_PID" | \
xargs -n1 ps -o 'PID' -P | \
grep -v PID
)
# 注入到这些应用的挂载命名空间中：
for PID in $APP_PIDS; do
nsenter --mount=/proc/$PID/ns/mnt -- \
/bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts &
done
wait # 并行启动 - 在这里等待完成
echo "系统证书已注入"
这段代码展示了一个在Android设备上动态注入（添加）新的CA（证书颁发机构）证书的过程，使得系统和应用信任新添加的证书。这通常用于中间人攻击（MITM）场景，如使用Charles或Wireshark等代理和调试工具来分析HTTPS加密流量时需要。下面是代码步骤的详细解释：
- 清理旧的临时目录:
利用 rm -rf /data/local/tmp/tmp-ca-copy 删除之前可能存在的临时目录，确保不会与旧文件发生冲突。 - 创建新的临时目录:
mkdir -p -m 700 /data/local/tmp/tmp-ca-copy 创建一个新的临时目录来存储当前有效的证书，设置权限为700（只有拥有者具有读、写、执行权限）。 - 备份现有证书:
cp /apex/com.android.conscrypt/cacerts/* /data/local/tmp/tmp-ca-copy/ 和 cp /system/etc/security/cacerts/* /data/local/tmp/tmp-ca-copy/ 将Android系统现有的CA证书从两个不同的位置复制到临时目录中。这么做是为了在执行接下来的挂载操作后能够恢复这些证书，因为挂载操作会使原始证书不可访问。 - 在证书目录上创建内存型挂载点:
mount -t tmpfs tmpfs /system/etc/security/cacerts 在 /system/etc/security/cacerts 目录上创建一个临时文件系统挂载点。这意味着该目录现在在内存中，并且可以更灵活的修改，而不会影响实际的文件系统。 - 恢复证书和添加新证书:
mv /data/local/tmp/tmp-ca-copy/* /system/etc/security/cacerts/ 将备份的证书从临时目录移动到新的内存挂载点中。
mv /data/local/tmp/7c2c2971.0 /system/etc/security/cacerts/ 移动新的证书（例如，Charles的根证书）到内存挂载点。这个证书会被系统额外信任。 - 更新权限和SELinux上下文:
使用 chown, chmod, 和 chcon 命令设置证书文件的所有者、权限和SELinux上下文，确保这些证书文件符合系统安全策略。 - 处理APEX覆盖问题:
系统为每个应用进程维护单独的命名空间。脚本通过查找系统初始化过程（Zygote）的PID，使用nsenter命令注入到每个Zygote命名空间中，从而使所有新启动的应用也能信任新添加的证书。 - 为所有已运行的应用注入挂载点:
查找所有由Zygote启动的应用进程的PID，并为这些进程注入改动后的挂载点，使他们也能立即信任新添加的证书而无需重新启动。 - 等待上述所有命令执行完毕。
此脚本使得新添加的证书被系统和所有应用信任，这对于开发者和安全研究人员在调试或安全测试过程中捕获和分析HTTPS加密通信非常有用。务必注意，执行这一操作通常需要root权限，并且应该在充分理解可能带来的安全隐患的情况下进行。
SSL劫持
SSL劫持（SSL Hijacking）是中间人攻击（MITM）的一种形式，其中攻击者插入到客户端（如Web浏览器）和服务器（如Web服务器）之间的加密通信连接中。在SSL劫持攻击中，攻击者不仅能够监视通信内容，还能够动态地篡改交互的数据。
工作原理
SSL劫持的典型情景包括以下几个步骤：
- 拦截初始连接:
客户端尝试与服务器建立SSL连接时，攻击者利用各种手段（如ARP欺骗、DNS劫持等）接管通信。 - 建立两个SSL会话:
攻击者与客户端建立一个SSL连接，并与服务器建立另一个SSL连接。这样攻击者既是客户端与服务器的中间人，又是两个独立SSL会话的终点。 - 中继和篡改数据:
攻击者接收客户端的SSL加密数据，解密数据以查看内容，然后再加密数据发送给服务器；同时也将服务器的响应解密后，视情况决定是否篡改，再加密发送回客户端。
实施条件
成功实施SSL劫持通常需要以下条件：
- 流量控制: 攻击者需要能够控制客户端和服务器之间的数据流量。
- 信任问题: 攻击者必须让客户端信任其提供的SSL证书，这通常需要伪造或窃取某个受信任的CA（证书颁发机构）签署的证书。
- 握手过程介入: 攻击者必须在SSL握手过程中介入，以插入自己的证书和权限。
防御措施
- 证书透明度 (Certificate Transparency): 一个通过公开和监测SSL证书来增加透明度的机制，以显露不合法证书的发行。
- HSTS（HTTP Strict Transport Security）: 一种Web安全策略机制，它告诉浏览器只能通过HTTPS而非HTTP通信。
- 证书固定 (Certificate Pinning): 是指在客户端存储已知的服务器证书的信息，后续的通信必须使用包含这些信息的证书，否则连接会被认为是不安全的。
- 持续监控和审计: 通过不断监控网络活动和审计SSL证书的合法性来防范不正常的通信模式。
- 使用自动更新的浏览器和操作系统: 确保使用的浏览器和操作系统有最新的安全补丁和防御机制。
SSL劫持是一种高级的攻击技术，因其可以完全控制客户端和服务器之间的加密通信，所以其防御措施需要多层次的安全保护和用户教育。牢记，始终验证和确认SSL证书的可信性是防止SSL劫持攻击的关键一步。
APEX机制
APEX（Application EXpress）是从 Android 9 (API级别 28) 开始介绍的一种新的软件分发格式，旨在改善关键系统组件的核心运行时和模块化更新。在Android历代版本中，谷歌致力于将更多系统组件模块化，APEX是这一努力的一部分。这种机制主要体现在以下方面：
APEX的主要目标
- 更新系统组件: 在传统的Android OTA（Over-The-Air）更新中，为了更新系统组件，通常需要进行全面的系统更新，这往往是一个庞大而耗时的过程。APEX旨在允许单独更新系统组件，无需完整OTA更新，以此加快更新过程，提高灵活性，同时减少需要下载的数据量。
- 提高安全性: APEX通过限定系统组件的更新方式和更新源，使得整个系统的安全性得到增强。每个APEX模块都必须经过严格的验证，确保其来源的安全性和稳定性。
- 提高兼容性: 通过将系统组件封装为APEX模块，Google可以在不同设备上提供统一的系统组件，无论制造商做了什么定制，这有助于减少Android碎片化。
APEX的工作原理
- 模块化: APEX模块包含了构成某个系统组件的所有必要组成部分，包括本地库、资源文件和Dex文件。它不仅仅是一个文件，而是一个完整的文件系统映像，这意味着它可以包含一整套目录和文件结构。
- 独立更新: APEX文件可以通过设备上的Google Play系统更新或其他方式分发到设备上。广泛使用了APEX的设备可以只更新单独的系统组件而无需执行完整的系统升级。
- 验证与安全: 在安装或更新APEX文件之前，系统会验证APEX文件的签名，保证其未被篡改，并且来自于可信的来源。更新时，也会验证版本的兼容性，确保系统的稳定性。
- 只读挂载: 一旦验证并安装，APEX模块将以只读方式挂载到特定的挂载点上。这有助于防止未授权的更改，并维护系统的完整性。
APEX模块的安装与更新
在系统启动时会挂载APEX文件。如果检测到有新的APEX更新文件，系统将在下一次启动时安装这些文件。
更新流程通常遵循以下步骤：下载 -> 验证 -> 激活 -> 重启 -> 挂载。
APEX模块的实例
Conscrypt: 负责加密的Android平台本地库。
Media: 提供多媒体支持的模块。
Runtime: 包含了ART（Android Runtime）。
APEX的局限性
- 设备兼容性: 并非所有Android设备都支持APEX，特别是那些早于Android 9的设备。
- 定制限制: 尽管APEX模块有助于减少系统组件的碎片化，但设备制造商和运营商对系统组件的定制可能仍然需要全系统更新。
- 更新流程: 由于APEX模块是在系统启动时进行更新的，用户可能需要重启设备来完成更新过程。
APEX是Android系统持续发展和改进中的重要一环，未来的Android版本可能会进一步扩展和优化这一机制。
APEX官方文档与资源
- Android官方文档: Android开发者官网提供了关于APEX的介绍和文档，这是学习APEX机制最权威的资源之一。
APEX | Android Open Source Project - Google开发者博客: Google的开发者博客上不时会发布与APEX相关的文章，介绍新功能、案例研究或最佳实践。Google Developers Blog
- Android Source: 在Android的开源项目代码库中，你可以找到关于APEX模块实现的实际代码，对于深入理解APEX如何在系统级别工作非常有用。
AOSP Source Code
1650
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
