ReverseEngineering

Reverse-Engineering Android APKs with JADX https://blog1.neuralengineer.org/reverse-engineering-android-apks-with-jadx-ebded67ceb8f @reverseengine

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

Low-Level Process Hunting on macOS https://objective-see.com/blog/blog_0x4A.html @reverseengine

Python scripts to help analzye go binaries in radare2. Basically this is a port of the IDA pro script golang_load_assist to r2 https://github.com/f0rki/r2-go-helpers @reverseengine

Binary instrumentation framework based on FRIDA https://github.com/Ch0pin/medusa @reverseengine

Set of antianalysis techniques found in malware https://github.com/hasherezade/antianalysis_demos @reverseengine

کنترل واقعی EIP / RIP لحظه‌ای که مطمئن میشید CPU دقیقا همون کاری رو میکنه که شما میخواید تا اینجا: برنامه رو کرش دادید Offset دقیق رو پیدا کردید کنترل EIP/RIP یعنی چی؟ یعنی بتونید تعیین کنی CPU بعدش کجا رو اجرا کنه اگه بتونی مقدار EIP روی 32 بیت یا RIP روی 64 بیت رو خودتون پر کنید یعنی کنترل جریان اجرا افتاده دست شما   کنترل ساده فرض کنی  Offset = 524 بود یه payload ساده میسازیم:

"A" * 524 + "BBBB"

یا به شکل هگز:

0x42424242

حالا این ورودی رو به برنامه میدید اگه همه چیز درست باشه توی debugger میبینید:

EIP = 0x42424242 (32 بیت)

یا RIP شامل همون مقدار روی 64 بیت اگه کارایی که کردید درست بود کنترل EIP/RIP رو گرفتید چند حالت وجود داره: برنامه قبلش کرش میکنه احتمالاً: Offset اشتباهه یا یه چک امنیتی قبل از رسیدن به RIP فعال میشه مقدار RIP تغییر نکرد یعنی: داده‌ ی شما به اون رجیستر نرسیده یا overflow روی یه بافر دیگه اتفاق افتاده فقط کرش بدون کنترل یعنی کرش دارید ولی کنترل ندارید این فرق داره با exploit واقعی تفاوت 32 بیت و 64 بیت اینجا مشخص میشه روی 32 بیت: EIP مستقیم با 4 بایت پر میشه کنترل گرفتن خیلی واضح تره روی 64 بیت: RIP معمولا کامل overwrite نمیشه باید با stack alignment RSP و sometimes partial overwrite کار کنید اینجا اکسپلویت‌ نویسی جدیتر میشه چرا اینا مهمن: میتونید بپرید به: شل‌کد تابع system gadget های ROP یا حتی فقط اجرای یه تابع ساده رو تست کنید ولی بدون کنترل RIP/EIP هیچکدوم معنی نداره پیدا کردن Offset کافی نیست باید ثابت کنید که واقعا میتونی مقدار EIP یا RIP رو خودت تعیین کنید وقتی دیدید مقداری که میخاید داخل RIP نشسته یعنی CPU کاملا تحت کنترلتون قرار گرفته این فرق بین کرش ساده و اکسپلویت واقعیه Real EIP/RIP Control The moment you make sure the CPU is doing exactly what you want So far: You crashed the program You found the exact offset What is EIP/RIP control? That is, you can determine where the CPU will execute next If you can fill in the value of EIP on 32 bits or RIP on 64 bits yourself, that means you have control over the execution flow Simple control Let's assume Offset = 524 We create a simple payload:

"A" * 524 + "BBBB"

Or in hex:

0x42424242

Now you will see this input to the program If everything is correct, you will see in the debugger:

EIP = 0x42424242 (32 bits)

Or RIP contains the same value on 64 bits If what you did was correct You have taken control of EIP/RIP There are several cases: The program crashes before Probably: The offset is wrong Or a security check is activated before reaching RIP The RIP value has not changed That is: The data You didn't reach that register Or an overflow occurred on another buffer Just an uncontrolled crash That means you have a crash but no control This is different from a real exploit The difference between 32-bit and 64-bit is clear here On 32-bit: EIP is filled directly with 4 bytes Taking control is much clearer On 64-bit: RIP usually cannot be completely overwritten You have to work with stack alignment RSP and sometimes partial overwrite Here is where exploit writing gets more serious Why these are important: You can jump to: Shellcode System function ROP gadgets Or even just test the execution of a simple function But without RIP/EIP control, none of that makes sense Finding Offset is not enough, you have to prove that you can actually set the EIP or RIP value yourself. When you see the value you want sitting in RIP, you have full control over the CPU Taken This is the difference between a simple crash and a real exploit @reverseengine

Registry Artifact رجیستری مثل دفترچه‌ی خاطرات ویندوزه هر برنامه‌ ای یه چیزی توش مینویسه: مسیر آخرین فایل‌هایی که باز کردید برنامه‌هایی که اجرا شدن مسیرهای Run و RunOnce MRU (Most Recently Used) کلیدهای موقتی Component COM Object Service و Driver هایی که ساخته شدن AppCompat / Shim Cache خیلیاش حتی با پاک کردن فایل اجرایی هم پاک نمیشن مهمترین ردپاهای رجیستری که معمولا جا میمونن Run / RunOnce / Startup Items اگر برنامه‌ ای رو یه بار فقط تست کنید این مسیرها رو پیدا میکنه لاگش میمونه AppCompatCache / ShimCache فقط با اجرا شدن برنامه پر میشه حتی اگه هیچکاری نکرده باشید MUICache نرم‌افزار اجرا بشه اسمش اینجا ذخیره میشه UserAssist لیست فعالیت‌های کاربر با شمارنده RecentDocs هر فایلی که باز شده باشه اینجا لیست میشه TypedPaths / OpenSavePidlMRU وقتی از File Explorer یا Run استفاده بشه اثرش هست Services / Drivers Keys اگر برنامه‌ای سرویسی بالا بیاره یا تغییر بده ردپا طولانی مدت میمونه COM Registration گاهی ابزارا برای کارکردشون COM Object موقتی میسازن چجوری کمترشون کنید؟ بدونید که اجرای هر فایل = چند رجیستری جدید خیلیا فکر نمی‌کنن که حتی run کردن یه exe خالی AppCompatCache رو آلوده میکنه برنامه‌ تون رو طوری طراحی کنید که احتیاج به نوشتن رجیستری نداشته باشه اگه فقط read-only باشه ردپای کمتری داره مسیر های پیشبینی‌ نشده استفاده نکنید مثلاً ساختن key تو HKLM بدون نیاز حتی از دور معلومه Temporary Keys اگه لازم شد کلیدی ساخته بشه طراحی درست برنامه باید باعث حذف خودکارش بشه با COM کار نکنید مگر مجبور باشید COM بیشترین ردپای طولانی‌ مدت رو داره Registry Artifact The registry is like a Windows diary Every program writes something in it: Paths of the last files you opened Programs that were run Run and RunOnce paths MRU (Most Recently Used) Temporary keys Component COM Object Service and Driver That were created AppCompat / Shim Cache Most of them are not deleted even by deleting the executable file The most important registry traces that are usually left Run / RunOnce / Startup Items If you test a program only once, it will find these paths and log it AppCompatCache / ShimCache It is only filled when the program is run, even if you have not done anything MUICache When the software is run, its name is stored here UserAssist List of user activities with counters RecentDocs Every file that has been opened is listed here TypedPaths / OpenSavePidlMRU It works when using File Explorer or Run Services / Drivers Keys If a program starts or changes a service, it leaves a long-term footprint COM Registration Sometimes tools create temporary COM Objects for their work How to reduce them? Know that executing each file = several new registries Many don't think that even running an empty exe pollutes the AppCompatCache Design your program so that it doesn't need to write to the registry If it's read-only, it has a smaller footprint Don't use unexpected paths For example, creating a key in HKLM without need It's obvious even from afar Temporary Keys If a key needs to be created A properly designed program should automatically delete it Don't work with COM unless you have to COM has the most long-term footprint @reverseengine

Pointer Arithmetic مهمترین نکته برای Exploit:

a + i آدرس a + i * sizeof(type)

پس:

double arr[10];

و:

arr + 1

یعنی:

arr + (1 * 8)

نه 1 بایت 8 بایت همین موضوع برای باگ‌ های زیر مهمه:

Out-of-bounds read/write Heap corruption InfoLeak

Pointer Arithmetic The most important thing for Exploit:

a + i Address a + i * sizeof(type)

So:

double arr[10];

And:

arr + 1

That is:

arr + (1 * 8)

Not 1 byte, 8 bytes The same thing is important for the following bugs:

Out-of-bounds read/write Heap corruption InfoLeak

@reverseengine

انتشار کامل سورس کد بدافزار Hyena یک بدافزار سرقت اطلاعات با نام Hyena Stealer که به زبان Go توسعه ش دادن داخل اوسط سال 2024 شناسایی و در فروم‌ های دارک وب منتشر شده این بدافزار میتونه اطلاعات حساس رو از انواع سیستم‌ ها و برنامه‌ ها جمع کنه مثل: کیف‌ پول های ارز های دیجیتال مرورگر های وب حساب‌ های دیسکورد کلاینت‌های FTP مثل FileZilla کامپایلر ها برای کامپایل: کامپایلر GCC کامپایلر Go تنظیمات: آدرس Webhook دیسکورد خودتون رو داخل فایل config.go قرار بدید برای فعال‌ سازی حالت دیباگ به فایل time.go برید و متغیر DEBUG رو روی true تنظیم کنید

One Byte to rule them all - The new iOS kernel exploitation technique that turns a one-byte controlled heap overflow directly into a read/write primitive https://googleprojectzero.blogspot.com/2020/07/one-byte-to-rule-them-all.html @reverseengine

The core of Apple is PPL (Apple's Page Protection Layer): Breaking the XNU kernel's kernel https://googleprojectzero.blogspot.com/2020/07/the-core-of-apple-is-ppl-breaking-xnu.html @reverseengine

پاکسازی ردپای سیستم‌ فایلی FileSystem Artifacts FileSystem Artifact هرچی میسازید باز میکنید Extract میکنید حتی فقط لمس میکنید روی NTFS یه اثر میذاره ردپای سیستم فایل دقیقا همین اثرات رو داره:

MFT Records USN Journal Zone.Identifier ADS Alternate Data Streams Prefetch Recent Files Jump Lists ShellBags Thumbnails

یعنی حتی اگه فایلتوتو پاک کنید باز از این طرف و اون طرف لو میرید رایج‌ ترین ردپاهایی که معمولا جا میمونن MFT Entries هر فایلی که ساخته کپی Extract بشه تو Master File Table رکوردش میمونه USN Journal تقریبا قابل حذف نیست و همه تغییرات فایل رو log می‌نه Zone.Identifier وقتی فایلی از اینترنت میاد حتی از ابزار خودتون ویندوز میگه این از اینترنت اومده روش Alternate Data Stream میزاره گاهی ابزارا config یا متادیتا رو تو ADS ذخیره میکنن Prefetch هر فایل اجرایی که اجرا شد یه PF ساخت میشه Jump Lists Recent Items وقتی یه فایل باز یا اجرا میشه اینجا لیست میشه Thumbnail Cache اگه فایل تصویری باز شده باشه preview ش ذخیره میشه Temp / Roaming / LocalLow ابزا را هزار جور اثر ریز تو مسیر های جانبی میذارن هیچ روش مخربی توضیح نمیدم  فقط اصول حرفه‌ای و پاک فایلی که نمیخواید اثر بذاره اصلا روی دیسک نسازید تا میتونید memory-only کار کنید Extract نکنید مگر مجبور باشید بیشترین ردپا ها از همینه: zip → Extract → اجرا → حذف → پایان اما ردپاها باقی Prefetch-aware رفتار کنه اجرای فایل‌ های با اسم random، Prefetch لو بره سناریو های قانون باید بدونید چیزی که اجرا میکنید اثر long-term میذاره Zone.Identifier رو چک کنید اگه فایلی رو جا به‌ جا میکنی باید بدونید ویندوز حتی منبع اینترنتی رو علامت‌ گذاری میکنه Temp رو حواست باشه کلی ابزار خودشون فایل temp درست میکنن بدون اینکه شما بفهمید تغییرات جانبی مثل Thumbnail و JumpList رو پیشبینی کنید چیزی که Preview میزنید یا Open میکنید احتمالا Thumbnail میسازه File System Artifacts Cleanup FileSystem Artifact Everything you create, open, extract, even just touch leaves an impact on NTFS File system footprints have exactly the same effects:

MFT Records USN Journal Zone.Identifier ADS Alternate Data Streams Prefetch Recent Files Jump Lists ShellBags Thumbnails

That is, even if you delete your file, it will still be visible from here and there The most common footprints that are usually left MFT Entries Every file that is created, copied, extracted Its record is left in the Master File Table USN Journal It is almost impossible to delete and does not log all file changes Zone.Identifier When a file comes from the Internet, even from your own tool, Windows says that it came from the Internet, it uses the Alternate Data Stream method Sometimes tools store config or metadata in ADS Prefetch Every file  The executable that is run will create a PF Jump Lists Recent Items When a file is opened or executed, it will be listed here Thumbnail Cache If an image file is opened, its preview will be saved Temp / Roaming / LocalLow Tools leave a thousand kinds of small traces in side paths I will not explain any destructive methods, just professional and clean principles Do not create a file that you do not want to affect on the disk at all So that you can work memory-only Do not extract unless you have to Most traces are like this: zip → Extract → Run → Delete → End But traces remain Behave Prefetch-aware Executing files with random names, Prefetch will be leaked Legal scenarios, you should know that what you are executing has a long-term effect Check Zone.Identifier If you move a file, you should know that Windows even marks the Internet resource Watch Temp All tools  They create temp files without you knowing Anticipate side effects like Thumbnails and JumpLists Anything you Preview or Open will probably create a Thumbnail @reverseengine

Memory Layout: Arrays, Structs, Pointers مهمترین بخش برای Exploit, InfoLeak، ROP، UAF، heap overflow آرایه‌ها (Arrays) داخل حافظه چگونه ذخیره میشن؟ آرایه همیشه contiguous پشت سر هم داخل استک یا هیپ ذخیره میشه مثال:

int a[5] = {1,2,3,4,5};

داخل حافظه:

a[0] → offset 0 a[1] → offset 4 a[2] → offset 8 a[3] → offset 12 a[4] → offset 16

نکته Exploit: اگر بافر آرایه باشه اورفلو مستقیم وارد متغیر های محلی RBP Return Address میشه Memory Layout: Arrays, Structs, Pointers The most important part for Exploit, InfoLeak, ROP, UAF, heap overflow How are Arrays stored in memory? Arrays are always stored contiguously in the stack or heap Example:

int a[5] = {1,2,3,4,5};

In memory:

a[0] → offset 0 a[1] → offset 4 a[2] → offset 8 a[3] → offset 12 a[4] → offset 16

 Exploit Tip: If the buffer is an array, the overflow goes directly into the local variables RBP Return Address @reverseengine

A gentle introduction into ARM assembly https://www.shadowinfosec.io/2018/05/a-gentle-introduction-into-arm-assembly.html @reverseengine

Reverse Engineering Starling Bank (Part I): Obfuscation Techniques https://hot3eed.github.io/2020/07/30/starling_p1_obfuscations.html Reverse Engineering Starling Bank (Part II): Jailbreak & Debugger Detection, Weaknesses & Mitigations https://hot3eed.github.io/2020/08/02/starling_p2_detections_mitigations.html @reverseengine

Article: Removing Kernel Callbacks Using Signed Drivers https://br-sn.github.io/Removing-Kernel-Callbacks-Using-Signed-Drivers Code: Enumerating and removing kernel callbacks using signed vulnerable drivers https://github.com/br-sn/CheekyBlinder @reverseengine