EDR Killer

Exploits a vulnerability in the wsftprm.sys driver to disable antivirus and EDR

https://github.com/ThanniKudam/TopazTerminator

@reverseengine

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

@p0or1ya


Unfortunately, due to recent events, Pouria is no longer with us.
Dear, kind and diligent student
Your name will be immortal to all of us forever
May your soul rest in peace, brother, we miss you
My dear Pouria, I still can't believe you're gone
Out of respect for Pouria, we will start the channel's activity with a slight delay.
We will never forget you, brother.


R. I. P. 🖤

@p0or1ya

سیستم عامل چجوری کار میکنه؟

یک برنامه در حال اجرا یک کار بسیار ساده رو انجام میده دستور ها رو دنبال میکنه میلیون ها و حتی میلیارد ها بار در هر ثانیه CPU یک دستور رو از حافظه میگیره و اونو رمزگشایی میکنه یعنی میفهمه کدوم دستور هست و اونو اجرا میکنه یعنی کاری که قراره انجام بشه مثل جمع کردن دو عدد با هم دسترسی به حافظه بررسی یک شرط پرش به یک تابع انجام میده بعد از تموم شدن کار با این دستور CPU به دستور بعدی میره و به همین ترتیب تا زمانی که برنامه کامل بشه



How does an operating system work?

A running program does a very simple job It follows instructions Millions and even billions of times per second, the CPU fetches an instruction from memory and decodes it meaning it understands what the instruction is and executes it meaning it does what it is supposed to do such as adding two numbers together accessing memory checking a condition jumping to a function and after it finishes working with this instruction the CPU moves on to the next instruction and so on until the program is complete

@reverseengine

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

Virtualization:
The operating system takes a physical resource such as a processor or disk or storage and converts it into a more general powerful and easier-to-use virtual form

@reverseengine

همزمانی:
مجموعه ای از مشکلات وقتی که کار روی چند تا چیز به طور همزمان در یک برنامه واحد اجرا میشن و باید مدام اونها رو چک کنیم

Concurrency: A set of problems that arise when multiple things are being worked on simultaneously in a single program and we need to keep checking them

@reverseengine

فرایند (process):
یک برنامه در حال اجرا فقط روی دیسک قرار میگیره سیستم عامل بایت ها رو میگیره و اجرا میکنه و برنامه رو به چیز مفیدی تبدیل میکنه

Process:
A running program simply sits on disk The operating system takes the bytes and executes them turning the program into something useful

@reverseengine

ما یک اصطلاح جالب داریم به نام توهم چند cpu

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


We have an interesting term called the illusion of multiple CPUs

The operating system creates this illusion by virtualizing CPUs By running one process stopping it, running another process and so on the operating system can create the illusion that there are many virtual CPUs when there is only one or a few physical CPUs This basic technique is known as time-sharing

@reverseengine

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

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

@reverseengine

PatchReview:

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

MS patch checking tool

DFIR Timeline Analysis for macOS

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

WINDOWS KERNELS AREN’T MEANT TO BE TOUCHED…

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

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

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

IDA CyberChef

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

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


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

@reverseengine

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

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

یک هلو؟

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

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

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

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

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

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

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



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

Imagine we have a peach

A peach?

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

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

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

Right! Exactly.

But there's only one peach.

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

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

@reverseengine

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

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

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

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


توضیح:

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

قدم اول

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

ایده ساده:

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

توضیح فایل:

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

C

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

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

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

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

قدم دوم

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

مثال ساده:

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

نکته:


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


قدم سوم

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

sub rsp, 0x20
push rbp
mov rbp, rsp

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

مثال ساده:

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

Asm

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


توضیح کد زیر

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


مرحله چهارم

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


مرحله پنجم

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

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

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

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


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

Part 16 Buffer Overflow

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

Explanation:

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

Step 1

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

Simple idea:

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

File description:

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

C

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

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

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

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

Step 2

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

Simple example:

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

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

Note:

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

This pattern is one of the most classic signs

Step 3

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

sub rsp, 0x20
push rbp
mov rbp, rsp

These show where local space is created on the stack

Simple example:

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

Asm

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


Explanation of the code below

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

Step 4

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

Step 5

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

Example execution line
Bash

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

If the program crashes, it means our diagnosis was correct

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

@reverseengine