شناسه:
ROOT_INDICATORSدسته: روت و وضعیت سامانه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: سرویسی
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
این شناسهٔ چتری وضعیت بررسی روت است. وقتی nativeDetectRoot() هیچ سطری برنگرداند، بررسیکننده زیر ROOT_INDICATORS پیام اطلاعاتی «هیچ نشانگر بومی روت یافت نشد» را نمایش میدهد. هنگام وجود آثار، برای su، propertyها، مسیرهای مدیریت، mountها، SELinux، UID و propertyهای Magisk شناسههای جداگانه استفاده میشود.
شرط مثبت مستقلی ندارد. findingهای مثبت میان نه صفحهٔ فرزند توزیع شدهاند.
نتیجهٔ پاک فقط یعنی فهرست ثابت آثار بومی سطری تولید نکرده است. این بررسی bootloader، Play Integrity، attestation سختافزاری، همهٔ گونههای KernelSU/APatch یا همهٔ namespaceهای سفارشی mount را پوشش نمیدهد.
تأثیر این خط بر گزارش: این یک شناسهٔ چتری یا پشتیبان است. گروهی از خطوط را به مستندات پیوند میدهد، اما همیشه تولیدکنندهٔ مثبت مستقلی ندارد.
هر مدل تشخیص روت هیوریستیک است. ممکن است فایل su پنهانشده در فهرست نباشد، درحالیکه build آزمایشی OEM میتواند بدون دسترسی روت نصبشده توسط کاربر از test-keys استفاده کند.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
اگر روت لازم نیست، راه قابلاعتماد بازگرداندن دستگاه به وضعیت استاندارد از مسیر رسمی است: روت را با مدیر خودش حذف کنید، یا پارتیشنهای کارخانهای boot/init_boot و system را که دقیقاً با build نصبشده تطبیق دارند flash کنید. bootloader باز، هستهٔ سفارشی و پوشههای باقیمانده حتی پس از حذف مدیر نیز میتوانند تغییر را آشکار کنند. پیش از بازیابی پشتیبان بگیرید؛ قفلکردن دوبارهٔ bootloader روی میانافزار تغییریافته ممکن است دادهها را پاک کند یا دستگاه را غیرقابلبوت سازد.
دسترسی روت فقط میتواند سطح قابلمشاهده را کاهش دهد؛ نبود روت را ثابت نمیکند. su را به کمترین تعداد برنامه بدهید، هرگز آن را به RKNHardering ندهید، ماژولهای غیرضروری را غیرفعال کنید و SELinux را permissive نکنید. رفتار App Profile/DenyList و جداسازی mount باید روی همان میانافزار بررسی شود. SUSFS و راهکارهای مشابه آزمایشیاند: به هستهٔ سازگار نیاز دارند و ممکن است آثار خودشان را ایجاد کنند. برای آزمون مرجع همچنان یک دستگاه استاندارد جدا لازم است.
جزئیات صفحات فرزند را باز کنید. برای جهتیابی کلی:
adb shell getprop ro.build.tags
adb shell getprop ro.debuggable
adb shell id
adb shell cat /sys/fs/selinux/enforce 2>/dev/null
UIDِ shell namespace مربوط به mountهای برنامه را بازتولید نمیکند.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
اشتباه است که نتیجهٔ تجمیعی پاک را تضمینی کامل بدانید. بازگرداندن وضعیت استاندارد ممکن است دادهها را پاک کند و قفلکردن bootloader روی میانافزار ناسازگار میتواند مانع بوت دستگاه شود.
اقدامهای تشخیصی بازگردانی لازم ندارند. برای unroot، روش رسمی حذف راهکار روت انتخابشده و image کارخانهای ذخیرهشده را بهکار ببرید.
ساختاری. شاخهٔ rootFindings.isEmpty() در evaluateRootIndicators() و تابع nativeDetectRoot() بررسی شدهاند.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.NativeSignsChecker.kt — منطق اصلی حکم بومی/قدیمی.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.NativeSignalId.kt — رجیستری کامل شناسهها.سیگنالهای مرتبط: root-su-binary, root-management, root-suspicious-mount, root-selinux.