شناسه:
BPF_MAP_ACCESSIBLEدسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: بالا
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
پروب قدیمی تلاش میکند سه مسیر را فقطخواندنی باز کند: /sys/fs/bpf/map_netd_iface_index_name_map، /sys/fs/bpf/netd_shared/map_netd_iface_index_name_map و /sys/fs/bpf/netd_iface_index_name_map. بازشدن موفق یکی از آنها bpf_map_accessible را تولید میکند؛ سیاست قدیمی آن را با اطمینان بالا طبقهبندی میکند.
فرایند عادی برنامه بتواند یکی از مسیرهای ثابت pin شدهٔ BPF را باز کند.
در Android اصلی معمولاً دسترسی محدود است. اگر در دسترس باشد، نگاشت میتواند رابطهٔ ifindex به نام را آشکار کند و از پنهانسازی سطحی عبور کند.
تأثیر این خط بر گزارش: این خط detected=true را تنظیم میکند و بهعنوان یک نشانهٔ محلی با اطمینان بالا در نظر گرفته میشود.
پروب فقط امکان بازکردن مسیر را میسنجد؛ نگاشت را نمیخواند و وجود ورودی VPN را تأیید نمیکند. چینش مسیرها میان نسخههای Android متفاوت است.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
روی ROM تولیدی، SELinux یا مجوزهای فایلسیستم BPF را تضعیف نکنید. اگر ROM سفارشی این دسترسی را باز گذاشته است، پاکترین گزینه یک ساخت اصلی با enforcing است.
کوچکترین اصلاح policy را اعمال کنید: UID هدف نباید بتواند نگاشتهای netd را بخواند. BPF یا netd را سراسری غیرفعال نکنید. VPNHide Next فیلتر eBPF را ادعا میکند، اما این آزمایشی پرخطر در سطح هسته است.
adb shell ls -l /sys/fs/bpf 2>/dev/null | head -80
adb shell 'for p in /sys/fs/bpf/map_netd_iface_index_name_map /sys/fs/bpf/netd_shared/map_netd_iface_index_name_map /sys/fs/bpf/netd_iface_index_name_map; do [ -r "$p" ] && echo readable:$p; done'
دسترسی پوسته معادل دسترسی UID برنامه نیست.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
تغییر نگاشتها یا policy مربوط به BPF در netd میتواند حسابداری ترافیک، فایروال و شبکه را خراب کند. نگاشتهای pin شده را حذف نکنید.
تغییر sepolicy یا ماژول را برگردانید و netd یا دستگاه را دوباره راهاندازی کنید؛ اگر سیستم ناپایدار است، تصویر boot را بازگردانید.
بالا. سه مسیر راستیآزمایی شدهاند؛ طبقهبندی قدیمی اطمینان بالا دارد.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.NativeSignsChecker.kt — منطق اصلی حکم بومی/قدیمی.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: deep-bpf-map-accessible, ifindexname-vpn.