dns_propشناسه:
DNS_PROPERTYدسته: آثار VPN و سوکتها وضعیت در RKNHardering 2.10.0: شناسه برای سازگاری حفظ شده است؛ در 2.10.0 تولیدکنندهٔ جداگانهای ندارد نقش در حکم نهایی: رجیستری/سازگاری
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
DNS_PROPERTY و نگاشت قدیمی dns_prop در کاتالوگ و رابط کاربری باقی ماندهاند، اما native_signs_probe.cpp در نسخهٔ 2.10.0 خط dns_prop تولید نمیکند. کلیدهای شبیه DNS مانند net.vpn.dns* و dhcp.tun0.dns* اکنون زیر kind مشترک vpn_prop قرار میگیرند و در صفحهٔ vpn-property توضیح داده میشوند.
تولیدکنندهٔ مثبت جداگانهای وجود ندارد. بررسیکننده هنوز برای این نوع یک خط اطلاعاتی «یافت نشد» تولید میکند.
صفحه برای حفظ URL پایدار و سازگاری عقبرو وجود دارد. این بهمعنای بررسینشدن DNS نیست: بررسیهای سمت سرور DNS و vpn_prop به دستههای دیگری تعلق دارند.
تأثیر این خط بر گزارش: این شناسه در کاتالوگ و رابط کاربری باقی مانده است، اما نسخهٔ 2.10.0 خط مثبت جداگانهای از این نوع تولید نمیکند. معمولاً یک سیگنال مجاور و دقیقتر این حالت را پوشش میدهد.
ممکن است نسخهٔ آینده dns_prop جداگانه را بازگرداند؛ با تغییر کد این صفحه باید دوباره بررسی شود.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
در نسخهٔ فعلی نیازی به دورزدن این شناسه نیست. بهجای آن سیگنالهای واقعی DNS را اصلاح کنید: resolver را با مسیر مورد انتظار هماهنگ کنید، نشتها را از میان ببرید و HTTP، DNS و UDP را با هم بیازمایید.
برای تولیدکنندهای که وجود ندارد روت لازم نیست. فقط برای سبزکردن خط dns-property ماژول نصب نکنید؛ خود ماژول ممکن است نشانههای روت یا هوک بسازد.
rg -n 'dns_prop|DNS_PROPERTY' app/src/main
rg -n 'net\.vpn\.dns|dhcp\.tun0\.dns' app/src/main/cpp/native_signs_probe.cpp
جستوجوی اول نگاشت کاتالوگ/رابط کاربری را نشان میدهد؛ جستوجوی دوم تولیدکنندهٔ واقعی vpn_prop را.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
خطر اصلی این است که خط صرفاً رجیستری را مدرکی برای نبود نشت DNS بدانید.
بازگردانی لازم نیست؛ فقط تغییرات DNS را که اتصال را خراب کردهاند برگردانید.
رجیستری/سازگاری. نبود تولیدکنندهٔ literal برای dns_prop در C++ و وجود نگاشت آن در NativeSignalCatalog راستیآزمایی شدهاند.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.NativeSignsChecker.kt — منطق اصلی حکم بومی/قدیمی.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.NativeSignalId.kt — رجیستری کامل شناسهها.سیگنالهای مرتبط: vpn-property, general-diagnostics.