I Jailbroke DeepSeek… And It Got SCARY
https://youtu.be/HDkI_z3IQ9s?si=2ou0gw8vJYkVlB7T
https://youtu.be/HDkI_z3IQ9s?si=2ou0gw8vJYkVlB7T
YouTube
I Jailbroke DeepSeek… And It Got SCARY
All demonstrations are intended solely for lawful, ethical, and defensive use. The creator assumes no liability for actions viewers take; attempting to replicate any activity on systems without authorization is illegal and may result in criminal or civil…
Understanding_the_Linux_Kernel_Daniel_P_Bovet,_Marco_Cesati.pdf
4.8 MB
Main Chapters:
Introduction
Memory Addressing
Processes
Interrupts and Exceptions
Timing Measurements
Memory Management
Process Address Space
System Calls
Signals
Process Scheduling
Kernel Synchronization
The Virtual Filesystem
I/O Device Management
Disk Caches
Accessing Regular Files
Swapping
The Ext2 Filesystem
Process Communication
Program Execution
Appendices: System Startup, Modules, Source Code Structure
Introduction
Memory Addressing
Processes
Interrupts and Exceptions
Timing Measurements
Memory Management
Process Address Space
System Calls
Signals
Process Scheduling
Kernel Synchronization
The Virtual Filesystem
I/O Device Management
Disk Caches
Accessing Regular Files
Swapping
The Ext2 Filesystem
Process Communication
Program Execution
Appendices: System Startup, Modules, Source Code Structure
Karta – Matching Open Sources in Binaries
https://research.checkpoint.com/karta-matching-open-sources-in-binaries/
https://research.checkpoint.com/karta-matching-open-sources-in-binaries/
Check Point Research
Karta – Matching Open Sources in Binaries - Check Point Research
Research by: Eyal Itkin Introduction “Karta” (Russian for “map”) is a source code assisted binary matching plugin for IDA. The plugin was developed to match symbols for an open source library in a very large binary, usually a firmware file. For those who…
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
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
GitHub
GitHub - x86byte/Obfusk8: Obfusk8: lightweight Obfuscation library based on C++17 / Header Only for windows binaries
Obfusk8: lightweight Obfuscation library based on C++17 / Header Only for windows binaries - x86byte/Obfusk8
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:
The script modifies the binary in-place. No backup is created.
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.
GitHub
GitHub - x86byte/Obfusk8: Obfusk8: lightweight Obfuscation library based on C++17 / Header Only for windows binaries
Obfusk8: lightweight Obfuscation library based on C++17 / Header Only for windows binaries - x86byte/Obfusk8
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
- 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
https://github.com/kernelstub/NTForge
Bypassing Denuvo in Hogwarts Legacy
https://momo5502.com/posts/2024-03-31-bypassing-denuvo-in-hogwarts-legacy/
https://momo5502.com/posts/2024-03-31-bypassing-denuvo-in-hogwarts-legacy/
Maurice's Blog
Bypassing Denuvo in Hogwarts Legacy
When I announced my Black Ops 3 integrity bypass, someone commented that my research was not impressive and I should try analyzing Denuvo instead.
That kinda stuck with me, so I did what everyone would do and spent the last 5 months of my free time reverse…
That kinda stuck with me, so I did what everyone would do and spent the last 5 months of my free time reverse…
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)
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)
0xRick's Blog
A dive into the PE file format - Introduction
A dive into the PE file format - Introduction What is this ? This is going to be a series of blog posts covering PE files in depth, it’s going to include a range of different topics, mainly the structure of PE files on disk and the way PE files get mapped…
GitRunner-C2
C2 framework abusing GitLab self-hosted runners as implants — Vue 3 operator UI, NGINX proxy, full file transfer and detection coverage.
Blog: https://vrls.ws/posts/abusing-gitlab-ci-runners-as-c2/
C2 framework abusing GitLab self-hosted runners as implants — Vue 3 operator UI, NGINX proxy, full file transfer and detection coverage.
Blog: https://vrls.ws/posts/abusing-gitlab-ci-runners-as-c2/
Dispatcher قلب ماشین مجازی
اگر فقط یک قسمت از VMProtect یا هر Virtual Machine رو بخواید تحلیل کنید اون قسمت Dispatcher هست
Dispatcher
مسئول اینه که تصمیم بگیره الان کدوم Opcode باید اجرا بشه
بدون Dispatcher هیچ Opcode ی اجرا نمیشه
فرض کنید این بایت کد رو داریم:
اینجا:
01 یعنی LOAD
02 یعنی ADD
03 یعنی PRINT
Dispatcher
اولین بایت (01) رو میخونه تشخیص میده Opcode از نوع LOAD هست و کنترل رو به Handler مربوط به LOAD میده
بعد دوباره برمیگرده
حالا Opcode بعدی (02) رو میخونه و Handler مربوط به ADD اجرا میشه
دوباره برمیگرده
در آخر Opcode 03 اجرا میشه
در تمام این مدت فقط Dispatcher داره تصمیم میگیره مرحله بعدی چیه
به همین خاطر بهش میگن قلب ماشین مجازی
در اکثر ماشینهای مجازی این چرخه دائماً
تکرار میشه:
به این چرخه معمولا Fetch → Decode → Execute گفته میشه
تقریبا تمام CPU های دنیا هم با همین ایده کار میکنن
تنها تفاوت اینه که CPU دستورهای واقعی پردازنده رو اجرا میکنه ولی ماشین مجازی دستورهای اختصاصی خودش رو
وقتی Dispatcher رو داخل دیس اسمبل پیدا کنید معمولا چند نشونه میبینی:
یک حلقه که دائما تکرار میشه
خواندن یک بایت از حافظه یا جدول Opcode ها
یک پرش غیرمستقیم یا انتخاب بین چند Handler
برگشت دوباره به ابتدای حلقه
به همین دلیل تحلیلگرها معمولا از Dispatcher شروع میکنن چون تمام مسیرهای اجرا از اون عبور میکنن
تمرین:
یک برنامه ساده بنویس که فقط سه Opcode داشته باشه:
بعد 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:
Here:
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:
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
اگر فقط یک قسمت از 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
بعد 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
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
🔥1
Persistence ماندگاری داده
فرض کنید فایل زیر رو ذخیره میکنید:
report.docx
بعد سیستم رو خاموش میکنید
روز بعد دوباره روشن میکنید
فایل هنوز وجود داره
چرا؟
چون داده روی حافظه دائمی ذخیره شده
اگر سیستمعامل Persistence نداشت:
با خاموش شدن سیستم همه چیز پاک میشد
هیچ فایلی وجود نداشت
هیچ دیتابیسی وجود نداشت
وظیفه سیستمعامل
سیستمعامل باید:
فایلها رو ذخیره میکنن
پوشهها رو مدیریت میکنن
خرابی اطلاعات رو کاهش میده
عملیات دیسک رو مدیریت میکنن
چرا برای مهندسی معکوس مهمه؟
چون بدافزارها و برنامهها دائما با موارد زیر کار میکنن:
اگر 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:
If you do not understand the File System, it becomes difficult to analyze many of the behavior of the program
@reverseengine
فرض کنید فایل زیر رو ذخیره میکنید:
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