شناسه:
RTM_GETLINK_VPNدسته: رابطها وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: بالا
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
پروب یک سوکت AF_NETLINK/NETLINK_ROUTE باز میکند، درخواست RTM_GETLINK را با NLM_F_DUMP میفرستد و پیامهای RTM_NEWLINK و ویژگی IFLA_IFNAME را تجزیه میکند. نامهای دقیق tun0، tun1، utun0، wg0، ppp0 و xfrm0 جستوجو میشوند؛ حلقهٔ دریافت از poll(..., 2000) و recv() استفاده میکند.
dump کامل لینک دستکم یک پیام RTM_NEWLINK با نام ثابت رابط VPN داشته باشد.
این یکی از مهمترین مسیرهاست: یک برنامهٔ عادی حتی وقتی /proc یا /sys در دسترس نیست، فهرست دستگاههای شبکه را مستقیم از هسته میگیرد. تطبیق، نشانهٔ محلی قدرتمندی است.
تأثیر این خط بر گزارش: این خط detected=true را تنظیم میکند و بهعنوان یک نشانهٔ محلی با اطمینان بالا در نظر گرفته میشود.
فقط شش نام دقیق بررسی میشود. پروب بریدهشدن پاسخ چندبخشی یا مقادیر sequence/PID را سختگیرانه اعتبارسنجی نمیکند؛ شکست send، poll یا receive بیسروصدا نتیجهای تولید نمیکند. هوک فضای کاربر که فقط getifaddrs() را پوشش میدهد این مسیر را نمیبندد.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
مطمئنترین روش بدون روت این است که روی تلفن تحت آزمون رابط VPN ساخته نشود: تونل را به روتر، روتر مسافرتی، تلفن جداگانهٔ دروازه یا گره دیگری از شبکه منتقل کنید. دورزدن بهازای برنامه در VpnService مسیر برنامهٔ انتخابشده را تغییر میدهد، اما establish() همچنان رابط VPN سیستمی میسازد؛ بنابراین بررسی محلی رابطها ممکن است همچنان فعال شود. حالت پراکسی محلی HTTP/SOCKS بدون TUN گاهی این بردار مشخص را حذف میکند، ولی درگاههای شنود و تنظیمات پراکسی را باقی میگذارد و برنامههای بیاعتنا به پراکسی را پوشش نمیدهد. کاربر ثانویهٔ Android فضای نام شبکهٔ جداگانهای دریافت نمیکند؛ بنابراین پروفایل کاری و شخصی معمولاً همان dump مربوط به RTM_GETLINK را میبینند.
پنهانسازی در سطح آزمایشگاه معمولاً هم به یک لایهٔ Java سیستمی و هم به یک پسزمینهٔ بومی نیاز دارد. در VPNHide یعنی APK بههمراه Vector/LSPosed با دامنهای محدود به System Framework، و دقیقاً یکی از kmod، KPM یا Zygisk. برای بررسیای که ممکن است syscall مستقیم یا netlink بهکار ببرد، kmod یا KPM ترجیح دارد: هوک Zygisk در فضای کاربر قابل دورزدن است و داخل فرایند رد باقی میگذارد. ابتدا نقشهٔ پوشش VPNHide را بررسی کنید و ساختها را فقط از صفحهٔ رسمی انتشار بگیرید. VPNHide Next پوشش گستردهتری ادعا میکند، اما دربارهٔ احتمال حلقهٔ بوت و کرنل پنیک نیز هشدار میدهد؛ آن را فقط روی دستگاه اختصاصی آزمون کنید. netlink خام به فیلتر در سطح هسته یا جداسازی سیستمی همارز نیاز دارد. Zygisk باید خانوادهٔ مشخصی از فراخوانیهای دریافت را رهگیری کند و باز هم قابل دورزدن باقی میماند؛ VPNHide بالادستی این محدودیت را صریحاً مستند کرده است.
adb shell ip -details link show
adb shell 'ip -o link | grep -E "tun0|tun1|utun0|wg0|ppp0|xfrm0"'
ip نیز از rtnetlink استفاده میکند، اما UID پوسته ممکن است نمای فیلترشدهٔ متفاوتی دریافت کند.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
فیلتر معیوب skb/netlink ممکن است هنگام dump گیر کند، پاسخ چندبخشی را خراب کند یا شبکه را برای UIDهای سیستمی از کار بیندازد.
آخرین تغییر را برگردانید: ماژول یا قاعدهٔ افزودهشده را با مدیر معمول خودش غیرفعال کنید، دستگاه را دوباره راهاندازی کنید و اسکن خط مبنا را تکرار کنید. روی وضعیتی ناشناخته هوک دیگری لایه نکنید.
بالا. با RTM_GETLINK، RTM_NEWLINK، IFLA_IFNAME، فهرست ششنامی و مجموعهٔ HIGH_CONFIDENCE راستیآزمایی شده است.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.VpnNativeDetectorChecker.kt — حکم و اطمینان بررسی عمیق VPN.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: getifaddrs-vpn, trim-oracle, ifindexname-vpn, interface-enumeration.