اگه حمایتا خوب بود کم کم میریم سمت باینری اکسپلویتیشن 🩶

If the supports is good, we will gradually move towards binary exploitation 🖤

خوش اومدین به هفته 75 از برنامه GO-TO CVE این هفته به برسی اسیب پذیری روی wsus پرداختیم .

CVE : CVE-2025-52287
type : RCE
target : wsus
week : 75

#week_75

Fuzzing the COM Classes and Their Interface Definitions

https://github.com/warpnet/COM-Fuzzer

@reverseengine

گزارش روند حملات سایبری در سال 2025 از mandiant

Cyberattack Trends Report 2025 From Mandiant

https://services.google.com/fh/files/misc/m-trends-2025-en.pdf

@FUZZ0x

روش کامپایل

فایل: vuln.c
قرار بدید داخل فولدری که تمرین میکنید

// vuln.c  VM ایزوله اجرا بشه

#include <stdio.h>
#include <string.h>

void vuln() {
    char buf[64];
    puts("Enter some text:");
    gets(buf);  //  فقط برای آموزش در عمل هرگز استفاده نکنید
    printf("You entered: %s\n", buf);
}

int main() {
    vuln();
    return 0;
}

🔧 کامپایل  دو حالت


نسخه ساده محافظت‌ ها غیر فعال

gcc -o vuln_plain vuln.c -fno-stack-protector -z execstack -no-pie -g

این نسخه برای دیدن رفتارهای پایه‌ ای overflow و آموزشه فقط داخل VM اجرا کنید


نسخه مقاوم‌تر پیش‌فرض کامپایلر

gcc -o vuln_hard vuln.c -g

این نسخه محافظت‌ های معمول canary, NX, PIE و ... فعالن و برای مقایسه استفاده میشن


چند تا نکته کوتاه:
gets()
نا امنه اینجا فقط برای نمایش overflow استفاده شده


Compile method

File: vuln.c
Place it in the folder where you are practicing

// vuln.c will run in an isolated VM

#include <stdio.h>
#include <string.h>

void vuln() {
char buf[64];
puts("Enter some text:");
gets(buf); // For training purposes only, never use in practice
printf("You entered: %s\n", buf);
}

int main() {
vuln();
return 0;
}

🔧 Two-mode compilation

Simple version with protections disabled

gcc -o vuln_plain vuln.c -fno-stack-protector -z execstack -no-pie -g

Run this version in a VM to see basic overflow behavior and tutorial

More robust version of the compiler default

gcc -o vuln_hard vuln.c -g

This version has the usual protections of canary, NX, PIE, etc. enabled and is used for comparison

A few quick notes:
gets()
Unsafe is used here only to demonstrate overflow

@reverseengine

اجرای سریع خارج از gdb چطور کرش میکنه

# ورودی کوتاه

نباید کرش کنه

echo "hello" | ./vuln_plain

ورودی خیلی طولانی  احتمالا کرش یا رفتار غیرعادی

python3 -c "print('A'*200)"  | ./vuln_plain

انتظار: با ورودی کوتاه برنامه معمولا خروجی میده با ورودی 200 بایت در vuln_plain احتمالا crash یا رفتار غیر معمول میبینید

باز کردن داخل gdb و گذاشتن breakpoint

gdb ./vuln_plain

داخل gdb:

(gdb) break vuln       
# ایست در تابع vuln

(gdb) run                  اجرا کنید #

# وقتی برنامه متوقف شد منتظر ورودی یا بعد از ارسال ورودی طولانی و کرش باشید:

(gdb) info register   # وضعیت رجیسترها

(gdb) x/40x $rsp   نمایش 40 #

qword
از آدرس RSP هگزادسیمال

(gdb) x/200xb $rsp

# نمایش 200 byte اطراف RSP بایت به بایت

(gdb) bt    # backtrace

(gdb) disassemble vuln
   # اسمبلی تابع vuln

نکته: اگر pwndbg نصب باشه به‌ جاش context و vmmap هم استفاده کنید:

(gdb) context

(gdb) vmmap

How does fast execution outside of gdb crash

# Short input

Shouldn't crash

echo "hello" | ./vuln_plain

Very long input  probably crash or unusual behavior

python3 -c "print('A'*200)"  |  ./vuln_plain

Wait: With short input the program usually outputs output. With 200 bytes of input in vuln_plain you may see a crash or unusual behavior

Opening inside gdb and setting a breakpoint

gdb ./vuln_plain

Inside gdb:

(gdb) break vuln   # stop in function

(gdb) run

Instead of context and vmmap
use:

(gdb) context

(gdb) vmmap

@reverseengine

Bypass AMSI in 2025

https://www.r-tec.net/r-tec-blog-bypass-amsi-in-2025.html

@reverseengine

The Tool C Code to Syscall Shellcode for Hackers

https://meterpreter.org/shellsilo-the-tool-translating-c-code-to-syscall-shellcode-for-hackers

@reverseengine

Windows X86-64 System Call Table (XP/2003/Vista/7/8/10/11 and Server

https://j00ru.vexillium.org/syscalls/nt/64

@reverseengine

بخش ششم بافر اورفلو

درک دقیق کرش و ساختار فریم تابع در استک

در این بخش میخایم ببینیم وقتی بافر اورفلو باعث کرش میشه دقیقا در پشت‌ صحنه چه اتفاقی میوفته باید بعد از این قسمت
بفهمیم چرا بازنویسی داده در استک باعث تغییر آدرس برگشت میشه
فریم تابع چه اجزایی داره
و چطور میشه این اجزا رو با gdb دید و تحلیل کرد

وقتی یک تابع در C صدا زده میشه سیستم برای اون تابع فضایی در استک درست میکنه به این فضا میگیم فریم تابع هر فریم شامل این بخش‌ هاست

متغیرهای لوکال تابع

مقادیر پارامترها

saved RBP یا base pointer
برای برگشت

saved return address
که بعد از تموم شدن تابع بهش برمیگرده


اگر داده‌ ای بیشتر از اندازه در بافر لوکال نوشته بشه این مقادیر مهم در فریم بازنویسی میشن
و در نتیجه برنامه در return کرش میکنه یا به آدرس اشتباه میپره


این کد کمک میکنه تا فریم تابع و کرش رو ببینیم و در gdb تجزیه ش کنیم

#include <stdio.h>
#include <string.h>

void crash(char *input) {
char buffer[16];
printf("address of buffer: %p\n", buffer);
strcpy(buffer, input);
printf("done copying\n");
}

int main(int argc, char **argv) {
if (argc < 2) {
printf("usage: %s input\n", argv[0]);
return 1;
}
crash(argv[1]);
printf("returned safely\n");
return 0;
}

دستورات اجرا و تحلیل

gcc -g file4.c -o file4

gdb --args ./file4 $(python3 -c "print('A'*40)")

بعد از اجرای برنامه داخل gdb این مراحل رو انجام بدید

break crash

run

info frame

x/32x $rbp

x/32x $rsp


اینجا میبینید که بافر پایین‌ تر از saved RBP قرار داره
هر بایتی که از بافر بیرون بنویسید در اخر به saved RBP و بعد return address میرسه


برای مشاهده کرش

continue

برنامه با خطای segmentation fault کرش میکنه
با دستور زیر مسیر برگشت رو ببینید

backtrace

و با این دستور آخرین آدرس برگشتی رو چک کنید

info registers rip

توضیح کامل

در هنگام اجرای تابع crash سیستم اول RBP فعلی رو ذخیره میکنه
بعد RSP رو به پایین‌ تر منتقل میکنه تا فضای لازم برای متغیر های لوکال فراهم بشه
داخل این فضای جدید بافر قرار داره
وقتی ما داده‌ ای بزرگ‌ تر از اندازه بافر بنویسیم اول داده روی متغیر های لوکال مینویسن بعد روی RBP و بعد روی return address
در لحظه‌ای که تابع میخاد برگرده مقدار اشتباه از روی استک خونده میشه و RIP به آدرسی اشتباه پرش میکنه و همین باعث segmentation fault میشه


بخش جذاب

میتونید در gdb با این دستور تفاوت قبل و بعد از overflow رو ببینید


قبل از strcpy

x/32x $rbp-32

بعد از strcpy

x/32x $rbp-32

میبینید که بایت‌های A تمام فضای بین بافر تا return address رو پر کرده
این همون دلیل کرش برنامه هست

@reverseengine

Part 6 Buffer Overflow

Understanding the Crash and the Structure of the Function Frame on the Stack

In this part, we are going to see what exactly happens behind the scenes when a buffer overflow causes a crash. After this part, we should
understand why overwriting data on the stack changes the return address.
What are the components of a function frame?
And how can these components be viewed and analyzed with gdb.

When a function is called in C, the system creates a space on the stack for that function. We call this space the function frame. Each frame contains these parts.

Local variables of the function

Parameter values

Saved RBP or base pointer
for return

Saved return address
which the function returns to after the function completes

If more data is written to the local buffer than the limit, these important values ​​are overwritten in the frame
And as a result, the program crashes on return or jumps to the wrong address

This code helps us see the function frame and crash and analyze it in gdb

#include <stdio.h>
#include <string.h>

void crash(char *input) {
char buffer[16];
printf("address of buffer: %p\n", buffer);
strcpy(buffer, input);
printf("done copying\n");
}

int main(int argc, char **argv) {
if (argc < 2) {
printf("usage: %s input\n", argv[0]);
return 1;
}
crash(argv[1]);
printf("returned safely\n");
return 0;
}

Execution and analysis commands

gcc -g file4.c -o file4

gdb --args ./file4 $(python3 -c "print('A'*40)")

After running the program in gdb, perform these steps

break crash

run

info frame

x/32x $rbp

x/32x $rsp

Here you can see that the buffer is below the saved RBP

Every byte you write out of the buffer will eventually reach the saved RBP and then the return address

To view the crash

continue

The program crashes with a segmentation fault error

See the return path with the following command

backtrace

And check the last return address with this command

info registers rip

Full explanation

When executing the crash function, the system first saves the current RBP

Then it moves the RSP down to provide the necessary space for local variables

In this new buffer space, Yes
When we write data larger than the buffer size, first the data is written to local variables, then to RBP, and then to the return address
At the moment the function wants to return, the wrong value is read from the stack and RIP jumps to the wrong address, which causes a segmentation fault

Interesting part

You can see the difference before and after the overflow in gdb with this command

Before strcpy
x/32x $rbp-32

After strcpy
x/32x $rbp-32

You can see that the A bytes have filled all the space between the buffer and the return address

This is the reason for the program crash

@reverseengine

Pwn20wn Ireland 2025

https://marcbarbezat.medium.com/pwn2own-ireland-2025-73-failles-zero-day-r%C3%A9v%C3%A9l%C3%A9es-pour-1-million-de-primes-25a2592dde57?source=rss------bug_bounty-5

@reverseengine

Reverse engineering the Obfuscated TikTok VM

https://github.com/LukasOgunfeitimi/TikTok-ReverseEngineering

@reverseengine

DWARF as a Shared Reverse Engineering Format

https://lief.re/blog/2025-05-27-dwarf-editor/

@reverseengine

Dissecting GobRAT

https://jstnk9.github.io/jstnk9/research/GobRAT-Malware


@reverseengine

Theldus Bread

https://github.com/Theldus/bread

@reverseengine

Acunetix Premium Plus OnPremise with API Discovery

v 25.8.250820089

https://cloud.proxy-bar.org/s/5KhtUcpx3Cxln0Y

Analysing a 1-day Vulnerability in the Linux Kernel's TLS Subsyste

https://faith2dxy.xyz/2025-10-02/kCTF-TLS-nday-analysis/

@reverseengine

Reverse Engineering Go Binaries with Ghidra

https://cujo.com/reverse-engineering-go-binaries-with-ghidra

@reverseengine