RKNHardering Help

جدول اصلی مسیریابی و مسیر پیش‌فرض

شناسه: ROUTE_TABLE دسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: ترکیبی

این صفحه پیاده‌سازی واقعی RKNHardering 2.10.0 را توضیح می‌دهد. در آن مشخص شده است چه اقدام‌هایی بدون روت ممکن‌اند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش می‌دهد، بی‌آن‌که VPN را به‌طور کامل پنهان کند.

چه چیزی بررسی می‌شود و چرا

پروب بومی مسیرهای IPv4 و IPv6 را همراه با فرادادهٔ netlink گردآوری می‌کند. evaluateRoutes() مسیرهای پیش‌فرض را شناسایی و بر پایهٔ رابط canonical و خانوادهٔ نشانی تکرارزدایی می‌کند. مسیر پیش‌فرض روی رابط شبیه VPN اطمینان بالا می‌گیرد. مسیر پیش‌فرض روی رابط ناشناخته و غیراستاندارد اطمینان متوسط می‌گیرد، هرچند بررسی‌کنندهٔ فعلی در این حالت نیز detected=true را تنظیم می‌کند. رابط‌های استاندارد منطبق با wlan*، rmnet*، eth*، lo، ccmni*، ccemni*، seth* و dummy* به‌صورت دادهٔ اطلاعاتی گزارش می‌شوند.

شرط دقیق فعال‌شدن

بررسی وقتی فعال می‌شود که مسیر پیش‌فرض به الگوی VPN یا به رابطی خارج از فهرست مجاز نام‌های استاندارد اشاره کند. نبود مسیر پیش‌فرض فقط اطلاعاتی است.

معنای نتیجه

مسیر پیش‌فرض VPN یک سیگنال محلی قوی است. رابط نامعمول نیاز به بررسی دارد، زیرا پشتهٔ OEM، tethering، CLAT یا پشتهٔ شبکهٔ سازمانی ممکن است نام غیراستانداردی داشته باشد.

تأثیر این خط بر گزارش: همین شناسه هم برای خلاصه‌های اطلاعاتی و هم برای خطوط مشکوک استفاده می‌شود. نتیجه به جزئیات همان خط و شاخهٔ بررسی‌کننده بستگی دارد.

محدودیت‌ها و مثبت‌های کاذب احتمالی

مسیریابی policy در Android از یک جدول اصلی ساده پیچیده‌تر است؛ مسیر واقعی برای UID مشخص ممکن است از طریق fwmark و ip rule انتخاب شود. بنابراین مسیر پیش‌فرض پاک VPN را رد نمی‌کند و dump مسیر هنگام handover می‌تواند برای مدت کوتاهی ناپایدار باشد.

این خط باید همراه با سیگنال‌های مجاور ارزیابی شود. پاک‌بودن نتیجهٔ یک API به‌تنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکت‌های محلی و نشانه‌های سمت سرور را هم‌زمان پوشش نمی‌دهد.

توصیه‌ها برای این بردار

بدون روت

بدون روت، طراحی مسیریابی را اصلاح کنید، نه نحوهٔ نمایش جدول را. برای تلفنی پاک از دروازهٔ خارجی استفاده کنید. اگر VPN در VpnService باقی می‌ماند، split routing را طوری تنظیم کنید که برنامهٔ تحت آزمون واقعاً از شبکهٔ فیزیکی مورد انتظار خارج شود؛ اما این را پنهان‌سازی مسیرهای محلی ندانید، زیرا رابط و قواعد policy ممکن است قابل مشاهده بمانند. روی دستگاه در حال استفاده، مسیرها را با ip route حذف نکنید؛ Android و سرویس VPN آن‌ها را دوباره می‌سازند و ممکن است اتصال قطع شود.

با روت

روی دستگاه روت‌شده، پس‌زمینه باید منبع داده را فیلتر کند، نه فقط libc را. در VPNHide بالادستی، پس‌زمینه‌های هسته برای ioctl، netlink و برخی بردارهای route/procfs طراحی شده‌اند و Zygisk یک گزینهٔ مشروط باقی می‌ماند. kmod و KPM را هم‌زمان نصب نکنید، زیرا ممکن است همان توابع هسته را رهگیری کنند. VPNHide Next پوشش گسترده‌تری برای PMTU/MSS/qdisc/BPF ادعا می‌کند، اما این ادعای بیرونی باید روی همان هسته بازتولید شود.

روش راستی‌آزمایی نتیجه

adb shell ip -4 route show table all
adb shell ip -6 route show table all
adb shell ip rule show

رابط، خانوادهٔ نشانی، جدول و مسیر پیش‌فرض را مقایسه کنید. به‌دلیل مسیریابی مبتنی بر UID و fwmark، تصویر پوسته برای تعیین مسیر یک برنامهٔ مشخص کافی نیست.

پس از هر تغییر، RKNHardering و سرویس‌گیرندهٔ VPN را به‌اجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژول‌های هسته معمولاً به راه‌اندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنال‌های مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد می‌کند.

مجوزهای لازم و خطرها

خود پروب با مجوزهای معمول برنامه اجرا می‌شود و روت درخواست نمی‌کند. دستورهای ADB زیر فقط برای جهت‌یابی تشخیصی‌اند: adb shell با UID دیگری اجرا می‌شود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیین‌کننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.

خطرها

حذف دستی مسیر پیش‌فرض دستگاه را بدون دسترسی شبکه می‌گذارد. فیلتر نادرست dump مسیر می‌تواند با شاخص رابط یا LinkProperties در Java ناسازگاری ایجاد کند.

بازگردانی

آخرین تغییر را برگردانید: ماژول یا قاعدهٔ افزوده‌شده را با مدیر معمول خودش غیرفعال کنید، دستگاه را دوباره راه‌اندازی کنید و اسکن خط مبنا را تکرار کنید. روی وضعیتی ناشناخته هوک دیگری لایه نکنید.

سطح شواهد

ترکیبی. با evaluateRoutes()، canonicalization و فهرست رابط‌های استاندارد/VPN راستی‌آزمایی شده است.

وضعیت یک راهکار شخص ثالث خودبه‌خود به این دستگاه تعمیم پیدا نمی‌کند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجه‌ای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میان‌افزار و هسته نیاز دارد.

منابع و تاریخ آخرین راستی‌آزمایی

سیگنال‌های مرتبط: host-route, route-vpn-interface, vpn-policy-rules-netlink, route-count.

بازگشت به مرجع بررسی‌های بومی