ch
Feedback
ReverseEngineering

ReverseEngineering

前往频道在 Telegram
1 265
订阅者
无数据24 小时
-37 天
+730 天
帖子存档
Exploit Development: Investigating Kernel Mode Shadow Stacks on Windows https://connormcgarr.github.io/km-shadow-stacks/ @reverseengine

🔒 New Persist Technique in Windows! 📌 Article Summary: In this section, we will introduce a persistence technique in Windows that is implemented using DLL injection and replacement with user access. In this method, the malicious DLL file is executed by the svchost.exe process, allowing continuous and secret code execution on the target system. #RedTeam #CyberSecurity #Maldev #Persistence #WindowsInternals 💬 Forum  📣 DarkBit

Repost from DarkBit
Password: @DarkBitx

Repost from DarkBit
🔒 تکنیک جدید Persist در ویندوز!  📌 خلاصه مقاله:  در این بخش به معرفی یک تکنیک پایداری (Persistence) در ویندوز می‌پردازیم که با استفاده از تزریق و جایگزینی DLL با دسترسی کاربر پیاده‌سازی شده است. در این روش، فایل DLL مخرب توسط فرآیند svchost.exe اجرا می‌شود و امکان اجرای مداوم و مخفیانه کد در سیستم هدف را فراهم می‌سازد. #RedTeam #CyberSecurity #Maldev #Persistence #WindowsInternals 💬 Forum  📣 DarkBit

Repost from GO-TO CVE
🎯 Week 79 — CVE‑2025‑32433 — Erlang/OTP SSH — Pre‑Auth RCE 🔹 CVE: CVE‑2025‑32433 🔹 Type: Remote Code Execution (pre‑authentication flaw in Erlang/OTP SSH server) 🔹 Impact: Full system compromise via crafted SSH messages — no credentials required 🔹 Fixed in: OTP‑27.3.3 / OTP‑26.2.5.11 / OTP‑25.3.2.20 🔹 Action: Patch immediately or disable SSH / restrict access by firewall Exploit #week_79

Introducing Lumen Server Protocol
https://abda.nl/posts/introducing-lumen/
A private Lumina server for IDA Pro
https://github.com/naim94a/lumen
Investigating IDA Lumina Feature
https://www.synacktiv.com/en/publications/investigating-ida-lumina-feature.html
Local server for IDA Lumina feature
https://github.com/synacktiv/lumina_server
@reverseengine

قسمت دهم بافر اورفلو
تست کنترل کامل RIP/EIP میخوایم به برنامه بگیم که میتونیم RIP/EIP رو کنترل کنیم یعنی کاری کنیم که مقدار ریجستر بشه 0x42424242 یا 4222222 هگز معادل BBBB اگه این مرحله موفق بشه یعنی: ما وارد مغز برنامه شدیم از اینجا به بعد میتونیم مسیر اجرای برنامه رو خودمون تعیین کنیم ساختن ورودی تست کنترل الان باید یه ورودی بسازیم که: 112 کاراکتر اول  هرچی مثلا “A” جای RIP  4 تا کاراکتر “B” چون “B” در ASCII میشه 0x42  پس RIP باید بشه 0x42424242 برای مثال پایتونی ساده:
from pwn import * offset = 112 payload = b"A" * offset payload += b"B" * 8     برای 64bit معمولا 8 بایت برای 32bit چهار بایت print(payload)
اجرای برنامه با پیلود کنترل برنامه رو اجرا میکنیم:
./vuln $(python3 exploit.py)
یا اگر ورودی از stdin میخواد:
python3 exploit.py | ./vuln
چک کردن اینکه RIP کنترل شده داخل gdb:
(gdb) run < <(python3 exploit.py)
(gdb) info registers
اگر همه چی درست باشه باید ببینید:
RIP: 0x4242424242424242
یا تو نسخه 32bit:
EIP: 0x42424242
Part 10 Buffer Overflow
Full RIP/EIP Control Test We want to tell the program that we can control RIP/EIP That is, we make the register value 0x42424242 or 4222222 hex equivalent to BBBB If this step is successful, it means: We have entered the brain of the program From here on, we can determine the path of the program execution ourselves Creating a control test input Now we need to create an input that: The first 112 characters of anything, for example “A” Instead of RIP, 4 characters “B” Since “B” is 0x42 in ASCII, then RIP should be 0x42424242 For a simple Python example:
from pwn import * offset = 112 payload = b"A" * offset payload += b"B" * 8 For 64bit, usually 8 bytes, for 32bit, four Byte print(payload)
Running the program with the control payload We run the program:
./vuln $(python3 exploit.py)
Or if it asks for input from stdin:
python3 exploit.py | ./vuln
Checking that RIP is controlled Inside gdb:
(gdb) run < <(python3 exploit.py)
(gdb) info registers
If everything is correct you should see:
RIP: 0x4242424242424242
Or in 32bit version:
EIP: 0x42424242
@reverseengine

Powerful automated tool for reverse engineering Unity IL2CPP binaries https://github.com/djkaty/Il2CppInspector @reverseengine

Nim implementation of Process Hollowing using syscalls (for educational purposes) https://github.com/snovvcrash/NimHollow @reverseengine

IDA Pattern Search is a plugin that adds a capability of finding functions according to bit-patterns into the well-known IDA Pro https://forum.reverse4you.org/t/idapatternsearch-adds-a-capability-of-finding-functions-according-to-bit-patterns/17209 @reverseengine

پاک کردن واقعی True Deletion پاک کردن واقعی تو ردزون یعنی چی تو ردزون فقط این مهم نیست که چی میریزید رو هارد مهم‌ ترش اینه که چی باید از بین بره که هیچ اثری ازش نمونه پاک کردن واقعی همون چیزیه که باعث میشه ریورس کاز حرفه‌ای با فرق از آماتور شناخته بشه چی باید حذف بشه اهداف میانی ابزارهای مصرفی این‌ها همون چیزایی‌ ان که تو مسیر عملیات درست میشن: فایل‌های خروجی ابزارها اسکریپت‌های موقتی DLL های تزریقی config های تست فایل‌هایی که فقط برای یک مرحله استفاده شدن این‌ها اگه بمونن = هم لو رفتن عملیات هم باگ امنیتی مشکل اصلی اینجاست: Windows پاک نمیکنه  فقط unlink میکنه وقتی یه فایل Delete میکنید فقط از جدول فایل‌ها حذف میشه اما بیشتر حجم  اطلاعات تو دیسک میمونه یعنی با Forensics راحت قابل ریکاوریه پاک کردن واقعی یعنی: پاک کردن Metadata پاک کردن محتوا Overwriting پاک کردن اثرهای Cached پاک کردن Prefetch + EventLogs بعضی سناریو ها روش‌های پاک سازی Overwrite امن یعنی داده قدیمی با صفر/رندوم باز نویسی بشه تا برنگرده خیلیا فکر می‌کنن 7-pass یا 35-pass لازمه نه! روی SSD یک پاس رندوم هم معمولا کافیه حذف log های بی‌ اثر غیرسیستمی مثلا لاگ‌های لوکال ابزارهایی که خودتون اجرا کردید  نه سیستم اینکار برای پاک‌ کردن کار های خودتون طبیعی و امنه Memory Cleanup خیلیا حواسشون نیست ولی artifact های زیر توی RAM میمونن: کلیدهای crypto مصرفی بایت‌ کد ابزار Buffer های network داده‌های حساس پاک کردن حافظه یعنی: بستن پروسه‌ ها پاک کردن Handle ها Zero کردن buffer های حساس چیا معمولا جا میمونه؟ و باعث لو رفتن ابزار میشه Artifact های PowerShell History Temp folderها فایل‌های Extract شده از Zip Jump Listها Recent Items Prefetch Crash dumpها registry keys مرتبط با ابزار یا اجرا این‌ها 90٪ مواقع باعث لو رفتن میشن True Deletion What does true deletion mean in Redzone In Redzone, it's not just about what you put on the hard drive, it's more important that what needs to be removed so that no trace of it remains. True deletion is what makes a professional reverse engineer different from an amateur. What needs to be deleted Intermediate goals of consumer tools These are the things that are created along the way: Tool output files Temporary scripts Injected DLLs Test configs Files that are only used for one step If these remain = both the operation and the security bug The main problem here is: Windows does not delete, it only unlinks When you delete a file, it is only deleted from the file table, but most of the information remains on the disk, which means it can be easily recovered with Forensics True deletion means: Erasing Metadata Erasing content  Overwriting Clearing Cached traces Clearing Prefetch + EventLogs Some scenarios Clearing methods Safe overwrite That means overwriting old data with zero/random so that it doesn't come back Many people think that 7-pass or 35-pass is not necessary! On SSD, a random pass is usually enough Delete ineffective non-system logs For example, local logs of tools that you run yourself, not the system This is normal and safe for clearing your own work Memory Cleanup Many people don't pay attention, but the following artifacts remain in RAM: Used crypto keys Tool bytecode Network buffers Sensitive data Clearing memory means: Closing processes Clearing handles Zeroing sensitive buffers What usually remains? And it causes tool leaks Artifacts PowerShell History Temp folders Files extracted from Zip Jump Lists Recent Items Prefetch Crash dumps Registry keys related to the tool or execution These cause leaks 90% of the time @reverseengine

Red zone فقط روی System V لینوکس/مک نه ویندوز یک فضای 128 بایتی پایین‌ تر از RSP که تابع بدون تغییر دادن RSP میتونه از اون استفاده کنه ویندوز red zone نداره همیشه فریم ساخته میشه؟ نه مواردی که Stack Frame ساخته نمیشه: تابع خیلی ساده باشد Leaf Function اگر تابع هیچ تابع دیگری رو call نکنه و رجیسترهای callee-saved رو استفاده نکنه و متغیر محلی هم نداشته باشه کامپایلر Frame رو حذف میکنه مثال:
int add(int a, int b) { return a + b; }
اسم این تکنیک: Frame Omission Optimization Red zone Only on System V Linux/Mac, not Windows A space 128 bytes below the RSP that a function can use without changing the RSP Windows does not have a red zone Is a frame always created? No Cases where a Stack Frame is not created: The function is very simple Leaf Function If the function does not call any other function And does not use callee-saved registers And does not have any local variables The compiler will omit the Frame Example:
int add(int a, int b) { return a + b; }
Name of this technique: Frame Omission Optimization