RKNHardering Help

سطرهای mount حاوی Magisk/core-only و نشانگرهای روت

شناسه: ROOT_SUSPICIOUS_MOUNT دسته: روت و وضعیت سامانه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: متوسط

این صفحه پیاده‌سازی واقعی RKNHardering 2.10.0 را توضیح می‌دهد. در آن مشخص شده است چه اقدام‌هایی بدون روت ممکن‌اند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش می‌دهد، بی‌آن‌که VPN را به‌طور کامل پنهان کند.

چه چیزی بررسی می‌شود و چرا

C++ فایل /proc/self/mounts را می‌خواند و وقتی سطر حاوی magisk یا core-only باشد suspicious_mount تولید می‌کند. Kotlin افزون بر آن detail را برای magisk، zygisk، lsposed، riru، kernelsu، apatch، /data/adb و core-only ارزیابی می‌کند: تطبیق اطمینان زیاد می‌گیرد؛ در غیر این صورت اطمینان متوسط است.

شرط دقیق فعال‌شدن

سطر دارای نشانگر ثابت C++ در namespaceِ mount فرایند دیده شود. در تولیدکنندهٔ فعلی، نشانگر عملاً magisk یا core-only است.

معنای نتیجه

این نشانه‌ای قوی از mount سیستمیِ بدون‌تغییر مستقیم یا روت است. بررسی namespace خود فرایند برنامه را می‌بیند، بنابراین خروجی سراسری mount در shell ممکن است یکسان نباشد.

تأثیر این خط بر گزارش: این خط به‌تنهایی حکم نهایی صادر نمی‌کند، اما needsReview=true را تنظیم و شاهدی با اطمینان متوسط اضافه می‌کند.

محدودیت‌ها و مثبت‌های کاذب احتمالی

mountهای KernelSU یا APatch که واژهٔ magisk ندارند ممکن است به تولیدکنندهٔ C++ نرسند، هرچند Kotlin آماده است این نشانگرها را در detail تشخیص دهد. bind mount مربوط به sandbox مشروع نیز می‌تواند غیرعادی به‌نظر برسد.

این خط باید همراه با سیگنال‌های مجاور ارزیابی شود. پاک‌بودن نتیجهٔ یک API به‌تنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکت‌های محلی و نشانه‌های سمت سرور را هم‌زمان پوشش نمی‌دهد.

توصیه‌ها برای این بردار

بدون روت

اگر روت لازم نیست، راه قابل‌اعتماد بازگرداندن دستگاه به وضعیت استاندارد از مسیر رسمی است: روت را با مدیر خودش حذف کنید، یا پارتیشن‌های کارخانه‌ای boot/init_boot و system را که دقیقاً با build نصب‌شده تطبیق دارند flash کنید. bootloader باز، هستهٔ سفارشی و پوشه‌های باقی‌مانده حتی پس از حذف مدیر نیز می‌توانند تغییر را آشکار کنند. پیش از بازیابی پشتیبان بگیرید؛ قفل‌کردن دوبارهٔ bootloader روی میان‌افزار تغییریافته ممکن است داده‌ها را پاک کند یا دستگاه را غیرقابل‌بوت سازد.

با روت

دسترسی روت فقط می‌تواند سطح قابل‌مشاهده را کاهش دهد؛ نبود روت را ثابت نمی‌کند. su را به کمترین تعداد برنامه بدهید، هرگز آن را به RKNHardering ندهید، ماژول‌های غیرضروری را غیرفعال کنید و SELinux را permissive نکنید. رفتار App Profile/DenyList و جداسازی mount باید روی همان میان‌افزار بررسی شود. SUSFS و راهکارهای مشابه آزمایشی‌اند: به هستهٔ سازگار نیاز دارند و ممکن است آثار خودشان را ایجاد کنند. برای آزمون مرجع همچنان یک دستگاه استاندارد جدا لازم است. تأیید کنید App Profile یا جداسازی mount پیش از شروع فرایند واقعاً اعمال می‌شود. پس از تغییر، برنامه را به‌اجبار متوقف کنید؛ ممکن است راه‌اندازی مجدد نیز لازم باشد.

روش راستی‌آزمایی نتیجه

adb shell cat /proc/self/mounts | grep -Ei 'magisk|core-only|zygisk|lsposed|riru|kernelsu|apatch|/data/adb'

این‌ها mountهای فرایند shell هستند. برای namespace دقیق برنامه از detail داخلی یا run-as در build قابل‌اشکال‌زدایی استفاده کنید.

پس از هر تغییر، RKNHardering و سرویس‌گیرندهٔ VPN را به‌اجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژول‌های هسته معمولاً به راه‌اندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنال‌های مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد می‌کند.

مجوزهای لازم و خطرها

خود پروب با مجوزهای معمول برنامه اجرا می‌شود و روت درخواست نمی‌کند. دستورهای ADB زیر فقط برای جهت‌یابی تشخیصی‌اند: adb shell با UID دیگری اجرا می‌شود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیین‌کننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.

خطرها

unmount دستی نقاط mount مدیر روت ممکن است فرایندها را معلق یا سیستم را خراب کند. lazy unmount را کورکورانه اعمال نکنید.

بازگردانی

آخرین تغییر را برگردانید: ماژول یا قاعدهٔ افزوده‌شده را از مدیر معمول خودش غیرفعال کنید، دستگاه را دوباره راه‌اندازی کنید و اسکن خط مبنا را تکرار کنید. روی وضعیت ناشناخته هوک دیگری لایه نکنید.

سطح شواهد

متوسط. خواندن /proc/self/mounts و دو سطح منطق نشانگر بررسی شده‌اند.

وضعیت یک راهکار شخص ثالث خودبه‌خود به این دستگاه تعمیم پیدا نمی‌کند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجه‌ای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میان‌افزار و هسته نیاز دارد.

منابع و تاریخ آخرین راستی‌آزمایی

سیگنال‌های مرتبط: root-overlay-mount, root-management, hook-markers.

بازگشت به مرجع بررسی‌های بومی