شناسه:
ROOT_SU_BINARYدسته: روت و وضعیت سامانه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: متوسط
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
C++ برای ۱۲ مسیر access(F_OK) را فراخوانی میکند: /system/bin/su، /system/xbin/su، /sbin/su، /su/bin/su، /data/local/su، /data/local/bin/su، /data/local/xbin/su، /system/sd/xbin/su، /system/bin/failsafe/su، /vendor/bin/su، /product/bin/su و /apex/com.android.runtime/bin/su. مسیر تطبیقیافته اطمینان زیاد میگیرد، اما دسته بهتنهایی detected را تنظیم نمیکند و فقط finding بازبینی میسازد.
هر مسیر ثابت فهرست از بررسی وجود فایل توسط UID برنامه قابلمشاهده باشد.
این یک اثر محلی قوی روت است. وجود فایل ثابت نمیکند RKNHardering میتواند su را اجرا کند و نبود آن روت مبتنی بر هسته یا مسیر غیراستاندارد را رد نمیکند.
تأثیر این خط بر گزارش: این خط بهتنهایی حکم نهایی صادر نمیکند، اما needsReview=true را تنظیم و شاهدی با اطمینان متوسط اضافه میکند.
namespaceِ mount میتواند مسیر را فقط از UIDهای انتخابشده پنهان کند. ROMهای قدیمی، buildهای engineering و باقیماندهٔ unroot ناقص ممکن است فایل su غیرعملیاتی بر جا بگذارند.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
اگر روت لازم نیست، راه قابلاعتماد بازگرداندن دستگاه به وضعیت استاندارد از مسیر رسمی است: روت را با مدیر خودش حذف کنید، یا پارتیشنهای کارخانهای boot/init_boot و system را که دقیقاً با build نصبشده تطبیق دارند flash کنید. bootloader باز، هستهٔ سفارشی و پوشههای باقیمانده حتی پس از حذف مدیر نیز میتوانند تغییر را آشکار کنند. پیش از بازیابی پشتیبان بگیرید؛ قفلکردن دوبارهٔ bootloader روی میانافزار تغییریافته ممکن است دادهها را پاک کند یا دستگاه را غیرقابلبوت سازد. اگر روت پیشتر حذف شده، فایل را دستی از پارتیشن فقطخواندنی پاک نکنید. ابتدا image یا ماژولی را که آن را افزوده شناسایی کنید، سپس پارتیشن را از مسیر عادی بازیابی کنید.
دسترسی روت فقط میتواند سطح قابلمشاهده را کاهش دهد؛ نبود روت را ثابت نمیکند. su را به کمترین تعداد برنامه بدهید، هرگز آن را به RKNHardering ندهید، ماژولهای غیرضروری را غیرفعال کنید و SELinux را permissive نکنید. رفتار App Profile/DenyList و جداسازی mount باید روی همان میانافزار بررسی شود. SUSFS و راهکارهای مشابه آزمایشیاند: به هستهٔ سازگار نیاز دارند و ممکن است آثار خودشان را ایجاد کنند. برای آزمون مرجع همچنان یک دستگاه استاندارد جدا لازم است. فقط تغییر نام su، mountها، مسیرهای مدیریت، propertyها یا وضعیت UID را پنهان نمیکند. دسترسی را با قابلیت رسمی App Profile/DenyList راهکار روت محدود کنید و UID واقعی برنامه را بیازمایید.
adb shell 'for p in /system/bin/su /system/xbin/su /sbin/su /su/bin/su /data/local/su /data/local/bin/su /data/local/xbin/su /system/sd/xbin/su /system/bin/failsafe/su /vendor/bin/su /product/bin/su /apex/com.android.runtime/bin/su; do [ -e "$p" ] && ls -l "$p"; done'
خروجی خالی shell تضمین نمیکند namespace برنامه یکسان است.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
حذف binary از پارتیشن سیستم میتواند OTA یا بوت را خراب کند. پیش از پشتیبانگیری image و شناسایی منبع mount، فرمان rm اجرا نکنید.
image ذخیرهشدهٔ بوت یا system را بازیابی کنید، یا اگر فایل بخشی از نصب عادی بوده روت را از مدیر رسمی دوباره نصب کنید.
متوسط. آرایهٔ دقیق kSuPaths بررسی شده است؛ Kotlin اطمینان زیاد و needsReview=true میدهد.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.NativeSignsChecker.kt — منطق اصلی حکم بومی/قدیمی.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: root-management, root-suspicious-mount, root-uid.