ReverseEngineering – Telegram
ReverseEngineering
1.24K subscribers
40 photos
10 videos
55 files
666 links
Download Telegram
خوندن تابع توی دیس‌ اسمبلر

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


تا حالا یه تابع رو دیدید توی دیس‌اسمبلر که انگار رمزآلود یا ی جوری حرف میزنه؟ اول دنبال prologue و epilogue باشید اون push/pop و mov های اول و آخر پارامترها معمولا توی رجیسترها یا روی stack میان ببینید کجا با حافظه کار میکنه چه آرگومانی میخونه و چی برمیگردونه اسم‌گذاری ساده بزنید: مثلا check_len یا read_input — بعد pseudocode رو بخونید یه خط کامنت بزنید که این تابع طول رشته رو چک میکنه و اگر > 5 بود OK میده

مثال:
فایل ساده‌ای باز کنید که ورودی میگیره توی Ghidra/IDA تابع main رو باز کنید ببینید push rbp، mov rbp, rsp و چند cmp/jle هست یا نه اگر یه cmp با عدد 5 دیدید حدس بزنید اینجا طول رو مقایسه میکنه اسمش رو بذارید check_length و pseudocode رو بخونید

تشخیص (دیتکشن)

push/pop
‌های زیاد یا غیر متعارف تو پرولوگ/اپیلوگ

cmp/jmp
‌هایی که تعداد زیادی branch تولید میکنن

استفاده مکرر از توابعی مثل strlen، memcpy یا فراخوانی‌ های ورودی/خروجی نشونه پردازش ورودی


میتیگیشن یا کاهش (دفاع ها)

لاگ‌گذاری ورودی‌ها و بررسی edge-case ها با unit test

برای تشخیص رفتاری: Telemetry که فراخوانی‌های حساس مثل خوندن فایل/شبکه رو لاگ کنه تا اگر تابع‌ های مشکوک ظاهر شد سریع ببینید


Reading a Function in a Disassembler

How to Find Out from Assembly What a Function Does Exactly? Input Protocol, Conditions, and Outputs

Have you ever seen a function in a disassembler that seems to be talking cryptically or something? First look for prologue and epilogue. Those push/pop and mov of the first and last parameters are usually in registers or on the stack. See where it works with memory. What arguments it reads and what it returns. Give it a simple name: for example check_len or read_input — then read the pseudocode. Comment a line that says this function checks the length of the string and if it is > 5 it says OK.

Example:
Open a simple file that takes input in Ghidra/IDA. Open the main function. See if there are push rbp, mov rbp, rsp and a few cmp/jle. If you see a cmp with the number 5, guess where it compares the length. Name it check_length and read the pseudocode.

Detection
Too many or unusual push/pops in the prologue/epilogue.

Cmp/jmps that generate a lot of branches.

Repeated use of functions like strlen, memcpy or I/O calls. Process token Input

Mitigation
Logging inputs and examining edge-cases with unit tests

For behavioral detection: Telemetry that logs sensitive calls like file/network reads so you can quickly see if suspicious functions appear

@reverseengine
1
دیباگینگ با Breakpoint و Step


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


اگه تا حالا حس کردید کد یه برنامه مثل جادو کار میکنه وقتشه جادوشو بشکنید💀
با یه دیباگر مثل x64dbg یا gdb میتونید وسط اجرای برنامه ترمز برنامه نویس رو بکشید😂
یه breakpoint بذارید روی یه تابع خاص مثلا جایی که ورودی رو بررسی میکنه بعد با دکمه F8 یا Step برید خط‌ به‌ خط جلو ببینید مقدار رجیسترها و متغیرها چطوری تغییر میکنن
اگه شرطی داره (cmp/jz و از اینا) مقدار رو قبل و بعدش ببینید تا بفهمی چرا true یا false میشه
کم‌کم ذهنتون کد رو از اسمبلی به رفتار واقعی ترجمه میکنه  اونجاست که میفهمید باینری چطور فکر میکنه👾

مثال عملی:
برنامه‌ ای باز کنید که عدد از کاربر میگیره و میگه بزرگ‌تر از ۱۰ هست یا نه
روی جایی که شرط چک میشه (cmp eax, 0Ah) breakpoint بذارید
مقدار eax رو موقع stop ببینید اگه 9 باشه پرش انجام نمیشه اگه 12 باشه میپره به مسیر بله بزرگتره

دیتکشن

اگر دیدید برنامه مدام سعی میکنه دیباگر رو ببنده یا Thread Information Query میفرسته  یعنی anti-debug داره

اگه اجرای معمولی و اجرای با دیباگر خروجی متفاوت بده یعنی داره دنبال حضورتون میگرده👀


میتیگیشن

محقق: همیشه توی VM با snapshot کار کنید تا اگه برنامه قاطی کرد راحت برگردید

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



Debugging with Breakpoints and Steps

Debugging means stopping the program and seeing exactly what it is doing at that moment. It is like a slow-motion camera on the brain of the program.

If you have ever felt that the code of a program works like magic, it is time to break its magic💀

With a debugger like x64dbg or gdb, you can brake the programmer in the middle of the program😂

Set a breakpoint on a specific function, for example, where it checks the input. Then use the F8 or Step button to go forward line by line and see how the values ​​of registers and variables change.

If there is a condition (cmp/jz and so on), look at the value before and after to understand why it becomes true or false.

Your mind will gradually translate the code from assembly to real behavior. That is where you will understand how binary thinks👾


Practical example:
Open a program that takes a number from the user and tells whether it is greater than 10 or not.
Set a breakpoint where the condition is checked (cmp eax, 0Ah).

Value Check eax at stop. If it is 9, the jump will not be performed. If it is 12, it will jump to the larger path.

Detection

If you see that the program keeps trying to close the debugger or sends Thread Information Query, it means it has anti-debug.

If normal execution and execution with debugger give different output, it means it is looking for your presence👀

Mitigation

Researcher:
Always work with snapshots in the VM so that if the program messes up, you can easily return.

Defender:
Follow behaviors such as debugger detection in security logs because they are usually signs of protected software or malware.


@reverseengine
👏4
بخش پنجم بافر اورفلو


off by one

off by one زمانی رخ میده که دقیقا یک بایت یا یک واحد کمتر یا بیشتر در نوشتن تحت کنترل باشه

این خطاها کوچک به نظر میرسن اما میتونن باعث تغییر یک بایت از saved rbp یا تغییر null terminator رشته بشن و رفتار غیرمنتظره ایجاد کنن
تشخیص off by one نیاز به دقت در اندازه ها و دیدن بایت های محلی داره

توضیح کد:
در این کد نشون میدیم که نوشتن دقیقا یک بایت میتونه نال ترمینیتور رشته رو از بین ببره یا بایت مهمی رو تغییر بده
هدف دیدن خروجی متفاوت رشته هست

کد آف بای وان offbyone.c

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

int main() {
    char s[8];
    /* suppose we incorrectly copy 9 bytes into 8 byte buffer */
    memcpy(s, "ABCDEFGH", 8);
    s[7] = 'Z'; /* simulate off by one by modifying last byte */
    printf("string maybe not null terminated %s\n", s);
    return 0;
}


دستورات رو اجرا کنید و ببینید off by one
این مثال رو اجرا کنید و خروجی رو نگاه کنید تا مشکل در اخر رشته مشخص بشه

gcc -g offbyone.c -o offbyone
./offbyone


ببینید که رشته ممکنه نال ترمینیت نشده باشه



Part 5 Buffer Overflow


off by one

off by one occurs when exactly one byte or one unit is under control in the write

These errors seem small, but they can change a byte from the saved rbp or change the null terminator of the string and cause unexpected behavior

Detecting off by one requires accuracy in sizes and seeing local bytes

Code explanation:
In this code, we show that writing exactly one byte can remove the null terminator of the string or change an important byte

The goal is to see different output of the string

Off by one code offbyone.c

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

int main() {

char s[8];

/* suppose we incorrectly copy 9 bytes into 8 byte buffer */
memcpy(s, "ABCDEFGH", 8);
s[7] = 'Z'; /* simulate off by one by modifying last byte */
printf("string maybe not null terminated %s\n", s);
return 0;
}


Run the commands and see off by one
Run this example and look at the output to see if the problem is at the end of the string

gcc -g offbyone.c -o offbyone
./offbyone


See if the string might not be null terminated


@reverseengine
4
Unveiling Secrets in Binaries using Code Detection Strategies

https://synthesis.to/presentations/recon23_code_detection.pdf

@reverseengine
1
How to Detect Leaked Passwords and Decrypt Hashes?

Password Leak Check:

exposed.lol
Discover leaked passwords associated with your email address (Note: Service stability may vary)


breachdirectory.org
Search for password SHA1 hashes linked to your email or nickname. (Utilize md5decrypt.net/en/Sha1/ for decryption)


search.0t.rocks
Find emails associated with a particular password


Password Hash Decryption :

Websites :
crackstation.net
Decrypts various hash types


hashes.com
Provides a platform for hash decryption


cmd5.org
Specialized in MD5 hash decryption


md5decrypt.net
Decrypts MD5 hashes


onlinehashcrack.com
Offers paid services with extensive functionality


CLI Tools:
HashCat
Search That Hash

@reverseengine
1
mas_1_rev_1.pdf
1.8 MB
Malware Analysis Series (Mas)

@reverseengine
3
داینامیک اینسترومنت با Frida دیدن و لاگ کردن زمان اجرا

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


میخواید بدونی برنامه موقع باز کردن فایل یا فرستادن درخواست شبکه چی میفرسته؟ با Frida یه اسکریپت کوچیک میزنید که وقتی تابع open یا send اجرا شد آدرس و داده‌ ها رو لاگ کنه بدون اینکه فایل رو دست بزنی میتونی جریان اجرا و ورودی‌ ها رو ببینید انگار گوشیت رو برای 5 ثانیه شنود میکنید ولی اخلاقی و برای تحلیل 😅

مثال:
یه برنامه ساده که فایل باز میکنه: با Frida hook کنید fopen یا open پارامتر مسیر فایل رو چاپ کنید و بعد اجازه بدید اجرا ادامه پیدا کنه فقط دیدن پارامترها نه تغییر رفتار

دیتکشن (تشخیص):

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

تعداد بالای hook ها یا فراخوانی‌ های مکرر به توابع IO که میتونه نشونه obfuscation یا exfiltration باشه


میتیگشن (مدافع‌ها):

محقق: Frida رو داخل VM با شبکه محدود اجرا کنید

برای سازمان: telemetry که فراخوانی API حساس و رفتارهای غیر عادی runtime رو لاگ کنه اینطوری اگر کسی سعی کنه داده‌ ای لو بره یا رفتار مشکوکی باشه سریع عکس‌ العمل میگیرید


Dynamic Instrumentation with Frida Runtime Viewing and Logging

Frida lets you drop into a running program without changing the file and hook a function, view parameters, or log them often just seeing the parameters can tell you a lot

Want to know what your program is sending when it opens a file or makes a network request? With Frida you write a small noscript that logs the address and data when the open or send function is executed. Without touching the file, you can see the execution flow and inputs. It's like you're bugging your phone for 5 seconds, but ethically and for analysis 😅

Example:
A simple program that opens a file: Hook with Frida fopen or open, print the file path parameter, and then let it continue execution. Only see the parameters, not change the behavior

Detection:

Sudden calls to sensitive APIs with strange data, such as sudden encryption before sending it to the network

A high number of hooks or repeated calls to IO functions that can be a sign of obfuscation or exfiltration

Mitigations:
researchers Run Frida inside a VM with restricted network

For organizations:
telemetry that logs sensitive API calls and unusual runtime behaviors. This way, if someone tries to leak data or has suspicious behavior, you can react quickly.

@reverseengine
3
بازسازی struct ها و مرتب‌ سازی pseudocode

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


اگه توی دیس‌اسمبلر چند جا دیدید با offset مشابه به یه آدرس دسترسی پیدا میکنن خیلی احتمال داره که اونجا یه struct نشسته توی Ghidra یا IDA براش member بذارید اسم بزنید username, len, flags و ببینید کد چقدر براتون منطقی‌تر میشه همین تغییر کوچیک باعث میشه pseudocode مثل یه متن عادی بخونه نه یه سری دستور عجیب و غریب

مثال:
یه باینری که چند تابع از آدرسی با offsets 0x0, 0x4, 0x8 استفاده میکنه بردارید توی دی‌کامپایلر struct درست کنید با سه فیلد مثلا int, int, ptr و اسم‌گذاری کنید بعد دوباره pseudocode رو ببینید فهمیدن منطق تابع خیلی آسون تر میشه

دیتکشن (تشخیص):

دسترسی‌های ثابت و تکراری به یک آدرس با offset های مشابه

pattern هایی مثل base + 0x10, base + 0x14
که نشون‌ دهنده field ها هستن

این‌ها بهتون میگه این یه struct یا object هست


میتیگیشن (مدافع‌ها):

توسعه‌دهنده: از ساختارهای واضح و مستندسازی استفاده کنید تعریف struct و کامنت تا کسی دیگه مجبور نشه حدس بزنه

آنالیزور: نگه داشتن debug symbols در محیط توسعه یا build مخصوص آنالیز خیلی کمک میکنه قبل از انتشار strip‌ کردن باینری و منیج کردن symbol ها رو مدیریت کنید



Reconstructing structs and sorting pseudocode

Once you understand what the function does, the next step is to understand how the data is organized, i.e. reconstruct the structs and types from the access patterns to make the code more understandable

If you see several places in the disassembler where they access the same address with the same offset, it is very likely that there is a struct sitting there in Ghidra or IDA. Call it member, name it username, len, flags and see how much more logical the code becomes for you. This small change will make the pseudocode read like normal text, not a series of strange instructions

Example:

Take a binary that uses several functions with addresses with offsets 0x0, 0x4, 0x8, create a struct in the decompiler with three fields, for example int, int, ptr and name it. Then look at the pseudocode again. Understanding the logic of the function becomes much easier

Detection:

Fixed and repeated accesses to an address with offsets Similar

Patterns like base + 0x10, base + 0x14
which indicate fields

These tell you if this is a struct or an object

Mitigations (Defenders):

Developer: Use clear structures and documentation, struct definitions and comments so no one else has to guess

Analyzer: Keeping debug symbols in the development environment or build for analysis is very helpful. Strip the binary and manage the symbols before releasing.

@reverseengine
8
اگه حمایتا خوب بود کم کم میریم سمت باینری اکسپلویتیشن 🩶

If the supports is good, we will gradually move towards binary exploitation 🖤
🔥112
Forwarded from GO-TO CVE
CVE-2025-52287-week-75.pdf
5 MB
خوش اومدین به هفته 75 از برنامه GO-TO CVE این هفته به برسی اسیب پذیری روی wsus پرداختیم .

CVE : CVE-2025-52287
type : RCE
target : wsus
week : 75

#week_75
5