RKNHardering Help

ویژگی‌های سیستمی قدیمی VPN/DNS

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

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

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

detectVpnPropertiesAll() مقادیر net.vpn.dns1..4، dhcp.tun0.dns1/2، net.interfaces.default.type و net.interfaces.default.name را می‌خواند. هر مقدار غیرخالی vpn_prop تولید می‌کند. افزون بر این، net.interfaces.default.type دوباره از نظر زیررشته‌های tun یا vpn بررسی می‌شود. در سیاست قدیمی، این نوع اطمینان بالا دارد و detected=true را تنظیم می‌کند.

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

یکی از ویژگی‌های ثابت VPN غیرخالی باشد، یا default.type شامل tun یا vpn باشد.

معنای نتیجه

وقتی میان‌افزار واقعاً این ویژگی‌ها را صادر می‌کند، سیگنال قدیمی قدرتمندی است. در نسخه‌های جدیدتر Android، حتی هنگام فعال‌بودن VPN نیز این نام‌ها اغلب وجود ندارند.

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

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

فهرست ویژگی‌ها بخشی از API پایدار Android نیست. OEM ممکن است پس از غیرفعال‌شدن VPN مقدار کهنه‌ای باقی بگذارد یا اصلاً این کلیدها را به‌کار نبرد.

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

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

بدون روت

سرویس‌گیرندهٔ VPN را کاملاً متوقف و شبکه را دوباره راه‌اندازی کنید، سپس ببینید ویژگی ناپدید می‌شود یا نه. اگر میان‌افزار آن را تنظیم کند، برنامهٔ عادی نمی‌تواند تغییرش دهد. دروازهٔ خارجی شاید ویژگی کهنه را تا ریبوت پاک نکند، اما VpnService تازه‌ای هم نمی‌سازد.

با روت

resetprop می‌تواند یک کلید قدیمی را پنهان کند، اما فقط همین سطح را پوشش می‌دهد. مقدار DNS را بدون سازگار نگه‌داشتن آن با مسیر واقعی resolver جایگزین نکنید. بهتر است منبع ویژگی حذف شود یا فیلتر سیستمی‌ای به‌کار رود که شبکهٔ سراسری را تغییر ندهد.

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

for p in net.vpn.dns1 net.vpn.dns2 net.vpn.dns3 net.vpn.dns4 dhcp.tun0.dns1 dhcp.tun0.dns2 net.interfaces.default.type net.interfaces.default.name; do
  printf '%s=' "$p"; adb shell getprop "$p"
done

پس از غیرفعال‌کردن VPN و ریبوت، بررسی را تکرار کنید.

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

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

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

خطرها

جایگزینی سراسری مقادیر DNS یا ویژگی‌ها ممکن است نشت DNS یا ازکارافتادن نام‌گشایی ایجاد کند. با اسکریپت همهٔ ویژگی‌های net.* را پاک نکنید.

بازگردانی

قاعدهٔ هدفمند resetprop را حذف و دستگاه را ریبوت کنید؛ پیکربندی اصلی VPN و DNS را بازگردانید.

سطح شواهد

بالا. فهرست دقیق ویژگی‌ها راستی‌آزمایی شده است؛ vpn_prop در انواع قدیمی با اطمینان بالا قرار دارد.

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

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

سیگنال‌های مرتبط: dns-property, hook-property, interface-enumeration.

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