getifaddrs()شناسه:
GETIFADDRS_VPNدسته: رابطها وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: بالا
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
detectGetifaddrsVpn() تابع libc یعنی getifaddrs() را فراخوانی میکند و نامهای دقیق tun0، tun1، utun0، wg0، ppp0 و xfrm0 را میجوید. رکوردهای تکراری نشانی deduplicate نمیشوند، بنابراین ممکن است یک نام چند بار در detail ظاهر شود.
زنجیرهٔ ifaddrs حداقل یک ورودی با یکی از شش نام دقیق داشته باشد؛ وضعیت UP بررسی نمیشود.
فهرست مستقیم رابطها در فضای کاربر نام رایج شبیه VPN دارد. برخلاف بررسی اصلی interface-enumeration، این بردار عمیق حتی وقتی رابط پرچم UP ندارد هم میتواند فعال شود.
تأثیر این خط بر گزارش: این خط detected=true را تنظیم میکند و بهعنوان یک نشانهٔ محلی با اطمینان بالا در نظر گرفته میشود.
این matcher کامل پروژه نیست: tailscale0، svpn0، zt*، gre*، رابطهای تغییرنامیافته یا رابطهای خاص OEM را جستوجو نمیکند. هوک inline در فضای کاربر میتواند نتایج getifaddrs() را عوض کند، اما netlink خام و مسیرهای دیگر همچنان جداگانه بررسی میشوند.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
مطمئنترین راه بدون روت این است که روی تلفنِ در حال آزمون رابط VPN ساخته نشود: تونل را به روتر، travel router، تلفن دروازهٔ جدا یا گرهٔ شبکهٔ دیگری منتقل کنید. bypass هر برنامه در VpnService مسیر برنامهٔ انتخابشده را تغییر میدهد، اما establish() همچنان یک رابط VPN سیستمی میسازد؛ بنابراین بررسیهای محلی رابط ممکن است فعال بمانند. حالت proxy محلی HTTP/SOCKS بدون TUN گاهی این بردار خاص را حذف میکند، ولی پورتهای شنونده و تنظیمات proxy بر جا میگذارد و برنامههایی را که proxy را نادیده میگیرند پوشش نمیدهد. بدون روت، یک برنامه نمیتواند نتیجهٔ getifaddrs() را که برنامهای دیگر میبیند فیلتر کند. هوک بدون روت یا APK بازبستهبندیشدهٔ هدف نشانگرهای واضحتر یکپارچگی ایجاد میکند و توصیه نمیشود.
پنهانسازی در سطح آزمایشگاه معمولاً به یک لایهٔ Java سیستمی و یک backend بومی نیاز دارد. در VPNHide یعنی APK بههمراه Vector/LSPosed که فقط به System Framework محدود شده باشد، و دقیقاً یکی از kmod، KPM یا Zygisk. برای بررسیای که ممکن است از syscall مستقیم یا netlink استفاده کند، kmod/KPM مناسبتر است؛ هوک Zygisk در فضای کاربر قابل دورزدن است و درون فرایند ردپا میگذارد. ابتدا نقشهٔ پوشش VPNHide را بررسی کنید و buildها را فقط از صفحهٔ رسمی انتشار بگیرید. VPNHide Next پوشش گستردهتری ادعا میکند، اما دربارهٔ boot loop و kernel panic احتمالی نیز هشدار میدهد و باید فقط روی دستگاه آزمایشی امتحان شود. Zygisk میتواند فراخوانی libc را رهگیری کند، اما syscall خام و netlink از interposition فضای کاربر عبور میکنند. برای نتیجهٔ سازگار، backend هسته همراه با لایهٔ system_server مناسبتر است.
adb shell ip -br link
adb shell 'cat /proc/net/dev | grep -E "tun0|tun1|utun0|wg0|ppp0|xfrm0"'
بازتولید دقیق به harness کوچک بومی با getifaddrs() نیاز دارد؛ ip مسیرهای netlink خودش را استفاده میکند و فقط برای مقایسه است.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
هوک ناقص فضای کاربر با RTM_GETLINK، lookupهای ifindex و APIهای Java ناسازگاری میسازد؛ این امر سیگنالهای trim-oracle و mismatch را تقویت میکند.
آخرین تغییر را برگردانید: ماژول یا قاعدهٔ افزودهشده را از مدیر معمول خودش غیرفعال کنید، دستگاه را دوباره راهاندازی کنید و اسکن خط مبنا را تکرار کنید. روی وضعیت ناشناخته هوک دیگری لایه نکنید.
بالا. حلقهٔ نامهای دقیق در detectGetifaddrsVpn() بررسی شده است؛ kind با اطمینان زیاد است.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.VpnNativeDetectorChecker.kt — حکم و اطمینان بررسی عمیق VPN.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: interface-enumeration, rtm-getlink-vpn, trim-oracle, sysclassnet-vpn.