شناسه:
ROOT_SYSTEM_RWدسته: روت و وضعیت سامانه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: متوسط
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
پروب از UID برنامه access("/system", W_OK) را فراخوانی میکند. موفقیت، system_rw|/system is writable و finding بازبینی با اطمینان زیاد تولید میکند.
فرایند برنامه /system را قابلنوشتن ببیند.
در دستگاه تولیدی Android جدید، /system معمولاً فقطخواندنی و زیر حفاظت verified boot است. دسترسی نوشتن برای UID عادی ناهنجاری قوی و نشانهٔ محیط، sandbox با مجوز بیشازحد یا مجازیسازی است.
تأثیر این خط بر گزارش: این خط بهتنهایی حکم نهایی صادر نمیکند، اما needsReview=true را تنظیم و شاهدی با اطمینان متوسط اضافه میکند.
access(W_OK) مجوز مؤثر و flagهای mount را بررسی میکند و نوشتن واقعی انجام نمیدهد. container غیرعادی ممکن است نتیجهٔ نادرست برگرداند. اجرای RKNHardering با روت نیز بهطور مشروع بررسی را فعال میکند.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
از میانافزار استاندارد استفاده کنید و برنامه را در container با مجوز گستردهٔ فایلسیستم اجرا نکنید. factory reset image سیستم تغییریافته را تعمیر نمیکند.
به RKNHardering روت ندهید و system را سراسری read-write remount نکنید. ماژولهای systemless باید نمای برنامه را فقطخواندنی نگه دارند. اگر /system بهسبب remount اشکالزدایی قابلنوشتن است، آن را read-only کنید و دستگاه را راهاندازی مجدد کنید.
adb shell mount | grep -E ' /system( |/)| / '
adb shell test -w /system; echo $?
کد خروج 0 یعنی برای shell قابلنوشتن است، اما UID برنامه ممکن است نتیجهٔ دیگری ببیند.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
remount و نوشتن روی پارتیشن system میتواند AVB را نقض، OTA را خراب و موجب شکست بوت شود. برای راستیآزمایی فایل واقعی نسازید.
پس از حذف remount دستگاه را راهاندازی مجدد کنید. اگر image سیستم تغییر کرده، image کارخانهای و metadata مربوط به verified boot را طبق راهنمای دستگاه بازیابی کنید.
متوسط. شرط منفرد access(W_OK) بررسی شده است؛ بررسیکننده finding بازبینی با اطمینان زیاد میدهد.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.NativeSignsChecker.kt — منطق اصلی حکم بومی/قدیمی.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: root-overlay-mount, root-suspicious-mount, root-selinux.