/proc/net/fib_trieشناسه:
FIB_TRIE_DENIEDدسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: متوسط
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
detectFibTrieAccess() فقط /proc/net/fib_trie را باز میکند. بازشدن موفق چیزی تولید نمیکند؛ EACCES یا EPERM نتیجهٔ SELinux denies، مقدار ENOENT نتیجهٔ خنثی و هر errno دیگر نیز یک خط تولید میکند. در بررسیکنندهٔ عمیق، این نوع نه اطمینان بالا است و نه اطلاعاتی؛ بنابراین شاهد needsReview با اطمینان متوسط میسازد.
بازکردن /proc/net/fib_trie مقدار EACCES، EPERM یا هر خطایی جز ENOENT برگرداند.
این بررسی دسترسی به یک مسیر تشخیصی است، نه تشخیص VPN. در Android جدید، رد دسترسی برای untrusted_app میتواند سیاست عادی باشد. خط نیاز به بررسی دارد، اما دلیلی برای «اصلاح» SELinux نیست.
تأثیر این خط بر گزارش: این خط بهتنهایی حکم نهایی صادر نمیکند، اما needsReview=true را تنظیم و شاهدی با اطمینان متوسط اضافه میکند.
نام میتواند گمراهکننده باشد: رد دسترسی معمولاً حریم خصوصی را بهتر میکند و نشت اطلاعات را میبندد. کد پس از open موفق تلاشی برای خواندن محتوا نمیکند و حالت «قابل دسترسی» را گزارش نمیدهد. پوسته و UID برنامه در دامنههای متفاوت SELinux اجرا میشوند.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
هیچ چیزی را تضعیف نکنید. نسخهٔ Android و ROM را ثبت کنید و نتیجه را با دستگاه پاک دارای همان build مقایسه کنید. اگر برنامه errno=N گزارش میدهد، errno را تفسیر و سلامت mount مربوط به procfs را بررسی کنید.
فقط برای ناپدیدشدن خط، قاعدهٔ allow اضافه نکنید؛ این کار دادهٔ مسیر را در اختیار برنامهٔ عادی میگذارد. برای عیبیابی آزمایشگاهی بهجای permissive کردن SELinux، گزارشهای AVC را بررسی کنید.
adb shell 'cat /proc/net/fib_trie >/dev/null; echo shell_rc=$?'
adb logcat -d | grep -E 'avc: denied.*fib_trie' | tail -30
موفقیت یا شکست در پوسته زمینهٔ untrusted_app را بازتولید نمیکند؛ نتیجهٔ نهایی باید داخل RKNHardering بررسی شود.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
حالت permissive در SELinux یا قاعدهٔ allow گسترده وضعیت شبکه را افشا و کل sandbox را تضعیف میکند. این از خود سیگنال بازبینی بدتر است.
قاعدهٔ آزمایشی sepolicy را حذف کنید، enforcing را بازگردانید و دستگاه را ریبوت کنید. تأیید کنید getenforce مقدار Enforcing برمیگرداند.
متوسط. شاخههای errno راستیآزمایی شدهاند؛ این نوع همچنان یافتهٔ بازبینی با اطمینان متوسط است.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.VpnNativeDetectorChecker.kt — حکم و اطمینان بررسی عمیق VPN.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: bpf-map-accessible, sysfs-vpn-leak, syscall-unavailable.