بخش بیست و یکم بافر اورفلو

Double Free
یعنی آزاد کردن یک حافظه برای بار دوم

یکی دیگه از باگ‌ های معروف مدیریت حافظه Double Fre هست این باگ هم توی تحلیل باینری و هم توی تحلیل بدافزار خیلی دیده میشه

Double Free یعنی چی؟

یک حافظه فقط باید یک بار free بشه
اگر همون اشاره‌ گر دوباره free بشه
بهش میگن Double Free

مثال:
C

#include <stdlib.h>

int main() {

char *buf = malloc(32);

free(buf);

free(buf);

return 0;
}

مشکل این کجاست?

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

موقع مهندسی معکوس کردن دنبال چی بگردیم؟

فرض کنید داخل دیکامپایلر اینجور چیزی دیدید
C

free(ptr);

/* ... */

free(ptr);

همینجا باید مشکوک بشید حالا باید بررسی کنیید آیا بین این دو free دوباره malloc انجام شده یا اشاره‌گر تغییر کرده اگر نه احتمال Double Free خیلی بالاست

یک مثال واقعی تر:
C

buf = malloc(64);

/* ... */

if(error)
free(buf);

/* ... */

free(buf);

اینجا اگر شرط error برقرار باشه

buf
یک بار داخل شرط آزاد میشه
بعد دوباره پایین برنامه آزاد میشه
همین باعث Double Free میشه

چرا خطرناکه?

چون Heap Manager فکر میکنه
دو بار یک Chunk آزاد شده در نتیجه ساختار داخلی Heap ممکنه به هم بریزه
و همین موضوع میتونه رفتار های غیرمنتظره ایجاد کنه

چطور ازش جلوگیری میکنن?

بعد از free اشاره‌گر رو NULL میکنن

C

free(buf);
buf = NULL;

حالا اگر دوباره

free(buf);

صدا زده بشه

free(NULL)

مشکلی ایجاد نمیکنه

موقع تحلیل باینری این الگوها رو بررسی کنیو

اگر دیدید

malloc(...)

بعد

free(ptr)

و دوباره

free(ptr)

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


تا الان با سه باگ مهم مدیریت حافظه آشنا شدیم

Heap Overflow
Use After Free
Double Free

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

تمرین:

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

@reverseengine

Part 21 Buffer Overflow

Double Free means freeing a memory for the second time

Another famous memory management bug is Double Free. This bug is often seen in both binary analysis and malware analysis

What does Double Free mean?

A memory should only be freed once

If the same pointer is freed again

It is called Double Free

Example:

C

#include <stdlib.h>

int main() {

char *buf = malloc(32);

free(buf);

free(buf);

return 0;
}

What is the problem with this?

The first free frees the memory, but the second free is freeing the memory that was already freed, which can cause the program to crash or corrupt the Heap structure

What should we look for when reverse engineering?

Suppose you see something like this in the decompiler

C

free(ptr);

/* ... */

free(ptr);

You should be suspicious here. Now you should check if malloc was done again between these two frees or if the pointer changed. If not, the probability of Double Free is very high.

A more realistic example:

C

buf = malloc(64);

/* ... */

if(error)
free(buf);

/* ... */

free(buf);

Here, if the error condition is met,

buf
is freed once inside the condition,

then it is freed again at the bottom of the program,

This causes Double Free.

Why is it dangerous?

Because the Heap Manager thinks that
a Chunk has been freed twice, as a result, the internal structure of the Heap may be destroyed,

And this can cause unexpected behavior.

How do you prevent it?

After free, the pointer is NULL.

C

free(buf);
buf = NULL;

Now if again

free(buf);

Calling

free(NULL)

does not cause a problem

When analyzing the binary, check for these patterns

If you see

malloc(...)

then

free(ptr)

and again

free(ptr)

Be sure to check the program execution path

Maybe this only happens in a specific case, which is why no one noticed the bug for a long time

So far, we have learned about three important memory management bugs

Heap Overflow

Use After Free

Double Free

These three are among the most common vulnerabilities that you will encounter during reverse engineering and binary analysis

Exercise:

Write a simple program that has several different execution paths

Then check whether a pointer can be freed twice in one of the paths

If you can find this pattern inside a binary, it means that you are gradually learning about this bug


@reverseengine

How I found an integer overflow in tcpip.sys

https://aprl.pet/writing/cve-2026-58532

Complete list of LPE exploits for Windows (starting from 2023)

https://github.com/MzHmO/Exploit-Street

Following Attacker-Controlled Data Through Android Applications: A Practical Reverse Engineering Methodology

https://medium.com/@mustafamohammed789mm/following-attacker-controlled-data-through-android-applications-a-practical-reverse-engineering-78f566863650

Analyzing Carbanak: A Technical Walkthrough of a Banking Trojan

https://medium.com/@ckant/analyzing-carbanak-a-technical-walkthrough-of-a-banking-trojan-7cd8ca1be31c

Shipping post-quantum cryptography to Python

https://blog.trailofbits.com/2026/06/30/shipping-post-quantum-cryptography-to-python

@reverseengine

Simplifying MBA obfuscation with CoBRA

https://blog.trailofbits.com/2026/04/03/simplifying-mba-obfuscation-with-cobra

@reverseengine

Hidden Infrastructure Exposed: ANY.RUN Reveals Hijacked Gov Websites Delivering Malware

https://any.run/cybersecurity-blog/phantomenigma-research

@reverseengine

این ایمیل منه. اگه کاری داشتید یا حرفی، بگید حتما🩶

This is my email. If you have anything to say or need help, please do so🖤

addcss012@gmail.com

بخش بیست و دوم بافر اورفلو

Memory Leak
باگی که شاید برنامه رو کرش نکنه ولی دردسر درست میکنه


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



Memory Leak
هر وقت برنامه با malloc حافظه بگیره
باید بعدا با free آزادش کنه
اگر این کار انجام نشه
اون حافظه تا پایان اجرای برنامه اشغال میمونه
به این میگن Memory Leak

یک مثال ساده:
C

#include <stdlib.h>

int main() {

char *buf = malloc(1024);

return 0;
}

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

free(buf);

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

مثلا:
C

while (1) {
char *buf = malloc(1024);
}

هر بار 1024 بایت گرفته میشه ولی هیچ وقت آزاد نمیشه بعد از مدتی برنامه مقدار زیادی حافظه مصرف میکنه

موقع مهندسی معکوس دنبال چی بگردیم؟


اگر این الگو رو دیدید

ptr = malloc(...);

بعد مسیر اجرای تابع رو تا اخر دنبال کنید

اگر هیچ جا

free(ptr);

وجود نداشت احتمال Memory Leak هست

یک مثال واقعی تر:


C

char *buf = malloc(256);

if(error)
return;

free(buf);

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


چرا پیدا کردنش سخت‌ تره؟

چون معمولا برنامه کرش نمیکنه خطای واضحی نشون نمیده شاید فقط بعد از چند ساعت یا چند روز اجرا مشخص بشه
برای همین خیلی از Memory Leak ها مدت زیادی مخفی میمونن

ابزارهایی که کمک میکنن
برای پیدا کردن Memory Leak ابزار هایی مثل:

Valgrind
AddressSanitizer
LeakSanitizer

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


هر malloc باید یک free داشته باشه
نبودن free همیشه یعنی احتمال Memory Leak در مهندسی معکوس باید مسیر malloc تا پایان تابع رو دنبال کنیم
خروج زود هنگام از تابع یکی از رایج‌ ترین دلایل Memory Leak هست


تمرین:

یک برنامه ساده که از malloc استفاده میکنه داخل Ghidra یا IDA باز کنید بررسی کنید آیا برای همه مسیرهای اجرای برنامه در نهایت free صدا زده میشه یا نه اگر حتی یک مسیر پیدا کردید که حافظه آزاد نشه اولین Memory Leak خودتون رو پیدا کردید

@reverseengine

Part 22 Buffer Overflow

Memory Leak A bug that may not crash the program but causes problems

So far we have met with bugs that corrupt memory
But this section is about a bug that usually does not corrupt anything
Instead, it causes the program to gradually consume more memory
And after a while it slows down or even crashes

Memory Leak
Whenever a program allocates memory with malloc
It must later release it with free
If this is not done
That memory remains occupied until the end of the program execution
This is called a Memory Leak

A simple example:

C

#include <stdlib.h>

int main() {

char *buf = malloc(1024);

return 0;
}

What is the problem here?

Here, memory is allocated but never freed, meaning this instruction was not executed before the program exits

free(buf);

What if this happens once? Almost nothing special happens, but if it is inside a loop or a service that is always running, the memory consumption will gradually increase

For example:

C

while (1) {
char *buf = malloc(1024);
}

Each time 1024 bytes are taken but never freed. After a while, the program will consume a lot of memory

What should we look for when reverse engineering?

If you see this pattern

ptr = malloc(...);

Then follow the path of the function execution to the end

If there is no

free(ptr);

anywhere, there is a possibility of a Memory Leak

A more realistic example:

C

char *buf = malloc(256);

if(error)
return;

free(buf);

There is a problem here. If the error condition is met, the function exits before reaching free, as a result, the memory is never freed

Why is it harder to find?

Because the program usually does not crash, it does not show an obvious error, it may only be detected after a few hours or days of execution. That is why many memory leaks remain hidden for a long time. Tools that help to find memory leaks include: Valgrind AddressSanitizer LeakSanitizer These tools show which memory was taken but not freed Every malloc must have a free No free always means there is a possibility of a memory leak In reverse engineering, we must follow the malloc path to the end of the function Early exit from the function is one of the most common causes of memory leaks


Exercise:

Open a simple program that uses malloc in Ghidra or IDA Check whether free is called at the end for all paths of the program execution If you find even one path where the memory is not freed, you have found your first memory leak

@reverseengine

یکی از مهم‌ترین مباحث Heap اگر این بخش رو خوب یاد بگیرید فهمیدن تکنیک‌ های Heap Exploitation خیلی راحت‌ تر میشه


Memory Allocator
چیه و چجوری Heap رو مدیریت میکنه
در پست قبل گفتیم که Heap بخشی از حافظه است که برنامه موقع اجرا از اون استفاده میکنه اما یک سؤال پیش میاد؟

چه کسی تصمیم میگیره حافظه از کجا اختصاص داده بشه و بعد از آزاد شدن چه اتفاقی براش میوفته

جواب این سوال Memory Allocator هست

Memory Allocator
بخشی از سیستم یا کتابخانه استاندارد که وظیفه مدیریت حافظه Heap رو به عهده داره

هر بار که برنامه از توابعی مثل:

malloc()
calloc()
realloc()
free()

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

Allocator
تصمیم میگیره:

حافظه از کجا گرفته بشه
چه مقدار حافظه اختصاص داده بشه
حافظه آزاد شده دوباره چطور استفاده بشه
اگر حافظه کافی نبود چه کاری انجام بشه



هیپ یک فضای خالی بزرگه؟
جواب نه هست

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

هر بار که ()malloc صدا زده میشه معمولا یک Chunk به برنامه تحویل داده میشه

Chunk

کوچک‌ترین واحدی که Allocator مدیریت میکنه

هر Chunk دو قسمت اصلی داره:

Metadata
User Data

قسمت Metadata اطلاعات مدیریتی Chunk رو نگه میداره

مثلا:

اندازه Chunk
وضعیت آزاد یا اشغال بودن
اطلاعاتی که Allocator برای مدیریت حافظه نیاز داره

بعد از Metadata بخشی قرار داره که برنامه واقعا از اون استفاده کرده



چرا Metadata مهمه؟
چون Allocator برای تصمیم گیری به همین اطلاعات وابسته هست
اگر این اطلاعات به هر دلیلی خراب بشن Allocator ممکنه حافظه رو اشتباه مدیریت کنه به همین دلیل بیشتر آسیب‌ پذیری‌ های Heap در گذشته تلاش میکردن Metadata رو هدف قرار بدن
البته Allocator های امروزی نسبت به گذشته محافظت‌ های بیشتری دارن و سواستفاده از این ساختار ها سخت‌ تر شده


همه سیستم‌ها از یک Allocator استفاده میکنن؟ نه
هر سیستم‌ عامل یا حتی هر برنامه ممکنه از Allocator متفاوتی استفاده کنه

چند نمونه معروف:

ptmalloc (داخل لینوکس glibc)
jemalloc
tcmalloc
mimalloc

هر کدوم طراحی و روش مدیریت متفاوتی دارن اما هدف همه یکیه:

مدیریت سریع و بهینه حافظه Heap



چرا شناخت Allocator مهمه؟
وقتی درباره Heap Exploitation صحبت میکنیم فقط با خود Heap سر و کار نداریم
در واقع داریم رفتار Allocator رو بررسی میکنیم اگر ندونیم Allocator چجوری تصمیم میگیره حافظه رو اختصاص بده یا آزاد کنه درک باگ‌ های Heap هم سخت میشه

به همین دلیل قبل از یادگیری تکنیک‌ های Heap Exploitation باید با ساختار Allocator آشنا بشیم


Heap
توسط بخشی به نام Memory Allocator مدیریت میشه این بخش مسئول تخصیص آزاد سازی و استفاده مجدد از حافظه ست حافظه Heap به واحد هایی به نام Chunk تقسیم میشه و هر Chunk اطلاعات مدیریتی مخصوص خودش رو داره شناخت این ساختار پایه‌ ی یادگیری Heap Exploitation هست

@reverseengine

One of the most important topics of Heap is that if you learn this section well, it will be much easier to understand Heap Exploitation techniques

What is Memory Allocator and how does it manage Heap

In the previous post, we said that Heap is a part of memory that the program uses when it runs, but a question arises?

Who decides where to allocate memory and what happens to it after it is freed

The answer to this question is Memory Allocator

Memory Allocator

A part of the system or standard library that is responsible for managing Heap memory

Every time a program uses functions such as:

malloc()
calloc()
realloc()
free()

it actually sends its request to Allocator

Allocator

Decides:

Where to get memory

How much memory to allocate

How to reuse freed memory

What to do if there is not enough memory

Is the heap a large empty space?

The answer is no

Many people think that the Heap is just a big empty space that the program writes to wherever it wants. In fact, the Heap is made up of small parts called Chunks

Every time malloc() is called, a Chunk is usually handed over to the program

Chunk

The smallest unit that the Allocator manages

Each Chunk has two main parts:

Metadata

User Data

The Metadata part holds Chunk management information

For example:

Chunk size

Free or busy status

Information that the Allocator needs to manage memory

After the Metadata is the part that the program actually uses

Why is Metadata important?

Because the Allocator relies on this information to make decisions If this information is corrupted for any reason, the Allocator may mismanage memory, which is why most Heap vulnerabilities in the past tried to target Metadata
Of course, today's Allocators have more protections than in the past and it has become harder to abuse these structures

Do all systems use the same Allocator? No

Each operating system or even each program may use a different Allocator

A few famous examples:

ptmalloc (inside Linux glibc)
jemalloc
tcmalloc
mimalloc

Each has a different design and management method, but the goal is the same:

Fast and efficient management of Heap memory

Why is it important to understand Allocators?

When we talk about Heap Exploitation, we are not just dealing with the Heap itself. We are actually examining the behavior of the Allocator. If we do not know how the Allocator decides to allocate or free memory, it will be difficult to understand Heap bugs. That is why before learning Heap Exploitation techniques, we should familiarize ourselves with the Allocator structure. The Heap is managed by a part called the Memory Allocator. This part is responsible for allocating, freeing, and reusing memory.

The Heap memory set is divided into units called Chunks, and each Chunk has its own management information. Understanding this structure is the basis for learning Heap Exploitation.

@reverseengine

Opcode Encoding

چرا Opcode ها اینقدر عجیب به نظر میرسن؟

تا اینجا فرض کردیم Opcode ها خیلی ساده هستن

مثلا:

01 = LOAD
02 = ADD
03 = JMP

ولی توی ماشین‌های مجازی واقعی تقریبا هیچ‌ وقت اوضاع اینقدر ساده نیست
سازنده محافظ نمیخواد تحلیلگر با چند دقیقه نگاه کردن معنی Opcode ها رو بفهمه
به همین خاطر Opcode ها رو به شکل‌ های مختلف مخفی میکنه
مثلا ممکنه Opcode واقعی این باشه:

0x8F

ولی قبل از اجرا این عملیات روی اون انجام بشه:

Opcode ^= 0xA5

بعد از XOR شدن تازه مقدار واقعی به دست میاد
یا ممکنه Opcode اصلا مستقیم داخل بایت‌ کد ذخیره نشده باشه
مثلا قبل از استفاده از روی یک جدول ترجمه عبور کنه

0x3C  →  LOAD
0x91  →  ADD
0xE7  →  JMP

در این حالت اگر فقط به بایت‌کد نگاه کنید هیچ معنی خاصی نمیبینید
یکی دیگه از روش‌های رایج اینه که اندازه Opcode ها ثابت نباشه
مثلا:

Opcode
Operand
Operand

یا:

Opcode
Operand

یا حتی:

Opcode
Operand
Operand
Operand

یعنی هر Opcode تعداد متفاوتی Operand داره اگر تحلیلگر این موضوع رو متوجه نشه از همون دستور اول کل بایت‌ کد رو اشتباه تفسیر میکنه بعضی ماشین‌های مجازی حتی Opcode ها رو موقع اجرا تولید میکنن یعنی مقداری که Dispatcher میبینه همون مقداری نیست که داخل فایل ذخیره شده به همین خاطر یکی از اولین کارهای تحلیلگر اینه که مسیر رسیدن Opcode به Dispatcher رو دنبال کنه اگر قبل از Dispatcher عملیاتی مثل XOR، ADD، SUB یا چرخش بیت‌ ها انجام بشه احتمال زیادی وجود داره که Opcode ها رمزگذاری شده باشن هدف از Opcode Encoding فقط سخت‌تر کردن تحلیل نیست باعث میشه ابزارهایی مثل IDA یا Ghidra هم نتونن به‌ راحتی منطق ماشین مجازی رو تشخیص بدن به همین دلیل تحلیلگرها معمولا قبل از اینکه سراغ Handler ها برن سعی میکنن بفهمن Opcode ها دقیقا چطور Decode میشن اگر این مرحله رو درست انجام بدید ادامه فرایند Devirtualization خیلی ساده‌ تر میشه

تمرین:

فرض کنید بایت‌ کد زیر رو دارید:

8F 91 E7

و میدونید قبل از اجرا هر Opcode با 0xA5 عمل XOR میشه
اول مقدار واقعی هر Opcode رو حساب کنید
بعد فرض کنید نتیجه این جدول باشه:

2A = LOAD
34 = ADD
42 = PRINT

سعی کنید مسیر اجرای ماشین مجازی رو روی کاغذ باز سازی کنید

@reverseengine

Opcode Encoding

Why do Opcodes look so weird?

So far we have assumed that the Opcodes are very simple

For example:

01 = LOAD
02 = ADD
03 = JMP

But in real virtual machines things are almost never that simple
The manufacturer of the protection does not want the analyst to understand the meaning of the Opcodes by looking at them for a few minutes
That is why they hide the Opcodes in different ways

For example, the real Opcode may be:

0x8F

But before performing this operation on it:

Opcode ^= 0xA5

The real value is obtained only after XORing
Or the Opcode may not be stored directly in the bytecode at all
For example, it passes through a translation table before use

0x3C → LOAD
0x91 → ADD
0xE7 → JMP

In this case, if you only look at the bytecode, you will not see any special meaning
Another common method is to make the Opcodes not have a fixed size

For example:

Opcode
Operand
Operand

Or:

Opcode
Operand

Or Even:

Opcode
Operand
Operand
Operand

That is, each Opcode has a different number of Operands. If the analyst does not understand this, he will misinterpret the entire bytecode from the very first instruction. Some virtual machines even generate Opcodes at runtime, meaning that the value that the Dispatcher sees is not the same value that is stored in the file. Therefore, one of the first tasks of the analyst is to follow the path of the Opcode to the Dispatcher. If an operation such as XOR, ADD, SUB, or bit rotation is performed before the Dispatcher, there is a high probability that the Opcodes are encrypted. The purpose of Opcode Encoding is not just to make the analysis more difficult. It also makes tools such as IDA or Ghidra unable to easily recognize the logic of the virtual machine. Therefore, analysts usually try to understand exactly how the Opcodes are decoded before moving on to the Handlers. If you do this step correctly, the rest of the Devirtualization process will be much easier.

Exercise:

Suppose you have the following bytecode:

8F 91 E7

And you know that before Each Opcode can be XORed with 0xA5
First calculate the actual value of each Opcode
Then assume the result is this table:

2A = LOAD
34 = ADD
42 = PRINT

Try to reconstruct the path of the virtual machine execution on paper

@reverseengine

PCB (Process Control Block)
شناسنامه هر Process

تا اینجا یاد گرفتیم Process ساخته میشوه اجرا میشه و بین حالت‌ های مختلف جا به جا میشه

اما یک سؤال مهم:

سیستم‌عامل از کجا میفهه هر Process چه وضعیتی داره؟

مثلا از کجا میدونه:
الان در حال اجراست؟
چقدر حافظه گرفته؟
چند Thread داره؟
چه فایل‌هایی رو باز کرده؟
جواب همه این سؤال‌ها یک چیزه:

PCB (Process Control Block)

PCB
رو میتونیم مثل پرونده یا شناسنامه یک Process تصور کنیم
هر Process که ساخته میشه سیستم‌ عامل یک PCB هم برای اون ایجاد میکنه
داخل این ساختار تمام اطلاعات لازم برای مدیریت اون Process نگهداری میشه

داخل PCB چه اطلاعاتی وجود داره؟

شناسه پردازه (PID)

هر Process یک شماره منحصر به‌ فرد داره

مثلا:

Process A → PID = 1200
Process B → PID = 2456

سیستم‌ عامل از این شناسه برای تشخیص Process ها استفاده میکنه

وضعیت Process

همان State هایی که پست قبل یاد گرفتیم:

New
Ready
Running
Waiting
Terminated

وضعیت فعلی Process داخل PCB ذخیره میشه

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

برای همین اطلاعاتی مثل:

مقدار Register ها
Program Counter
Stack Pointer
داخل PCB ذخیره میشن

اطلاعات حافظه

سیستم‌عامل باید بدونه:

حافظه Process کجاست؟
Heap کجاست؟

Stack کجاست؟

Page Table
مربوط به این Process چیه؟

همه این اطلاعات داخل PCB ثبت میشن

اطلاعات فایل‌ ها
اگر Process چند فایل رو باز کرده باشه سیستم‌ عامل باید اونها رو مدیریت کنه

مثلا:

فایل متنی
سوکت شبکه
پرینتر
این اطلاعات هم در PCB نگهداری میشن

چرا PCB مهمه؟

فرض کنید CPU در حال اجرای Chrome هست
یهو سیستم‌ عامل تصمیم میگیره به Telegram زمان اجرا بده
قبل از این جا به‌ جایی باید وضعیت Chrome ذخیره بشه تا بعدا دقیقا از همون نقطه ادامه بده

این اطلاعات داخل PCB ذخیره میشن
به این کار Context Switch میگن

یک مثال ساده:

فرض کنید داری یک بازی انجام میدید
اگر بازی رو Pause کنید انتظار دارید بعد از Resume دقیقا از همون لحظه ادامه پیدا کنه

سیستم‌ عامل هم برای Process ها همین کار رو انجام میده
قبل از اینکه اجرای یک Process متوقف بشه وضعیت اون رو داخل PCB ذخیره میکنه تا بعدا بدون مشکل ادامه پیدا کنه

چرا برای مهندسی معکوس مهمه؟

در مهندسی معکوس شاید مستقیما با PCB کار نکنید اما بسیاری از مفاهیم مهم به اون وابسته ان:

Context Switch
Process Scheduling
Thread Management
Kernel Debugging
Windows Internals

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


هر Process یک PCB داره که مثل شناسنامه اون عمل میکنه

داخل PCB اطلاعاتی مثل:
PID
وضعیت Process
Register ها
اطلاعات حافظه
فایل‌های باز
اطلاعات زمان‌بندی
ذخیره میشن

بدون PCB سیستم‌ عامل نمیتونه Process ها رو مدیریت کنه

@reverseengine

PCB (Process Control Block) The ID of Each Process

So far we have learned that a Process is created, executed, and switched between different states

But an important question:

How does the operating system know what state each Process is in?

For example, how does it know:

Is it currently running?
How much memory does it take?
How many threads does it have?
What files has it opened?
The answer to all these questions is the same:

PCB (Process Control Block)

We can imagine the PCB as a file or ID of a Process.
For each Process that is created, the operating system also creates a PCB for it.
Inside this structure, all the information necessary to manage that Process is stored.

What information is inside the PCB?

Process ID (PID)

Each process has a unique number

For example:

Process A → PID = 1200
Process B → PID = 2456

The operating system uses this ID to identify processes

Process State

Same states as we learned in the previous post:

New
Ready
Running
Waiting
Terminated

The current state of the process is stored in the PCB

CPU Information
When the operating system stops executing a process, it needs to know where to continue next

For this reason, information such as:

Register values

Program Counter

Stack Pointer
are stored in the PCB

Memory Information

The operating system needs to know:

Where is the process memory?

Where is the heap?

Where is the stack?

Page Table
What is related to this process?

All this information is recorded in the PCB

File information
If a Process has opened several files, the operating system must manage them

For example:

Text file
Network socket
Printer
This information is also stored in the PCB

Why is the PCB important?

Suppose the CPU is running Chrome
An operating system decides to give Telegram time to run
Before this, the state of Chrome must be saved somewhere so that it can continue exactly from the same point later

This information is stored in the PCB
This is called Context Switch

A simple example:

Suppose you are playing a game
If you pause the game, you expect it to continue exactly from that moment after Resume

The operating system does the same for Processes
Before a Process is stopped, it saves its state in the PCB so that it can continue later without any problems

Why is it important for reverse engineering?

In reverse engineering, you may not work directly with the PCB, but many important concepts depend on it:

Context Switch
Process Scheduling
Thread Management
Kernel Debugging
Windows Internals

If you know what information the operating system keeps about each process, analyzing the behavior of programs will be much easier for you

Each process has a PCB that acts as its identity card

Inside the PCB, information such as:

PID
Process status
Registers
Memory information
Open files
Scheduling information

Without the PCB, the operating system cannot manage processes

@reverseengine

Celebrating our 2025 open-source contributions

https://blog.trailofbits.com/2026/01/30/celebrating-our-2025-open-source-contributions

@reverseengine

Binary type inference in Ghidra

https://blog.trailofbits.com/2024/02/07/binary-type-inference-in-ghidra

@reverseengine