RKNHardering Help

تأیید وجود رابط VPN با SO_BINDTODEVICE

شناسه: BINDTODEVICE_LEAK دسته: آثار VPN و سوکت‌ها وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: بالا

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

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

برای هر یک از tun0، tun1، utun0، wg0 و ppp0 یک سوکت UDP ساخته می‌شود. پروب setsockopt(SO_BINDTODEVICE, name) و سپس getsockopt(SO_BINDTODEVICE) را اجرا می‌کند و لازم است رشتهٔ بازگشتی همان نام را در بر داشته باشد. xfrm0 در این فهرست نیست.

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

هم تنظیم و هم خواندن SO_BINDTODEVICE برای یکی از پنج نام ثابت شبیه VPN موفق باشد.

معنای نتیجه

API سوکت هسته bind به دستگاه شبکهٔ شبیه VPN را می‌پذیرد؛ یعنی رابط واقعاً وجود دارد و برای فرایند قابل دسترسی است. این شاهد از بررسی سادهٔ فایل قوی‌تر است.

تأثیر این خط بر گزارش: این خط detected=true را تنظیم می‌کند و به‌عنوان یک نشانهٔ محلی با اطمینان بالا در نظر گرفته می‌شود.

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

در Linux، SO_BINDTODEVICE ممکن است با مجوز یا policy محدود شود؛ شکست نبود رابط را ثابت نمی‌کند. فهرست نام‌های دقیق محدود است. پروب ترافیک نمی‌فرستد و عبور ترافیک از دستگاه را تأیید نمی‌کند.

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

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

بدون روت

مطمئن‌ترین روش بدون روت این است که روی تلفن تحت آزمون رابط VPN ساخته نشود: تونل را به روتر، روتر مسافرتی، تلفن جداگانهٔ دروازه یا گره دیگری از شبکه منتقل کنید. دورزدن به‌ازای برنامه در VpnService مسیر برنامهٔ انتخاب‌شده را تغییر می‌دهد، اما establish() همچنان رابط VPN سیستمی می‌سازد؛ بنابراین بررسی محلی رابط‌ها ممکن است همچنان فعال شود. حالت پراکسی محلی HTTP/SOCKS بدون TUN گاهی این بردار مشخص را حذف می‌کند، ولی درگاه‌های شنود و تنظیمات پراکسی را باقی می‌گذارد و برنامه‌های بی‌اعتنا به پراکسی را پوشش نمی‌دهد. تنظیمات عادی VPN نمی‌توانند مانع فراخوانی setsockopt توسط برنامهٔ هدف شوند. پروفایل دوم همان پشتهٔ شبکهٔ هسته را به اشتراک می‌گذارد.

با روت

پنهان‌سازی در سطح آزمایشگاه معمولاً به یک لایهٔ Java سیستمی و یک پس‌زمینهٔ بومی نیاز دارد. در VPNHide یعنی APK به‌همراه Vector/LSPosed با دامنه‌ای محدود به System Framework، و دقیقاً یکی از kmod، KPM یا Zygisk. برای بررسی‌ای که ممکن است از syscall مستقیم یا netlink استفاده کند، kmod/KPM ترجیح دارد: هوک Zygisk در فضای کاربر قابل دورزدن است و داخل فرایند رد باقی می‌گذارد. ابتدا نقشهٔ پوشش VPNHide را بررسی کنید و ساخت‌ها را فقط از صفحهٔ رسمی انتشار بگیرید. VPNHide Next پوشش گسترده‌تری ادعا می‌کند، اما دربارهٔ احتمال حلقهٔ بوت و کرنل پنیک نیز هشدار می‌دهد؛ فقط روی دستگاه آزمایشی امتحانش کنید. پس‌زمینه باید برای UID هدف خطای سازگار «رابط یافت نشد» برگرداند و هم‌زمان رابط را از getifaddrs، netlink و بررسی‌های مبتنی بر ifindex پنهان کند. هوک فضای کاربر با syscall خام قابل دورزدن است.

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

adb shell su -c 'for n in tun0 tun1 utun0 wg0 ppp0; do ip link show dev "$n" 2>/dev/null && echo present:$n; done'

آزمون دقیق به harness بومی با SO_BINDTODEVICE نیاز دارد؛ فرمان بالا فقط برای جهت‌یابی از روت استفاده می‌کند و زمینهٔ UID/SELinux برنامه را بازتولید نمی‌کند.

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

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

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

خطرها

مسدودکردن سراسری SO_BINDTODEVICE می‌تواند VPN، DHCP، tethering و سرویس‌های سیستمی را خراب کند. هر جایگزینی errno باید به UID محدود باشد.

بازگردانی

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

سطح شواهد

بالا. حلقهٔ پنج‌نامی، تأیید setsockopt/getsockopt و مجموعهٔ HIGH_CONFIDENCE راستی‌آزمایی شده‌اند.

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

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

سیگنال‌های مرتبط: so-bindtodevice, getifaddrs-vpn, ifindexname-vpn.

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