Obfusk8 v1.5 released!

Enhanced AES string obfuscation with improved decryption reliability and stronger PE obfuscation hardening. Smoother, more resilient code protection.

https://github.com/x86byte/Obfusk8/releases/tag/v1.5

Post-Build PE Obfuscation

Obfusk8 includes a post-build script to further harden the compiled binary by removing forensic artifacts.

* Script Location: Obfusk8/Obfusk8/SCRIPTS/obfuscate_pe.ps1 at main · x86byte/Obfusk8
* What it does:
1. Strips the Rich Header — removes the MSVC build-environment fingerprint that reveals compiler version and toolchain details.
2. Spoofs the TimeDateStamp — replaces the PE header timestamp with a fixed value to obscure build time.
3. Clears the Debug Directory — wipes debug directory entries that could leak PDB paths or build metadata.
* Usage:
Run as a post-build step after compiling:
powershell PowerShell -NoProfile -ExecutionPolicy Bypass -File Obfusk8/SCRIPTS/obfuscate_pe.ps1 -Path "path\to\Obfusk8.exe"

The script modifies the binary in-place. No backup is created.

We’re building a small community around binary security research, focused on things like:

- Reverse Engineering
- Binary Obfuscation / Deobfuscation
- Exploit Development
- Compiler / interpreters...
- Malware Analysis
- Binary Hardening research

we also work on open source tools and experiments here:
GitHub → BinaryHardening GitHub
Discord → BinaryHardening Discord

Toolkit for Windows internals, vulnerability analysis, and reproducible security research workflows.

https://github.com/kernelstub/NTForge

Bypassing Denuvo in Hogwarts Legacy

https://momo5502.com/posts/2024-03-31-bypassing-denuvo-in-hogwarts-legacy/

A dive into the PE file format

https://0xrick.github.io/win-internals/pe1/
https://0xrick.github.io/win-internals/pe2/
https://0xrick.github.io/win-internals/pe3/
https://0xrick.github.io/win-internals/pe4/
https://0xrick.github.io/win-internals/pe5/
https://0xrick.github.io/win-internals/pe6/
[Mastering PE Structure for Malware Analysis: A Layman’s Guide](https://tech-zealots.com/malware-analysis/pe-portable-executable-structure-malware-analysis-part-2/)
[Peering Inside the PE: A Tour of the Win32 Portable Executable File Format](https://coffi.readthedocs.io/en/latest/peering_inside_pe.pdf)
https://0xrick.github.io/win-internals/pe8/

packages:
- c++ : https://lief.re/doc/stable/formats/pe/cpp.html
- rust : https://docs.rs/pe-parser/latest/pe_parser/
- python : https://pypi.org/project/pe-parser/


questions? :
- [What does "e_lfanew" mean in the DOS header for the PE format?](https://stackoverflow.com/questions/47711282/what-does-e-lfanew-mean-in-the-dos-header-for-the-pe-format)
- [Disassemble Windows PE .data section (using python)](https://stackoverflow.com/questions/58775954/disassemble-windows-pe-data-section)
- [Loading a 64-bit Windows PE file from memory](https://stackoverflow.com/questions/68988499/loading-a-64-bit-windows-pe-file-from-memory)

Dispatcher قلب ماشین مجازی

اگر فقط یک قسمت از VMProtect یا هر Virtual Machine رو بخواید تحلیل کنید اون قسمت Dispatcher هست
Dispatcher
مسئول اینه که تصمیم بگیره الان کدوم Opcode باید اجرا بشه
بدون Dispatcher هیچ Opcode ی اجرا نمیشه
فرض کنید این بایت کد رو داریم:

01 10
02 20
03

اینجا:

01 یعنی LOAD
02 یعنی ADD
03 یعنی PRINT

Dispatcher
اولین بایت (01) رو میخونه تشخیص میده Opcode از نوع LOAD هست و کنترل رو به Handler مربوط به LOAD میده

بعد دوباره برمیگرده
حالا Opcode بعدی (02) رو میخونه و Handler مربوط به ADD اجرا میشه
دوباره برمیگرده
در آخر Opcode 03 اجرا میشه
در تمام این مدت فقط Dispatcher داره تصمیم میگیره مرحله بعدی چیه
به همین خاطر بهش میگن قلب ماشین مجازی
در اکثر ماشین‌های مجازی این چرخه دائماً
تکرار میشه:

خواندن Opcode

تشخیص نوع Opcode

اجرای Handler

برگشت به Dispatcher

خواندن Opcode بعدی

به این چرخه معمولا Fetch → Decode → Execute گفته میشه

تقریبا تمام CPU های دنیا هم با همین ایده کار میکنن
تنها تفاوت اینه که CPU دستورهای واقعی پردازنده رو اجرا میکنه ولی ماشین مجازی دستورهای اختصاصی خودش رو
وقتی Dispatcher رو داخل دیس‌ اسمبل پیدا کنید معمولا چند نشونه میبینی:

یک حلقه که دائما تکرار میشه

خواندن یک بایت از حافظه یا جدول Opcode ها

یک پرش غیرمستقیم یا انتخاب بین چند Handler

برگشت دوباره به ابتدای حلقه

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

تمرین:

یک برنامه ساده بنویس که فقط سه Opcode داشته باشه:

LOAD
XOR
PRINT

بعد Dispatcher اونو رسم کنید
لازم نیست کد بنویسید فقط روی کاغذ مشخص کنید هر Opcode بعد از Dispatcher به کجا میره
وقتی این مفهوم رو کاملا درک کنید فهمیدن ماشین‌های مجازی پیچیده مثل VMProtect خیلی ساده‌تر میشه



Dispatcher is the heart of the virtual machine

If you want to analyze only one part of VMProtect or any Virtual Machine, that part is Dispatcher

Dispatcher
is responsible for deciding which Opcode should be executed now

Without Dispatcher, no Opcode can be executed

Suppose we have this byte code:

01 10

02 20

03

Here:

01 means LOAD

02 means ADD

03 means PRINT

Dispatcher
reads the first byte (01) and recognizes that the Opcode is of type LOAD and passes control to the Handler related to LOAD

Then it returns again

Now it reads the next Opcode (02) and the Handler related to ADD is executed

It returns again
Finally, Opcode 03 is executed

All this time, only Dispatcher is deciding what the next step is

That is why it is called the heart of the virtual machine

In most virtual machines, this cycle
is constantly
repeated:

Reading Opcode

Determining type Opcode

Execution of Handler

Return to Dispatcher

Read next Opcode

This cycle is usually called Fetch → Decode → Execute

Almost all CPUs in the world work with the same idea

The only difference is that the CPU executes the actual processor instructions, but the virtual machine executes its own instructions

When you find the Dispatcher in the disassembler, you will usually see a few signs:

A loop that repeats itself over and over

Reading a byte from memory or the Opcode table

An indirect jump or selection between several Handlers

Return to the beginning of the loop

That is why analysts usually start with the Dispatcher because all execution paths pass through it

Exercise:

Write a simple program that has only three Opcodes:

LOAD
XOR
PRINT

Then draw the Dispatcher

You don't need to write the code, just mark on paper where each Opcode goes after the Dispatcher

Once you fully understand this concept, understanding machines Complex virtualization like VMProtect becomes much simpler

@reverseengine

Persistence ماندگاری داده

فرض کنید فایل زیر رو ذخیره میکنید:

report.docx

بعد سیستم رو خاموش میکنید
روز بعد دوباره روشن میکنید
فایل هنوز وجود داره

چرا؟

چون داده روی حافظه دائمی ذخیره شده
اگر سیستم‌عامل Persistence نداشت:
با خاموش شدن سیستم همه چیز پاک میشد

هیچ فایلی وجود نداشت
هیچ دیتابیسی وجود نداشت

وظیفه سیستم‌عامل

سیستم‌عامل باید:

فایل‌ها رو ذخیره میکنن
پوشه‌ها رو مدیریت میکنن
خرابی اطلاعات رو کاهش میده
عملیات دیسک رو مدیریت میکنن

چرا برای مهندسی معکوس مهمه؟

چون بدافزارها و برنامه‌ها دائما با موارد زیر کار میکنن:

Files
Registry
Logs
Databases
Disk I/O

اگر File System رو نفهمید تحلیل بسیاری از رفتارهای برنامه سخت میشه




Persistence of data

Suppose you save the following file:

report.docx

Then you shut down the system

You turn it back on the next day
The file still exists

Why?

Because the data is stored in permanent memory

If the operating system did not have persistence:

Everything would be erased when the system was shut down

There would be no files

There would be no databases

Operating system tasks

The operating system must:

Store files

Manage folders

Reduce data corruption

Manage disk operations

Why is it important for reverse engineering?

Because malware and programs constantly work with:

Files

Registry

Logs

Databases

Disk I/O

If you do not understand the File System, it becomes difficult to analyze many of the behavior of the program

@reverseengine

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

Heap Overflow
از دید یک Reverse Engineer

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

Heap اصلا چیه

بخشی از حافظه است که برنامه موقع اجرا هر وقت به حافظه بیشتری نیاز داشته باشه ازش استفاده میکنه
برخلاف Stack که خودکار مدیریت میشه
Heap کاملا تحت کنترل برنامه است
یعنی برنامه خودش درخواست حافظه میده
بعد هم خودش باید آزادش کنه

دو تابعی که همیشه میبینید

تقریبا تو هر برنامه C این دو تابع رو میبینید

malloc() free()

malloc حافظه رزرو میکنه

free هم همون حافظه رو آزاد میکنه

یک مثال ساده:

#include <stdlib.h> int main() { char *buf = malloc(32); free(buf); return 0; }


پشت صحنه چه اتفاقی میوفته

وقتی malloc(32) صدا زده میشه
برنامه فقط 32 بایت داده نمیگیره
کتابخانه مدیریت حافظه کنار اون داده یکسری اطلاعات مدیریتی هم ذخیره میکنه

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

از دید مهندسی معکوس

وقتی داخل Ghidra یا IDA تابعی مثل این رو ببینید

char *buf = malloc(64)

strcpy(buf, input)

memcpy(buf, input, len)

باید بررسی کنید
آیا اندازه ورودی واقعا با اندازه Chunk یکیه یا نه

فرق Heap Overflow با Stack Overflow

در Stack Overflow معمولا هدف Return Address بود

ولی در Heap Overflow معمولا Return Address وجود نداره

در عوض چیزی که اهمیت داره ساختار Heap و داده‌های کنار حافظه است
به همین خاطر روش تحلیل این دو کاملا فرق میکنه

موقع آنالیز باینری دنبال چی بگردیم

اگر این الگوها رو دیدید بیشتر دقت کنید

malloc(...)

بعد از اون
strcpy(...)

یا
memcpy(...)

یا

read(...)

اگر اندازه ورودی کنترل نشده باشه
احتمال وجود Heap Overflow بیشتر میشه

نکته مهم

هر جا malloc دیدید به معنی آسیب‌ پذیری نیست

باید ببینید
چقدر حافظه گرفته شده
چقدر داده داخلش نوشته میشه
آیا قبل از نوشتن بررسی اندازه انجام شده یا نه

Heap با Stack فرق داره

حافظه Heap با malloc گرفته میشه
هر قطعه حافظه یک Chunk داره
و در مهندسی معکوس باید مسیر
ورودی → malloc → نوشتن داده
رو دنبال کنیم

چالش این قسمت:

یک برنامه ساده که از malloc استفاده میکنه داخل Ghidra باز کنید
مسیر حرکت داده از ورودی تا حافظه Heap رو پیدا کنید و مشخص کنید داده دقیقا کجا نوشته میشه

@reverseengine

Part 19 Buffer Overflow

Heap Overflow
From a Reverse Engineer's Perspective

So far, we have worked mostly with the stack

But many real vulnerabilities occur on the heap

Before we try to analyze heap overflow, we must first understand the heap itself

What is the heap?

It is a part of memory that the program uses whenever it needs more memory during execution

Unlike the stack, which is automatically managed

The heap is completely under the control of the program

That is, the program itself requests memory

Then it must free it

Two functions that you always see

You will see these two functions in almost every C program

malloc() free()

malloc reserves memory

free also frees the same memory

A simple example:

#include <stdlib.h> int main() { char *buf = malloc(32); free(buf); return 0; }

What happens behind the scenes

When malloc(32) is called

The program doesn't just get 32 bytes of data

The memory management library also stores some management information along with that data

This collection is usually called a Chunk

Each Chunk has two parts

Management information

Data that the program uses

From a reverse engineering perspective

When you see a function like this in Ghidra or IDA

char *buf = malloc(64)

strcpy(buf, input)

memcpy(buf, input, len)

You need to check

Is the input size really the same as the Chunk size or not

The difference between Heap Overflow and Stack Overflow

In Stack Overflow, the target was usually the Return Address

But in Heap Overflow, there is usually no Return Address

Instead, what matters is the structure of the Heap and the data next to the memory

That's why the analysis method for these two is completely different

What to look for when analyzing binary Let's look

If you see these patterns, pay more attention

malloc(...)

After that

strcpy(...)

or

memcpy(...)

or

read(...)

If the input size is not controlled
The probability of Heap Overflow increases

Important point

Wherever you see malloc, it does not mean a vulnerability

You need to see
How much memory is taken
How much data is written into it
Whether the size check is done before writing

Heap is different from Stack

Heap memory is taken with malloc
Each piece of memory has a Chunk
And in reverse engineering, we need to follow the path
Input → malloc → writing data

Challenge of this part:

Open a simple program that uses malloc in Ghidra
Find the path of data movement from input to Heap memory and determine where exactly the data is written

@reverseengine

Windows Process Injection: Print Spooler

https://modexp.wordpress.com/2019/03/07/process-injection-print-spooler

https://azeria-labs.com/heap-exploitation-part-1-understanding-the-glibc-heap-implementation/ #exploit #dukeBarman

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

Hello friends, I hope you are well. If I haven't been very active these past few days, and I haven't been posting, it's because of the World Cup, and unfortunately their time zone is not the same as ours, and there are a number of problems that have come up for me. When it's OK, we'll be back with full force again. It won't be long. I'll be back in a few days. I love you all,
Alone. 🖤

امشب دوباره شروع میکنیم.

We start again tonight.