RKNHardering Help

شمارنده‌های قدیمی ترافیک tun0/wg0 زیر نام qdisc

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

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

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

برخلاف نامش، detectQdisc() وضعیت qdisc را پرس‌وجو نمی‌کند. این تابع /proc/net/dev را می‌خواند، بایت‌ها و بسته‌های RX/TX را تجزیه می‌کند و vpn_qdisc را فقط برای نام‌های دقیق tun0 و wg0 تولید می‌کند. سیاست قدیمی این ردیف را یافتهٔ بازبینی با اطمینان متوسط می‌داند.

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

tun0 یا wg0 در /proc/net/dev وجود داشته باشد؛ شمارنده‌های ترافیک می‌توانند صفر باشند.

معنای نتیجه

این نشت دیگری از رابط در procfs است، نه تحلیل زمان‌بند بسته. خط لولهٔ عمیق فعلی عملاً تولیدکنندهٔ جداگانه‌ای برای وضعیت واقعی qdisc ندارد.

تأثیر این خط بر گزارش: این خط به‌تنهایی حکم نهایی صادر نمی‌کند، اما needsReview=true را تنظیم و شاهدی با اطمینان متوسط اضافه می‌کند.

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

نام تاریخی و احتمالاً گمراه‌کننده است. فقط دو نام بررسی می‌شوند و آن هم تنها وقتی procfs در دسترس باشد.

این خط باید همراه با سیگنال‌های مجاور ارزیابی شود. پاک‌بودن نتیجهٔ یک 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 پوشش گسترده‌تری ادعا می‌کند، اما دربارهٔ احتمال حلقهٔ بوت و کرنل پنیک نیز هشدار می‌دهد؛ آن را فقط روی دستگاه اختصاصی آزمون کنید. فیلتر /proc/net/dev جدا از netlink لازم است. VPNHide بالادستی پوشش کامل این فایل را از طریق پس‌زمینهٔ هسته ادعا نمی‌کند؛ VPNHide Next یک لایهٔ گسترده‌تر proc/qdisc را ادعا می‌کند.

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

adb shell cat /proc/net/dev 2>&1 | grep -E '(^|:)[[:space:]]*(tun0|wg0):'
adb shell tc qdisc show 2>/dev/null

فرمان دوم نشان می‌دهد وضعیت واقعی qdisc سطح جداگانه‌ای است.

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

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

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

خطرها

شمارنده‌های واقعی را صفر نکنید و تنظیمات qdisc را بی‌دلیل تغییر ندهید؛ این کار روی QoS و تأخیر اثر می‌گذارد.

بازگردانی

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

سطح شواهد

متوسط. با تجزیه‌گر /proc/net/dev راستی‌آزمایی شده است؛ این مستندات صریحاً نام تاریخی را اصلاح می‌کنند.

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

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

سیگنال‌های مرتبط: proc-net-dev-vpn, deep-vpn-qdisc.

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