شناسه:
DEEP_VPN_QDISCدسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: شناسه برای سازگاری حفظ شده است؛ در 2.10.0 تولیدکنندهٔ جداگانهای ندارد نقش در حکم نهایی: رجیستری/سازگاری
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
نگاشت کاتالوگ fromDeepVpnKind("vpn_qdisc") خط را به DEEP_VPN_QDISC هدایت میکند، اما nativeDetectVpnDetector() فعلی تابع تولیدکنندهٔ vpn_qdisc را فراخوانی نمیکند. تولیدکنندهٔ فعال فقط در مسیر قدیمی nativeDetectVpnAdvanced() وجود دارد و در صفحهٔ vpn-qdisc مستند شده است.
در خط لولهٔ عمیق فعلی محرک جداگانهای وجود ندارد. این شناسه فقط زمانی ظاهر میشود که نسخهٔ آیندهٔ nativeDetectVpnDetector() نوع vpn_qdisc را برگرداند یا پل بومی تغییر کند.
این صفحه معمولاً از کاتالوگ قابل دسترسی است، اما در زمان اجرا یافتهای با این شناسه وجود ندارد. نبود شناسهٔ عمیق را مدرکی برای پنهانبودن وضعیت qdisc یا شمارندهها ندانید.
تأثیر این خط بر گزارش: این شناسه در کاتالوگ و رابط کاربری باقی مانده است، اما نسخهٔ 2.10.0 خط مثبت جداگانهای از این نوع تولید نمیکند. معمولاً یک سیگنال مجاور و دقیقتر این حالت را پوشش میدهد.
نام qdisc در تولیدکنندهٔ قدیمی نیز دقیق نیست: تابع فعلی بهجای پرسوجوی وضعیت qdisc از طریق rtnetlink TC، مقادیر RX/TX مربوط به tun0/wg0 را از /proc/net/dev میخواند. هر دو مقاله این تفاوت را توضیح میدهند.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
برای شناسهٔ غیرفعال چیزی را تغییر ندهید. برای سیگنال واقعی، vpn-qdisc و proc-net-dev-vpn را ببینید.
فقط برای یک خط خالی در رجیستری ماژول هسته نصب نکنید. اگر آشکارساز واقعی qdisc اضافه میکنید، ابتدا معنای RTM_GETQDISC/TC و مدل جداگانهٔ مثبت کاذب را تعریف کنید.
rg -n 'detectQdisc|nativeDetectVpnDetector|nativeDetectVpnAdvanced|"vpn_qdisc"' app/src/main/cpp/native_signs_probe.cpp app/src/main/java/com/notcvnt/rknhardering
تأیید کنید که فراخوانی مشخصاً در تابع یکپارچهٔ deep وجود ندارد.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
تلاش برای پنهانکردن سراسری وضعیت کنترل ترافیک میتواند shaping، QoS و NetworkStack را خراب کند. تا پیش از وجود تولیدکننده چیزی برای اصلاح وجود ندارد.
اگر فراخوانی را آزمایشی افزودهاید، فقط تغییرات خط لوله و آزمونها را برگردانید؛ تغییری روی دستگاه لازم نیست.
رجیستری/سازگاری. با فهرست فراخوانیهای تابع JNI و نگاشت کاتالوگ راستیآزمایی شده است؛ وضعیت فقط رجیستری.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.VpnNativeDetectorChecker.kt — حکم و اطمینان بررسی عمیق VPN.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.NativeSignalId.kt — رجیستری کامل شناسهها.سیگنالهای مرتبط: vpn-qdisc, proc-net-dev-vpn, route-count.