شناسه:
PROC_IPV6_ROUTE_VPNدسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: بالا
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
پروب ابتدا /proc/net/ipv6_route و سپس /proc/self/net/ipv6_route را میخواند. هر خط به ده توکن تقسیم میشود و توکن دهم نام رابط در نظر گرفته میشود. تطبیق با tun0، tun1، utun0، wg0، ppp0 و xfrm0 شمارش را افزایش میدهد.
دستکم یک ردیف مسیر IPv6 از نام ثابت رابط VPN استفاده کند.
جدول مسیریابی IPv6 مستقیماً به رابط شبیه VPN اشاره دارد. غیرفعالکردن IPv4 این مسیر را نمیبندد.
تأثیر این خط بر گزارش: این خط detected=true را تنظیم میکند و بهعنوان یک نشانهٔ محلی با اطمینان بالا در نظر گرفته میشود.
قالب procfs به هسته وابسته است و ممکن است SELinux آن را مسدود کند. پروب فقط شمار را گزارش میدهد، نه مقصد، پیشوند یا جدول؛ بنابراین تحلیل به تصویر خام نیاز دارد. نامهای غیراستاندارد رابط شناسایی نمیشوند.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
بدون روت، طراحی مسیریابی را اصلاح کنید، نه نحوهٔ نمایش جدول را. برای تلفنی پاک از دروازهٔ خارجی استفاده کنید. اگر VPN در VpnService باقی میماند، split routing را طوری تنظیم کنید که برنامهٔ تحت آزمون واقعاً از شبکهٔ فیزیکی مورد انتظار خارج شود؛ اما این را پنهانسازی مسیرهای محلی ندانید، زیرا رابط و قواعد policy ممکن است قابل مشاهده بمانند. روی دستگاه در حال استفاده مسیرها را با ip route حذف نکنید؛ Android و سرویس VPN آنها را دوباره میسازند و ممکن است اتصال قطع شود. غیرفعالکردن IPv6 در پروفایل سطح در معرض دید را کم میکند، ولی ممکن است ترافیک IPv6 را از VPN عبور ندهد یا اتصال IPv6 را کاملاً از بین ببرد. ابتدا روی شبکهای جداگانه آزمایش کنید.
روی دستگاه روتشده، پسزمینه باید منبع داده را فیلتر کند، نه فقط libc را. در VPNHide بالادستی، پسزمینههای هسته برای ioctl، netlink و برخی بردارهای route/procfs طراحی شدهاند و Zygisk یک گزینهٔ مشروط باقی میماند. kmod و KPM را همزمان نصب نکنید، زیرا ممکن است همان توابع هسته را رهگیری کنند. VPNHide Next پوشش گستردهتری برای PMTU/MSS/qdisc/BPF ادعا میکند، اما این ادعای بیرونی باید روی همان هسته بازتولید شود. فیلتر باید procfs و RTM_GETROUTE مربوط به IPv6 را بهشکل سازگار پوشش دهد. جایگزینی فقط /proc/net/ipv6_route، dump مربوط به netlink را باز میگذارد.
adb shell 'cat /proc/net/ipv6_route 2>/dev/null || cat /proc/self/net/ipv6_route 2>/dev/null'
adb shell ip -6 route show table all
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
حذف دستی مسیرهای IPv6 ممکن است DNS یا NAT64 را خراب کند و با بازسازی VPN پایدار نمیماند. هوک معیوب seq-file در هسته میتواند خواندن procfs را خراب کند.
آخرین تغییر را برگردانید: ماژول یا قاعدهٔ افزودهشده را با مدیر معمول خودش غیرفعال کنید، دستگاه را دوباره راهاندازی کنید و اسکن خط مبنا را تکرار کنید. روی وضعیتی ناشناخته هوک دیگری لایه نکنید.
بالا. هر دو مسیر proc، توکن [9] و فهرست ششنامی راستیآزمایی شدهاند؛ نوع نتیجه بالا است.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.VpnNativeDetectorChecker.kt — حکم و اطمینان بررسی عمیق VPN.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: route-table, rtm-getlink-vpn, proc-if-inet6-vpn.