مکانیسم ها:
روش ها یا پروتوکول های سطح پایینی هستند که یک قطعه مورد نیاز رو پیاده سازی میکنن

Mechanisms:
are low-level methods or protocols that implement a required component

@reverseengine

PatchReview:

https://github.com/f-bader/MSRC-PatchReview

MS patch checking tool

DFIR Timeline Analysis for macOS

https://github.com/r3nzsec/irflow-timeline

WINDOWS KERNELS AREN’T MEANT TO BE TOUCHED…

…but this guide shows exactly how researchers break them apart.

From Stack Overflow exploitation to SMEP/KPTI bypassing, ROP chains, and kernel shellcoding — this is pure low-level offensive security madness.

Inside this beast:
HEVD exploitation workflow
WinDbg kernel debugging
kASLR, SMEP & KPTI bypass concepts
ROP chain construction
Kernel privilege escalation theory
Real exploit development methodology

IDA CyberChef

https://github.com/HexRaysSA/ida-cyberchef

سوئیچ زمینه:
به سیستم عامل این امکان رو میده که اجرای یک برنامه رو متوقف کنه و اجرای برنامه دیگه ای رو روی یک cpu مشخص شروع کنه


Context Switch:
Allows the operating system to stop executing one program and start executing another program on a specific CPU

@reverseengine

اینجوری احساس میکنم ی جورایی هم جالبه هم بهتر درک میکنید مفهومو.

تصور کنید یک هلو داریم

یک هلو؟

بله، یک هلو بیایید بهش بگیم هلوی فیزیکی اما ما تعداد زیادی خورنده داریم که دوست دارن این هلو رو بخورن چیزی که میخایم به هر خورنده ای بدیم هلوی خودشه تا بتونه خوشحال باشه ما هلویی رو که به خورنده‌ ها میدیم هلوهای مجازی میگیم ما به نوعی بسیاری از این هلوهای مجازی رو از یک هلوی فیزیکی میسازیم

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

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

درسته! دقیقا.

ولی فقط یک هلو وجود دارده

بله. خب، اگر من ی هلو رو با کس دیگه ای تقسیم کنم فکر میکنم متوجه میشدم

بله! نکته خوبیه اما این مشکل بسیاری از کسایه که هلو میخورن؛ بعضی وقت ها اونا چرت میزنن یا کار دیگه ای انجام میدن بنابر این میتونید اون هلو رو بدزدید و برای مدت کوتاهی به شخص دیگه ای بدید و به این ترتیب ما توهم هلو های مجازی زیادی رو ایجاد میکنیم، یک هلو برای هر نفر!



I feel like this is kind of interesting and you understand the concept better.

Imagine we have a peach

A peach?

Yes, a peach, let's call it a physical peach, but we have a lot of eaters who want to eat this peach. What we want to give each eater is their own peach so that they can be happy. We call the peaches that we give to the eaters virtual peaches. We kind of make a lot of these virtual peaches out of one physical peach.

The important point: in this illusion, it seems like each eater has a physical peach, but in reality, that's not the case.

So you're sharing the peach, but you don't even know it?

Right! Exactly.

But there's only one peach.

Yeah. Well, if I shared the peach with someone else, I think I would understand.

Yeah! That's a good point, but this is the problem with a lot of people who eat peaches; Sometimes they're taking a nap or doing something else, so you can steal that peach and give it to someone else for a short time, and that way we create the illusion of lots of virtual peaches, one for each person!

@reverseengine

بطور اضافیه این توضیح خودمون رو همیشه داریم این اضافه است اونم برای بعضی از توضیحات

Additionally, we always have this explanation of our own. This is an addition, and that's for some explanations.

بخش شونزدهم بافر اورفلو

کشف بافر اورفلو در مهندسی معکوس با ابزارهای IDA و Ghidra و r2


توضیح:

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

قدم اول

تشخیص توابع خطرناک در باینری این یکی از سریعترین روش‌ هاست

ایده ساده:

اگه جایی تابع‌ هایی مثل strcpy sprintf gets memcpy بدون سایز مشخص وجود داشته باشه احتمال بافر اورفلو زیاده

توضیح فایل:

ما از یک باینری ساده برای آموزش استفاده میکنیم که توش strcpy و gets استفاده شده تا فقط مفهوم کشف آسیب‌پذیری رو تمرین کنیم
file10_copy_data.c

C

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

void read_name() {
    char name[32];
    gets(name);
    printf("hello %s\n", name);
}

void copy_data(char *s) {
    char buf[16];
    strcpy(buf, s);
    puts("done copy");
}

int main(int argc, char **argv) {
    if (argc > 1)
        copy_data(argv[1]);
    read_name();
    return 0;
}

قدم دوم

باز کردن باینری در IDA یا Ghidra
وقتی فایل رو داخل IDA باز میکنید دنبال اسک توابع خطرناک بگردید

مثال ساده:

اگه توی view functions ببینید gets یا strcpy هست همین خودش یک خطره
بعد برید داخل خود تابع و نگاه کنید سایز بافر چقدره و ورودی از کجا میاد

نکته:


وقتی دیدید strcpy(buf s) و buf اندازه ثابت داره ولی طول s از ورودی کاربر میاد خیلی احتمال بافر اورفلو هست
این الگو یکی از کلاسیک ترین نشونه هاست


قدم سوم

دیدن فریم تابع و محل بافر توی disassembly دنبال دستوراتی مثل

sub rsp, 0x20
push rbp
mov rbp, rsp

بگردید اینا مکان ساختن فضای لوکال روی استک رو نشون میدن

مثال ساده:

نمایش اسمبلی تابع copy_data وقتی disassemble کنیم تقریبا چیزی شبیه این میبینیم

Asm

push rbp
mov rbp, rsp
sub rsp, 0x20
mov rax, rdi
lea rdx, [rbp-0x10]
mov rsi, rax
call strcpy


توضیح کد زیر

اینجا واضح میبینید که بافر 16 بایته چون از rbp تا rbp-0x10 فاصله داره
و چون strcpy هیچ چک طولی نمیکنه اگه ورودی طولانی بیاد استک میتونه خراب بشه


مرحله چهارم

چک کردن مسیر ورودی کاربر این خیلی مهمه
اگه ورودی مستقیم از argv یا fgets یا read یا gets گرفته بشه و همون مستقیم به strcpy بره آسیب‌ پذیری تقریبا قطعی میشه هر ورودی = نگاه دقیق


مرحله پنجم

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

نمونه خط اجرا
Bash

./a.out $(python3 -c "print('A'*200)")

اگر برنامه کرش کرد یعنی تشخیص ما درست بوده


برای تمرین برید دنبال فانکشن دیگه ای داخل همین باینری و سعی کنید آنالیز کنید که آیا اون تابع هم قابل سو استفاده هست یا نه
این تمرین باعث میشه کم کم چشمتون به الگوها عادت کنه

Part 16 Buffer Overflow

Discovering Buffer Overflow in Reverse Engineering with IDA, Ghidra, and R2 Tools

Explanation:

In this section, we will learn how to find out if a binary has a buffer overflow when we get it, that is, without having the source and only by analyzing the functions, we will find dangerous inputs and sensitive paths and we will only check the binary

Step 1

Detecting dangerous functions in the binary This is one of the fastest methods

Simple idea:

If there are functions like strcpy sprintf gets memcpy without a specified size, the probability of buffer overflow is high

File description:

We will use a simple binary for training in which strcpy and gets are used to practice the concept of vulnerability discovery
file10_copy_data.c

C

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

void read_name() {
    char name[32];
    get(name);
    printf("hello %s\n", name);
}

void copy_data(char *s) {
    char buf[16];
    strcpy(buf, s);
    puts("done copy");
}

int main(int argc, char **argv) {
    if (argc > 1)
        copy_data(argv[1]);
    read_name();
    return 0;
}

Step 2

Opening the binary in IDA or Ghidra
When you open the file in IDA, look for dangerous function scripts

Simple example:

If you see gets or strcpy in the view functions, that is a danger in itself

Then go into the function itself and see what is the buffer size and where the input comes from

Note:

When you see strcpy(buf s) and buf has a fixed size but the length s comes from the user input, it is very likely a buffer overflow

This pattern is one of the most classic signs

Step 3

See the function frame and the buffer location in the disassembly. Look for commands like

sub rsp, 0x20
push rbp
mov rbp, rsp

These show where local space is created on the stack

Simple example:

Showing the assembly of the copy_data function When we disassemble, we see something like this

Asm

push rbp
mov rbp, rsp
sub rsp, 0x20
mov rax, rdi
lea rdx, [rbp-0x10]
mov rsi, rax
call strcpy


Explanation of the code below

Here you can clearly see that the buffer is 16 bytes because it is from rbp to rbp-0x10
And since strcpy does not do any length check, if the input is long, the stack can be corrupted

Step 4

Checking the user input path This is very important
If the input is taken directly from argv or fgets or read or gets and goes directly to strcpy, the vulnerability is almost certain. Every input = close look

Step 5

Confirming the vulnerability
In this step, we only do one thing that is safe
We only execute very long input to see if the program crashes
No need to calculate the offset, no code execution
Just confirm the existence of the problem

Example execution line
Bash

./a.out $(python3 -c "print('A'*200)")

If the program crashes, it means our diagnosis was correct

For practice, look for another function in the same binary and try to analyze whether that function can also be exploited or not
This exercise will gradually get your eyes used to the patterns

@reverseengine

PPID Spoofing

PPID

هر پروسه در ویندوز یک Parent Process ID (PPID) دارد که نشون میده توسط چه پروسه‌ ای ایجاد شده

مثال:

explorer.exe
notepad.exe

در اینجا explorer.exe والد (Parent) و notepad.exe فرزند (Child) هست

چرا تحلیل PPID مهم است؟

ابزارهای امنیتی از رابطه والد و فرزند برای شناسایی رفتار های غیر عادی استفاده میکنن

مثلا:

winword.exe  powershell.exe
cmd.exe

یا:

excel.exe
rundll32.exe


این زنجیره‌ ها میتونن برای تیم امنیتی مشکوک باشن


هدف مهاجمان از PPID Spoofing چیست؟

بعضی حملات مهاجم تلاش میکنن رابطه والد-فرزند رو طوری نمایش دهد که فعالیتش عادی به نظر برسد

هدف معمولا:

مخفی کردن مرکز واقعی اجرای یک پروسه
پیچیده‌تر کردن تحلیل Incident Response

دشوارتر کردن Threat Hunting

روش‌های تشخیص

تیم‌های دفاعی معمولا فقط به PPID اعتماد نمیکنن و موارد زیر رو نیز بررسی میکنن

1 Command Line Analysis

بررسی آرگومان‌ های اجرا شده

مثال:

explorer.exe powershell.exe

EncodedCommand

2 Image Path Analysis

بررسی مسیر فایل اجرایی
مثال:

C:\Users\Public\svchost.exe

به شدت مشکوکه

3 Behavioral Correlation

بررسی:
ایجاد Thread
دسترسی به حافظه سایر پروسه‌ها
بارگذاری DLLهای غیرعادی
ارتباطات شبکه
4 Sysmon Logging

ابزارهایی مثل:

میتونن روابط والد-فرزند رو ثبت و تحلیل کنن

Indicator
های رایج برای Threat Hunting

winword.exe → powershell.exe
excel.exe → cmd.exe
outlook.exe → rundll32.exe
wscript.exe → powershell.exe
mshta.exe → cmd.exe

راهکار های دفاعی

فعال‌سازی Sysmon و جمع‌آوری Eventهای Process Creation

مانیتور کردن Parent/Child Relationship

استفاده از EDR برای Behavioral Detection

ساخت Detection Rule برای زنجیره‌ های غیرعادی

Threat Hunting
بر اساس Process Tree




PPID Spoofing

PPID

Every process in Windows has a Parent Process ID (PPID) that indicates which process created it

Example:

explorer.exe

notepad.exe

Here explorer.exe is the parent and notepad.exe is the child

Why is PPID analysis important?

Security tools use the parent-child relationship to identify abnormal behavior

For example:

winword.exe powershell.exe

cmd.exe

Or:

excel.exe

rundll32.exe

These chains can be suspicious to the security team

What is the attackers’ goal with PPID Spoofing?


Some attackers attempt to disguise the parent-child relationship in a way that makes it look normal

Usually aim to:

Hide the true center of a process' execution

Make Incident Response analysis more complex

Make Threat Hunting more difficult

Detection methods

Defense teams usually do not rely only on PPID and also check the following:

1 Command Line Analysis

Check the arguments executed

Example:

explorer.exe powershell.exe

EncodedCommand

2 Image Path Analysis

Check the path of the executable file

Example:

C:\Users\Public\svchost.exe

Highly suspicious

3 Behavioral Correlation

Check:
Thread creation

Access to memory of other processes

Loading unusual DLLs

Network communications

4 Sysmon Logging

Tools such as:

Can record and analyze parent-child relationships

Common Indicators for Threat Hunting

winword.exe → powershell.exe
excel.exe → cmd.exe
outlook.exe → rundll32.exe
wscript.exe → powershell.exe
mshta.exe → cmd.exe

Defense Solutions

Enabling Sysmon and Collecting Process Creation Events

Monitoring Parent/Child Relationship

Using EDR for Behavioral Detection

Building Detection Rules for Abnormal Chains

Threat Hunting
Based on Process Tree


@reverseengine

برای درک اینکه یک فرآیند چیه باید وضعیت دستگاه رو درک کنیم:

یک برنامه هنگام اجرا چه چیزی رو میتونه بخونه یا اپدیت کنه

در هر زمان چه بخش‌هایی از دستگاه برای اجرای این برنامه مهمن؟

یکی از اجزای بارز وضعیت دستگاه که یک فرآیند رو تشکیل میده حافظه اونه

دستورالعمل‌ ها در حافظه قرار دارن داده‌ هایی که برنامه در حال اجرا میخونه و مینویسه هم در حافظه قرار دارن پس حافظه‌ ای که فرآیند میتونه به اون آدرس بده به اسم فضای آدرس اونه بخشی از فرآینده


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

مثال:

شمارنده برنامه (PC) (که بعضی وقتا اشاره‌ گر دستورالعمل یا IP بهش میگن



To understand what a process is we need to understand the state of the machine:

What can a program read or update while it is running?

What parts of the machine are important to the execution of the program at any given time?

One of the most obvious components of the machine state that makes up a process is its memory

Instructions are in memory The data that the program reads and writes while it is running is also in memory So the memory that a process can address is called its address space

Also part of the state of the machine are the registers Most instructions read or update registers so it is important to understand that there are certain registers that make up this state of the machine

For example:

The program counter (PC) (sometimes called the instruction pointer or IP)

@reverseengine

A Deep Dive Into Warlock Ransomware Deployed Via ToolShell SharePoint Chained
Vulnerabilities


https://hybrid-analysis.blogspot.com/2025/10/a-deep-dive-into-warlock-ransomware.html

@reverseengine

Coruna is a multi-stage, multi-platform browser exploit framework targeting Apple's Safari/WebKit engine on ARM64 (arm64e) devices running iOS and macOS

https://www.nadsec.online/blog/coruna-technical-analysis

@reverseengine

Mergen

Mergen is a deobfuscation tool that leverages LLVM IR and assembly parsing to reverse engineer obfuscated code.

https://github.com/NaC-L/Mergen

@reverseengine

Pwning Minecraft: 4-Byte Heap Overflow to RCE

https://osec.io/blog/2026-06-02-minecraft-heap-overflow-to-rce

@reverseengine