System Call
برنامه چجور با Kernel حرف میزنه؟
تا اینجا با چیزهایی مثل:
lua
fork()
exec()
wait()
exit()
کار کردیم
اما یک سوال مهم وجود داره
این توابع چطور میتونن از Kernel درخواست انجام یک کار بکنن؟
مثلا برنامهای که داخل User Space اجرا میشه چطور میتونه:
فایل باز کنه؟
داده بخوانه؟
Process
جدید بسازه؟
حافظه بگیره؟
Process
خودش رو تموم کنه؟
جواب اصلی:
System Call
User Mode و Kernel Mode
CPU
معمولا اجرای برنامه رو در سطح دسترسی محدودی انجام میدهد که به اون:
User Mode
میگیم
برنامه در این حالت نمیتونه مستقیما هر کاری که دلش خواست با سیستم انجام بده
مثلا نمیتونه مستقیما:
Hardware
Kernel Memory
Page Tables
Device Control
رو دستکاری کنه
چون اگر هر برنامهای چنین دسترسیای داشت یک برنامه خرابکار میتونست کل سیستم رو به فنا بده😁
و ادم ها قبلا به اندازه کافی راه های دیگه ای برای این کار پیدا کردن
Kernel Mode
Kernel
در سطح دسترسی بالاتری اجرا میشه:
Kernel Mode
در این حالت Kernel میتونه به منابع حساس سیستم دسترسی داشته باشه
پس ساختار کلی تقریبا این شکلیه:
User Space
│
│ System Call
↓
Kernel Space
│
↓
Hardware / Resources
برنامه مستقیم وارد Kernel نمیشه
بلکه از یک دروازه کنترل شده استفاده میکنه این دروازه همون System Call هست
یک مثال ساده
فرض کنیم برنامه میخاد از یک فایل بخونه
در سطح برنامه ممکنه چیزی شبیه این داشته باشیم:
read(fd, buffer, size);
برنامه درخواست میکنه:
من میخاهم از این File Descriptor
به اندازه مشخصی داده بخونم
در اخر درخواست باید به Kernel برسه
Kernel
بررسی میکنه:
این Process چه کسیه؟
اجازه دسترسی داره؟
fd
معتبره؟
آدرس buffer معتبره؟
چه مقدار داده باید خونده بشه؟
بعد عملیات رو انجام میده و نتیجه رو برمیگردونه
مسیر کلی System Call
به شکل ساده:
Program
│
↓
Library / API Wrapper
│
↓
System Call Mechanism
│
↓
CPU → Kernel Mode
│
↓
Kernel
│
↓
Operation
│
↓
Return Value
│
↓
User Mode
یعنی برنامه برای انجام عملیات حساس از یک مسیر مشخص وارد Kernel میشه
System Call با Function Call
یکی نیست
این دو تا رو قاطی نکنیم
یک Function Call معمولی مثلا:
result = add(a, b);
معمولا در همون فضای اجرای برنامه انجام میشه
اما System Call یک عبور از مرز دسترسی User و Kernel ایجاد میکنه
پس:
Function Call
↓
همون فضای اجرا
System Call
↓
User Mode
↓
Kernel Mode
↓
برگشت به User Mode
این تفاوت در Reverse Engineering خیلی مهمه
هم از همین مسیر استفاده میکنن
مثلا در برنامه C مینویسیم:
fork();
اما این به معنی یک Function ساده مثل:
C
int add(int a, int b)
نیست
در سیستمهای Unix-like این درخواست در اخر باید به Kernel برسه تا Kernel بتونه Process جدید ایجاد کنه
همین ایده برای عملیات هایی مثل:
shell
read
write
open
mmap
fork
exec
wait
هم وجود داره
البته یک نکته مهم
چیزی که در کد میبینیم لزوما خود System Call خام نیست ممکنه یک Library Wrapper باشه که در اخر System Call مناسب رو انجام میده
System Call
چطور به Kernel میرسه؟
در معماریهای مدرن CPU مکانیزم مخصوصی برای این انتقال داره
مثلا در x86-64 لینوکس دستور:
syscall
برای ورود به مسیر System Call استفاده میشه
به صورت مفهومی:
User Code
↓
Arguments آماده میشن
↓
System Call Number
↓
syscall
↓
CPU
↓
Kernel Entry
↓
Kernel Handler
Kernel
بعد از ورود درخواست رو بررسی و پردازش میکنه
برای ما چرا مهمه؟
فرض کنید داخل یک Binary این رو ببینید:
syscall
دیگه فقط با یک دستور اسمبلی معمولی طرف نیستید
این دستور میتونه نشون دهنده عبور برنامه از:
User Space
↓
Kernel Space
باشه
از طرف دیگه اگر داخل کد برنامه API هایی مثل:
CreateFile
ReadFile
VirtualAlloc
CreateProcess
رو ببینید باید بدونید این API ها در اخر برای انجام تعداد زیادی از عملیات های سیستمی به مکانیزمهای Kernel وابسته هستن پس در RE باید بتونید این زنجیره رو در ذهنتون ببینید:
Application
↓
Library / API
↓
System Call
↓
Kernel
↓
Resource / Hardware
این دیدگاه بعدا هنگام تحلیل Process ها Memory File System Thread ها و حتی رفتارهای پیچیدهتر Binary ها خیلی به کارتون میاد
برنامه چجور با Kernel حرف میزنه؟
تا اینجا با چیزهایی مثل:
lua
fork()
exec()
wait()
exit()
کار کردیم
اما یک سوال مهم وجود داره
این توابع چطور میتونن از Kernel درخواست انجام یک کار بکنن؟
مثلا برنامهای که داخل User Space اجرا میشه چطور میتونه:
فایل باز کنه؟
داده بخوانه؟
Process
جدید بسازه؟
حافظه بگیره؟
Process
خودش رو تموم کنه؟
جواب اصلی:
System Call
User Mode و Kernel Mode
CPU
معمولا اجرای برنامه رو در سطح دسترسی محدودی انجام میدهد که به اون:
User Mode
میگیم
برنامه در این حالت نمیتونه مستقیما هر کاری که دلش خواست با سیستم انجام بده
مثلا نمیتونه مستقیما:
Hardware
Kernel Memory
Page Tables
Device Control
رو دستکاری کنه
چون اگر هر برنامهای چنین دسترسیای داشت یک برنامه خرابکار میتونست کل سیستم رو به فنا بده😁
و ادم ها قبلا به اندازه کافی راه های دیگه ای برای این کار پیدا کردن
Kernel Mode
Kernel
در سطح دسترسی بالاتری اجرا میشه:
Kernel Mode
در این حالت Kernel میتونه به منابع حساس سیستم دسترسی داشته باشه
پس ساختار کلی تقریبا این شکلیه:
User Space
│
│ System Call
↓
Kernel Space
│
↓
Hardware / Resources
برنامه مستقیم وارد Kernel نمیشه
بلکه از یک دروازه کنترل شده استفاده میکنه این دروازه همون System Call هست
یک مثال ساده
فرض کنیم برنامه میخاد از یک فایل بخونه
در سطح برنامه ممکنه چیزی شبیه این داشته باشیم:
read(fd, buffer, size);
برنامه درخواست میکنه:
من میخاهم از این File Descriptor
به اندازه مشخصی داده بخونم
در اخر درخواست باید به Kernel برسه
Kernel
بررسی میکنه:
این Process چه کسیه؟
اجازه دسترسی داره؟
fd
معتبره؟
آدرس buffer معتبره؟
چه مقدار داده باید خونده بشه؟
بعد عملیات رو انجام میده و نتیجه رو برمیگردونه
مسیر کلی System Call
به شکل ساده:
Program
│
↓
Library / API Wrapper
│
↓
System Call Mechanism
│
↓
CPU → Kernel Mode
│
↓
Kernel
│
↓
Operation
│
↓
Return Value
│
↓
User Mode
یعنی برنامه برای انجام عملیات حساس از یک مسیر مشخص وارد Kernel میشه
System Call با Function Call
یکی نیست
این دو تا رو قاطی نکنیم
یک Function Call معمولی مثلا:
result = add(a, b);
معمولا در همون فضای اجرای برنامه انجام میشه
اما System Call یک عبور از مرز دسترسی User و Kernel ایجاد میکنه
پس:
Function Call
↓
همون فضای اجرا
System Call
↓
User Mode
↓
Kernel Mode
↓
برگشت به User Mode
این تفاوت در Reverse Engineering خیلی مهمه
fork() و wait() هم از همین مسیر استفاده میکنن
مثلا در برنامه C مینویسیم:
fork();
اما این به معنی یک Function ساده مثل:
C
int add(int a, int b)
نیست
در سیستمهای Unix-like این درخواست در اخر باید به Kernel برسه تا Kernel بتونه Process جدید ایجاد کنه
همین ایده برای عملیات هایی مثل:
shell
read
write
open
mmap
fork
exec
wait
هم وجود داره
البته یک نکته مهم
چیزی که در کد میبینیم لزوما خود System Call خام نیست ممکنه یک Library Wrapper باشه که در اخر System Call مناسب رو انجام میده
System Call
چطور به Kernel میرسه؟
در معماریهای مدرن CPU مکانیزم مخصوصی برای این انتقال داره
مثلا در x86-64 لینوکس دستور:
syscall
برای ورود به مسیر System Call استفاده میشه
به صورت مفهومی:
User Code
↓
Arguments آماده میشن
↓
System Call Number
↓
syscall
↓
CPU
↓
Kernel Entry
↓
Kernel Handler
Kernel
بعد از ورود درخواست رو بررسی و پردازش میکنه
برای ما چرا مهمه؟
فرض کنید داخل یک Binary این رو ببینید:
syscall
دیگه فقط با یک دستور اسمبلی معمولی طرف نیستید
این دستور میتونه نشون دهنده عبور برنامه از:
User Space
↓
Kernel Space
باشه
از طرف دیگه اگر داخل کد برنامه API هایی مثل:
CreateFile
ReadFile
VirtualAlloc
CreateProcess
`رو ببینید باید بدونید این API ها در اخر برای انجام تعداد زیادی از عملیات های سیستمی به مکانیزمهای Kernel وابسته هستن پس در RE باید بتونید این زنجیره رو در ذهنتون ببینید:
Application
↓
Library / API
↓
System Call
↓
Kernel
↓
Resource / Hardware
این دیدگاه بعدا هنگام تحلیل Process ها Memory File System Thread ها و حتی رفتارهای پیچیدهتر Binary ها خیلی به کارتون میاد
System Call
رابط کنترلشده ای که یک برنامه در User Mode از طریق اون درخواست هایی رو از Kernel میخاد
مهمترین نکته:
User Mode
│
│ System Call
↓
Kernel Mode
│
↓
Kernel performs operation
│
↓
User Mode
و این دقیقا یکی از پایه های مهم درک OS Internals و Reverse Engineering هست
@reverseengine
رابط کنترلشده ای که یک برنامه در User Mode از طریق اون درخواست هایی رو از Kernel میخاد
مهمترین نکته:
User Mode
│
│ System Call
↓
Kernel Mode
│
↓
Kernel performs operation
│
↓
User Mode
و این دقیقا یکی از پایه های مهم درک OS Internals و Reverse Engineering هست
@reverseengine
ReverseEngineering
System Call برنامه چجور با Kernel حرف میزنه؟ تا اینجا با چیزهایی مثل: lua fork() exec() wait() exit() کار کردیم اما یک سوال مهم وجود داره این توابع چطور میتونن از Kernel درخواست انجام یک کار بکنن؟ مثلا برنامهای که داخل User Space اجرا میشه چطور میتونه:…
System Call
How does a program talk to the Kernel?
So far we have worked with things like:
lua
fork()
exec()
wait()
exit()
But there is an important question
How can these functions request the Kernel to do something?
For example, how can a program running in User Space:
Open a file?
Read data?
Create a new process?
Get memory?
Process
terminate itself?
Original answer:
System Call
User Mode and Kernel Mode
The CPU
usually executes the program at a limited access level, which we call:
User Mode
The program in this mode cannot directly do anything it wants with the system
For example, it cannot directly manipulate:
Hardware
Kernel Memory
Page Tables
Device Control
Because if any program had such access, a malicious program could destroy the entire system😁
And people have already found enough other ways to do this
Kernel Mode
The Kernel is executed at a higher access level:
Kernel Mode
In this mode, the Kernel can access sensitive system resources
So the overall structure is approximately as follows:
User Space
│
│ System Call
↓
Kernel Space
│
↓
Hardware / Resources
The program does not enter the Kernel directly
But uses a controlled gateway, this gateway is the System Call
A simple example
Suppose the program wants to Read a file
At the program level we might have something like this:
read(fd, buffer, size);
The program requests:
I want to read a certain amount of data from this File Descriptor
At the end of the request, it should reach the Kernel
The Kernel checks:
Who is this Process?
Does it have access?
Is the fd
valid?
Is the buffer address valid?
How much data should be read?
Then it performs the operation and returns the result
General System Call Path
In simple terms:
Program
│
↓
Library / API Wrapper
│
↓
System Call Mechanism
│
↓
CPU → Kernel Mode
│
↓
Kernel
│
↓
Operation
│
↓
Return Value
│
↓
User Mode
That is, the program enters the Kernel from a specific path to perform sensitive operations
System Call is not the same as Function Call
Let's not confuse the two
A normal Function Call, for example:
result = add(a, b);
Usually it is done in the same execution space of the program
But System Call creates a crossing of the User and Kernel access boundaries
So:
Function Call
↓
Same execution space
System Call
↓
User Mode
↓
Kernel Mode
↓
Return to User Mode
This difference is very important in Reverse Engineering
Fork() and wait()
also use the same path
For example, in a C program we write:
fork();
But this does not mean a simple Function like:
C
int add(int a, int b)
In Unix-like systems this request must finally reach the Kernel so that the Kernel can create a new Process
The same idea exists for operations like:
shell
read
write
open
mmap
fork
exec
wait
Of course, one important point
What we see in the code is not necessarily the raw System Call itself, it may be a Library Wrapper that finally performs the appropriate System Call
How does System Call
reach the Kernel?
In modern architectures, the CPU has a special mechanism for this transfer. For example, in x86-64 Linux, the command:
syscall
is used to enter the System Call path. Conceptually:
User Code
↓
Arguments are prepared
↓
System Call Number
↓
syscall
↓
CPU
↓
Kernel Entry
↓
Kernel Handler
The Kernel
checks and processes the request after it has entered.
Why is it important to us?
Suppose you see this inside a Binary:
syscall
You are no longer dealing with just a regular assembly instruction
This instruction can indicate that the program passes through:
User Space
↓
Kernel Space
On the other hand, if you see APIs like:
CreateFile
ReadFile
VirtualAlloc
CreateProcess
in the program code, you should know that these APIs ultimately depend on Kernel mechanisms to perform a large number of system operations, so in RE you should be able to see this chain in your mind:
Application
↓
Library / API
↓
System Call
↓
Kernel
↓
Resource / Hardware
This perspective will come in handy later when analyzing Processes, Memory, File System, Threads, and even more complex behavior of Binary.
How does a program talk to the Kernel?
So far we have worked with things like:
lua
fork()
exec()
wait()
exit()
But there is an important question
How can these functions request the Kernel to do something?
For example, how can a program running in User Space:
Open a file?
Read data?
Create a new process?
Get memory?
Process
terminate itself?
Original answer:
System Call
User Mode and Kernel Mode
The CPU
usually executes the program at a limited access level, which we call:
User Mode
The program in this mode cannot directly do anything it wants with the system
For example, it cannot directly manipulate:
Hardware
Kernel Memory
Page Tables
Device Control
Because if any program had such access, a malicious program could destroy the entire system😁
And people have already found enough other ways to do this
Kernel Mode
The Kernel is executed at a higher access level:
Kernel Mode
In this mode, the Kernel can access sensitive system resources
So the overall structure is approximately as follows:
User Space
│
│ System Call
↓
Kernel Space
│
↓
Hardware / Resources
The program does not enter the Kernel directly
But uses a controlled gateway, this gateway is the System Call
A simple example
Suppose the program wants to Read a file
At the program level we might have something like this:
read(fd, buffer, size);
The program requests:
I want to read a certain amount of data from this File Descriptor
At the end of the request, it should reach the Kernel
The Kernel checks:
Who is this Process?
Does it have access?
Is the fd
valid?
Is the buffer address valid?
How much data should be read?
Then it performs the operation and returns the result
General System Call Path
In simple terms:
Program
│
↓
Library / API Wrapper
│
↓
System Call Mechanism
│
↓
CPU → Kernel Mode
│
↓
Kernel
│
↓
Operation
│
↓
Return Value
│
↓
User Mode
That is, the program enters the Kernel from a specific path to perform sensitive operations
System Call is not the same as Function Call
Let's not confuse the two
A normal Function Call, for example:
result = add(a, b);
Usually it is done in the same execution space of the program
But System Call creates a crossing of the User and Kernel access boundaries
So:
Function Call
↓
Same execution space
System Call
↓
User Mode
↓
Kernel Mode
↓
Return to User Mode
This difference is very important in Reverse Engineering
Fork() and wait()
also use the same path
For example, in a C program we write:
fork();
But this does not mean a simple Function like:
C
int add(int a, int b)
In Unix-like systems this request must finally reach the Kernel so that the Kernel can create a new Process
The same idea exists for operations like:
shell
read
write
open
mmap
fork
exec
wait
Of course, one important point
What we see in the code is not necessarily the raw System Call itself, it may be a Library Wrapper that finally performs the appropriate System Call
How does System Call
reach the Kernel?
In modern architectures, the CPU has a special mechanism for this transfer. For example, in x86-64 Linux, the command:
syscall
is used to enter the System Call path. Conceptually:
User Code
↓
Arguments are prepared
↓
System Call Number
↓
syscall
↓
CPU
↓
Kernel Entry
↓
Kernel Handler
The Kernel
checks and processes the request after it has entered.
Why is it important to us?
Suppose you see this inside a Binary:
syscall
You are no longer dealing with just a regular assembly instruction
This instruction can indicate that the program passes through:
User Space
↓
Kernel Space
On the other hand, if you see APIs like:
CreateFile
ReadFile
VirtualAlloc
CreateProcess
in the program code, you should know that these APIs ultimately depend on Kernel mechanisms to perform a large number of system operations, so in RE you should be able to see this chain in your mind:
Application
↓
Library / API
↓
System Call
↓
Kernel
↓
Resource / Hardware
This perspective will come in handy later when analyzing Processes, Memory, File System, Threads, and even more complex behavior of Binary.
👍1
System Call A controlled interface through which a program in User Mode makes requests to the Kernel
The most important point:
User Mode
│
│ System Call
↓
Kernel Mode
│
↓
Kernel performs operation
│
↓
User Mode
And this is exactly one of the important foundations of understanding OS Internals and Reverse Engineering
@reverseengine
The most important point:
User Mode
│
│ System Call
↓
Kernel Mode
│
↓
Kernel performs operation
│
↓
User Mode
And this is exactly one of the important foundations of understanding OS Internals and Reverse Engineering
@reverseengine
SELECT * FROM binary - Vibe Reverse Engineering with IDA, Ghidra and Binary Ninja
https://youtu.be/ADPoD7-_K5s?si=HCgt4gVmbkw5S05i
https://youtu.be/ADPoD7-_K5s?si=HCgt4gVmbkw5S05i
YouTube
RECON 2026 - SELECT * FROM binary — Vibe Reversing Across IDA, Ghidra, and Binary Ninja
Presented by Elias Bachaalany
"Vibe coding" lets developers build software by describing intent to an AI agent. Can the same approach work for reverse engineering - where the analyst describes what they want to understand and the agent drives the tools?…
"Vibe coding" lets developers build software by describing intent to an AI agent. Can the same approach work for reverse engineering - where the analyst describes what they want to understand and the agent drives the tools?…
Fileless ELF Execution via Kernel Keyring
Using the Linux kernel keyring to stage an ELF in slab memory and execute it via userland exec, skipping execve and the filesystem entirely.
https://matheuzsecurity.github.io/hacking/linux-kernel-keyring-fileless-exec/
Using the Linux kernel keyring to stage an ELF in slab memory and execute it via userland exec, skipping execve and the filesystem entirely.
https://matheuzsecurity.github.io/hacking/linux-kernel-keyring-fileless-exec/
matheuzsecurity.github.io
Fileless ELF Execution via Kernel Keyring · 0xMatheuZ
Using the Linux kernel keyring to stage an ELF in slab memory and execute it via userland exec, skipping execve and the filesystem entirely.
Dragon Power Against VMProtect
https://farena.in/dragon-tales-web/posts/dragon-power-against-vmprotect/
https://farena.in/dragon-tales-web/posts/dragon-power-against-vmprotect/
farena.in
Dragon Power Against VMProtect · dragon-tales
Reverse-engineering, naming and devirtualizing a VMProtect x64 virtual machine with dragon-tales: all 256 handlers in four views, the virtual CFG recovered from the file alone with no trace, the last MBA cleaned, and the function recompiled to an executable…
_writing_a_c_compiler_build_a_real_programming_language_from_scratch.pdf
7.2 MB
Writing a C compiler
Defeating Anti-Reverse Engineering: A Deep Dive into the 'Trouble' Binary
https://binary.ninja/2026/01/23/reversing-linux-anti-re.html
@reverseengine
https://binary.ninja/2026/01/23/reversing-linux-anti-re.html
@reverseengine
Binary Ninja
Binary Ninja - Defeating Anti-Reverse Engineering: A Deep Dive into the 'Trouble' Binary
Binary Ninja is a modern reverse engineering platform with a scriptable and extensible decompiler.
Bringing Metal to a crypto backdoor fight! Exploiting the GPU and the 90s crypto wars to crack the APT Down code signing keys
https://reverse.put.as/2025/08/24/rc4bruteforce
@reverseengine
https://reverse.put.as/2025/08/24/rc4bruteforce
@reverseengine
Reverse Engineering
Bringing Metal to a crypto backdoor fight! Exploiting the GPU and the 90s crypto wars to crack the APT Down code signing keys
The APT Down leak contained four code signing certificates and the passphrase only for the most recent one. Since the passphrase was found on the usual rockyou.txt wordlist, I was curious to see if the remaining three could be cracked using the same wordlist.…
Trap
و ورود از User Mode به Kernel Mode
تا اینجا فهمیدیم برنامه ها توی User Mode اجرا میشن و وقتی بخوان از سیستم عامل یه کار حساس بخوان از System Call استفاده میکنن
ولی یه سوال مهم داریم
CPU
دقیقا چطوری از اجرای عادی برنامه توی User Mode میره داخل Kernel Mode
اینجا مفهوم Trap وارد ماجرا میشه
Trap
یعنی یه انتقال کنترل شده از اجرای عادی برنامه به Kernel یعنی برنامه داره توی User Mode اجرا میشه
User Mode
│
│ درخواست سرویس
▼
Trap
│
▼
Kernel Mode
بعد از اینکه Kernel کارش رو انجام داد کنترل دوباره به برنامه برمیگرده
System Call و Trap
چه فرقی دارن
این دوتا یکی نیستن
System Call
در واقع درخواست برنامه از سیستم عامله
مثلا برنامه میگه من میخوام از فایل بخونم
یا چیزی بنویسم
یا حافظه بگیرم
مثل:
read()
write()
mmap()
اما Trap مکانیزمیه که باعث میشه CPU کنترل اجرا رو به Kernel منتقل کنه
پس خیلی ساده
Program
│
│ System Call
▼
Trap / System call entry
│
▼
Kernel
یعنی System Call میگه چه سرویسی میخوام
Trap
یا مسیر ورود باعث میشه اجرای برنامه وارد Kernel بشه
مثال x86 64:
توی Linux روی معماری x86 64 معمولا System Call با دستور
syscall
انجام میشه
قبل از اجرای این دستور برنامه اطلاعات لازم رو داخل Register های مشخص قرار میده
مفهوم:
Registers
│
├── شماره System Call
├── Argument 1
├── Argument 2
└──
│
▼
syscall
│
▼
Kernel
Kernel
وقتی وارد میشه شماره System Call رو بررسی میکنه تا بفهمه برنامه دقیقا چه درخواستی داشته
مثلا برنامه ممکنه درخواست خوندن اطلاعات از یه فایل رو داشته باشه
پس Kernel باید بفهمه این درخواست مربوط به کدوم System Call هست
Kernel
از کجا میفهمه چه System Call ای درخواست شده
اینجا یکی از چیزهای مهم System Call Number هست
هر System Call توی Linux یه شماره مشخص داره
البته این شماره ها به معماری و ABI وابسته هستن
یعنی نباید فکر کنیم شماره یه System Call روی همه سیستم ها یکیه
به صورت مفهومی:
System Call Number
+
Arguments
│
▼
syscall
│
▼
Kernel
Kernel
با استفاده از این اطلاعات مسیر مربوط به اون درخواست رو پیدا میکنه
Kernel
هنگام ورود چه کار میکنه
وقتی CPU وارد Kernel میشه Kernel باید درخواست برنامه رو بررسی کنه
به صورت ساده
User Code
│
▼
syscall
│
▼
Kernel Entry
│
▼
بررسی درخواست
│
▼
اجرای عملیات
│
▼
Return Value
│
▼
User Mode
Kernel
ممکنه چیزهایی مثل مجوز دسترسی و معتبر بودن بعضی اطلاعات رو بررسی کنه
مثلاً برنامه User Space نباید بتونه هر آدرس حافظه ای که دلش خواست رو بدون کنترل دستکاری کنه
سیستم عامل اینجا نقش یک مراقب رو بازی میکنه چون اگر هر برنامه ای میتونست هر کاری با منابع سیستم بکنه عملا سیستم عامل تبدیل میشد به چیزی که کاربردی نداره
Trap
فقط برای System Call نیست
اینجا یه نکته مهم داریم
وقتی میگیم Trap نباید فکر کنیم فقط برای System Call استفاده میشه
در سیستم عامل و معماری CPU انتقال کنترل به Kernel میتونه به دلایل مختلف اتفاق بیفته
مثلا:
System Call
Exception
بعضی رویدادهای سخت افزاری از مسیر Interrupt البته این مفاهیم دقیقا یکی نیستن و باید جدا از هم بررسی بشن
Exception چیه
Exception
وقتی اتفاق میفته که CPU موقع اجرای یه دستور با یه شرایط خاص روبرو بشه
مثلا:
برنامه
│
▼
اجرای دستور
│
▼
شرایط خاص
│
▼
Exception
│
▼
Kernel Handler
یکی از مثال های معروفش
Page Fault
فرض کنید برنامه به یه صفحه حافظه دسترسی پیدا کنه ولی اون صفحه در اون لحظه شرایط لازم برای دسترسی رو نداشته باشه
CPU
یه Page Fault ایجاد میکنه
بعد Kernel وارد ماجرا میشه و بررسی میکنه باید چه کاری انجام بشه
یه نکته مهم:
Page Fault
لزوما به معنی Crash نیست
ممکنه سیستم عامل بتونه اون رو کاملا عادی مدیریت کنه
مثلا صفحه موردنظر رو آماده کنه و برنامه دوباره ادامه بده
Interrupt
معمولا از طرف سخت افزار یا کنترل کننده سخت افزار ایجاد میشه مثلا یه دستگاه میخواد CPU رو از یه اتفاق باخبر کنه
به صورت ساده:
Hardware
│
▼
Interrupt
│
▼
CPU
│
▼
Kernel
مثلا یه عملیات I O تموم شده
سخت افزار میتونه با Interrupt به CPU خبر بده که عملیات تموم شده
بعد Kernel میتونه این اتفاق رو مدیریت کنه
تفاوت این سه مفهوم:
System Call
درخواست برنامه برای گرفتن یه سرویس از سیستم عامل
Exception
اتفاقی که در نتیجه اجرای دستور یا شرایط مربوط به CPU رخ میده
و ورود از User Mode به Kernel Mode
تا اینجا فهمیدیم برنامه ها توی User Mode اجرا میشن و وقتی بخوان از سیستم عامل یه کار حساس بخوان از System Call استفاده میکنن
ولی یه سوال مهم داریم
CPU
دقیقا چطوری از اجرای عادی برنامه توی User Mode میره داخل Kernel Mode
اینجا مفهوم Trap وارد ماجرا میشه
Trap
یعنی یه انتقال کنترل شده از اجرای عادی برنامه به Kernel یعنی برنامه داره توی User Mode اجرا میشه
User Mode
│
│ درخواست سرویس
▼
Trap
│
▼
Kernel Mode
بعد از اینکه Kernel کارش رو انجام داد کنترل دوباره به برنامه برمیگرده
System Call و Trap
چه فرقی دارن
این دوتا یکی نیستن
System Call
در واقع درخواست برنامه از سیستم عامله
مثلا برنامه میگه من میخوام از فایل بخونم
یا چیزی بنویسم
یا حافظه بگیرم
مثل:
read()
write()
mmap()
اما Trap مکانیزمیه که باعث میشه CPU کنترل اجرا رو به Kernel منتقل کنه
پس خیلی ساده
Program
│
│ System Call
▼
Trap / System call entry
│
▼
Kernel
یعنی System Call میگه چه سرویسی میخوام
Trap
یا مسیر ورود باعث میشه اجرای برنامه وارد Kernel بشه
مثال x86 64:
توی Linux روی معماری x86 64 معمولا System Call با دستور
syscall
انجام میشه
قبل از اجرای این دستور برنامه اطلاعات لازم رو داخل Register های مشخص قرار میده
مفهوم:
Registers
│
├── شماره System Call
├── Argument 1
├── Argument 2
└──
│
▼
syscall
│
▼
Kernel
Kernel
وقتی وارد میشه شماره System Call رو بررسی میکنه تا بفهمه برنامه دقیقا چه درخواستی داشته
مثلا برنامه ممکنه درخواست خوندن اطلاعات از یه فایل رو داشته باشه
پس Kernel باید بفهمه این درخواست مربوط به کدوم System Call هست
Kernel
از کجا میفهمه چه System Call ای درخواست شده
اینجا یکی از چیزهای مهم System Call Number هست
هر System Call توی Linux یه شماره مشخص داره
البته این شماره ها به معماری و ABI وابسته هستن
یعنی نباید فکر کنیم شماره یه System Call روی همه سیستم ها یکیه
به صورت مفهومی:
System Call Number
+
Arguments
│
▼
syscall
│
▼
Kernel
Kernel
با استفاده از این اطلاعات مسیر مربوط به اون درخواست رو پیدا میکنه
Kernel
هنگام ورود چه کار میکنه
وقتی CPU وارد Kernel میشه Kernel باید درخواست برنامه رو بررسی کنه
به صورت ساده
User Code
│
▼
syscall
│
▼
Kernel Entry
│
▼
بررسی درخواست
│
▼
اجرای عملیات
│
▼
Return Value
│
▼
User Mode
Kernel
ممکنه چیزهایی مثل مجوز دسترسی و معتبر بودن بعضی اطلاعات رو بررسی کنه
مثلاً برنامه User Space نباید بتونه هر آدرس حافظه ای که دلش خواست رو بدون کنترل دستکاری کنه
سیستم عامل اینجا نقش یک مراقب رو بازی میکنه چون اگر هر برنامه ای میتونست هر کاری با منابع سیستم بکنه عملا سیستم عامل تبدیل میشد به چیزی که کاربردی نداره
Trap
فقط برای System Call نیست
اینجا یه نکته مهم داریم
وقتی میگیم Trap نباید فکر کنیم فقط برای System Call استفاده میشه
در سیستم عامل و معماری CPU انتقال کنترل به Kernel میتونه به دلایل مختلف اتفاق بیفته
مثلا:
System Call
Exception
بعضی رویدادهای سخت افزاری از مسیر Interrupt البته این مفاهیم دقیقا یکی نیستن و باید جدا از هم بررسی بشن
Exception چیه
Exception
وقتی اتفاق میفته که CPU موقع اجرای یه دستور با یه شرایط خاص روبرو بشه
مثلا:
برنامه
│
▼
اجرای دستور
│
▼
شرایط خاص
│
▼
Exception
│
▼
Kernel Handler
یکی از مثال های معروفش
Page Fault
فرض کنید برنامه به یه صفحه حافظه دسترسی پیدا کنه ولی اون صفحه در اون لحظه شرایط لازم برای دسترسی رو نداشته باشه
CPU
یه Page Fault ایجاد میکنه
بعد Kernel وارد ماجرا میشه و بررسی میکنه باید چه کاری انجام بشه
یه نکته مهم:
Page Fault
لزوما به معنی Crash نیست
ممکنه سیستم عامل بتونه اون رو کاملا عادی مدیریت کنه
مثلا صفحه موردنظر رو آماده کنه و برنامه دوباره ادامه بده
Interrupt
معمولا از طرف سخت افزار یا کنترل کننده سخت افزار ایجاد میشه مثلا یه دستگاه میخواد CPU رو از یه اتفاق باخبر کنه
به صورت ساده:
Hardware
│
▼
Interrupt
│
▼
CPU
│
▼
Kernel
مثلا یه عملیات I O تموم شده
سخت افزار میتونه با Interrupt به CPU خبر بده که عملیات تموم شده
بعد Kernel میتونه این اتفاق رو مدیریت کنه
تفاوت این سه مفهوم:
System Call
درخواست برنامه برای گرفتن یه سرویس از سیستم عامل
Exception
اتفاقی که در نتیجه اجرای دستور یا شرایط مربوط به CPU رخ میده
Interrupt
اعلام یه رویداد که معمولا از طرف سخت افزار میاد
Trap
هم یه اصطلاح معماری و سیستم عاملیه که برای انتقال کنترل به یه Handler استفاده میشه بسته به منبعی که میخونید ممکنه تعریف دقیق این اصطلاح کمی فرق داشته باشه پس بهتره فقط یه تعریف حفظ نکنید مهم اینه بفهمی چه اتفاقی باعث میشه CPU مسیر اجرا رو عوض کنه و وارد Handler مربوطه بشه
چرا این موضوع برای Reverse Engineering مهمه
اینجا موضوع برای ما جالب تر میشه
وقتی دارید یه باینری رو Reverse میکنید
ممکنه به دستورهایی مثل
syscall
برسی
یا رفتارهایی مربوط به Exception و Page Fault ببینید
اگر فقط اسمبلی رو حفظ کرده باشید میبینید
syscall
ولی اگر OS رو فهمیده باشید میفهمید پشت این دستور چه اتفاقی افتاده
User Code
↓
System Call
↓
CPU / Kernel Entry
↓
Kernel Handler
↓
Operation
↓
Return
یعنی فرق زیادی هست بین اینکه فقط یه دستور رو ببینید و اینکه بفهمید پشت اون دستور چه اتفاقی توی سیستم عامل میوفته
این مفاهیم پایه خیلی از چیزهاییه که بعدا توی OS و Reverse Engineering باهاشون سروکار داریم
@reverseengine
اعلام یه رویداد که معمولا از طرف سخت افزار میاد
Trap
هم یه اصطلاح معماری و سیستم عاملیه که برای انتقال کنترل به یه Handler استفاده میشه بسته به منبعی که میخونید ممکنه تعریف دقیق این اصطلاح کمی فرق داشته باشه پس بهتره فقط یه تعریف حفظ نکنید مهم اینه بفهمی چه اتفاقی باعث میشه CPU مسیر اجرا رو عوض کنه و وارد Handler مربوطه بشه
چرا این موضوع برای Reverse Engineering مهمه
اینجا موضوع برای ما جالب تر میشه
وقتی دارید یه باینری رو Reverse میکنید
ممکنه به دستورهایی مثل
syscall
برسی
یا رفتارهایی مربوط به Exception و Page Fault ببینید
اگر فقط اسمبلی رو حفظ کرده باشید میبینید
syscall
ولی اگر OS رو فهمیده باشید میفهمید پشت این دستور چه اتفاقی افتاده
User Code
↓
System Call
↓
CPU / Kernel Entry
↓
Kernel Handler
↓
Operation
↓
Return
یعنی فرق زیادی هست بین اینکه فقط یه دستور رو ببینید و اینکه بفهمید پشت اون دستور چه اتفاقی توی سیستم عامل میوفته
این مفاهیم پایه خیلی از چیزهاییه که بعدا توی OS و Reverse Engineering باهاشون سروکار داریم
@reverseengine
ReverseEngineering
Trap و ورود از User Mode به Kernel Mode تا اینجا فهمیدیم برنامه ها توی User Mode اجرا میشن و وقتی بخوان از سیستم عامل یه کار حساس بخوان از System Call استفاده میکنن ولی یه سوال مهم داریم CPU دقیقا چطوری از اجرای عادی برنامه توی User Mode میره داخل Kernel…
Trap
and Entering from User Mode to Kernel Mode
So far we have understood that programs run in User Mode and when they ask the operating system for a sensitive task, they use System Call
But we have an important question
How exactly does the CPU go from normal program execution in User Mode to Kernel Mode
Here the concept of Trap comes into play
Trap
means a controlled transition from normal program execution to Kernel, meaning the program is running in User Mode
User Mode
│
│ Service Request
▼
Trap
│
▼
Kernel Mode
After the Kernel has done its job, control returns to the program
What is the difference between System Call and Trap
These two are not the same
System Call
Actually, the program requests the operating system
For example, the program says I want to read from a file
or write something
or get memory
For example:
read()
write()
mmap()
But Trap is a mechanism that causes the CPU to transfer execution control to the Kernel
So very simply
Program
│
│ System Call
▼
Trap / System call entry
│
▼
Kernel
That is, the System Call tells what service I want
Trap
or the entry path causes the program to enter the Kernel
Example x86 64:
In Linux on the x86 64 architecture, a System Call is usually executed with the
syscall
command
Before executing this command, the program places the necessary information into specific registers
Concept:
Registers
│
├── System Call Number
├── Argument 1
├── Argument 2
└──
│
▼
syscall
│
▼
Kernel
Kernel
When it enters, it checks the System Call number to find out exactly what the program requested. For example, the program may request to read information from a file. So the Kernel needs to know which System Call this request is related to.
How does the Kernel know what System Call was requested? Here, one of the important things is the System Call Number. Each System Call in Linux has a specific number. Of course, these numbers depend on the architecture and ABI. There are
That is, we should not think that the number of a System Call is the same on all systems
Conceptually:
System Call Number
+
Arguments
│
▼
syscall
│
▼
Kernel
Kernel
Using this information, it finds the path to that request
Kernel
What does it do when it enters
When the CPU enters the Kernel, the Kernel must check the program request
Simply
User Code
│
▼
syscall
│
▼
Kernel Entry
│
▼
Check the request
│
▼
Execution of the operation
│
▼
Return Value
│
▼
User Mode
Kernel
It may check things like access permissions and the validity of some information
For example, a User Space program should not be able to manipulate any memory address it wants without control
The operating system plays the role of a watchdog here because if any program could do anything with system resources, the operating system would practically become useless
Trap
Is not just for System Calls
Here is an important point We have
When we say Trap, we should not think that it is only used for System Call
In the operating system and CPU architecture, control transfer to the Kernel can occur for various reasons
For example:
System Call
Exception
Some hardware events via Interrupt, of course, these concepts are not exactly the same and should be examined separately
What is Exception
Exception
It happens when the CPU encounters a special condition while executing an instruction
For example:
Program
│
▼
Execution of instruction
│
▼
Special conditions
│
▼
Exception
│
▼
Kernel Handler
One of its famous examples is
Page Fault
Suppose the program accesses a memory page, but that page does not have the necessary conditions for access at that moment
The CPU
creates a Page Fault
Then the Kernel enters the story and checks what should be done
An important point:
Page Fault
does not necessarily mean Crash
The operating system may be able to handle it completely normally
For example, it can prepare the desired page and the program can continue again Give
Interrupt
Usually generated by hardware or hardware controller, for example, a device wants to notify the CPU of an event
Simply:
and Entering from User Mode to Kernel Mode
So far we have understood that programs run in User Mode and when they ask the operating system for a sensitive task, they use System Call
But we have an important question
How exactly does the CPU go from normal program execution in User Mode to Kernel Mode
Here the concept of Trap comes into play
Trap
means a controlled transition from normal program execution to Kernel, meaning the program is running in User Mode
User Mode
│
│ Service Request
▼
Trap
│
▼
Kernel Mode
After the Kernel has done its job, control returns to the program
What is the difference between System Call and Trap
These two are not the same
System Call
Actually, the program requests the operating system
For example, the program says I want to read from a file
or write something
or get memory
For example:
read()
write()
mmap()
But Trap is a mechanism that causes the CPU to transfer execution control to the Kernel
So very simply
Program
│
│ System Call
▼
Trap / System call entry
│
▼
Kernel
That is, the System Call tells what service I want
Trap
or the entry path causes the program to enter the Kernel
Example x86 64:
In Linux on the x86 64 architecture, a System Call is usually executed with the
syscall
command
Before executing this command, the program places the necessary information into specific registers
Concept:
Registers
│
├── System Call Number
├── Argument 1
├── Argument 2
└──
│
▼
syscall
│
▼
Kernel
Kernel
When it enters, it checks the System Call number to find out exactly what the program requested. For example, the program may request to read information from a file. So the Kernel needs to know which System Call this request is related to.
How does the Kernel know what System Call was requested? Here, one of the important things is the System Call Number. Each System Call in Linux has a specific number. Of course, these numbers depend on the architecture and ABI. There are
That is, we should not think that the number of a System Call is the same on all systems
Conceptually:
System Call Number
+
Arguments
│
▼
syscall
│
▼
Kernel
Kernel
Using this information, it finds the path to that request
Kernel
What does it do when it enters
When the CPU enters the Kernel, the Kernel must check the program request
Simply
User Code
│
▼
syscall
│
▼
Kernel Entry
│
▼
Check the request
│
▼
Execution of the operation
│
▼
Return Value
│
▼
User Mode
Kernel
It may check things like access permissions and the validity of some information
For example, a User Space program should not be able to manipulate any memory address it wants without control
The operating system plays the role of a watchdog here because if any program could do anything with system resources, the operating system would practically become useless
Trap
Is not just for System Calls
Here is an important point We have
When we say Trap, we should not think that it is only used for System Call
In the operating system and CPU architecture, control transfer to the Kernel can occur for various reasons
For example:
System Call
Exception
Some hardware events via Interrupt, of course, these concepts are not exactly the same and should be examined separately
What is Exception
Exception
It happens when the CPU encounters a special condition while executing an instruction
For example:
Program
│
▼
Execution of instruction
│
▼
Special conditions
│
▼
Exception
│
▼
Kernel Handler
One of its famous examples is
Page Fault
Suppose the program accesses a memory page, but that page does not have the necessary conditions for access at that moment
The CPU
creates a Page Fault
Then the Kernel enters the story and checks what should be done
An important point:
Page Fault
does not necessarily mean Crash
The operating system may be able to handle it completely normally
For example, it can prepare the desired page and the program can continue again Give
Interrupt
Usually generated by hardware or hardware controller, for example, a device wants to notify the CPU of an event
Simply:
ReverseEngineering
Trap و ورود از User Mode به Kernel Mode تا اینجا فهمیدیم برنامه ها توی User Mode اجرا میشن و وقتی بخوان از سیستم عامل یه کار حساس بخوان از System Call استفاده میکنن ولی یه سوال مهم داریم CPU دقیقا چطوری از اجرای عادی برنامه توی User Mode میره داخل Kernel…
Hardware
│
▼
Interrupt
│
▼
CPU
│
▼
Kernel
For example, an I O operation is completed
Hardware can notify the CPU with an Interrupt that the operation is completed
Then the Kernel can manage this event
The difference between these three concepts:
System Call
A program request to get a service from the operating system
Exception
An event that occurs as a result of executing a command or condition related to the CPU
Interrupt
Declaration of an event that usually comes from hardware
Trap
Is also an architectural and operating system term that is used to transfer control to a Handler. Depending on the source you read, the exact definition of this term may vary slightly, so it's better not to just memorize one definition. The important thing is to understand what causes the CPU to change the execution path and enter the corresponding Handler
Why is this important for Reverse Engineering
Here the topic becomes more interesting for us
When you are reversing a binary
You may see instructions like
syscall
or behaviors related to Exception and Page Fault
If you have only memorized the assembly you will see
syscall
But if you understand the OS you will understand what happened behind this instruction
User Code
↓
System Call
↓
CPU / Kernel Entry
↓
Kernel Handler
↓
Operation
↓
Return
That is, there is a big difference between just seeing an instruction and understanding what happens behind that instruction in the operating system
These are the basic concepts of many things that we will deal with later in OS and Reverse Engineering
@reverseengine
│
▼
Interrupt
│
▼
CPU
│
▼
Kernel
For example, an I O operation is completed
Hardware can notify the CPU with an Interrupt that the operation is completed
Then the Kernel can manage this event
The difference between these three concepts:
System Call
A program request to get a service from the operating system
Exception
An event that occurs as a result of executing a command or condition related to the CPU
Interrupt
Declaration of an event that usually comes from hardware
Trap
Is also an architectural and operating system term that is used to transfer control to a Handler. Depending on the source you read, the exact definition of this term may vary slightly, so it's better not to just memorize one definition. The important thing is to understand what causes the CPU to change the execution path and enter the corresponding Handler
Why is this important for Reverse Engineering
Here the topic becomes more interesting for us
When you are reversing a binary
You may see instructions like
syscall
or behaviors related to Exception and Page Fault
If you have only memorized the assembly you will see
syscall
But if you understand the OS you will understand what happened behind this instruction
User Code
↓
System Call
↓
CPU / Kernel Entry
↓
Kernel Handler
↓
Operation
↓
Return
That is, there is a big difference between just seeing an instruction and understanding what happens behind that instruction in the operating system
These are the basic concepts of many things that we will deal with later in OS and Reverse Engineering
@reverseengine
Taint Analysis
دنبال کردن یک داده در کل برنامه
تا اینجا با Forward Slicing و Backward Slicing یاد گرفتیم چطور مسیر داده رو پیدا کنیم
حالا یه قدم جلوتر میریم
Taint Analysis
یعنی یه داده مشخص رو علامت گذاری کنیم و بعد ببینیم این داده توی ادامه برنامه کجاها میره و روی چه چیزهایی تاثیر میذاره
فرض کنید برنامه یه ورودی میگیره:
C
ما
یعنی فعلا فرض میکنیم
input = TAINTED
حالا اگه این مقدار وارد یه محاسبه بشه
int x = input + 10;
پس
input
↓
x
اگه بعدا داشته باشیم
C
int y = x * 5;
مسیر میشه
input
↓
x
↓
y
پس
حالا اگه داشته باشیم
C
int result = y ^ 0x55;
مسیر میشه
input
↓
x
↓
y
↓
result
و اگه آخرش داشته باشیم
if (result == 100)
میفهمیم ورودی اولیه روی این شرط تاثیر گذاشته
این یکی از کاربردهای مهم Taint Analysis هست
یک مثال ساده:
C
int check(int input)
{
int x = input ^ 0x55;
int y = x + 10;
int temp = 500;
temp *= 20;
if (y == 100)
return 1;
return 0;
}
ما
پس مسیرش میشه
input
↓
x
↓
y
↓
comparison
ولی این قسمت
temp
↓
temp * 20
به شرط نهایی وصل نیست
پس Taint هم بهش منتقل نمیشه
یعنی
Taint
توی Assembly
وقتی وارد Reverse Engineering میشیم معمولا دیگه متغیری به اسم
ممکنه چیزی شبیه این ببینیم
mov eax, [rbp-20h]
xor eax, 55h
add eax, 10
cmp eax, 100
فرض کنیم
json
[rbp-20h] = ورودی
پس مسیر داده میشه
[rbp-20h]
↓
EAX
↓
XOR 55h
↓
ADD 10
↓
CMP 100
اینجا میتونیم ببینیم ورودی مستقیم وارد محاسبات شده و در نهایت به مقایسه رسیده
Taint
فقط برای ورودی کاربر نیست
هر داده ای میتونه نقطه شروع Taint باشه
مثلا:
Powershell
File Data
Network Data
Configuration
Function Argument
Registry Value
Environment Variable
مثلا اگه یه تابع اینو بگیره
C
void process(char *data)
میتونیم
بعد دنبال کنیم که این داده توی ادامه برنامه وارد چه توابعی میشه
ممکنه مسیرش این شکلی باشه
Input
↓
Parser
↓
Transformation
↓
Function A
↓
Function B
↓
Comparison
یا حتی
Input
↓
Buffer
↓
Memory
↓
Function
↓
Output
یه نکته مهم
Taint Analysis
یعنی لزوما مقدار دقیق اولیه همونطوری باقی مونده نه
ممکنه مقدار چند بار تغییر کنه
مثلا:
Input
↓
XOR
↓
ADD
↓
SHIFT
↓
SUB
↓
Comparison
چیزی که دنبال میکنیم اینه که ببینیم مقدار جدید هنوز به داده اولیه وابسته هست یا نه
یعنی سؤال اصلی اینه
آیا این مقدار تحت تاثیر داده Tainted قرار گرفته
نه اینکه
آیا مقدار دقیقا همون مقدار اولیه عسا
به انتقال Taint از یه مقدار به مقدار دیگه میگیم
Taint Propagation
مثلا
a = input;
b = a + 5;
c = b ^ 0x44;
مسیرش میشه
input
↓
a
↓
b
↓
c
یعنی Taint همراه داده حرکت میکنه
ولی اگه داشته باشیم
C++
int x = 100;
int y = x + 20;
چون
x = CLEAN
y = CLEAN
پس Taint وارد این مسیر نمیشه
حالا یه مثال واقعی تر
فرض کنید یه تابع پیچیده داریم
Function
│
├── Input
├── Calculation A
├── Junk Code
├── Function B
├── Calculation C
├── Comparison
└── Return
اگه ورودی رو Tainted کنیم ممکنه بعد از تحلیل به این نتیجه برسیم
Input
↓
Calculation A
↓
Function B
↓
Calculation C
↓
Comparison
و بخش Junk Code اصلاً توی مسیر Taint نباشه
اینجا دقیقا میبینیم چرا Taint Analysis در کنار Slicing خیلی قدرتمنده
Slicing میگه
چه چیزهایی به این نقطه مربوط میشن
Taint Analysis میگه
این داده مشخص کجاها رفته و روی چه چیزهایی تاثیر گذاشته
این دوتا خیلی به هم نزدیکن ولی دقیقا یکی نیستن
تمرین:
این تابع رو بررسی کنید
C
int verify(int input)
{
int a = input ^ 0x31;
int junk = 900;
junk *= 5;
int b = a + 20;
int temp = 100;
temp ^= 55;
int result = b * 3;
return result == 300;
}
فرض کنید فقط
حالا مسیر Taint رو مشخص کنید
input
↓
?
↓
?
↓
?
↓
comparison
و مشخص کنید کدوم متغیرها اصلا نباید Tainted بشن
@reverseengine
دنبال کردن یک داده در کل برنامه
تا اینجا با Forward Slicing و Backward Slicing یاد گرفتیم چطور مسیر داده رو پیدا کنیم
حالا یه قدم جلوتر میریم
Taint Analysis
یعنی یه داده مشخص رو علامت گذاری کنیم و بعد ببینیم این داده توی ادامه برنامه کجاها میره و روی چه چیزهایی تاثیر میذاره
فرض کنید برنامه یه ورودی میگیره:
C
int input = get_input();
ما
input رو Tainted در نظر میگیریمیعنی فعلا فرض میکنیم
input = TAINTED
حالا اگه این مقدار وارد یه محاسبه بشه
int x = input + 10;
پس
input
↓
x
x هم Tainted حساب میشهاگه بعدا داشته باشیم
C
int y = x * 5;
مسیر میشه
input
↓
x
↓
y
پس
y هم تحت تاثیر ورودی اولیه قرار گرفتهحالا اگه داشته باشیم
C
int result = y ^ 0x55;
مسیر میشه
input
↓
x
↓
y
↓
result
و اگه آخرش داشته باشیم
if (result == 100)
میفهمیم ورودی اولیه روی این شرط تاثیر گذاشته
این یکی از کاربردهای مهم Taint Analysis هست
یک مثال ساده:
C
int check(int input)
{
int x = input ^ 0x55;
int y = x + 10;
int temp = 500;
temp *= 20;
if (y == 100)
return 1;
return 0;
}
ما
input رو Tainted میکنیمپس مسیرش میشه
input
↓
x
↓
y
↓
comparison
ولی این قسمت
temp
↓
temp * 20
به شرط نهایی وصل نیست
پس Taint هم بهش منتقل نمیشه
یعنی
temp همچنان Clean هستTaint
توی Assembly
وقتی وارد Reverse Engineering میشیم معمولا دیگه متغیری به اسم
input نداریمممکنه چیزی شبیه این ببینیم
mov eax, [rbp-20h]
xor eax, 55h
add eax, 10
cmp eax, 100
فرض کنیم
json
[rbp-20h] = ورودی
پس مسیر داده میشه
[rbp-20h]
↓
EAX
↓
XOR 55h
↓
ADD 10
↓
CMP 100
اینجا میتونیم ببینیم ورودی مستقیم وارد محاسبات شده و در نهایت به مقایسه رسیده
Taint
فقط برای ورودی کاربر نیست
هر داده ای میتونه نقطه شروع Taint باشه
مثلا:
Powershell
File Data
Network Data
Configuration
Function Argument
Registry Value
Environment Variable
مثلا اگه یه تابع اینو بگیره
C
void process(char *data)
میتونیم
data رو نقطه شروع قرار بدیمبعد دنبال کنیم که این داده توی ادامه برنامه وارد چه توابعی میشه
ممکنه مسیرش این شکلی باشه
Input
↓
Parser
↓
Transformation
↓
Function A
↓
Function B
↓
Comparison
یا حتی
Input
↓
Buffer
↓
Memory
↓
Function
↓
Output
یه نکته مهم
Taint Analysis
یعنی لزوما مقدار دقیق اولیه همونطوری باقی مونده نه
ممکنه مقدار چند بار تغییر کنه
مثلا:
Input
↓
XOR
↓
ADD
↓
SHIFT
↓
SUB
↓
Comparison
چیزی که دنبال میکنیم اینه که ببینیم مقدار جدید هنوز به داده اولیه وابسته هست یا نه
یعنی سؤال اصلی اینه
آیا این مقدار تحت تاثیر داده Tainted قرار گرفته
نه اینکه
آیا مقدار دقیقا همون مقدار اولیه عسا
به انتقال Taint از یه مقدار به مقدار دیگه میگیم
Taint Propagation
مثلا
a = input;
b = a + 5;
c = b ^ 0x44;
مسیرش میشه
input
↓
a
↓
b
↓
c
یعنی Taint همراه داده حرکت میکنه
ولی اگه داشته باشیم
C++
int x = 100;
int y = x + 20;
چون
x از Input نیومدهx = CLEAN
y = CLEAN
پس Taint وارد این مسیر نمیشه
حالا یه مثال واقعی تر
فرض کنید یه تابع پیچیده داریم
Function
│
├── Input
├── Calculation A
├── Junk Code
├── Function B
├── Calculation C
├── Comparison
└── Return
اگه ورودی رو Tainted کنیم ممکنه بعد از تحلیل به این نتیجه برسیم
Input
↓
Calculation A
↓
Function B
↓
Calculation C
↓
Comparison
و بخش Junk Code اصلاً توی مسیر Taint نباشه
اینجا دقیقا میبینیم چرا Taint Analysis در کنار Slicing خیلی قدرتمنده
Slicing میگه
چه چیزهایی به این نقطه مربوط میشن
Taint Analysis میگه
این داده مشخص کجاها رفته و روی چه چیزهایی تاثیر گذاشته
این دوتا خیلی به هم نزدیکن ولی دقیقا یکی نیستن
تمرین:
این تابع رو بررسی کنید
C
int verify(int input)
{
int a = input ^ 0x31;
int junk = 900;
junk *= 5;
int b = a + 20;
int temp = 100;
temp ^= 55;
int result = b * 3;
return result == 300;
}
فرض کنید فقط
input رو Tainted کردیمحالا مسیر Taint رو مشخص کنید
input
↓
?
↓
?
↓
?
↓
comparison
و مشخص کنید کدوم متغیرها اصلا نباید Tainted بشن
@reverseengine