ReverseEngineering

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

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:

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 و ورود از 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 رخ میده

Reversing a StealC Infostelaer https://blog.ghozt.ninja/2025/12/21/stealc @reverseengine

A Glimpse Into DexProtector https://www.romainthomas.fr/post/26-01-dexprotector @reverseengine

iCDump: A Modern Objective-C Class Dump https://www.romainthomas.fr/post/23-01-icdump @reverseengine

A Glimpse Into DexProtector https://www.romainthomas.fr/post/26-01-dexprotector @reverseengine

Cracking the Crackers https://reverse.put.as/2025/03/13/cracking-the-crackers @reverseengine

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

Defeating Anti-Reverse Engineering: A Deep Dive into the 'Trouble' Binary https://binary.ninja/2026/01/23/reversing-linux-anti-re.html @reverseengine

Dragon Power Against VMProtect https://farena.in/dragon-tales-web/posts/dragon-power-against-vmprotect/

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/

SELECT * FROM binary - Vibe Reverse Engineering with IDA, Ghidra and Binary Ninja https://youtu.be/ADPoD7-_K5s?si=HCgt4gVmbkw5S05i

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

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.

System Call رابط کنترل‌شده‌ ای که یک برنامه در User Mode از طریق اون درخواست‌ هایی رو از Kernel میخاد مهم‌ترین نکته: User Mode │ │ System Call ↓ Kernel Mode │ ↓ Kernel performs operation │ ↓ User Mode و این دقیقا یکی از پایه‌ های مهم درک OS Internals و Reverse Engineering هست @reverseengine

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 خیلی مهمه 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 ها خیلی به کارتون میاد