diff --git a/Chapter31/31-1.md b/Chapter31/31-1.md
new file mode 100644
index 0000000..4f53394
--- /dev/null
+++ b/Chapter31/31-1.md
@@ -0,0 +1,38 @@
+### 安卓系统如何进行 RCE，有什么思路
+
+**1. 安卓 RCE 的核心思路**
+
+安卓 RCE 的核心思想是**找到一个可以被远程触发的入口点，并利用这个入口点来执行任意代码**。这个过程通常分为两步：
+
+1. **触发点（Trigger）**：寻找一个可以被远程控制，且会处理恶意数据的接口。这个接口可以是应用程序的某个功能、某个系统服务，甚至是底层的通信协议
+2. **代码执行（Execution）**：利用触发点，让系统执行攻击者预设的代码。这通常涉及到内存破坏、反序列化、或动态加载恶意代码
+
+**2. 安卓 RCE 的主要利用途径**
+
+安卓系统的 RCE 漏洞通常存在于以下几个层面：
+
+**a) 应用层漏洞**
+
+这是最常见的 RCE 攻击途径，通常利用的是应用程序自身的逻辑或代码缺陷
+
+- **WebView 远程代码执行**：如果应用使用了 `WebView` 组件，并且没有对其进行安全配置，攻击者可以利用 `JavaScript` 接口或 `addJavascriptInterface` 接口来触发漏洞。如果 `WebView` 加载了恶意网页，恶意 `JavaScript` 就可以调用本地 Java 方法，从而实现 RCE
+- **反序列化漏洞**：如果应用使用了不安全的序列化库（如 `Fastjson`、`GSON` 的旧版本），并且从远程接收不可信的序列化数据，攻击者可以构造恶意 Payload，在反序列化时触发 RCE
+- **动态加载漏洞**：如果应用从远程服务器下载 `jar`、`dex` 或其他可执行文件，并对其进行动态加载，攻击者可以控制下载的文件，从而实现 RCE
+
+**b) IPC（进程间通信）漏洞**
+
+安卓系统依赖于各种 IPC 机制（如 `Binder`、`Content Provider`）来允许不同应用之间进行通信
+
+- **Binder 漏洞**：安卓的 `Binder` 机制是其核心 IPC 方式。如果一个 `Binder` 服务没有对传入的数据进行严格验证，攻击者可以构造恶意数据，利用 `Binder` 通信的漏洞，在服务端进程中触发内存破坏或逻辑缺陷，从而实现 RCE
+- **Content Provider 漏洞**：如果 `Content Provider` 存在 SQL 注入或文件路径遍历漏洞，攻击者可以利用这些漏洞，读取或写入敏感文件，甚至触发其他漏洞，最终导致 RCE。
+
+**c) 系统服务漏洞**
+
+安卓系统本身运行着大量的系统服务（例如 `SurfaceFlinger`、`mediaserver`）。这些服务通常以高权限运行，如果它们存在漏洞，其危害性是毁灭性的
+
+- **媒体服务（Media Server）漏洞**：安卓的媒体服务负责处理音频、视频和图像文件。如果攻击者能让其处理一个恶意的媒体文件（例如一个特制的 `MP4` 文件），可能会触发内存破坏漏洞，导致在媒体服务进程中实现 RCE。
+- **图形渲染服务（SurfaceFlinger）漏洞**：`SurfaceFlinger` 负责安卓的图形渲染。如果它存在漏洞，攻击者可以利用一个恶意的应用或网页，向其发送恶意数据，从而在 `SurfaceFlinger` 进程中实现 RCE
+
+**d) 底层协议或驱动漏洞**
+
+- **Wi-Fi、蓝牙驱动漏洞**：这些驱动程序负责处理来自无线网络的流量。如果其中存在漏洞，攻击者可以发送特制的无线数据包，在无需用户交互的情况下，触发 RCE
\ No newline at end of file
diff --git a/Chapter31/31-2.md b/Chapter31/31-2.md
new file mode 100644
index 0000000..f4c6fa6
--- /dev/null
+++ b/Chapter31/31-2.md
@@ -0,0 +1,39 @@
+### 给一个移动端的 APP，已知服务端是 cloud 环境有什么思路利用
+
+**1. 移动端 App 本地分析**
+
+首先，你需要从 App 本身入手，这是你与云端环境交互的唯一“客户端”
+
+- **逆向工程（Reverse Engineering）**
+  - **代码分析**：使用工具如 **JADX** 或 **MobSF** 对 APK/IPA 文件进行逆向，分析其 Java/Kotlin/Swift/Objective-C 源码。寻找硬编码在代码中的敏感信息，例如：
+    - API Key、Secret Key、Access Token
+    - 数据库密码、云服务凭证（如 AWS S3、Azure Blob Storage 的凭证）
+    - 加密算法和密钥
+    - 内网 IP 地址或域名
+  - **本地数据存储**：检查 App 在本地存储的数据，例如 SharedPreferences、SQLite 数据库、文件缓存等。这些地方可能存储了用户的敏感信息或 API 调用凭证
+- **网络流量抓包分析**
+  - 使用 **Burp Suite** 或 **Charles Proxy** 拦截 App 与云端服务器的所有通信流量
+  - **分析 API 接口**：这是最关键的一步。仔细分析每一个 API 接口的功能、请求参数、响应数据。特别关注：
+    - **认证机制**：App 如何进行用户认证？是基于 Token 还是 Cookie？Token 是否有过期时间？
+    - **授权机制**：是否可以越权访问其他用户的数据？例如，修改请求参数中的 `user_id`。
+    - **输入验证**：是否有 SQL 注入、命令注入、XXE 等漏洞？尝试在参数中注入特殊字符或恶意代码
+
+**2. 云端服务渗透（以 App 为跳板）**
+
+在完成本地分析后，你将拥有大量关于云端环境的信息。现在，你可以利用这些信息，以 App 为跳板，攻击后端的云服务
+
+- **攻击 API 网关和后端服务**
+  - **API 漏洞**：利用你在抓包中发现的 API 接口，进行更深入的渗透
+    - **SQL 注入**：尝试在所有参数中注入 SQL 语句，看是否能读取数据库内容
+    - **命令注入**：如果 App 调用了某些系统命令，尝试注入命令，执行 `whoami` 等
+    - **不安全的对象反序列化**：如果通信数据是序列化的 Java、Python 或其他语言对象，尝试构造恶意 Payload，触发反序列化漏洞
+    - **越权访问**：尝试用低权限用户访问高权限接口，或越权修改其他用户的数据
+- **攻击云存储**
+  - 如果 App 逆向后发现了云存储（如 AWS S3、Azure Blob Storage）的凭证，尝试使用这些凭证访问云存储
+  - **权限枚举**：检查凭证是否有读写、列出文件的权限
+  - **数据窃取**：如果能访问 S3 桶，尝试下载其中的文件，这些文件可能包含用户的敏感数据、源代码、或备份
+  - **恶意文件上传**：如果能写入，尝试上传恶意文件，可能能被 Web 服务调用
+- **攻击云函数/无服务器架构**
+  - 如果 App 的某些功能是通过云函数（如 AWS Lambda）实现的，尝试寻找云函数的 API 接口
+  - **注入攻击**：在云函数的输入参数中，尝试注入命令或代码，看是否能触发 RCE
+  - **权限滥用**：云函数通常有特定的 IAM 角色。如果能利用云函数，你可以通过其权限访问其他云资源
\ No newline at end of file