شناسه:
DEEP_BPF_MAP_ACCESSIBLEدسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: شناسه برای سازگاری حفظ شده است؛ در 2.10.0 تولیدکنندهٔ جداگانهای ندارد نقش در حکم نهایی: رجیستری/سازگاری
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
fromDeepVpnKind("bpf_map_accessible") به DEEP_BPF_MAP_ACCESSIBLE نگاشت میشود، اما nativeDetectVpnDetector() یکپارچه detectBpfMaps() را فراخوانی نمیکند. در حال حاضر همان رشتهٔ kind فقط از خط لولهٔ قدیمی تولید میشود و شناسهٔ BPF_MAP_ACCESSIBLE میگیرد.
در خط لولهٔ عمیق فعلی تولیدکنندهای وجود ندارد. محرک احتمالی، بازشدن موفق یکی از سه مسیر pin شدهٔ BPF در netd خواهد بود.
نبود یافتهٔ deep چیزی دربارهٔ محافظتشدن نگاشتهای BPF نشان نمیدهد. سیگنال قدیمی bpf-map-accessible و دسترسی واقعی UID برنامه را بررسی کنید.
تأثیر این خط بر گزارش: این شناسه در کاتالوگ و رابط کاربری باقی مانده است، اما نسخهٔ 2.10.0 خط مثبت جداگانهای از این نوع تولید نمیکند. معمولاً یک سیگنال مجاور و دقیقتر این حالت را پوشش میدهد.
وجود دو شناسه برای یک kind پس از تغییرات آینده میتواند گمراهکننده باشد. این مستندات وضعیت نسخهٔ 2.10.0 را ثبت میکنند؛ اگر تابع بعداً متصل شود، نگاشت و آزمونها نیز باید بهروز شوند.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
مجوزهای اصلی SELinux/BPF را حفظ کنید و کنترل دسترسی /sys/fs/bpf را تضعیف نکنید. برای شناسهٔ فعلی اقدامی لازم نیست.
نگاشتهای pin شدهٔ netd را حذف و eBPF را غیرفعال نکنید. اگر هدف بستن دسترسی است، کوچکترین تغییر policy ممکن برای untrusted_app را اعمال و حسابداری ترافیک را آزمون کنید.
rg -n 'detectBpfMaps|nativeDetectVpnDetector|nativeDetectVpnAdvanced|bpf_map_accessible' app/src/main/cpp/native_signs_probe.cpp app/src/main/java/com/notcvnt/rknhardering
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
حذف یا خرابکردن نگاشتهای BPF در netd میتواند فایروال، آمار مصرف داده و شبکه را از کار بیندازد. پاکسازی مخرب انجام ندهید.
تغییر sepolicy یا ماژول را برگردانید و دستگاه را ریبوت کنید. اگر وضعیت netd آسیب دیده است، بهجای بازسازی دستی نگاشتها تصویر boot/system را بازگردانید.
رجیستری/سازگاری. نبود فراخوانی در تابع deep و وجود تولیدکنندهٔ قدیمی راستیآزمایی شدهاند؛ وضعیت فقط رجیستری.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.VpnNativeDetectorChecker.kt — حکم و اطمینان بررسی عمیق VPN.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.NativeSignalId.kt — رجیستری کامل شناسهها.سیگنالهای مرتبط: bpf-map-accessible, proc-net-dev-vpn.