اندروید | امنیت و هک
🔥 شکار ۴ باگ بحرانی و منطقی در لایه سوکت پرداخت! در ادامه پست قبل، تستر با اسکریپت پایتون خودش شروع کرد به فرستادن فریم‌های دستکاری‌شده ISO 8583 به سمت سرور شبیه‌ساز پرداخت. سرور پردازشگر برخلاف ظاهرش، توی بررسی منطق تراکنش‌ها (Business Logic) فاجعه بود…
💡 نتیجه‌گیری معماری؛ چرا نباید به لایه‌های بعدی اعتماد کرد؟
شاید بعد از خوندن باگ‌های پست قبل بگید:
«خب این باگ‌ها روی سرور بانک واقعی کار نمی‌کنه چون بانک خودش دبل تراکنش یا موجودی رو چک می‌کنه». اما نویسنده مقاله یک استدلال فوق‌العاده درست و استاندارد رو مطرح می‌کنه:
تسوویه و منطق تراکنش‌ها وظیفه خودِ پردازشگر پرداخت (Payment Processor) هست که این وسط قرار گرفته. لایه‌هایی مثل بررسی هویت کارت در زمان ابطال، عدم دسترسی فروشگاه‌ها به تراکنش‌های همدیگه (IDOR) و ثبت لاگ‌ها تماماً باید در لایه همین سوکت مدیریت بشن و رها کردن این باگ‌ها به امید اینکه «بانک نهایی جلوش رو می‌گیره» یک خطای بزرگ در معماری امنیته.
🛠 چک‌لیست پیشنهادی برای تست پروتکل ISO 8583:
اگر رفقای تستر می‌خوان این لایه رو تست کنن، حتماً این موارد رو فازینگ (Fuzzing) کنن:
🔹 تغییر مقدار تراکنش به صفر یا اعداد منفی
🔹 تغییر کدهای ارز (تست جابه‌جایی ارزها)
🔹 دستکاری طول فیلدهای متغیر (LLVAR/LLLVAR) برای بررسی بافر سرور
🔹 به‌هم ریختن نقشه بیتی (Bitmap) فیلدها
خوشبختانه این باگ‌ها قبل از اینکه پوزها عملیاتی بشن و به بانک واقعی وصل بشن، در این پروژه تست نفوذ کشف و اصلاح شدن که اهمیت ارزیابی امنیتی رو قبل از ریلیز نشون میده.
🔗 مطالعه کامل و فنی مقاله در وبلاگ نویسنده:
👉 https://m4kr0.vercel.app/posts/iso-8583-under-fire-finding-vulnerabilities-in-a-payment-socket
🆔 @androidSec_fa
#امنیت #تست_نفوذ #معماری_امنیت #تست_پوز #پروتکل_ISO8583 #امنیت_اندروید
شاید بعد از خوندن باگ‌های پست قبل بگید:
«خب این باگ‌ها روی سرور بانک واقعی کار نمی‌کنه چون بانک خودش دبل تراکنش یا موجودی رو چک می‌کنه». اما نویسنده مقاله یک استدلال فوق‌العاده درست و استاندارد رو مطرح می‌کنه:
تسوویه و منطق تراکنش‌ها وظیفه خودِ پردازشگر پرداخت (Payment Processor) هست که این وسط قرار گرفته. لایه‌هایی مثل بررسی هویت کارت در زمان ابطال، عدم دسترسی فروشگاه‌ها به تراکنش‌های همدیگه (IDOR) و ثبت لاگ‌ها تماماً باید در لایه همین سوکت مدیریت بشن و رها کردن این باگ‌ها به امید اینکه «بانک نهایی جلوش رو می‌گیره» یک خطای بزرگ در معماری امنیته.
🛠 چک‌لیست پیشنهادی برای تست پروتکل ISO 8583:
اگر رفقای تستر می‌خوان این لایه رو تست کنن، حتماً این موارد رو فازینگ (Fuzzing) کنن:
🔹 تغییر مقدار تراکنش به صفر یا اعداد منفی
🔹 تغییر کدهای ارز (تست جابه‌جایی ارزها)
🔹 دستکاری طول فیلدهای متغیر (LLVAR/LLLVAR) برای بررسی بافر سرور
🔹 به‌هم ریختن نقشه بیتی (Bitmap) فیلدها
خوشبختانه این باگ‌ها قبل از اینکه پوزها عملیاتی بشن و به بانک واقعی وصل بشن، در این پروژه تست نفوذ کشف و اصلاح شدن که اهمیت ارزیابی امنیتی رو قبل از ریلیز نشون میده.
🔗 مطالعه کامل و فنی مقاله در وبلاگ نویسنده:
👉 https://m4kr0.vercel.app/posts/iso-8583-under-fire-finding-vulnerabilities-in-a-payment-socket
🆔 @androidSec_fa
#امنیت #تست_نفوذ #معماری_امنیت #تست_پوز #پروتکل_ISO8583 #امنیت_اندروید
M4KR0 Blog
ISO 8583 Under Fire: Finding Vulnerabilities in a Payment Socket - M4KR0 Blog
A hands-on walkthrough of security testing an ISO 8583 payment socket — from reversing the app and enabling hidden debug mode, to finding four critical vulnerabilities in the processor layer
👍4
بررسی آسیب‌پذیری جدید در شبیه‌ساز اندروید MEmu (افزایش سطح دسترسی)
📌 شناسه: CVE-2026-36213
💻 محصول تحت تأثیر: MEmu Android Emulator (نسخه 9.2.7.0 و احتمالاً نسخه‌های هم‌خانواده)
🎯 نوع آسیب‌پذیری: Local Privilege Escalation (LPE)
📂 مؤلفه آسیب‌پذیر: سرویس پس‌زمینه MemuService.exe
⚙️ شرح آسیب‌پذیری به زبان ساده:
سرویس MemuService.exe متعلق به شبیه‌ساز MEmu، با بالاترین سطح دسترسی در ویندوز (SYSTEM/Administrator) اجرا می‌شود. این آسیب‌پذیری به یک کاربر با دسترسی محدود یا یک بدافزارِ معمولیِ مستقر روی سیستم اجازه می‌دهد تا از نقص موجود در مدیریت دسترسی‌های این سرویس سوءاستفاده کند.
مهاجم با فریب دادن این سرویس، می‌تواند کدهای مخرب خود را با اختیارات بالا (Privilege Escalation) اجرا کرده و کنترل کامل سیستم‌عامل ویندوز را به دست بگیرد.
🛠 راهکار:
اگر از این شبیه‌ساز روی سیستم خود یا سازمان استفاده می‌کنید، سریعاً آن را به آخرین نسخه ارائه‌شده توسط توسعه‌دهنده به‌روزرسانی کنید تا فایل اجرایی مربوطه اصلاح شود.
🔗 لینک مخزن گیت‌هاب (PoC/Details):
https://github.com/sec-zone/CVE-2026-36213
🆔 @androidSec_fa
#CVE_2026_36213 #WindowsSecurity #AndroidEmulator #MEmu #PrivilegeEscalation #LPE #Vulnerability #Exploit
📌 شناسه: CVE-2026-36213
💻 محصول تحت تأثیر: MEmu Android Emulator (نسخه 9.2.7.0 و احتمالاً نسخه‌های هم‌خانواده)
🎯 نوع آسیب‌پذیری: Local Privilege Escalation (LPE)
📂 مؤلفه آسیب‌پذیر: سرویس پس‌زمینه MemuService.exe
⚙️ شرح آسیب‌پذیری به زبان ساده:
سرویس MemuService.exe متعلق به شبیه‌ساز MEmu، با بالاترین سطح دسترسی در ویندوز (SYSTEM/Administrator) اجرا می‌شود. این آسیب‌پذیری به یک کاربر با دسترسی محدود یا یک بدافزارِ معمولیِ مستقر روی سیستم اجازه می‌دهد تا از نقص موجود در مدیریت دسترسی‌های این سرویس سوءاستفاده کند.
مهاجم با فریب دادن این سرویس، می‌تواند کدهای مخرب خود را با اختیارات بالا (Privilege Escalation) اجرا کرده و کنترل کامل سیستم‌عامل ویندوز را به دست بگیرد.
🛠 راهکار:
اگر از این شبیه‌ساز روی سیستم خود یا سازمان استفاده می‌کنید، سریعاً آن را به آخرین نسخه ارائه‌شده توسط توسعه‌دهنده به‌روزرسانی کنید تا فایل اجرایی مربوطه اصلاح شود.
🔗 لینک مخزن گیت‌هاب (PoC/Details):
https://github.com/sec-zone/CVE-2026-36213
🆔 @androidSec_fa
#CVE_2026_36213 #WindowsSecurity #AndroidEmulator #MEmu #PrivilegeEscalation #LPE #Vulnerability #Exploit
GitHub
GitHub - sec-zone/CVE-2026-36213: CVE-2026-36213 | Local Privilege Escalation in MEmu Android Emulator 9.2.7.0 via Insecure Service…
CVE-2026-36213 | Local Privilege Escalation in MEmu Android Emulator 9.2.7.0 via Insecure Service Binary Permissions | Patched in 9.3.2 - sec-zone/CVE-2026-36213
👍3
🚨 شکارچیان خاموش؛ چطور چراغ هشدار عینک‌های هوشمند هک می‌شود؟
عینک‌های هوشمند جدید (مثل Ray-Ban Meta) دقیقاً شبیه عینک طبی یا آفتابی معمولی هستند و دوربین کوچک آن‌ها عملاً قابل تشخیص نیست.
🛠 دور زدن فیزیکی چراغ هشدار (LED)
سازندگان برای حفظ حریم خصوصی، یک LED روی فریم گذاشته‌اند که هنگام ضبط روشن می‌شود. اما این مانع به راحتی دور زده می‌شود:
▪️ کاورها و استیکرها: برچسب‌هایی در بازار هستند که روی LED را می‌پوشانند. این کاورها با داشتن یک روزنه ریز، نور کافی را به سنسور عینک می‌رسانند تا ضبط متوقف نشود، اما دیدن چراغ را غیرممکن می‌کنند.
▪️ جراحی سخت‌افزاری (Modding): هکرها با ابزارهای ظریف، LED را دستکاری یا مسدود کرده تا عینک در حالت صددرصد مخفی (Stealth) فیلم‌برداری کند!
در پست بعدی به این می‌پردازیم که چرا اپلیکیشن‌های موبایلی هم از شناسایی این عینک‌ها عاجز هستند.👇
ID: @androidSec_fa
#Cybersecurity #Privacy #HardwareHacking #SmartGlasses
عینک‌های هوشمند جدید (مثل Ray-Ban Meta) دقیقاً شبیه عینک طبی یا آفتابی معمولی هستند و دوربین کوچک آن‌ها عملاً قابل تشخیص نیست.
🛠 دور زدن فیزیکی چراغ هشدار (LED)
سازندگان برای حفظ حریم خصوصی، یک LED روی فریم گذاشته‌اند که هنگام ضبط روشن می‌شود. اما این مانع به راحتی دور زده می‌شود:
▪️ کاورها و استیکرها: برچسب‌هایی در بازار هستند که روی LED را می‌پوشانند. این کاورها با داشتن یک روزنه ریز، نور کافی را به سنسور عینک می‌رسانند تا ضبط متوقف نشود، اما دیدن چراغ را غیرممکن می‌کنند.
▪️ جراحی سخت‌افزاری (Modding): هکرها با ابزارهای ظریف، LED را دستکاری یا مسدود کرده تا عینک در حالت صددرصد مخفی (Stealth) فیلم‌برداری کند!
در پست بعدی به این می‌پردازیم که چرا اپلیکیشن‌های موبایلی هم از شناسایی این عینک‌ها عاجز هستند.👇
ID: @androidSec_fa
#Cybersecurity #Privacy #HardwareHacking #SmartGlasses
👍3
اندروید | امنیت و هک
🚨 شکارچیان خاموش؛ چطور چراغ هشدار عینک‌های هوشمند هک می‌شود؟ عینک‌های هوشمند جدید (مثل Ray-Ban Meta) دقیقاً شبیه عینک طبی یا آفتابی معمولی هستند و دوربین کوچک آن‌ها عملاً قابل تشخیص نیست. 🛠 دور زدن فیزیکی چراغ هشدار (LED) سازندگان برای حفظ حریم خصوصی، یک…
📡 پشت پرده فنی؛ چرا اپ‌های اندرویدی در ردیابی عینک‌های هوشمند شکست می‌خورند؟
پس از موج نگرانی‌ها بابت جاسوسی با عینک‌های هوشمند، متخصصان امنیت اندروید تلاش کردند با استفاده از BLE Scanner API، اپلیکیشن‌هایی بسازند که سیگنال‌های بلوتوث (BLE) این دستگاه‌ها را اسکن کرده و در صورت وجود عینک در نزدیکی کاربر، هشدار دهند.
اما تحلیل‌های فنی نشان می‌دهند این اپ‌ها عملاً یک «حس امنیت کاذب» ایجاد می‌کنند و به دو دلیل شکست می‌خورند:
۱. پنهان شدن پس از اتصال (The Stealth Mode):
عینک‌های هوشمند فقط در زمانی که منتظر جفت‌شدن (Pairing) با یک گوشی جدید هستند، سیگنال‌های بیرونی و آشکار BLE می‌فرستند. به محض اینکه عینک به اندرویدِ مالک خود متصل شد، استک بلوتوث آن تغییر رفتار داده و در اسکن‌های رادیویی دستگاه‌های اطراف کاملاً نامرئی می‌شود.
۲. حملات سیگنالی و اسپم (BLE Spoofing):
مهاجمان به راحتی می‌توانند با ابزارهایی مثل Flipper Zero یا بردهای نظیر ESP32، سیگنال‌های فیکِ BLE با هدرهای عینک‌های هوشمند تولید کنند. این کار باعث خطای مثبت کاذب (False Positive) در اپ‌های ردیاب شده و سیستم‌های پایش رادیویی را کاملاً مختل و بی‌خاصیت می‌کند.
در پست آخر، خطرناک‌ترین سناریوی این عینک‌ها یعنی ترکیب با هوش مصنوعی را بررسی می‌کنیم.👇
ID: @androidSec_fa
#Android #Cybersecurity #BLE #Bluetooth #WirelessSecurity
پس از موج نگرانی‌ها بابت جاسوسی با عینک‌های هوشمند، متخصصان امنیت اندروید تلاش کردند با استفاده از BLE Scanner API، اپلیکیشن‌هایی بسازند که سیگنال‌های بلوتوث (BLE) این دستگاه‌ها را اسکن کرده و در صورت وجود عینک در نزدیکی کاربر، هشدار دهند.
اما تحلیل‌های فنی نشان می‌دهند این اپ‌ها عملاً یک «حس امنیت کاذب» ایجاد می‌کنند و به دو دلیل شکست می‌خورند:
۱. پنهان شدن پس از اتصال (The Stealth Mode):
عینک‌های هوشمند فقط در زمانی که منتظر جفت‌شدن (Pairing) با یک گوشی جدید هستند، سیگنال‌های بیرونی و آشکار BLE می‌فرستند. به محض اینکه عینک به اندرویدِ مالک خود متصل شد، استک بلوتوث آن تغییر رفتار داده و در اسکن‌های رادیویی دستگاه‌های اطراف کاملاً نامرئی می‌شود.
۲. حملات سیگنالی و اسپم (BLE Spoofing):
مهاجمان به راحتی می‌توانند با ابزارهایی مثل Flipper Zero یا بردهای نظیر ESP32، سیگنال‌های فیکِ BLE با هدرهای عینک‌های هوشمند تولید کنند. این کار باعث خطای مثبت کاذب (False Positive) در اپ‌های ردیاب شده و سیستم‌های پایش رادیویی را کاملاً مختل و بی‌خاصیت می‌کند.
در پست آخر، خطرناک‌ترین سناریوی این عینک‌ها یعنی ترکیب با هوش مصنوعی را بررسی می‌کنیم.👇
ID: @androidSec_fa
#Android #Cybersecurity #BLE #Bluetooth #WirelessSecurity
👍3
👁 کابوس بیومتری؛ وقتی عینک هوشمند ابزار OSINT و تشخیص چهره می‌شود!
خطر عینک‌های هوشمند جدید فقط به ضبط پنهانی ویدیو ختم نمی‌شود. تهدید بزرگتر و واقعی زمانی آغاز می‌شود که این گجت‌ها به موتورهای پردازش تصویر هوش مصنوعی و پایگاه‌های داده بیومتmetric متصل شوند.
تحلیل کدهای پنهان در اپلیکیشن‌های مدیریت این عینک‌ها (مانند پروژه آزمایشگاهی NameTag) نشان می‌دهد که سناریوی زیر چندان دور نیست:
۱. اسکن در لحظه (Real-time Scanning):
شما در حال قدم زدن در خیابان هستید؛ فردی با عینک هوشمند از کنار شما رد می‌شود. دوربین عینک بدون اینکه متوجه شوید، چهره شما را فریم‌به-فریم اسکن می‌کند.
۲. اتصال به موتورهای OSINT چهره:
تصویر صورت شما فوراً به سرورهای پردازش ابری فرستاده شده و با موتورهای جستجوی قدرتمند چهره مانند PimEyes یا FaceCheck تطبیق داده می‌شود.
۳. افشای آنی هویت:
ظرف چند ثانیه، نام کامل شما، حساب‌های شبکه‌های اجتماعی (اینستاگرام، لینکدین، تلگرام) و حتی محل کار یا سکونت احتمالی شما روی شیشه عینک یا گوشی فرد مقابل ظاهر می‌شود!
سرعت پیشرفت ابزارهای جاسوسی و مانیتورینگ توده‌ای، فراتر از قوانین حقوقی و سیستم‌های دفاع دیجیتال ماست. حریم خصوصی در فضاهای عمومی رسماً به پایان خود نزدیک شده است.
🔗 مطالعه کامل و فنی مقاله در وبلاگ نویسنده:
👉 https://www.mobile-hacker.com/2026/06/14/smart-glasses-can-record-you-and-detecting-them-isnt-so-simple/
🆔 @androidSec_fa
#OSINT #AI #FaceRecognition #Privacy #Biometrics
خطر عینک‌های هوشمند جدید فقط به ضبط پنهانی ویدیو ختم نمی‌شود. تهدید بزرگتر و واقعی زمانی آغاز می‌شود که این گجت‌ها به موتورهای پردازش تصویر هوش مصنوعی و پایگاه‌های داده بیومتmetric متصل شوند.
تحلیل کدهای پنهان در اپلیکیشن‌های مدیریت این عینک‌ها (مانند پروژه آزمایشگاهی NameTag) نشان می‌دهد که سناریوی زیر چندان دور نیست:
۱. اسکن در لحظه (Real-time Scanning):
شما در حال قدم زدن در خیابان هستید؛ فردی با عینک هوشمند از کنار شما رد می‌شود. دوربین عینک بدون اینکه متوجه شوید، چهره شما را فریم‌به-فریم اسکن می‌کند.
۲. اتصال به موتورهای OSINT چهره:
تصویر صورت شما فوراً به سرورهای پردازش ابری فرستاده شده و با موتورهای جستجوی قدرتمند چهره مانند PimEyes یا FaceCheck تطبیق داده می‌شود.
۳. افشای آنی هویت:
ظرف چند ثانیه، نام کامل شما، حساب‌های شبکه‌های اجتماعی (اینستاگرام، لینکدین، تلگرام) و حتی محل کار یا سکونت احتمالی شما روی شیشه عینک یا گوشی فرد مقابل ظاهر می‌شود!
سرعت پیشرفت ابزارهای جاسوسی و مانیتورینگ توده‌ای، فراتر از قوانین حقوقی و سیستم‌های دفاع دیجیتال ماست. حریم خصوصی در فضاهای عمومی رسماً به پایان خود نزدیک شده است.
🔗 مطالعه کامل و فنی مقاله در وبلاگ نویسنده:
👉 https://www.mobile-hacker.com/2026/06/14/smart-glasses-can-record-you-and-detecting-them-isnt-so-simple/
🆔 @androidSec_fa
#OSINT #AI #FaceRecognition #Privacy #Biometrics
Mobile Hacker
Smart Glasses Can Record You - And Detecting Them Isn’t So Simple - Mobile Hacker
Smart glasses with camera are becoming more common, fitting into everyday life. They look like normal sunglasses — but they can record video, capture audio, and take photos at any moment.
👍3
🪲 تروجان بانکی Rokarolla؛ تهدید جدید اندروید با قابلیت کنترل کامل دستگاه (Device Takeover)
تیم تحقیقاتی zLabs به‌تازگی یک بدافزار بسیار تهاجمی و پیشرفته اندرویدی به نام Rokarolla کشف کرده است که با هدف قرار دادن ۲۱۷ اپلیکیشن بانکی و صرافی رمزارز، کنترل اداری مطلق دستگاه قربانی را به دست می‌گیرد.
📍 تکنیک‌های انتشار و فریب کاربر:
این بدافزار عمدتاً از طریق سایت‌های مخرب و به شکل برنامه‌های معروفی مثل Google Chrome یا TikTok توزیع می‌شود. هسته اصلی بدافزار (Dropper) با جعل نام و ظاهر سیستم امنیتی Google Play Protect، کاربر را فریب داده تا بار داده مخرب اصلی را نصب کند و دسترسی حیاتی Accessibility Services را فعال نماید.
🛡 مهم‌ترین قابلیت‌های مخرب Rokarolla:
🔹 جعل پیشرفته صفحه (Overlays): نمایش صفحات فیشینگ منطبق بر بانک‌های هدف روی برنامه اصلی، جهت سرقت رمز عبور، پین‌کد یا مشخصات کارت اعتباری.
🔹 جاسوسی تصویری (Pseudo-VNC): تهیه اسکرین‌شات‌های مداوم، فشرده‌سازی و ارسال سیستماتیک آن‌ها به سرور C2 همراه با برچسب زمانی.
🔹 جاسوسی اختصاصی واتساپ: پایش صفحه برای پیدا کردن کلمات کلیدی واتساپ و استخراج لیست مخاطبین.
🔹 سرقت SMS و کنترل تماس: ربودن رمزهای یک‌بار مصرف (OTP) و مسدود کردن تماس‌های دریافتی برای جلوگیری از دریافت هشدارهای امنیتی بانک.
🔹 عملیات بی‌صدا و ماندگاری: حذف آیکون برنامه از منو، قطع کامل صدا و لرزش گوشی برای پنهان‌کاری، روشن نگه داشتن دائمی صفحه نمایش و تلاش برای غیرفعال‌سازی پروتکل‌های حفاظتی Play Protect.
🔹 دستکاری حافظه موقت (Clipboard): جایگزینی خودکار آدرس کیف پول‌های رمزارز کپی شده با آدرس مهاجم (Crypto Clipper).
هکرها در این تروجان از یک پنل مدیریت قدرتمند با ۱۳۷ فرمان مختلف استفاده می‌کنند که دسترسی آن‌ها را به یک «کنترل کامل تصویری و عملکردی» روی گوشی تبدیل می‌کند.
🔗 مطالعه متن کامل گزارش فنی و بررسی تحلیل دامنه‌ها:
👉 https://zimperium.com/blog/rokarolla-android-banker-with-complete-device-takeover-capabilities
🚩 کانال تخصصی امنیت اندروید:
🆔 @androidSec_fa
#AndroidSecurity #MalwareAnalysis #MobileTargeting #Rokarolla #BankingTrojan #zLabs #CyberSecurity #Phishing
تیم تحقیقاتی zLabs به‌تازگی یک بدافزار بسیار تهاجمی و پیشرفته اندرویدی به نام Rokarolla کشف کرده است که با هدف قرار دادن ۲۱۷ اپلیکیشن بانکی و صرافی رمزارز، کنترل اداری مطلق دستگاه قربانی را به دست می‌گیرد.
📍 تکنیک‌های انتشار و فریب کاربر:
این بدافزار عمدتاً از طریق سایت‌های مخرب و به شکل برنامه‌های معروفی مثل Google Chrome یا TikTok توزیع می‌شود. هسته اصلی بدافزار (Dropper) با جعل نام و ظاهر سیستم امنیتی Google Play Protect، کاربر را فریب داده تا بار داده مخرب اصلی را نصب کند و دسترسی حیاتی Accessibility Services را فعال نماید.
🛡 مهم‌ترین قابلیت‌های مخرب Rokarolla:
🔹 جعل پیشرفته صفحه (Overlays): نمایش صفحات فیشینگ منطبق بر بانک‌های هدف روی برنامه اصلی، جهت سرقت رمز عبور، پین‌کد یا مشخصات کارت اعتباری.
🔹 جاسوسی تصویری (Pseudo-VNC): تهیه اسکرین‌شات‌های مداوم، فشرده‌سازی و ارسال سیستماتیک آن‌ها به سرور C2 همراه با برچسب زمانی.
🔹 جاسوسی اختصاصی واتساپ: پایش صفحه برای پیدا کردن کلمات کلیدی واتساپ و استخراج لیست مخاطبین.
🔹 سرقت SMS و کنترل تماس: ربودن رمزهای یک‌بار مصرف (OTP) و مسدود کردن تماس‌های دریافتی برای جلوگیری از دریافت هشدارهای امنیتی بانک.
🔹 عملیات بی‌صدا و ماندگاری: حذف آیکون برنامه از منو، قطع کامل صدا و لرزش گوشی برای پنهان‌کاری، روشن نگه داشتن دائمی صفحه نمایش و تلاش برای غیرفعال‌سازی پروتکل‌های حفاظتی Play Protect.
🔹 دستکاری حافظه موقت (Clipboard): جایگزینی خودکار آدرس کیف پول‌های رمزارز کپی شده با آدرس مهاجم (Crypto Clipper).
هکرها در این تروجان از یک پنل مدیریت قدرتمند با ۱۳۷ فرمان مختلف استفاده می‌کنند که دسترسی آن‌ها را به یک «کنترل کامل تصویری و عملکردی» روی گوشی تبدیل می‌کند.
🔗 مطالعه متن کامل گزارش فنی و بررسی تحلیل دامنه‌ها:
👉 https://zimperium.com/blog/rokarolla-android-banker-with-complete-device-takeover-capabilities
🚩 کانال تخصصی امنیت اندروید:
🆔 @androidSec_fa
#AndroidSecurity #MalwareAnalysis #MobileTargeting #Rokarolla #BankingTrojan #zLabs #CyberSecurity #Phishing
Zimperium
Rokarolla : Android Banker with Complete Device Takeover Capabilities
true
👍3
This media is not supported in your browser
VIEW IN TELEGRAM
📱 اتصال همزمان ده‌ها سیم‌کارت به یک آیفون و دور زدن بن‌شدن‌های واتساپ!
شاید در نگاه اول عجیب به نظر برسد، اما در این ویدیو با دستگاهی به نام Chipeira (شبیه‌ساز سخت‌افزاری سیم‌کارت) آشنا می‌شوید که به هکرها و متخصصان سئو/مارکتینگ اجازه می‌دهد صدها اکانت واتساپ را به طور همزمان روی یک گوشی مدیریت کنند.
⚙️ ترفند کار کجاست؟
۱. بورد سخت‌افزاری: کنترل دستی سیم‌کارت‌ها؛ برای فعال‌سازی یا دریافت پیامک تأیید هر شماره، کلید مربوط به آن سیم‌کارت روی بورد روشن می‌شود و نیازی به خرید ده‌ها گوشی نیست.
۲. ایزوله‌سازی نرم‌افزاری (Cloning): با فریب دادن هویت دیجیتال برنامه (Device ID و MAC Address)، واتساپ تصور می‌کند هر اکانت روی یک گوشی کاملاً مجزا در نقطه‌ای دیگر از دنیا نصب شده است؛ در نتیجه با بن شدن یک اکانت، بقیه اکانت‌ها هیچ آسیبی نمی‌بینند!
🚀 ابزاری کاربردی برای پروژه‌های ترافیک مستقیم و ارسال انبوه که ساختار امنیتی واتساپ را به چالش می‌کشد.
🆔 @androidSec_fa
#امنیت #تست_نفوذ #واتساپ #امنیت_شبکه #هک #
شاید در نگاه اول عجیب به نظر برسد، اما در این ویدیو با دستگاهی به نام Chipeira (شبیه‌ساز سخت‌افزاری سیم‌کارت) آشنا می‌شوید که به هکرها و متخصصان سئو/مارکتینگ اجازه می‌دهد صدها اکانت واتساپ را به طور همزمان روی یک گوشی مدیریت کنند.
⚙️ ترفند کار کجاست؟
۱. بورد سخت‌افزاری: کنترل دستی سیم‌کارت‌ها؛ برای فعال‌سازی یا دریافت پیامک تأیید هر شماره، کلید مربوط به آن سیم‌کارت روی بورد روشن می‌شود و نیازی به خرید ده‌ها گوشی نیست.
۲. ایزوله‌سازی نرم‌افزاری (Cloning): با فریب دادن هویت دیجیتال برنامه (Device ID و MAC Address)، واتساپ تصور می‌کند هر اکانت روی یک گوشی کاملاً مجزا در نقطه‌ای دیگر از دنیا نصب شده است؛ در نتیجه با بن شدن یک اکانت، بقیه اکانت‌ها هیچ آسیبی نمی‌بینند!
🚀 ابزاری کاربردی برای پروژه‌های ترافیک مستقیم و ارسال انبوه که ساختار امنیتی واتساپ را به چالش می‌کشد.
🆔 @androidSec_fa
#امنیت #تست_نفوذ #واتساپ #امنیت_شبکه #هک #
👍3❤1
یه ابزار برای مهندسی معکوس اندروید که قابلیت اجرا مستقیم روی گوشی رو داره. از Flutter و il2cpp هم پشتیبانی می‌کنه.
لینک: https://github.com/UltraSina/androidReverse/releases
🆔 @androidSec_fa
#Android #ReverseEngineering #Security
لینک: https://github.com/UltraSina/androidReverse/releases
🆔 @androidSec_fa
#Android #ReverseEngineering #Security
GitHub
Releases · UltraSina/androidReverse
Android reverse engineering entirely on-device. Radare2 binary analysis, 8 Java decompilers, Flutter & Unity il2cpp support. - UltraSina/androidReverse
👍2
This media is not supported in your browser
VIEW IN TELEGRAM
⚠️ هشدار امنیتی: ادعای روت کردن اندروید ۱۷ با استفاده از لینک
اخیراً در فضای مجازی توییتی منتشر شده که ادعا می‌کند یک زنجیره اکسپلویت (Full Chain) برای روت کردن سیستم‌عامل اندروید ۱۷ کشف شده است. این حمله ادعا می‌کند که با کلیک روی یک لینک و بهره‌برداری از دو آسیب‌پذیری 0-day در مرورگر فایرفاکس (از جمله CVE-2026-10702)، امکان نفوذ به هسته سیستم‌عامل وجود دارد.
نکات کلیدی برای کاربران:
۱. این آسیب‌پذیری در نسخه‌های جدید فایرفاکس (151.0.3 و بالاتر) به‌طور کامل اصلاح شده است.
۲. زنجیره‌های اکسپلویت این‌چنینی معمولاً وابسته به سخت‌افزار و نسخه‌های خاص هستند و به صورت عمومی و پایدار برای همه دستگاه‌ها کارایی ندارند.
۳. بهترین راه مقابله، به‌روزرسانی مداوم مرورگر و سیستم‌عامل است.
منبع و جزئیات بیشتر را می‌توانید در توییتر مشاهده کنید:
https://x.com/nebusecurity/status/2069707520160227688
🛡 برای آگاهی از آخرین اخبار و تحلیل‌های امنیتی، کانال ما را دنبال کنید:
@androidSec_fa
#امنیت #اندروید #فایرفاکس #هشدار_امنیتی #CVE202610702 #سایبری #AndroidSecurity
اخیراً در فضای مجازی توییتی منتشر شده که ادعا می‌کند یک زنجیره اکسپلویت (Full Chain) برای روت کردن سیستم‌عامل اندروید ۱۷ کشف شده است. این حمله ادعا می‌کند که با کلیک روی یک لینک و بهره‌برداری از دو آسیب‌پذیری 0-day در مرورگر فایرفاکس (از جمله CVE-2026-10702)، امکان نفوذ به هسته سیستم‌عامل وجود دارد.
نکات کلیدی برای کاربران:
۱. این آسیب‌پذیری در نسخه‌های جدید فایرفاکس (151.0.3 و بالاتر) به‌طور کامل اصلاح شده است.
۲. زنجیره‌های اکسپلویت این‌چنینی معمولاً وابسته به سخت‌افزار و نسخه‌های خاص هستند و به صورت عمومی و پایدار برای همه دستگاه‌ها کارایی ندارند.
۳. بهترین راه مقابله، به‌روزرسانی مداوم مرورگر و سیستم‌عامل است.
منبع و جزئیات بیشتر را می‌توانید در توییتر مشاهده کنید:
https://x.com/nebusecurity/status/2069707520160227688
🛡 برای آگاهی از آخرین اخبار و تحلیل‌های امنیتی، کانال ما را دنبال کنید:
@androidSec_fa
#امنیت #اندروید #فایرفاکس #هشدار_امنیتی #CVE202610702 #سایبری #AndroidSecurity
👍4
🔴 آسیب‌پذیری خطرناک در هدست‌های Meta Quest؛ کرش دادن کل سیستم با یک اپلیکیشن ساده!
تیم امنیتی Djini.ai گزارش فنی یک آسیب‌پذیری DoS (محروم‌سازی از سرویس) در سیستم‌عامل هدست‌های واقعیت مجازی Meta Quest (از جمله Quest 3S) منتشر کرده که نشان می‌دهد چطور یک اپلیکیشن بدون داشتن هیچ دسترسی حساسی، می‌توانست کل دستگاه را غیرقابل استفاده کند.
⚙️ ماجرا از چه قرار است؟
در سیستم‌عامل این هدست‌ها، یک برنامه پیش‌فرض و سیستمی به نام com.oculus.systemresource وجود داشت که برای تست و مانیتورینگ منابع دستگاه استفاده می‌شد. توسعه‌دهندگان متا فراموش کرده بودند روی کامپوننت‌های این برنامه (Broadcast Receiver و Service) کنترل دسترسی یا Permission Gate قرار دهند!
🛠 نحوه سوءاستفاده (Attack Chain):
هر اپلیکیشن ثالثی (Third-party) که کاربر روی هدست نصب می‌کرد، بدون نیاز به دسترسی‌های خطرناک یا روت، می‌توانست ۳ مرحله زیر را اجرا کند:
1️⃣ سرویسِ سیستم را استارت بزند.
2️⃣ با فرستادن یک Broadcast، محیط نیتیو آن را مقداردهی اولیه کند.
3️⃣ با فرستادن یک دستور به بخش AllocationEngine، سیستم را مجبور کند یک فایل ۸.۶ گیگابایتی را روی حافظه رم (RAM) مپ (Memory-map) کند!
💥 نتیجه چه می‌شد؟
از آنجا که دستگاهی مثل Quest 3S کلاً ۸ گیگابایت رم دارد، این درخواستِ سنگین فوراً حافظه را اشباع می‌کرد. در این حالت سیستم مدیریت حافظه اندروید (Low Memory Killer) برای نجات دستگاه فعال می‌شد و شروع به کشتن اجباری (Kill) فرآیندهای حیاتی سیستم با UID 1000 (مانند تنظیمات، سرویس احراز هویت، سیستم ردیابی محیط یا Guardian و مرورگر) می‌کرد که باعث فریز شدن و از کار افتادن کامل هدست می‌شد.
✅ وضعیت اصلاحیه:
متا این آسیب‌پذیری را در نسخه vros 204 با حذف کامل این پکیجِ عیب‌یابی از روی سیستم‌عامل برطرف کرده است؛ بنابراین اگر هدست خود را آپدیت کرده باشید، دیگر خطری شما را تهدید نمی‌کند.
🔗 لینک مقاله کامل و تحلیل کدها:
https://www.djini.ai/blog/technical-advisory-meta-quest-system-wide-dos-via-unprotected-memory
🆔 @androidSec_fa
#Android #Security #Vulnerability #MetaQuest #VR #DoS #AndroidSecurity
تیم امنیتی Djini.ai گزارش فنی یک آسیب‌پذیری DoS (محروم‌سازی از سرویس) در سیستم‌عامل هدست‌های واقعیت مجازی Meta Quest (از جمله Quest 3S) منتشر کرده که نشان می‌دهد چطور یک اپلیکیشن بدون داشتن هیچ دسترسی حساسی، می‌توانست کل دستگاه را غیرقابل استفاده کند.
⚙️ ماجرا از چه قرار است؟
در سیستم‌عامل این هدست‌ها، یک برنامه پیش‌فرض و سیستمی به نام com.oculus.systemresource وجود داشت که برای تست و مانیتورینگ منابع دستگاه استفاده می‌شد. توسعه‌دهندگان متا فراموش کرده بودند روی کامپوننت‌های این برنامه (Broadcast Receiver و Service) کنترل دسترسی یا Permission Gate قرار دهند!
🛠 نحوه سوءاستفاده (Attack Chain):
هر اپلیکیشن ثالثی (Third-party) که کاربر روی هدست نصب می‌کرد، بدون نیاز به دسترسی‌های خطرناک یا روت، می‌توانست ۳ مرحله زیر را اجرا کند:
1️⃣ سرویسِ سیستم را استارت بزند.
2️⃣ با فرستادن یک Broadcast، محیط نیتیو آن را مقداردهی اولیه کند.
3️⃣ با فرستادن یک دستور به بخش AllocationEngine، سیستم را مجبور کند یک فایل ۸.۶ گیگابایتی را روی حافظه رم (RAM) مپ (Memory-map) کند!
💥 نتیجه چه می‌شد؟
از آنجا که دستگاهی مثل Quest 3S کلاً ۸ گیگابایت رم دارد، این درخواستِ سنگین فوراً حافظه را اشباع می‌کرد. در این حالت سیستم مدیریت حافظه اندروید (Low Memory Killer) برای نجات دستگاه فعال می‌شد و شروع به کشتن اجباری (Kill) فرآیندهای حیاتی سیستم با UID 1000 (مانند تنظیمات، سرویس احراز هویت، سیستم ردیابی محیط یا Guardian و مرورگر) می‌کرد که باعث فریز شدن و از کار افتادن کامل هدست می‌شد.
✅ وضعیت اصلاحیه:
متا این آسیب‌پذیری را در نسخه vros 204 با حذف کامل این پکیجِ عیب‌یابی از روی سیستم‌عامل برطرف کرده است؛ بنابراین اگر هدست خود را آپدیت کرده باشید، دیگر خطری شما را تهدید نمی‌کند.
🔗 لینک مقاله کامل و تحلیل کدها:
https://www.djini.ai/blog/technical-advisory-meta-quest-system-wide-dos-via-unprotected-memory
🆔 @androidSec_fa
#Android #Security #Vulnerability #MetaQuest #VR #DoS #AndroidSecurity
Djini.ai
Technical Advisory - Meta Quest System-Wide DoS via Unprotected Memory - Djini.ai
Product Meta Quest System Resource (com.oculus.systemresource) Affected versions 201.0.0.129.1682 and below (the v201 OS train) Fixed in vros 204 — the com.oculus.systemresource application is removed entirely from the build Vulnerability type Denial of Service…
👍3
🚨 هشدار امنیتی: بدافزار بانکی در لباس برنامه‌های سندخوان!
گروه امنیتی ThreatLabz به‌تازگی هشدار داده که یک تروجان بانکی خطرناک با نام Anatsa (که با نام TeaBot هم شناخته می‌شود)، موفق شده از سد امنیتی گوگل‌پلی عبور کند.
⚠️ نکات مهمی که باید بدانید:
🔹 این بدافزار تحت پوشش یک برنامه «سندخوان» (PDF/Document Reader) در فروشگاه گوگل عرضه شده و بیش از ۱۰۰ هزار بار دانلود شده است.
🔹 روش فریب: برنامه در ابتدا کاملاً سالم به‌نظر می‌رسد، اما پس از نصب، فایل مخرب اصلی را از سرور هکرها دانلود می‌کند.
🔹 هدف: این تروجان می‌تواند با ایجاد صفحات ورود جعلی روی اپلیکیشن‌های بانکی و صرافی‌ها، رمزهای عبور شما را سرقت کند و حتی به پیامک‌های حاوی رمز پویا دسترسی پیدا کند.
🛡 توصیه امنیتی:
پیش از نصب برنامه‌های جدید، حتماً اعتبار توسعه‌دهنده را بررسی کنید و از دادن دسترسی‌های غیرضروری (مانند Accessibility) به برنامه‌ها خودداری کنید.
🔗 منبع و جزئیات بیشتر:
https://x.com/Threatlabz/status/2069190345418854810
➖➖➖➖➖➖➖➖
🆔 @androidSec_fa
#امنیت #اندروید #بدافزار #هشدار #Anatsa #AndroidSecurity #CyberSecurity
گروه امنیتی ThreatLabz به‌تازگی هشدار داده که یک تروجان بانکی خطرناک با نام Anatsa (که با نام TeaBot هم شناخته می‌شود)، موفق شده از سد امنیتی گوگل‌پلی عبور کند.
⚠️ نکات مهمی که باید بدانید:
🔹 این بدافزار تحت پوشش یک برنامه «سندخوان» (PDF/Document Reader) در فروشگاه گوگل عرضه شده و بیش از ۱۰۰ هزار بار دانلود شده است.
🔹 روش فریب: برنامه در ابتدا کاملاً سالم به‌نظر می‌رسد، اما پس از نصب، فایل مخرب اصلی را از سرور هکرها دانلود می‌کند.
🔹 هدف: این تروجان می‌تواند با ایجاد صفحات ورود جعلی روی اپلیکیشن‌های بانکی و صرافی‌ها، رمزهای عبور شما را سرقت کند و حتی به پیامک‌های حاوی رمز پویا دسترسی پیدا کند.
🛡 توصیه امنیتی:
پیش از نصب برنامه‌های جدید، حتماً اعتبار توسعه‌دهنده را بررسی کنید و از دادن دسترسی‌های غیرضروری (مانند Accessibility) به برنامه‌ها خودداری کنید.
🔗 منبع و جزئیات بیشتر:
https://x.com/Threatlabz/status/2069190345418854810
➖➖➖➖➖➖➖➖
🆔 @androidSec_fa
#امنیت #اندروید #بدافزار #هشدار #Anatsa #AndroidSecurity #CyberSecurity
X (formerly Twitter)
Zscaler ThreatLabz (@Threatlabz) on X
⚠️ ThreatLabz discovered another fake document reader in the Google Play Store with more than 100K downloads, which delivers the Anatsa Android trojan.
Anatsa installer MD5 hash: f72b1a333fa28b…
Anatsa installer MD5 hash: f72b1a333fa28b…
👍3❤1
معماری پردازنده گرافیکی به زبان آدمیزاد! (بخش اول: کارگاه نقاشی)
خیلی از ما فکر می‌کنیم کارت گرافیک یا همان GPU داخل گوشی، فقط یک قطعه برای بالا آوردن بازی‌ها یا رندر کردن ویدیوهاست. اما در دنیای هک و امنیت، پردازنده گرافیکی یکی از خطرناک‌ترین و جذاب‌ترین مسیرها برای نفوذ به قلب سیستم‌عامل (کرنل) است.
تیم قرمز اندروید گوگل (Android Red Team) در کنفرانس امنیتی OffensiveCon 2026 از یک زنجیره باگ خیره‌کننده روی پردازنده‌های گرافیکی PowerVR (تراشه Tensor G5 در گوشی‌های گوگل) پرده برداشته که نشان می‌دهد چطور یک اشتباه در نقاشی تصاویر، کل امنیت گوشی را به باد می‌دهد.
قبل از اینکه وارد بحث باگ بشویم، باید بفهمیم این قطعه اصلاً چطور کار می‌کند.
پردازنده‌های گرافیکی موبایل برای اینکه باتری کمتری مصرف کنند و سرعتشان بالا برود، از روشی به نام Tile-Based Deferred Rendering (TBDR) استفاده می‌کنند.
💡 یک مثال ساده:
تصور کنید می‌خواهید یک بوم نقاشی خیلی بزرگ را رنگ کنید. اگر بخواهید کل بوم را یک‌دفعه رنگ کنید، دستتان خسته می‌شود و رنگ کم می‌آورید. GPU موبایل می‌آید این بوم بزرگ (صفحه نمایش) را به مربع‌های بسیار کوچک مثل کاشی (Tile) تقسیم می‌کند. سپس رندر کردن هر کاشی را تا آخرین لحظه عقب می‌اندازد تا مطمئن شود دقیقاً چه چیزی قرار است روی صفحه دیده شود و فقط همان را نقاشی کند.
برای اینکه این «کاشی‌ها» و اطلاعات هندسی نقاشی‌ها در حافظه موقت گم نشوند، پردازنده گرافیکی از مکانیزمی به نام FreeList (FL) استفاده می‌کند.
فری‌لیست را مثل یک «کمد بایگانی مخصوص سخت‌افزار گرافیک» در نظر بگیرید که وظیفه‌اش رزرو کردن و مدیریت صفحات حافظه برای ذخیره داده‌های گرافیکی است.
در پست بعدی می‌بینیم که چطور هکرها قفل این کمد بایگانی را می‌شکنند! 👇
🆔 @androidSec_fa
#AndroidSecurity #GPU_Hacking #ReverseEngineering #PowerVR #Part1
خیلی از ما فکر می‌کنیم کارت گرافیک یا همان GPU داخل گوشی، فقط یک قطعه برای بالا آوردن بازی‌ها یا رندر کردن ویدیوهاست. اما در دنیای هک و امنیت، پردازنده گرافیکی یکی از خطرناک‌ترین و جذاب‌ترین مسیرها برای نفوذ به قلب سیستم‌عامل (کرنل) است.
تیم قرمز اندروید گوگل (Android Red Team) در کنفرانس امنیتی OffensiveCon 2026 از یک زنجیره باگ خیره‌کننده روی پردازنده‌های گرافیکی PowerVR (تراشه Tensor G5 در گوشی‌های گوگل) پرده برداشته که نشان می‌دهد چطور یک اشتباه در نقاشی تصاویر، کل امنیت گوشی را به باد می‌دهد.
قبل از اینکه وارد بحث باگ بشویم، باید بفهمیم این قطعه اصلاً چطور کار می‌کند.
پردازنده‌های گرافیکی موبایل برای اینکه باتری کمتری مصرف کنند و سرعتشان بالا برود، از روشی به نام Tile-Based Deferred Rendering (TBDR) استفاده می‌کنند.
💡 یک مثال ساده:
تصور کنید می‌خواهید یک بوم نقاشی خیلی بزرگ را رنگ کنید. اگر بخواهید کل بوم را یک‌دفعه رنگ کنید، دستتان خسته می‌شود و رنگ کم می‌آورید. GPU موبایل می‌آید این بوم بزرگ (صفحه نمایش) را به مربع‌های بسیار کوچک مثل کاشی (Tile) تقسیم می‌کند. سپس رندر کردن هر کاشی را تا آخرین لحظه عقب می‌اندازد تا مطمئن شود دقیقاً چه چیزی قرار است روی صفحه دیده شود و فقط همان را نقاشی کند.
برای اینکه این «کاشی‌ها» و اطلاعات هندسی نقاشی‌ها در حافظه موقت گم نشوند، پردازنده گرافیکی از مکانیزمی به نام FreeList (FL) استفاده می‌کند.
فری‌لیست را مثل یک «کمد بایگانی مخصوص سخت‌افزار گرافیک» در نظر بگیرید که وظیفه‌اش رزرو کردن و مدیریت صفحات حافظه برای ذخیره داده‌های گرافیکی است.
در پست بعدی می‌بینیم که چطور هکرها قفل این کمد بایگانی را می‌شکنند! 👇
🆔 @androidSec_fa
#AndroidSecurity #GPU_Hacking #ReverseEngineering #PowerVR #Part1
👍3
اندروید | امنیت و هک
معماری پردازنده گرافیکی به زبان آدمیزاد! (بخش اول: کارگاه نقاشی) خیلی از ما فکر می‌کنیم کارت گرافیک یا همان GPU داخل گوشی، فقط یک قطعه برای بالا آوردن بازی‌ها یا رندر کردن ویدیوهاست. اما در دنیای هک و امنیت، پردازنده گرافیکی یکی از خطرناک‌ترین و جذاب‌ترین…
جرقه اول؛ وقتی نقاش آدرس را گم می‌کند! (بخش دوم: بررسی باگ)
در پست قبلی گفتیم که پردازنده گرافیکی برای مدیریت نقاشی‌هایش یک کمد بایگانی به نام FreeList دارد. حالا آسیب‌پذیری اصلی که با شناسه CVE-2025-25180 ثبت شده، دقیقاً در همین بخش اتفاق می‌افتد.
وقتی یک برنامه یا بازی اجرا می‌شود، درایور گرافیک شروع به ساختن یک FreeList جدید در حافظه می‌کند. برای این کار، یک‌سری پارامتر و عدد به سخت‌افزار داده می‌شود. اما محققان گوگل متوجه شدند اگر این اعداد و پارامترها را به شکل خاص و بدخواهانه‌ای دستکاری کنند، یک بخش حیاتی به نام ثبات‌گر یا ریجسترِ پوینترِ استکِ فری‌لیست (FL Stack Pointer Register) دچار اختلال و خرابکاری (Corruption) می‌شود.
💡 به زبان ساده یعنی چی؟
پوینتر (Pointer) در دنیای کامپیوتر یعنی «اشاره‌گر» یا آدرس. فرض کنید به نقاش می‌گویید: «وسایلت را در کمد شماره ۱۰ بگذار». اما به خاطر این باگ، مغز نقاش اصطلاحاً ردیف می‌کند و آدرس کمد ۱۰ را اشتباهی «اتاق گاوصندوق رئیس» می‌خواند!
اینجا پردازنده گرافیکی از محدوده حافظه مجازی مجاز خودش خارج می‌شود (Out-of-bound GPU VA). در نتیجه، سیستم امنیتی کنترل حافظه سخت‌افزاری (MMU) که مثل یک دیوار بین گرافیک و بقیه سیستم است، کاملاً دور زده می‌شود.
حالا پردازنده گرافیکی فریب خورده و شروع به نوشتن داده‌های گرافیکی روی صفحات حافظه فیزیکی دلخواه سیستم (Arbitrary Physical Memory Pages) می‌کند! یعنی جایی که اصلاً و ابداً اجازه دسترسی به آن را نداشته است.
اما چطور می‌شود از این نوشتنِ اشتباه، برای هک کردن کل گوشی استفاده کرد؟
پست بعدی را دنبال کنید. 👇
🆔 @androidSec_fa
#ExploitDev #Vulnerability #CVE_2025_25180 #KernelHacking #Part2
در پست قبلی گفتیم که پردازنده گرافیکی برای مدیریت نقاشی‌هایش یک کمد بایگانی به نام FreeList دارد. حالا آسیب‌پذیری اصلی که با شناسه CVE-2025-25180 ثبت شده، دقیقاً در همین بخش اتفاق می‌افتد.
وقتی یک برنامه یا بازی اجرا می‌شود، درایور گرافیک شروع به ساختن یک FreeList جدید در حافظه می‌کند. برای این کار، یک‌سری پارامتر و عدد به سخت‌افزار داده می‌شود. اما محققان گوگل متوجه شدند اگر این اعداد و پارامترها را به شکل خاص و بدخواهانه‌ای دستکاری کنند، یک بخش حیاتی به نام ثبات‌گر یا ریجسترِ پوینترِ استکِ فری‌لیست (FL Stack Pointer Register) دچار اختلال و خرابکاری (Corruption) می‌شود.
💡 به زبان ساده یعنی چی؟
پوینتر (Pointer) در دنیای کامپیوتر یعنی «اشاره‌گر» یا آدرس. فرض کنید به نقاش می‌گویید: «وسایلت را در کمد شماره ۱۰ بگذار». اما به خاطر این باگ، مغز نقاش اصطلاحاً ردیف می‌کند و آدرس کمد ۱۰ را اشتباهی «اتاق گاوصندوق رئیس» می‌خواند!
اینجا پردازنده گرافیکی از محدوده حافظه مجازی مجاز خودش خارج می‌شود (Out-of-bound GPU VA). در نتیجه، سیستم امنیتی کنترل حافظه سخت‌افزاری (MMU) که مثل یک دیوار بین گرافیک و بقیه سیستم است، کاملاً دور زده می‌شود.
حالا پردازنده گرافیکی فریب خورده و شروع به نوشتن داده‌های گرافیکی روی صفحات حافظه فیزیکی دلخواه سیستم (Arbitrary Physical Memory Pages) می‌کند! یعنی جایی که اصلاً و ابداً اجازه دسترسی به آن را نداشته است.
اما چطور می‌شود از این نوشتنِ اشتباه، برای هک کردن کل گوشی استفاده کرد؟
پست بعدی را دنبال کنید. 👇
🆔 @androidSec_fa
#ExploitDev #Vulnerability #CVE_2025_25180 #KernelHacking #Part2
👍3
اندروید | امنیت و هک
جرقه اول؛ وقتی نقاش آدرس را گم می‌کند! (بخش دوم: بررسی باگ) در پست قبلی گفتیم که پردازنده گرافیکی برای مدیریت نقاشی‌هایش یک کمد بایگانی به نام FreeList دارد. حالا آسیب‌پذیری اصلی که با شناسه CVE-2025-25180 ثبت شده، دقیقاً در همین بخش اتفاق می‌افتد. وقتی…
از یک کرش ساده تا دور زدن KASLR (زنجیره باگ - گام اول)
وقتی شما می‌تونید با پردازنده گرافیکی روی حافظه اصلی بنویسید، اولش همه چیز خراب میشه و سیستم اصطلاحاً ریستارت میشه یا کرش می‌کنه (Kernel Panic).
چون شما دارید کورکورانه داده‌ها رو بازنویسی می‌کنید (فقط ۳.۵ بایت اول هر صفحه حافظه فیزیکی تغییر می‌کرد).
برای اینکه این باگ به یک اکسپلویت (کد مخرب کارآمد) تبدیل بشه، هکرها باید سد اول امنیتی کرنل یعنی KASLR رو دور می‌زدند.
اصطلاح KASLR چیه؟
مبحث (Kernel Address Space Layout Randomization) یک تکنیک امنیتیه که هر بار گوشی روشن میشه، آدرس توابع و بخش‌های حساس کرنل رو در حافظه جابه‌جا می‌کنه تا هکر نتونه حدس بزنه فلان دستور کجای حافظه قرار داره.
هکرها چطور دورش زدن؟
اون‌ها اومدن و از قابلیت نوشتن محدود پردازنده گرافیکی استفاده کردن تا توابع مربوط به سیستم‌فایل‌های مجازی اندروید (مثل مسیر /proc) رو پچ (دستکاری) کنن.
مشخصاً تابع proc_sched_show_task رو طوری تغییر دادن که به جای چاپ کردن آمارهای معمولی سیستم، آدرس‌های واقعی و پنهان شده حافظه کرنل رو بهشون نشون بده (Information Leak). با این کار، نقشه حافظه لو رفت و KASLR کاملاً بی‌اثر شد!
حالا آدرس‌ها رو داریم، گام بعدی چیه؟
پست بعدی رو بخونید. 👇
#KASLR_Bypass #AndroidExploit #KernelLeak #OffensiveSecurity #Part3
وقتی شما می‌تونید با پردازنده گرافیکی روی حافظه اصلی بنویسید، اولش همه چیز خراب میشه و سیستم اصطلاحاً ریستارت میشه یا کرش می‌کنه (Kernel Panic).
چون شما دارید کورکورانه داده‌ها رو بازنویسی می‌کنید (فقط ۳.۵ بایت اول هر صفحه حافظه فیزیکی تغییر می‌کرد).
برای اینکه این باگ به یک اکسپلویت (کد مخرب کارآمد) تبدیل بشه، هکرها باید سد اول امنیتی کرنل یعنی KASLR رو دور می‌زدند.
اصطلاح KASLR چیه؟
مبحث (Kernel Address Space Layout Randomization) یک تکنیک امنیتیه که هر بار گوشی روشن میشه، آدرس توابع و بخش‌های حساس کرنل رو در حافظه جابه‌جا می‌کنه تا هکر نتونه حدس بزنه فلان دستور کجای حافظه قرار داره.
هکرها چطور دورش زدن؟
اون‌ها اومدن و از قابلیت نوشتن محدود پردازنده گرافیکی استفاده کردن تا توابع مربوط به سیستم‌فایل‌های مجازی اندروید (مثل مسیر /proc) رو پچ (دستکاری) کنن.
مشخصاً تابع proc_sched_show_task رو طوری تغییر دادن که به جای چاپ کردن آمارهای معمولی سیستم، آدرس‌های واقعی و پنهان شده حافظه کرنل رو بهشون نشون بده (Information Leak). با این کار، نقشه حافظه لو رفت و KASLR کاملاً بی‌اثر شد!
حالا آدرس‌ها رو داریم، گام بعدی چیه؟
پست بعدی رو بخونید. 👇
#KASLR_Bypass #AndroidExploit #KernelLeak #OffensiveSecurity #Part3
👍3
اندروید | امنیت و هک
از یک کرش ساده تا دور زدن KASLR (زنجیره باگ - گام اول) وقتی شما می‌تونید با پردازنده گرافیکی روی حافظه اصلی بنویسید، اولش همه چیز خراب میشه و سیستم اصطلاحاً ریستارت میشه یا کرش می‌کنه (Kernel Panic). چون شما دارید کورکورانه داده‌ها رو بازنویسی می‌کنید (فقط…
غول اول؛ چطور نقشه مخفی حافظه را لو بدهیم؟ (بخش چهارم: دور زدن KASLR)
برای اینکه بتوانید یک سیستم‌عامل را هک کنید، باید بدانید دستورات و توابع اصلی آن در کجای حافظه (رم) قرار دارند. اما سیستم‌عامل‌های مدرن مثل اندروید، سد محکمی به نام KASLR دارند.
💡 اصطلاح کاربردی: KASLR چیست؟
مخفف Kernel Address Space Layout Randomization است. فرض کنید اتاق‌های یک هتل هر ثانیه جابه‌جا شوند! KASLR کاری می‌کند که هر بار گوشی روشن می‌شود، تمام توابع و بخش‌های حساس هسته سیستم‌عامل (کرنل) در آدرس‌های کاملاً تصادفی و متفاوتی از حافظه قرار بگیرند تا هکر نتواند جایش را پیدا کند.
هکرها چطور این سد را شکستند؟
آن‌ها از همان باگ گرافیکی و نوشتن ۳.۵ بایتی استفاده کردند تا کدهای مربوط به سیستم‌فایل‌های مجازی اندروید (مسیر /proc) را در حافظه دستکاری یا اصطلاحاً پچ (Patch) کنند. در اندروید، فایل‌های این مسیر اطلاعاتی درباره وضعیت سیستم به ما می‌دهند.
مشخصاً آن‌ها سراغ تابعی به نام proc_sched_show_task رفتند که کارش چاپ کردن آمارهای زمان‌بندی پردازنده است. هکرها این تابع را طوری بازنویسی کردند که فرمت خروجی‌اش عوض شود. حالا وقتی برنامه معمولی هکر این فایل را باز می‌کرد، تابع به جای آمارهای معمولی، آدرس‌های واقعی و پنهان‌شده کرنل را در خروجی چاپ می‌کرد (Information Leak)!
با این ترفند، نقشه هتل لو رفت و هکرها دقیقاً فهمیدند هر تابع کرنل کجای حافظه قرار دارد! گام بعدی؟ ساخت کلید اصلی. 👇
🆔 @androidSec_fa
#KASLR_Bypass #InfoLeak #KernelHacking #AndroidSecurity #Part4
برای اینکه بتوانید یک سیستم‌عامل را هک کنید، باید بدانید دستورات و توابع اصلی آن در کجای حافظه (رم) قرار دارند. اما سیستم‌عامل‌های مدرن مثل اندروید، سد محکمی به نام KASLR دارند.
💡 اصطلاح کاربردی: KASLR چیست؟
مخفف Kernel Address Space Layout Randomization است. فرض کنید اتاق‌های یک هتل هر ثانیه جابه‌جا شوند! KASLR کاری می‌کند که هر بار گوشی روشن می‌شود، تمام توابع و بخش‌های حساس هسته سیستم‌عامل (کرنل) در آدرس‌های کاملاً تصادفی و متفاوتی از حافظه قرار بگیرند تا هکر نتواند جایش را پیدا کند.
هکرها چطور این سد را شکستند؟
آن‌ها از همان باگ گرافیکی و نوشتن ۳.۵ بایتی استفاده کردند تا کدهای مربوط به سیستم‌فایل‌های مجازی اندروید (مسیر /proc) را در حافظه دستکاری یا اصطلاحاً پچ (Patch) کنند. در اندروید، فایل‌های این مسیر اطلاعاتی درباره وضعیت سیستم به ما می‌دهند.
مشخصاً آن‌ها سراغ تابعی به نام proc_sched_show_task رفتند که کارش چاپ کردن آمارهای زمان‌بندی پردازنده است. هکرها این تابع را طوری بازنویسی کردند که فرمت خروجی‌اش عوض شود. حالا وقتی برنامه معمولی هکر این فایل را باز می‌کرد، تابع به جای آمارهای معمولی، آدرس‌های واقعی و پنهان‌شده کرنل را در خروجی چاپ می‌کرد (Information Leak)!
با این ترفند، نقشه هتل لو رفت و هکرها دقیقاً فهمیدند هر تابع کرنل کجای حافظه قرار دارد! گام بعدی؟ ساخت کلید اصلی. 👇
🆔 @androidSec_fa
#KASLR_Bypass #InfoLeak #KernelHacking #AndroidSecurity #Part4
👍3
اندروید | امنیت و هک
غول اول؛ چطور نقشه مخفی حافظه را لو بدهیم؟ (بخش چهارم: دور زدن KASLR) برای اینکه بتوانید یک سیستم‌عامل را هک کنید، باید بدانید دستورات و توابع اصلی آن در کجای حافظه (رم) قرار دارند. اما سیستم‌عامل‌های مدرن مثل اندروید، سد محکمی به نام KASLR دارند. 💡 اصطلاح…
ساخت پیش‌خدمت مطیع در قلب سیستم (بخش پنجم: نوشتن دلخواه)
حالا هکرها دو چیز دارند:
۱. یک باگ گرافیکی که آدرس‌ها را جابه‌جا می‌کند
۲. نقشه دقیق حافظه کرنل (به خاطر دور زدن KASLR). اما هنوز یک مشکل بزرگ هست؛ باگ گرافیکی اولیه خیلی محدود است و نمی‌شود با آن کدهای پیچیده نوشت. هکر نیاز به یک ابزار پایداری دارد که بتواند «هر داده‌ای را در هر کجای حافظه کرنل» بنویسد. به این ابزار در دنیای هک Arbitrary Write Primitive می‌گویند.
برای ساخت این ابزار، هکرها سراغ یک تابع سیستمی (System Call) در قلب کرنل به نام __arm64_sys_setitimer رفتند. این تابع در حالت عادی کارش مدیریت تایمرهای سیستم است.
هکرها با استفاده از همان باگ گرافیکی، کدهای داخلی این تابع تایمر را در حافظه رم پچ (دستکاری) کردند. آن‌ها منطق تابع را طوری تغییر دادند که از آن به بعد، هر وقت برنامه هکر این تایمر را صدا بزند و یک آدرس و یک مقدار به آن بدهد، این تابع بدون هیچ لایه امنیتی، آن مقدار را دقیقاً در آن آدرس حساس کرنل بنویسد!
به زبان ساده، آن‌ها یکی از کارکنان رسمی و مورد اعتماد کرنل را جیره_خوار خود کردند تا هر دستوری که هکر از بیرون می‌دهد را در حافظه حساس سیستم اجرا کند. حالا قدرت نوشتن کامل باز شده است. اما برای خواندن اطلاعات چطور؟ 👇
🆔 @androidSec_fa
#ArbitraryWrite #ExploitPrimitive #LinuxKernel #AndroidOffsec #Part5
حالا هکرها دو چیز دارند:
۱. یک باگ گرافیکی که آدرس‌ها را جابه‌جا می‌کند
۲. نقشه دقیق حافظه کرنل (به خاطر دور زدن KASLR). اما هنوز یک مشکل بزرگ هست؛ باگ گرافیکی اولیه خیلی محدود است و نمی‌شود با آن کدهای پیچیده نوشت. هکر نیاز به یک ابزار پایداری دارد که بتواند «هر داده‌ای را در هر کجای حافظه کرنل» بنویسد. به این ابزار در دنیای هک Arbitrary Write Primitive می‌گویند.
برای ساخت این ابزار، هکرها سراغ یک تابع سیستمی (System Call) در قلب کرنل به نام __arm64_sys_setitimer رفتند. این تابع در حالت عادی کارش مدیریت تایمرهای سیستم است.
هکرها با استفاده از همان باگ گرافیکی، کدهای داخلی این تابع تایمر را در حافظه رم پچ (دستکاری) کردند. آن‌ها منطق تابع را طوری تغییر دادند که از آن به بعد، هر وقت برنامه هکر این تایمر را صدا بزند و یک آدرس و یک مقدار به آن بدهد، این تابع بدون هیچ لایه امنیتی، آن مقدار را دقیقاً در آن آدرس حساس کرنل بنویسد!
به زبان ساده، آن‌ها یکی از کارکنان رسمی و مورد اعتماد کرنل را جیره_خوار خود کردند تا هر دستوری که هکر از بیرون می‌دهد را در حافظه حساس سیستم اجرا کند. حالا قدرت نوشتن کامل باز شده است. اما برای خواندن اطلاعات چطور؟ 👇
🆔 @androidSec_fa
#ArbitraryWrite #ExploitPrimitive #LinuxKernel #AndroidOffsec #Part5
👍3
اندروید | امنیت و هک
ساخت پیش‌خدمت مطیع در قلب سیستم (بخش پنجم: نوشتن دلخواه) حالا هکرها دو چیز دارند: ۱. یک باگ گرافیکی که آدرس‌ها را جابه‌جا می‌کند ۲. نقشه دقیق حافظه کرنل (به خاطر دور زدن KASLR). اما هنوز یک مشکل بزرگ هست؛ باگ گرافیکی اولیه خیلی محدود است و نمی‌شود با آن…
چشم‌انداز کامل؛ کور کردن سیستم امنیتی (بخش ششم: خواندن دلخواه)
داشتن قدرت نوشتن در حافظه عالی است، اما اگر نتوانید حافظه را بخوانید، مثل نابینایی هستید که اسلحه دارد اما نمی‌داند به کجا شلیک کند! هکرها برای کنترل کامل به ابزاری برای «خواندن هر کجای حافظه کرنل» (Arbitrary Read Primitive) نیاز داشتند.
یک لایه امنیتی در اندروید به نام kptr_restrict وجود دارد که تمام آدرس‌ها و پوینترهای حساس را به صورت هش‌شده (رمزنگاری شده) نگه می‌دارد تا حتی اگر هکر دسترسی پیدا کرد، نتواند آن‌ها را بخواند. اما هکرها یک کلید مخفی پیدا کردند؛ کلیدی به نام ptr_key در بخش .data کرنل وجود دارد که وظیفه‌اش تولید همین هش‌هاست.
هکرها با استفاده از ابزار نوشتنی که در مرحله قبل ساختند، مقدار این کلید (ptr_key) را در حافظه پیدا کردند و آن را به صفر تغییر دادند! با صفر شدن این کلید، تمام سیستم هشینگ عملاً از کار افتاد و آدرس‌ها به صورت متن ساده (Plaintext) درآمدند.
سپس سراغ بخش شبکه کرنل و مسیر /proc/self/net/udp رفتند و ساختار یک سوکت شبکه (به نام sk_socket) را بازنویسی کردند. از این به بعد، هکر هر آدرس فیزیکی از رم گوشی را که می‌خواست بخواند، به این بخش می‌داد و سیستم مثل یک کتاب باز، اطلاعات آن آدرس را به هکر تحویل می‌داد.
حالا هکر هم بینایی کامل دارد (خواندن) و هم توانایی کامل (نوشتن). وقت ضربه آخر است. 👇
🆔 @androidSec_fa
#KernelRead #InformationDisclosure #AndroidInternals #Hacking #Part6
داشتن قدرت نوشتن در حافظه عالی است، اما اگر نتوانید حافظه را بخوانید، مثل نابینایی هستید که اسلحه دارد اما نمی‌داند به کجا شلیک کند! هکرها برای کنترل کامل به ابزاری برای «خواندن هر کجای حافظه کرنل» (Arbitrary Read Primitive) نیاز داشتند.
یک لایه امنیتی در اندروید به نام kptr_restrict وجود دارد که تمام آدرس‌ها و پوینترهای حساس را به صورت هش‌شده (رمزنگاری شده) نگه می‌دارد تا حتی اگر هکر دسترسی پیدا کرد، نتواند آن‌ها را بخواند. اما هکرها یک کلید مخفی پیدا کردند؛ کلیدی به نام ptr_key در بخش .data کرنل وجود دارد که وظیفه‌اش تولید همین هش‌هاست.
هکرها با استفاده از ابزار نوشتنی که در مرحله قبل ساختند، مقدار این کلید (ptr_key) را در حافظه پیدا کردند و آن را به صفر تغییر دادند! با صفر شدن این کلید، تمام سیستم هشینگ عملاً از کار افتاد و آدرس‌ها به صورت متن ساده (Plaintext) درآمدند.
سپس سراغ بخش شبکه کرنل و مسیر /proc/self/net/udp رفتند و ساختار یک سوکت شبکه (به نام sk_socket) را بازنویسی کردند. از این به بعد، هکر هر آدرس فیزیکی از رم گوشی را که می‌خواست بخواند، به این بخش می‌داد و سیستم مثل یک کتاب باز، اطلاعات آن آدرس را به هکر تحویل می‌داد.
حالا هکر هم بینایی کامل دارد (خواندن) و هم توانایی کامل (نوشتن). وقت ضربه آخر است. 👇
🆔 @androidSec_fa
#KernelRead #InformationDisclosure #AndroidInternals #Hacking #Part6
👍3
اندروید | امنیت و هک
چشم‌انداز کامل؛ کور کردن سیستم امنیتی (بخش ششم: خواندن دلخواه) داشتن قدرت نوشتن در حافظه عالی است، اما اگر نتوانید حافظه را بخوانید، مثل نابینایی هستید که اسلحه دارد اما نمی‌داند به کجا شلیک کند! هکرها برای کنترل کامل به ابزاری برای «خواندن هر کجای حافظه…
فروپاشی پادشاهی اندروید؛ فتح قله روت (بخش هفتم: تغییر اعتبارات)
به فاز نهایی زنجیره اکسپلویت رسیدیم.
هکر اکنون دو ابزار فوق‌العاده قدرتمند دارد:
خواندن و نوشتن بی‌قید و شرط در تمام حافظه کرنل سیستم‌عامل. هدف نهایی چیست؟ به دست آوردن دسترسی Root (بالاترین سطح دسترسی در لینوکس و اندروید).
توجیه این بخش بسیار ساده و در عین حال هیجان‌انگیز است. در سیستم‌عامل اندروید، هر برنامه یا پروسسی که اجرا می‌شود، یک شیء یا ساختار داده به نام cred (مخفف Credentials یا اعتبارات) در حافظه کرنل دارد. این ساختار مشخص می‌کند که این برنامه چه کسی است و چقدر اجازه دارد دسترسی داشته باشد. برای کاربر Root یا همان سوپریوزر، شناسه‌های این ساختار (مثل UID و GID) برابر با صفر است.
هکر با استفاده از ابزار خواندن خود، شروع به جستجو در لیست تمام پروسس‌های فعال کرنل (init_task_list_head) می‌کند تا برنامه خودش را پیدا کند.
به محض پیدا کردن برنامه خود، با ابزار نوشتن وارد عمل می‌شود و تمام شناسه‌های امنیتی شیء cred برنامه خود را پاک کرده و به صفر تغییر می‌دهد! به همین سادگی، سیستم‌عامل فریب می‌خورد و فکر می‌کند این برنامه معمولی، همان رئیس بزرگ یا کاربر روت است. اما هنوز یک لایه محافظتی سرسخت باقی مانده است: SELinux! 👇
🆔 @androidSec_fa
#Rooting #PrivilegeEscalation #KernelExploit #AndroidSecurity #Part7
به فاز نهایی زنجیره اکسپلویت رسیدیم.
هکر اکنون دو ابزار فوق‌العاده قدرتمند دارد:
خواندن و نوشتن بی‌قید و شرط در تمام حافظه کرنل سیستم‌عامل. هدف نهایی چیست؟ به دست آوردن دسترسی Root (بالاترین سطح دسترسی در لینوکس و اندروید).
توجیه این بخش بسیار ساده و در عین حال هیجان‌انگیز است. در سیستم‌عامل اندروید، هر برنامه یا پروسسی که اجرا می‌شود، یک شیء یا ساختار داده به نام cred (مخفف Credentials یا اعتبارات) در حافظه کرنل دارد. این ساختار مشخص می‌کند که این برنامه چه کسی است و چقدر اجازه دارد دسترسی داشته باشد. برای کاربر Root یا همان سوپریوزر، شناسه‌های این ساختار (مثل UID و GID) برابر با صفر است.
هکر با استفاده از ابزار خواندن خود، شروع به جستجو در لیست تمام پروسس‌های فعال کرنل (init_task_list_head) می‌کند تا برنامه خودش را پیدا کند.
به محض پیدا کردن برنامه خود، با ابزار نوشتن وارد عمل می‌شود و تمام شناسه‌های امنیتی شیء cred برنامه خود را پاک کرده و به صفر تغییر می‌دهد! به همین سادگی، سیستم‌عامل فریب می‌خورد و فکر می‌کند این برنامه معمولی، همان رئیس بزرگ یا کاربر روت است. اما هنوز یک لایه محافظتی سرسخت باقی مانده است: SELinux! 👇
🆔 @androidSec_fa
#Rooting #PrivilegeEscalation #KernelExploit #AndroidSecurity #Part7
👍3
اندروید | امنیت و هک
فروپاشی پادشاهی اندروید؛ فتح قله روت (بخش هفتم: تغییر اعتبارات) به فاز نهایی زنجیره اکسپلویت رسیدیم. هکر اکنون دو ابزار فوق‌العاده قدرتمند دارد: خواندن و نوشتن بی‌قید و شرط در تمام حافظه کرنل سیستم‌عامل. هدف نهایی چیست؟ به دست آوردن دسترسی Root (بالاترین…
تیر خلاص؛ چطور SELinux را فلج کنیم؟ (بخش هشتم: خلع سلاح نگهبان)
حتی اگر شما در اندروید دسترسی روت (Root) داشته باشید، یک نگهبان بسیار سختگیر و بی‌رحم به نام SELinux بالای سر شما ایستاده است.
💡 اصطلاح کاربردی: SELinux چیست؟
مخفف Security-Enhanced Linux است. این لایه امنیتی یک قانون دارد:
«حتی اگر روت هستید، حق ندارید کارهای خارج از تعریف خود را انجام دهید».
ویژگی SELinux معمولاً جلوی اکسپلویت‌ها را حتی بعد از روت شدن می‌گیرد.
اما هکری که دسترسی کامل به خواندن و نوشتن حافظه کرنل دارد را هیچ چیز نمی‌تواند متوقف کند. هکرها به جای اینکه تلاش کنند SELinux را متقاعد کنند، تصمیم گرفتند مغز آن را دستکاری کنند!
آن‌ها با ابزار نوشتن خود سراغ جدول تصمیم‌گیری‌های SELinux (معروف به AVC Decision Mapping) در حافظه کرنل رفتند و تمام قوانین آن را پاک کردند. سپس حافظه پنهان یا کاشِ (Cache) تصمیمات امنیتی آن را کاملاً فلش (پاکسازی) کردند.
نتیجه؟
نگهبان سختگیر سیستم‌عامل (SELinux) عملاً کور و فلج شد و دیگر هیچ درخواستی را رد نمی‌کرد. این تکنیک بی‌نظیر که از یک باگ کاشی‌کاری گرافیکی شروع شد و به روت کامل دستگاه ختم شد، Tile-based Deferred Rooting نام دارد! گوشی حالا کاملاً و ۱۰۰٪ در اختیار هکر است.
در پست آخر، جمع‌بندی نهایی و لینک مقاله اصلی را قرار داده‌ام. 👇
🆔 @androidSec_fa
#SELinux #AndroidSecurity #ExploitChain #KernelDefense #Part8
حتی اگر شما در اندروید دسترسی روت (Root) داشته باشید، یک نگهبان بسیار سختگیر و بی‌رحم به نام SELinux بالای سر شما ایستاده است.
💡 اصطلاح کاربردی: SELinux چیست؟
مخفف Security-Enhanced Linux است. این لایه امنیتی یک قانون دارد:
«حتی اگر روت هستید، حق ندارید کارهای خارج از تعریف خود را انجام دهید».
ویژگی SELinux معمولاً جلوی اکسپلویت‌ها را حتی بعد از روت شدن می‌گیرد.
اما هکری که دسترسی کامل به خواندن و نوشتن حافظه کرنل دارد را هیچ چیز نمی‌تواند متوقف کند. هکرها به جای اینکه تلاش کنند SELinux را متقاعد کنند، تصمیم گرفتند مغز آن را دستکاری کنند!
آن‌ها با ابزار نوشتن خود سراغ جدول تصمیم‌گیری‌های SELinux (معروف به AVC Decision Mapping) در حافظه کرنل رفتند و تمام قوانین آن را پاک کردند. سپس حافظه پنهان یا کاشِ (Cache) تصمیمات امنیتی آن را کاملاً فلش (پاکسازی) کردند.
نتیجه؟
نگهبان سختگیر سیستم‌عامل (SELinux) عملاً کور و فلج شد و دیگر هیچ درخواستی را رد نمی‌کرد. این تکنیک بی‌نظیر که از یک باگ کاشی‌کاری گرافیکی شروع شد و به روت کامل دستگاه ختم شد، Tile-based Deferred Rooting نام دارد! گوشی حالا کاملاً و ۱۰۰٪ در اختیار هکر است.
در پست آخر، جمع‌بندی نهایی و لینک مقاله اصلی را قرار داده‌ام. 👇
🆔 @androidSec_fa
#SELinux #AndroidSecurity #ExploitChain #KernelDefense #Part8
👍3
اندروید | امنیت و هک
تیر خلاص؛ چطور SELinux را فلج کنیم؟ (بخش هشتم: خلع سلاح نگهبان) حتی اگر شما در اندروید دسترسی روت (Root) داشته باشید، یک نگهبان بسیار سختگیر و بی‌رحم به نام SELinux بالای سر شما ایستاده است. 💡 اصطلاح کاربردی: SELinux چیست؟ مخفف Security-Enhanced Linux…
جمع‌بندی نهایی و لینک مقاله اصلی (بخش پایانی)
این تحقیق شاهکار که در کنفرانس OffensiveCon 2026 ارائه شد، توسط شینگیو جین (Xingyu Jin) و مارتین بوگارد (Martijn Bogaard) از تیم درخشان قرمز اندروید گوگل انجام شده است.
چه چیزهایی از این زنجیره باگ یاد گرفتیم؟
۱. فهمیدیم که چطور یک اشتباه کوچک در پیکربندی حافظه موقت پردازنده گرافیکی (GPU) می‌تواند به سخت‌افزار اجازه دهد سیستم امنیتی کنترل حافظه را دور بزند.
۲. یاد گرفتیم که هکرهای پیشرفته چطور با ترکیب کردن چند تکنیک (دور زدن KASLR، پچ کردن توابع کرنل و دستکاری ساختار cred) یک باگ کوچک را به کنترل کامل گوشی تبدیل می‌کنند.
⚠️ آیا گوشی ما در خطر است؟
خوشبختانه به هیچ وجه! این اکسپلویت و زنجیره باگ روی یک نسخه آزمایشی داخلی و آزمایشگاهی (Internal test build) پیاده‌سازی شده بود. تیم امنیتی گوگل و شرکت Imagination Technologies خیلی قبل از اینکه این مقاله و اسلایدها به صورت عمومی منتشر شوند، وصله‌ها و پچ‌های امنیتی آن را تولید و برای تمام گوشی‌ها فرستادند. بنابراین تمام دستگاه‌های موجود در بازار امن هستند.
اگر به مباحث مهندسی معکوس، کدهای اسمبلی سخت‌افزاری و جزئیات دقیق‌تر ساختار حافظه این باگ علاقه‌مندید، حتماً اسلایدهای رسمی این ارائه را از لینک زیر دانلود و مطالعه کنید:
🔗 لینک دانلود مستقیم اسلایدهای مقاله در وب‌سایت گوگل:
https://androidoffsec.withgoogle.com/slides/art_imagination_gpu_offensivecon_2026.pdf
امیدوارم این سلسله پست‌های آموزشی گام‌به‌گام برای شما مفید بوده باشد.🔥
🆔 @androidSec_fa
#AndroidSecurity #CyberSecurity #OffensiveCon2026 #GoogleRedTeam #TheEnd
این تحقیق شاهکار که در کنفرانس OffensiveCon 2026 ارائه شد، توسط شینگیو جین (Xingyu Jin) و مارتین بوگارد (Martijn Bogaard) از تیم درخشان قرمز اندروید گوگل انجام شده است.
چه چیزهایی از این زنجیره باگ یاد گرفتیم؟
۱. فهمیدیم که چطور یک اشتباه کوچک در پیکربندی حافظه موقت پردازنده گرافیکی (GPU) می‌تواند به سخت‌افزار اجازه دهد سیستم امنیتی کنترل حافظه را دور بزند.
۲. یاد گرفتیم که هکرهای پیشرفته چطور با ترکیب کردن چند تکنیک (دور زدن KASLR، پچ کردن توابع کرنل و دستکاری ساختار cred) یک باگ کوچک را به کنترل کامل گوشی تبدیل می‌کنند.
⚠️ آیا گوشی ما در خطر است؟
خوشبختانه به هیچ وجه! این اکسپلویت و زنجیره باگ روی یک نسخه آزمایشی داخلی و آزمایشگاهی (Internal test build) پیاده‌سازی شده بود. تیم امنیتی گوگل و شرکت Imagination Technologies خیلی قبل از اینکه این مقاله و اسلایدها به صورت عمومی منتشر شوند، وصله‌ها و پچ‌های امنیتی آن را تولید و برای تمام گوشی‌ها فرستادند. بنابراین تمام دستگاه‌های موجود در بازار امن هستند.
اگر به مباحث مهندسی معکوس، کدهای اسمبلی سخت‌افزاری و جزئیات دقیق‌تر ساختار حافظه این باگ علاقه‌مندید، حتماً اسلایدهای رسمی این ارائه را از لینک زیر دانلود و مطالعه کنید:
🔗 لینک دانلود مستقیم اسلایدهای مقاله در وب‌سایت گوگل:
https://androidoffsec.withgoogle.com/slides/art_imagination_gpu_offensivecon_2026.pdf
امیدوارم این سلسله پست‌های آموزشی گام‌به‌گام برای شما مفید بوده باشد.🔥
🆔 @androidSec_fa
#AndroidSecurity #CyberSecurity #OffensiveCon2026 #GoogleRedTeam #TheEnd
👍5