把证书安装为系统证书的脚本_windows 脚本安装证书-优快云博客

本文链接：https://blog.youkuaiyun.com/namedlock/article/details/139055990

文章目录

- 实施方式：
脚本代码
SSL劫持
APEX机制
APEX官方文档与资源
参考文章

抓包的本质是一种中间人攻击，攻击者插入到两方通信过程中，未经授权的第三方既可以拦截、监视、篡改传输中的数据，也可以冒充其中一方与另一方通信。以下是有关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