RKNHardering Help

دسترسی به رابط VPN از طریق sysfs و proc/sys

شناسه: SYSFS_VPN_LEAK دسته: رابط‌ها وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: بالا

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

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

detectSysfsLeak() کل پوشه‌ها را فهرست نمی‌کند؛ برای نام‌های ثابت tun0، tun1، utun0، wg0، ppp0 و xfrm0 مستقیماً stat() را فراخوانی می‌کند. مسیرهای /sys/class/net، /sys/devices/virtual/net و شاخه‌های /proc/sys/net/{ipv4,ipv6}/{conf,neigh} بررسی می‌شوند. همهٔ مسیرهای موجود در یک خط sysfs_vpn_leak ترکیب می‌شوند.

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

دست‌کم یکی از ۳۶ مسیر ثابت وجود داشته باشد و از فرایند برنامه با stat() قابل دسترسی باشد.

معنای نتیجه

این نتیجه مستقیماً تأیید می‌کند که شیء هسته‌ای با نام رایج VPN از نمای فایل‌سیستم شبکه قابل مشاهده مانده است. خط اطمینان بالا دارد، اما نام رابط را تأیید می‌کند و الزاماً ثابت نمی‌کند ترافیک RKNHardering از همان رابط عبور می‌کند.

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

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

فهرست نام‌ها عمداً محدود است. رابطی با نام تغییرکرده ممکن است در اینجا دیده نشود، اما تطبیق‌دهندهٔ اصلی، نوع 65534، netlink، اوراکل ifindex یا بررسی مسیرها آن را پیدا کنند. در Android اصلی با SELinux enforcing ممکن است بعضی مسیرها قابل دسترسی نباشند؛ نبود این خط در آن حالت فقط یعنی این مسیر خاص دسترسی نداده است.

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

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

بدون روت

مطمئن‌ترین روش بدون روت این است که روی تلفن تحت آزمون رابط VPN ساخته نشود: تونل را به روتر، روتر مسافرتی، تلفن جداگانهٔ دروازه یا گره دیگری از شبکه منتقل کنید. دورزدن به‌ازای برنامه در VpnService مسیر برنامهٔ انتخاب‌شده را تغییر می‌دهد، اما establish() همچنان رابط VPN سیستمی می‌سازد؛ بنابراین بررسی محلی رابط‌ها ممکن است همچنان فعال شود. حالت پراکسی محلی HTTP/SOCKS بدون TUN گاهی این بردار مشخص را حذف می‌کند، ولی درگاه‌های شنود و تنظیمات پراکسی را باقی می‌گذارد و برنامه‌های بی‌اعتنا به پراکسی را پوشش نمی‌دهد. پاک‌کردن کش، استفاده از Private Space یا تنظیم دورزدن به‌ازای برنامه، /sys/class/net/<iface> را از فضای نام مشترک هسته حذف نمی‌کند. دروازهٔ خارجی تنها گزینهٔ بدون روت است که واقعاً مانع ساخته‌شدن این شیء روی تلفن می‌شود.

با روت

پنهان‌سازی در سطح آزمایشگاه معمولاً هم به یک لایهٔ Java سیستمی و هم به یک پس‌زمینهٔ بومی نیاز دارد. در VPNHide یعنی APK به‌همراه Vector/LSPosed با دامنه‌ای محدود به System Framework، و دقیقاً یکی از kmod، KPM یا Zygisk. برای بررسی‌ای که ممکن است syscall مستقیم یا netlink به‌کار ببرد، kmod یا KPM ترجیح دارد: هوک Zygisk در فضای کاربر قابل دورزدن است و داخل فرایند رد باقی می‌گذارد. ابتدا نقشهٔ پوشش VPNHide را بررسی کنید و ساخت‌ها را فقط از صفحهٔ رسمی انتشار بگیرید. VPNHide Next پوشش گسترده‌تری ادعا می‌کند، اما دربارهٔ احتمال حلقهٔ بوت و کرنل پنیک نیز هشدار می‌دهد؛ آن را فقط روی دستگاه اختصاصی آزمون کنید. برای این بردار، پس‌زمینه باید عملیات lookup، stat() و readdir() را فیلتر کند یا خود دستگاه شبکه را به‌شکل سازگار پنهان سازد. VPNHide بالادستی /sys/class/net را شکافی می‌داند که معمولاً SELinux می‌پوشاند؛ VPNHide Next در بالاترین سطح خود پنهان‌سازی در سطح فایل‌سیستم را ادعا می‌کند، اما باید روی همان ROM راستی‌آزمایی شود.

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

adb shell 'for b in /sys/class/net /sys/devices/virtual/net /proc/sys/net/ipv4/conf /proc/sys/net/ipv6/conf /proc/sys/net/ipv4/neigh /proc/sys/net/ipv6/neigh; do for n in tun0 tun1 utun0 wg0 ppp0 xfrm0; do [ -e "$b/$n" ] && echo "$b/$n"; done; done'

فرمان با UID پوسته اجرا می‌شود. برای ارزیابی UID هدف به جزئیات RKNHardering تکیه کنید؛ پس از تغییر، برنامه را به‌اجبار متوقف و دوباره اجرا کنید.

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

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

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

خطرها

پنهان‌کردن سراسری /sys یا /proc/sys/net عیب‌یابی را خراب می‌کند و ممکن است روی سرویس‌های سیستمی اثر بگذارد. هوک معیوب هسته می‌تواند حلقهٔ بوت یا کرنل پنیک ایجاد کند.

بازگردانی

ماژول را از recovery یا safe mode غیرفعال کنید، تصویر اصلی boot را بازگردانید و دستگاه را دوباره راه‌اندازی کنید. SELinux را به‌عنوان «راه‌حل موقت» در حالت permissive رها نکنید.

سطح شواهد

بالا. شش نام، دو مسیر پایهٔ sysfs و چهار مسیر پایهٔ proc/sys در detectSysfsLeak() راستی‌آزمایی شده‌اند؛ این نوع در HIGH_CONFIDENCE قرار دارد.

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

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

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

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