🛡️ابزار کاربردی برای تست نفوذ اپلیکیشن‌های اندرویدی!

ابزار ​APKShield-PT ابزاری خودکار برای دیکامپایل کردن فایل‌های APK و شناسایی مکانیزم‌های امنیتی مثل SSL Pinning و Root Detection است که اسکریپت‌های لازم برای دور زدن آن‌ها را نیز در اختیارتان قرار می‌دهد.

​لینک ریپازیتوری:
https://github.com/Whitehat987/apkshield-pt

​@androidSec_fa

#AndroidSecurity #Pentest #Frida #CyberSecurity

​🔥 تست نفوذ پوزهای اندرویدی؛ وقتی پروتکل بانکی زیر ذره‌بین می‌رود!

​سلام رفقا! امروز می‌خوام خلاصه یک گزارش تست نفوذ (Penetration Testing) فوق‌العاده عمیق و کاربردی رو براتون بگم که روی سیستم‌های پرداخت و کارتخوان‌های جدید اندرویدی انجام شده.

​خیلی از تسترها وقتی امنیت یک دستگاه پوز (POS) رو بررسی می‌کنن، فقط سراغ باگ‌های وب، APIها یا کدهای جاوای خود اپلیکیشن میرن. اما این تستر رفته سراغ هسته اصلی و تاریک ماجرا: پروتکل ارتباطی ISO 8583؛ یعنی همون زبون استاندارد و فریم‌های هگزادسیمالی که دستگاه پوز باهاش مستقیماً از طریق سوکت شبکه با سرور بانک یا پردازشگر پرداخت حرف میزنه.

​🛠 تستر چطور راهش رو به سیستم باز کرد؟

این پروژه یک ارزیابی امنیتی قانونی بوده. شرکت سازنده، فایل APK اپلیکیشن پوز رو در اختیار تستر قرار میده. این برنامه در مرحله پیش-تولید بود و به جای بانک واقعی، به یک شبیه‌ساز (Mock Server) وصل می‌شد که روی اینترنت عمومی فعال بود و دقیقاً مثل سرور بانک رفتار می‌کرد.
​تستر با مهندسی معکوس کدهای اپلیکیشن، متوجه یک فلگ پنهان به نام debugMode=false میشه. اون این فلگ رو به true تغییر میده و برنامه رو دوباره باندل می‌کنه. با این کار، یک اتفاق جذاب میفته: دستگاه پوز تمام پیام‌های تراکنش (خرید، ابطال و...) رو که به زبان هگزادسیمال تولید می‌کرد، توی لاگ‌های سیستم چاپ می‌کنه!

​حالا تستر کدهای هگزادسیمال تراکنش‌ها رو کپی می‌کنه و با زبان پایتون یک اسکریپت می‌نویسه. این اسکریپت کارش این بود که خودش رو جای دستگاه پوز جا بزنه، مستقیم به آی‌پي و پورت اون شبیه‌ساز وصل بشه و پیام‌های دستکاری‌شده بفرسته تا ببینه سرور چقدر امنیت داره...

​👇 توی پست بعدی، باگ‌های عجیبی که توی لایه سوکت پیدا شد رو بررسی می‌کنیم!

​🆔 @androidSec_fa

​#امنیت #تست_نفوذ #امنیت_اندروید #تست_پوز #پروتکل_ISO8583 #هک_و_امنیت

​🔥 شکار ۴ باگ بحرانی و منطقی در لایه سوکت پرداخت!

​در ادامه پست قبل، تستر با اسکریپت پایتون خودش شروع کرد به فرستادن فریم‌های دستکاری‌شده ISO 8583 به سمت سرور شبیه‌ساز پرداخت. سرور پردازشگر برخلاف ظاهرش، توی بررسی منطق تراکنش‌ها (Business Logic) فاجعه بود و تستر تونست ۴ تا باگ بسیار خطرناک ازش دربیاره:

​1️⃣ دور زدن پنجره زمانی و حمله تکرار (Replay Attack):

سرورها برای اینکه یک تراکنش به خاطر اختلال شبکه دوبار حساب نشه، تا چند ثانیه تراکنش تکراری رو رد می‌کنن. اما تستر فهمید اگه کمی صبر کنه تا اون زمان منقضی بشه و بعد دقیقاً همون کد هگز تراکنش قبلی رو بفرسته، سرور اون رو به عنوان یک خرید کاملاً جدید قبول می‌کنه! (یعنی امکان دبل‌شارژ کردن و دزدیدن پول از کارت مشتری).

​2️⃣ آسیب‌پذیری IDOR بین فروشگاه‌ها (Cross-Merchant IDOR):

تستر با اکانت و سوکت «فروشگاه ب» به سرور وصل شد، اما در پیام هگزادسیمال، شماره مرجع تراکنش (RRN) متعلق به «فروشگاه الف» رو قرار داد. سرور اصلاً چک نکرد که این تراکنش مال کیه و درخواست ابطال (Void) یا برگشت وجه رو تایید کرد! یعنی یک فروشگاه راحت می‌تونست تراکنش‌های رقیبش رو باطل کنه.

​3️⃣ تراکنش شبح (Ghost Transactions):

تستر بدون اینکه فریم احراز هویت (AUTH) رو به سوکت سرور بفرسته، مستقیم درخواست پرداخت فرستاد. سرور تاییدیه پرداخت رو صادر کرد (DE39 = 00)، اما عجیب اینجا بود که این تراکنش در هیچ‌کدوم از سیستم‌های حسابداری، مانیتورینگ و پنل مدیریت ثبت نشد! یعنی پول جابه‌جا می‌شد بدون اینکه ردی بمونه.

​4️⃣ بای‌پاس تایید هویت کارت در زمان ابطال:

پوزهای اندرویدی موقع باطل کردن تراکنش، از کاربر می‌خوان که همون کارت قبلی رو بکشه تا دستگاه تطابق رو چک کنه. تستر با کپی کردن فریم ابطال و فرستادن مستقیم اون از طریق پایتون به سوکت شبکه، این لایه امنیتیِ توکن‌سازی کارت رو کاملاً دور زد و سرور بدون چک کردن اطلاعات کارت، ابطال رو انجام داد.

​👇 پست سوم و آخر رو برای نتیجه‌گیری معماری این باگ‌ها دنبال کنید...

​🆔 @androidSec_fa

​#امنیت #تست_نفوذ #باگ_منطقی #امنیت_شبکه #سوکت_نویسی #تست_پوز

​💡 نتیجه‌گیری معماری؛ چرا نباید به لایه‌های بعدی اعتماد کرد؟

​شاید بعد از خوندن باگ‌های پست قبل بگید:

«خب این باگ‌ها روی سرور بانک واقعی کار نمی‌کنه چون بانک خودش دبل تراکنش یا موجودی رو چک می‌کنه». اما نویسنده مقاله یک استدلال فوق‌العاده درست و استاندارد رو مطرح می‌کنه:

​تسوویه و منطق تراکنش‌ها وظیفه خودِ پردازشگر پرداخت (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 #امنیت_اندروید

بررسی آسیب‌پذیری جدید در شبیه‌ساز اندروید 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

🚨 شکارچیان خاموش؛ چطور چراغ هشدار عینک‌های هوشمند هک می‌شود؟

عینک‌های هوشمند جدید (مثل Ray-Ban Meta) دقیقاً شبیه عینک طبی یا آفتابی معمولی هستند و دوربین کوچک آن‌ها عملاً قابل تشخیص نیست.

🛠 دور زدن فیزیکی چراغ هشدار (LED)
سازندگان برای حفظ حریم خصوصی، یک LED روی فریم گذاشته‌اند که هنگام ضبط روشن می‌شود. اما این مانع به راحتی دور زده می‌شود:

▪️ کاورها و استیکرها: برچسب‌هایی در بازار هستند که روی LED را می‌پوشانند. این کاورها با داشتن یک روزنه ریز، نور کافی را به سنسور عینک می‌رسانند تا ضبط متوقف نشود، اما دیدن چراغ را غیرممکن می‌کنند.

▪️ جراحی سخت‌افزاری (Modding): هکرها با ابزارهای ظریف، LED را دستکاری یا مسدود کرده تا عینک در حالت صددرصد مخفی (Stealth) فیلم‌برداری کند!

در پست بعدی به این می‌پردازیم که چرا اپلیکیشن‌های موبایلی هم از شناسایی این عینک‌ها عاجز هستند.👇

ID: @androidSec_fa

#Cybersecurity #Privacy #HardwareHacking #SmartGlasses

📡 پشت پرده فنی؛ چرا اپ‌های اندرویدی در ردیابی عینک‌های هوشمند شکست می‌خورند؟

پس از موج نگرانی‌ها بابت جاسوسی با عینک‌های هوشمند، متخصصان امنیت اندروید تلاش کردند با استفاده از 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

👁 کابوس بیومتری؛ وقتی عینک هوشمند ابزار 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

​🪲 تروجان بانکی 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

​📱 اتصال همزمان ده‌ها سیم‌کارت به یک آیفون و دور زدن بن‌شدن‌های واتساپ!

​شاید در نگاه اول عجیب به نظر برسد، اما در این ویدیو با دستگاهی به نام Chipeira (شبیه‌ساز سخت‌افزاری سیم‌کارت) آشنا می‌شوید که به هکرها و متخصصان سئو/مارکتینگ اجازه می‌دهد صدها اکانت واتساپ را به طور همزمان روی یک گوشی مدیریت کنند.

​⚙️ ترفند کار کجاست؟
۱. بورد سخت‌افزاری: کنترل دستی سیم‌کارت‌ها؛ برای فعال‌سازی یا دریافت پیامک تأیید هر شماره، کلید مربوط به آن سیم‌کارت روی بورد روشن می‌شود و نیازی به خرید ده‌ها گوشی نیست.

۲. ایزوله‌سازی نرم‌افزاری (Cloning): با فریب دادن هویت دیجیتال برنامه (Device ID و MAC Address)، واتساپ تصور می‌کند هر اکانت روی یک گوشی کاملاً مجزا در نقطه‌ای دیگر از دنیا نصب شده است؛ در نتیجه با بن شدن یک اکانت، بقیه اکانت‌ها هیچ آسیبی نمی‌بینند!

​🚀 ابزاری کاربردی برای پروژه‌های ترافیک مستقیم و ارسال انبوه که ساختار امنیتی واتساپ را به چالش می‌کشد.

​🆔 @androidSec_fa

#‌امنیت #تست_نفوذ #واتساپ #امنیت_شبکه #هک #

​یه ابزار برای مهندسی معکوس اندروید که قابلیت اجرا مستقیم روی گوشی رو داره. از Flutter و il2cpp هم پشتیبانی می‌کنه.

​لینک: https://github.com/UltraSina/androidReverse/releases

​🆔 @androidSec_fa

​#Android #ReverseEngineering #Security

​⚠️ هشدار امنیتی: ادعای روت کردن اندروید ۱۷ با استفاده از لینک

​اخیراً در فضای مجازی توییتی منتشر شده که ادعا می‌کند یک زنجیره اکسپلویت (Full Chain) برای روت کردن سیستم‌عامل اندروید ۱۷ کشف شده است. این حمله ادعا می‌کند که با کلیک روی یک لینک و بهره‌برداری از دو آسیب‌پذیری 0-day در مرورگر فایرفاکس (از جمله CVE-2026-10702)، امکان نفوذ به هسته سیستم‌عامل وجود دارد.

​نکات کلیدی برای کاربران:
۱. این آسیب‌پذیری در نسخه‌های جدید فایرفاکس (151.0.3 و بالاتر) به‌طور کامل اصلاح شده است.

۲. زنجیره‌های اکسپلویت این‌چنینی معمولاً وابسته به سخت‌افزار و نسخه‌های خاص هستند و به صورت عمومی و پایدار برای همه دستگاه‌ها کارایی ندارند.

۳. بهترین راه مقابله، به‌روزرسانی مداوم مرورگر و سیستم‌عامل است.

​منبع و جزئیات بیشتر را می‌توانید در توییتر مشاهده کنید:

https://x.com/nebusecurity/status/2069707520160227688

​🛡 برای آگاهی از آخرین اخبار و تحلیل‌های امنیتی، کانال ما را دنبال کنید:
@androidSec_fa

​#امنیت #اندروید #فایرفاکس #هشدار_امنیتی #CVE202610702 #سایبری #AndroidSecurity

​🔴 آسیب‌پذیری خطرناک در هدست‌های 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

​🚨 هشدار امنیتی: بدافزار بانکی در لباس برنامه‌های سندخوان!

​گروه امنیتی ThreatLabz به‌تازگی هشدار داده که یک تروجان بانکی خطرناک با نام Anatsa (که با نام TeaBot هم شناخته می‌شود)، موفق شده از سد امنیتی گوگل‌پلی عبور کند.

​⚠️ نکات مهمی که باید بدانید:

🔹 این بدافزار تحت پوشش یک برنامه «سندخوان» (PDF/Document Reader) در فروشگاه گوگل عرضه شده و بیش از ۱۰۰ هزار بار دانلود شده است.

🔹 روش فریب: برنامه در ابتدا کاملاً سالم به‌نظر می‌رسد، اما پس از نصب، فایل مخرب اصلی را از سرور هکرها دانلود می‌کند.

🔹 هدف: این تروجان می‌تواند با ایجاد صفحات ورود جعلی روی اپلیکیشن‌های بانکی و صرافی‌ها، رمزهای عبور شما را سرقت کند و حتی به پیامک‌های حاوی رمز پویا دسترسی پیدا کند.

​🛡 توصیه امنیتی:

پیش از نصب برنامه‌های جدید، حتماً اعتبار توسعه‌دهنده را بررسی کنید و از دادن دسترسی‌های غیرضروری (مانند Accessibility) به برنامه‌ها خودداری کنید.

​🔗 منبع و جزئیات بیشتر:
https://x.com/Threatlabz/status/2069190345418854810

​➖➖➖➖➖➖➖➖

🆔 @androidSec_fa

​#امنیت #اندروید #بدافزار #هشدار #Anatsa #AndroidSecurity #CyberSecurity

معماری پردازنده گرافیکی به زبان آدمیزاد! (بخش اول: کارگاه نقاشی)

​خیلی از ما فکر می‌کنیم کارت گرافیک یا همان 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

جرقه اول؛ وقتی نقاش آدرس را گم می‌کند! (بخش دوم: بررسی باگ)

​در پست قبلی گفتیم که پردازنده گرافیکی برای مدیریت نقاشی‌هایش یک کمد بایگانی به نام 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

از یک کرش ساده تا دور زدن KASLR (زنجیره باگ - گام اول)

​وقتی شما می‌تونید با پردازنده گرافیکی روی حافظه اصلی بنویسید، اولش همه چیز خراب میشه و سیستم اصطلاحاً ریستارت میشه یا کرش می‌کنه (Kernel Panic).

چون شما دارید کورکورانه داده‌ها رو بازنویسی می‌کنید (فقط ۳.۵ بایت اول هر صفحه حافظه فیزیکی تغییر می‌کرد).

​برای اینکه این باگ به یک اکسپلویت (کد مخرب کارآمد) تبدیل بشه، هکرها باید سد اول امنیتی کرنل یعنی KASLR رو دور می‌زدند.

اصطلاح ​KASLR چیه؟

مبحث (Kernel Address Space Layout Randomization) یک تکنیک امنیتیه که هر بار گوشی روشن میشه، آدرس توابع و بخش‌های حساس کرنل رو در حافظه جابه‌جا می‌کنه تا هکر نتونه حدس بزنه فلان دستور کجای حافظه قرار داره.

​هکرها چطور دورش زدن؟

اون‌ها اومدن و از قابلیت نوشتن محدود پردازنده گرافیکی استفاده کردن تا توابع مربوط به سیستم‌فایل‌های مجازی اندروید (مثل مسیر /proc) رو پچ (دستکاری) کنن.

مشخصاً تابع proc_sched_show_task رو طوری تغییر دادن که به جای چاپ کردن آمارهای معمولی سیستم، آدرس‌های واقعی و پنهان شده حافظه کرنل رو بهشون نشون بده (Information Leak). با این کار، نقشه حافظه لو رفت و KASLR کاملاً بی‌اثر شد!

​حالا آدرس‌ها رو داریم، گام بعدی چیه؟

پست بعدی رو بخونید. 👇

​#KASLR_Bypass #AndroidExploit #KernelLeak #OffensiveSecurity #Part3

غول اول؛ چطور نقشه مخفی حافظه را لو بدهیم؟ (بخش چهارم: دور زدن 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). اما هنوز یک مشکل بزرگ هست؛ باگ گرافیکی اولیه خیلی محدود است و نمی‌شود با آن کدهای پیچیده نوشت. هکر نیاز به یک ابزار پایداری دارد که بتواند «هر داده‌ای را در هر کجای حافظه کرنل» بنویسد. به این ابزار در دنیای هک Arbitrary Write Primitive می‌گویند.

​برای ساخت این ابزار، هکرها سراغ یک تابع سیستمی (System Call) در قلب کرنل به نام __arm64_sys_setitimer رفتند. این تابع در حالت عادی کارش مدیریت تایمرهای سیستم است.

​هکرها با استفاده از همان باگ گرافیکی، کدهای داخلی این تابع تایمر را در حافظه رم پچ (دستکاری) کردند. آن‌ها منطق تابع را طوری تغییر دادند که از آن به بعد، هر وقت برنامه هکر این تایمر را صدا بزند و یک آدرس و یک مقدار به آن بدهد، این تابع بدون هیچ لایه امنیتی، آن مقدار را دقیقاً در آن آدرس حساس کرنل بنویسد!

​به زبان ساده، آن‌ها یکی از کارکنان رسمی و مورد اعتماد کرنل را جیره_خوار خود کردند تا هر دستوری که هکر از بیرون می‌دهد را در حافظه حساس سیستم اجرا کند. حالا قدرت نوشتن کامل باز شده است. اما برای خواندن اطلاعات چطور؟ 👇

​🆔 @androidSec_fa

​#ArbitraryWrite #ExploitPrimitive #LinuxKernel #AndroidOffsec #Part5

چشم‌انداز کامل؛ کور کردن سیستم امنیتی (بخش ششم: خواندن دلخواه)

​داشتن قدرت نوشتن در حافظه عالی است، اما اگر نتوانید حافظه را بخوانید، مثل نابینایی هستید که اسلحه دارد اما نمی‌داند به کجا شلیک کند! هکرها برای کنترل کامل به ابزاری برای «خواندن هر کجای حافظه کرنل» (Arbitrary Read Primitive) نیاز داشتند.

​یک لایه امنیتی در اندروید به نام kptr_restrict وجود دارد که تمام آدرس‌ها و پوینترهای حساس را به صورت هش‌شده (رمزنگاری شده) نگه می‌دارد تا حتی اگر هکر دسترسی پیدا کرد، نتواند آن‌ها را بخواند. اما هکرها یک کلید مخفی پیدا کردند؛ کلیدی به نام ptr_key در بخش .data کرنل وجود دارد که وظیفه‌اش تولید همین هش‌هاست.

​هکرها با استفاده از ابزار نوشتنی که در مرحله قبل ساختند، مقدار این کلید (ptr_key) را در حافظه پیدا کردند و آن را به صفر تغییر دادند! با صفر شدن این کلید، تمام سیستم هشینگ عملاً از کار افتاد و آدرس‌ها به صورت متن ساده (Plaintext) درآمدند.

​سپس سراغ بخش شبکه کرنل و مسیر /proc/self/net/udp رفتند و ساختار یک سوکت شبکه (به نام sk_socket) را بازنویسی کردند. از این به بعد، هکر هر آدرس فیزیکی از رم گوشی را که می‌خواست بخواند، به این بخش می‌داد و سیستم مثل یک کتاب باز، اطلاعات آن آدرس را به هکر تحویل می‌داد.

​حالا هکر هم بینایی کامل دارد (خواندن) و هم توانایی کامل (نوشتن). وقت ضربه آخر است. 👇

​🆔 @androidSec_fa

​#KernelRead #InformationDisclosure #AndroidInternals #Hacking #Part6

فروپاشی پادشاهی اندروید؛ فتح قله روت (بخش هفتم: تغییر اعتبارات)
​به فاز نهایی زنجیره اکسپلویت رسیدیم.

هکر اکنون دو ابزار فوق‌العاده قدرتمند دارد:

خواندن و نوشتن بی‌قید و شرط در تمام حافظه کرنل سیستم‌عامل. هدف نهایی چیست؟ به دست آوردن دسترسی Root (بالاترین سطح دسترسی در لینوکس و اندروید).

​توجیه این بخش بسیار ساده و در عین حال هیجان‌انگیز است. در سیستم‌عامل اندروید، هر برنامه یا پروسسی که اجرا می‌شود، یک شیء یا ساختار داده به نام cred (مخفف Credentials یا اعتبارات) در حافظه کرنل دارد. این ساختار مشخص می‌کند که این برنامه چه کسی است و چقدر اجازه دارد دسترسی داشته باشد. برای کاربر Root یا همان سوپریوزر، شناسه‌های این ساختار (مثل UID و GID) برابر با صفر است.

​هکر با استفاده از ابزار خواندن خود، شروع به جستجو در لیست تمام پروسس‌های فعال کرنل (init_task_list_head) می‌کند تا برنامه خودش را پیدا کند.

​به محض پیدا کردن برنامه خود، با ابزار نوشتن وارد عمل می‌شود و تمام شناسه‌های امنیتی شیء cred برنامه خود را پاک کرده و به صفر تغییر می‌دهد! به همین سادگی، سیستم‌عامل فریب می‌خورد و فکر می‌کند این برنامه معمولی، همان رئیس بزرگ یا کاربر روت است. اما هنوز یک لایه محافظتی سرسخت باقی مانده است: SELinux! 👇

​🆔 @androidSec_fa

​#Rooting #PrivilegeEscalation #KernelExploit #AndroidSecurity #Part7