شناسه:
INTERFACE_ENUMERATIONدسته: رابطها وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: ترکیبی
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
NativeInterfaceProbe.collectInterfaces() رابطها را از طریق getifaddrs() بومی دریافت میکند، رکوردها را بر پایهٔ نام گروهبندی میکند و شاخص، MTU، پرچمها، نوع ARP و نشانیها را میافزاید. evaluateInterfaces() همیشه خلاصهای از شمار کل رابطها و رابطهای فعال تولید میکند. سپس نام رابطهای فعال را با الگوهای tun*، tap*، wg*، ppp*، utun*، zt*، tailscale*، svpn*، gre*، l2tp* و he-ipv6* مقایسه میکند.
فقط برای رابطی با isUp=true که نام نرمالشدهٔ آن با یکی از الگوهای VPN تطبیق داشته باشد، یافتهای با اطمینان بالا ساخته میشود. فهرست خالی رابطها یک یافتهٔ بازبینی با اطمینان پایین ایجاد میکند؛ خلاصهٔ عادی صرفاً اطلاعاتی است.
خطی که یک نام مشخص شبیه VPN دارد، نشانهٔ محلی قدرتمندی از مسیر TUN، WireGuard یا PPP است. خلاصهای که چنین نامی در آن نیست چیزی را ثابت نمیکند و فقط برای مقایسهٔ اجراها وجود دارد.
تأثیر این خط بر گزارش: همین شناسه هم برای خلاصههای اطلاعاتی و هم برای خطوط مشکوک استفاده میشود. نتیجه به جزئیات همان خط و شاخهٔ بررسیکننده بستگی دارد.
نام رابطهای OEM یا سازمانی ممکن است تصادفاً با یک الگو تطبیق داشته باشد. حالت معکوس نیز ممکن است: تونلی با نام تغییرکرده میتواند از الگوی نام عبور کند، اما نوع TUN/TAP، netlink، مسیرها یا ناسازگاری JVM/بومی آن را آشکار کنند.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
مطمئنترین روش بدون روت این است که روی تلفن تحت آزمون اصلاً رابط VPN ساخته نشود: تونل را به روتر، روتر مسافرتی، تلفن جداگانهٔ دروازه یا گره دیگری از شبکه منتقل کنید. دورزدن بهازای برنامه در VpnService مسیر برنامهٔ انتخابشده را تغییر میدهد، اما establish() همچنان یک رابط VPN سیستمی میسازد؛ بنابراین بررسی محلی رابطها ممکن است همچنان فعال شود. حالت پراکسی محلی HTTP/SOCKS بدون TUN گاهی این بردار مشخص را حذف میکند، ولی درگاههای شنود و تنظیمات پراکسی را باقی میگذارد و برنامههایی را که پراکسی را نادیده میگیرند پوشش نمیدهد.
پنهانسازی در سطح آزمایشگاه معمولاً به یک لایهٔ Java سیستمی و یک پسزمینهٔ بومی نیاز دارد. در VPNHide یعنی APK بههمراه Vector/LSPosed با دامنهای محدود به System Framework، و دقیقاً یکی از kmod، KPM یا Zygisk. برای بررسیای که ممکن است از syscall مستقیم یا netlink استفاده کند، kmod/KPM ترجیح دارد: هوک Zygisk در فضای کاربر قابل دورزدن است و داخل فرایند رد باقی میگذارد. ابتدا نقشهٔ پوشش VPNHide را بررسی کنید و ساختها را فقط از صفحهٔ رسمی انتشار بگیرید. VPNHide Next پوشش گستردهتری ادعا میکند، اما دربارهٔ احتمال حلقهٔ بوت و کرنل پنیک نیز هشدار میدهد؛ فقط روی دستگاه آزمایشی امتحانش کنید.
adb shell ip -details link show
adb shell ip -br address show
adb shell cat /proc/net/dev
نام، وضعیت UP، شاخص و MTU را با جزئیات RKNHardering مقایسه کنید. به یاد داشته باشید UID پوسته با UID برنامه یکی نیست؛ راستیآزمایی نهایی را پس از اجرای adb shell am force-stop com.notcvnt.rknhardering و راهاندازی تازه انجام دهید.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
دروازهٔ خارجی کل مسیر شبکه را تغییر میدهد. فیلتر روت یا هسته ممکن است باعث قطع اتصال، گیرکردن getifaddrs() یا حلقهٔ بوت روی هستهٔ ناسازگار شود.
آخرین تغییر را برگردانید: ماژول یا قاعدهٔ افزودهشده را با مدیر معمول خودش غیرفعال کنید، دستگاه را دوباره راهاندازی کنید و اسکن خط مبنا را تکرار کنید. روی وضعیتی ناشناخته هوک دیگری لایه نکنید.
ترکیبی. با evaluateInterfaces()، NetworkInterfacePatterns و گردآورندهٔ رابط در C++ راستیآزمایی شده است. سیگنال اصلی با آزمونهای واحد کاتالوگ و بررسیکننده پوشش داده میشود.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
NativeSignsChecker.kt — منطق اصلی حکم بومی/قدیمی.native_signs_probe.cpp — پیادهسازی پروب بومی.NetworkInterfacePatterns.kt — قواعد نام رابطها.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: tuntap-type, jvm-native-mismatch, getifaddrs-vpn, rtm-getlink-vpn.