Low-Level Process Hunting on macOS

https://objective-see.com/blog/blog_0x4A.html

@reverseengine

JVM Reverse Engineering

https://medium.com/@Oscar404/jvm-reverse-engineering-99a12fd59eeb

@reverseengine

Reverse-Engineering Android APKs with JADX

https://blog1.neuralengineer.org/reverse-engineering-android-apks-with-jadx-ebded67ceb8f

@reverseengine

Decoding Brickstorms Garble strings

https://medium.com/walmartglobaltech/decoding-brickstorms-garble-strings-b0a60828b3cc

@reverseengine

How to Reverse-Engineer (with AI) an old Demoscene Exe

https://medium.com/@kevin.drapel/how-to-reverse-engineer-with-ai-an-old-demoscene-exe-part-1-07e22e48b0c2

@reverseengine

Reverse engineering of a crypto stealer

https://medium.com/@beardr3d/reverse-engineering-of-a-crypto-stealer-e768f0c20853

@reverseengine

LazyHook is a stealthy API hooking framework that bypasses Host Intrusion Prevention Systems (HIPS) through call stack spoofing. By leveraging CPU-level hardware breakpoints and Vectored Exception Handling, it executes arbitrary code as if it originated from trusted, Microsoft-signed modules—completely fooling behavioral analysis engines that rely on call stack inspection and module origin verification.

Evade behavioral analysis by executing malicious code within trusted Microsoft call stacks
Uses hardware breakpoints + VEH to hijack legitimate functions and spoof module origins

│ 1. Target Function Call
│ ↓
│ 2. CPU Debug Register Triggers (DR0-DR3) │
│ ↓
│ 3. EXCEPTION_SINGLE_STEP Raised │
│ ↓
│ 4. VEH Handler Intercepts Exception │
│ ↓
│ 5. Execution Redirected to Hook Function │
│ ↓
│ 6. CallOriginal() Temporarily Disables Breakpoint
│ ↓
│ 7. Original Function Executes │
│ ↓
│ 8. Breakpoint Re-enabled

#callstackspoofing #edr

X86-64 Assembly Language Programming with Ubuntu

@reverseengine

Linux rootkits explained

https://www.wiz.io/blog/linux-rootkits-explained-part-1-dynamic-linker-hijacking

@reverseengine

Singularity - Stealthy Linux Kernel Rootkit

https://blog.kyntra.io/Singularity-A-final-boss-linux-kernel-rootkit

https://github.com/MatheuZSecurity/Singularity?tab=readme-ov-file#installation

Piercing the Veil: Android Code Deobfuscation

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

@reverseengine

Updates on ThiefQuest, the Quickly-Evolving macOS Malware

https://blog.trendmicro.com/trendlabs-security-intelligence/updates-on-thiefquest-the-quickly-evolving-macos-malware

@reverseengine

Split 64 bits sep-firmware images

https://github.com/matteyeux/pysep

@reverseengine

Process Injection using DInvoke

https://rastamouse.me/blog/process-injection-dinvoke

@reverseengine

WEIZZ: Automatic Grey-Box Fuzzing for Structured Binary Formats

Slides: https://andreafioraldi.github.io/assets/weizz-issta2020-slides.pdf

Video: https://www.youtube.com/watch?v=MOeUqlFtgwE

Article: https://andreafioraldi.github.io/assets/weizz-issta2020.pdf

Code: https://github.com/andreafioraldi/weizz-fuzzer

@reverseengine

Breaking the BeeStation: Inside Our Pwn2Own 2025 Exploit Journey

https://www.synacktiv.com/en/publications/breaking-the-beestation-inside-our-pwn2own-2025-exploit-journey

@reverseengine

Exploiting an Envoy heap vulnerability

https://blog.envoyproxy.io/exploiting-an-envoy-heap-vulnerability-96173d41792

@reverseengine

Writing an iOS Kernel Exploit from Scratch

https://secfault-security.com/blog/chain3.html

@reverseengine

Rust reversing helper noscript

https://github.com/cha5126568/rust-reversing-helper

@reverseengine

Block Redo & Undo To Achieve Legacy IDA

https://github.com/tmr232/BRUTAL-IDA

@reverseengine

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

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


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



تشخیص توابع خطرناک در باینری

این یکی از سریع‌ترین روش‌ هاست


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


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

file.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
alloca

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

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

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 بره آسیب‌پذیری تقریبا قطعی میشه




نمونه اجرا

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

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

Part 14 Buffer Overflow

Detecting Buffer Overflow in Reverse Engineering with IDA, Ghidra and r2 tools

In this section, we will learn how to find out if there is a buffer overflow when you open a binary file

That is, without having the source and only by analyzing the functions, you can find dangerous inputs and sensitive paths. We only do binary inspection. No real exploits can be written. It is completely safe

Detecting dangerous functions in binary

This is one of the fastest methods

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

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

file.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;
}

Opening a binary in IDA or Ghidra

When you open a file in IDA, look for the names of dangerous functions

For example, if you see gets or strcpy in the view functions, that's a red flag.

Then go inside the function itself and look at the buffer size and where the input comes from.

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

This pattern is one of the most classic signs.

Seeing the function frame and buffer location.

In disassembly, look for commands like

sub rsp
alloca

These show where to create local space on the stack.

For example, the assembly of the copy_data function, when we disassemble it, we see something like this:

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