Clop Ransomware Group Claims the Hack of Harvard University

https://securityaffairs.com/183282/cyber-crime/clop-ransomware-group-claims-the-hack-of-harvard-university.html

@reverseengine

Reverse Engineering for Noobs

https://aceresponder.com/blog/reversing-for-noobs

@reverseengine

Bypassing EDR using an In Memory PE Loader

https://g3tsyst3m.com/fileless%20techniques/Bypassing-EDR-using-an-In-Memory-PE-Loader/

@reverseengine

Reverse Engineering WannaCry Ransomware => A Deep Dive

https://infosecwriteups.com/reverse-engineering-wannacry-ransomware-a-deep-dive-86ee4a8d7c7a?source=rss----7b722bfd1b8d---4

@reverseengine

Reverse Engineering the Android Malware

https://www.linkedin.com/pulse/reverse-engineering-new-android-malware-targeting-ukfie/

@reverseengine

Hypervisors for Memory Introspection and Reverse Engineering

https://secret.club/2025/06/02/hypervisors-for-memory-introspection-and-reverse-engineering.html

@reverseengine

ClayRat A New Android Spyware Targeting Russia

https://zimperium.com/blog/clayrat-a-new-android-spyware-targeting-russia

@reverseengine

GhostBat RAT Inside the Resurgence of RTO Themed Android Malware

https://cyble.com/blog/ghostbat-rat-inside-the-resurgence-of-rto-themed-android-malware/

@reverseengine

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

1️⃣ call func

آدرس بعد از call (return address) پوش میشه رو استک


2️⃣ داخل تابع:

RBP ذخیره میشه

فریم استک ساخته میشه

3️⃣ متغیرها آرگومان‌ ها استفاده میشن

4️⃣ leave → فریم قدیمی برگردونده میشه

5️⃣ ret → caller برگشت به

The basic flow when a function is called:

1️⃣ call func

The address after the call (return address) is pushed onto the stack

2️⃣ Inside the function:

RBP is saved

A stack frame is created

3️⃣ Variables and arguments are used

4️⃣ leave → Old frame is returned

5️⃣ ret → caller returns to

@reverseengine

Safeguarding Code Against Reverse Engineering

https://www.youtube.com/watch?v=Ie1eZSiMEJ8

https://github.com/emproof-com/webinars/tree/main/2025-01-software_protection

@reverseengine

DiffRays

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

DiffRays is a research-oriented tool for binary patch diffing designed to aid in vulnerability research exploit development and reverse engineering

https://github.com/pwnfuzz/diffrays

@reverseengine

ghidraMCP

Now AI Can Reverse Malware

https://www.youtube.com/watch?v=u2vQapLAW88

@reverseengine

Aiding Reverse Engineering with Rust and a local LLM

https://security.humanativaspa.it/aiding-reverse-engineering-with-rust-and-a-local-llm/

@reverseengine

Chaos Rootkit

https://github.com/ZeroMemoryEx/Chaos-Rootkit

@reverseengine

Reverse Engineering Focusing on x64 Windows

https://github.com/FaxHack/Reverse-Engineering-Course


@reverseengine

Reverse Engineering Windows 7 Minesweeper

https://vollragm.github.io/posts/minesweeper

@reverseengine

System Programming Roadmap

https://github.com/ujjwal-kr/system-programming-roadmap

@reverseengine

WatchDog Killer BYOVD

https://3xploit666.com/post/whatdog-killer-byovd-0cb155a0

@reverseengine

Free Malware Analysis and Reverse Engineering Course

class.malware.re

@reverseengine

بخش دوم بافر اورفلو

چطور استک کار میکنه؟ (فریم تابع و آدرس بازگشت)

ساختار فریم تابع در استک


نمایش saved return address و saved base pointer یادگرفتن اینکه چجوری ببینیم فریم ها داخل دیباگر و تشخیص نقاطی ان که overflow میتونه تاثیر بزاره روشون

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

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

وقتی تابعی فراخوانی میشه یک فریم روی استک ساخته میشه فریم شامل پارامترها و local variables و saved base pointer و saved return address است

در معماری x86 64 معمولا که رجیستر rbp برای لینک فریم استفاده میشه و آدرس بازگشت بالای فریم قرار میگیره اگر یک بافر محلی روی استک قرار داشته باشه و داده بیش از حد نوشته بشه میتونه تا saved rbp و saved return address میتونه پیش بره و اونها رو بازنویسی کنه بازنویسی saved return address یعنی وقتی تابع برمیگرده برنامه ممکنه به جای آدرس درست به آدرس دیگه ای بره یا کرش کنه

نمایش فریم در دیباگر
در gdb با دستور backtrace میتونیم زنجیره فراخوانی ها رو ببینیم
با دستور info frame یا display memory میتونیم محتوای فریم جاری رو مشاهده کنیم
ما  میگیم saved return address کجاست و چجوری میتونیم offset بین ابتدای بافر و آدرس بازگشت رو محاسبه کنیم

کد فایل demo2c

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

void vulnerable(char *input) {
    char buffer[24];
    printf("in vulnerable function\n");
    strcpy(buffer, input);
    printf("after strcpy\n");
}

int main(int argc, char **argv) {
    if (argc < 2) {
        printf("usage demo2 input\n");
        return 1;
    }
    vulnerable(argv[1]);
    printf("returned normally\n");
    return 0;
}

راهنمای اجرا
gcc -g demo2.c -o demo2

در VM امن و با snapshot اجرا کنید

gdb --args ./demo2 $(python3 -c "print('A'*80)")

داخل gdb از دستورات زیر استفاده کنید

break vulnerable
run
info frame
x/40gx $rbp
disassemble
continue

بعد از کرش از backtrace استفاده کنید

Part 2 Buffer Overflow

How does stack work? (Function Frame and Return Address)

Function Frame Structure on the Stack

Showing Saved Return Address and Saved Base Pointer Learn how to view frames in the debugger and identify where they can be affected by overflow

We want to understand what goes on the stack when a function is called and why this is important for buffer overflow

We will examine the function frame and return address and learn how to view frames in gdb

When a function is called, a frame is created on the stack. The frame contains parameters and local variables, the saved base pointer, and the saved return address

In the x86 64 architecture, the rbp register is usually used for frame linking and the return address is placed above the frame. If a local buffer is on the stack and too much data is written, it can go up to the saved rbp and saved return address and overwrite them. Overwriting the saved return address means that when the function returns, the program may go to another address instead of the correct address or Crash

Displaying frames in the debugger
In gdb, with the backtrace command, we can see the chain of calls
With the info frame or display memory command, we can see the contents of the current frame
We say where the saved return address is and how we can calculate the offset between the beginning of the buffer and the return address

Demo2c file code

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

void vulnerable(char *input) {
char buffer[24];
printf("in vulnerable function\n");
strcpy(buffer, input);
printf("after strcpy\n");
}

int main(int argc, char **argv) {
if (argc < 2) {
printf("usage demo2 input\n");
return 1;
}
vulnerable(argv[1]);
printf("returned normally\n");
return 0;
}

Run Guide
gcc -g demo2.c -o demo2

Run in a secure VM with snapshot

gdb --args ./demo2 $(python3 -c "print('A'*80)")

Inside gdb use the following commands

break vulnerable
run
info frame
x/40gx $rbp
disassemble
continue

Use backtrace after crash

@reverseengine