شناسه:
VPN_FILEدسته: آثار VPN و سوکتها وضعیت در RKNHardering 2.10.0: شناسه برای سازگاری حفظ شده است؛ در 2.10.0 تولیدکنندهٔ جداگانهای ندارد نقش در حکم نهایی: رجیستری/سازگاری
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
کاتالوگ kind قدیمی vpn_file را دارد، اما detectVpnFiles() فعلی آن را تولید نمیکند. مسیرها بر اساس پیشوندهای vpnhide، lsposed و zygisk جدا میشوند. دو مورد نخست شناسهٔ اختصاصی میگیرند؛ zygisk در فهرست مجاز قدیمی نیست و از طریق UNKNOWN نمایش داده میشود.
در نسخهٔ 2.10.0 تولیدکنندهٔ اختصاصی vpn_file وجود ندارد؛ این شناسه معمولاً فقط بهصورت ردیف اطلاعاتی «یافت نشد» ظاهر میشود.
این URL برای سازگاری است، نه یک بررسی فعال فایل. بررسیهای واقعی مسیر در صفحات vpnhide، lsposed و unknown-signals مستند شدهاند.
تأثیر این خط بر گزارش: این شناسه در کاتالوگ و رابط کاربری باقی مانده است، اما نسخهٔ 2.10.0 خط مثبت جداگانهای از این نوع تولید نمیکند. معمولاً یک سیگنال مجاور و دقیقتر این حالت را پوشش میدهد.
نام میتواند گمراهکننده باشد: برنامه فایلهای مشخصی را بررسی میکند، ولی شناسهٔ عمومی حاضر را به آنها اختصاص نمیدهد.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
برای این ردیف فایلسیستم را تغییر ندهید. فقط VPN یا framework روت واقعاً غیرضروری را از روش حذف عادی خودش پاک کنید، نه اینکه شناسهٔ صرفاً کاتالوگی را ماسک کنید.
ماسککردن شناسهٔ عمومی vpn_file در سطح روت بیفایده است. وقتی مسیر مشخصی دیده میشود، تولیدکنندهٔ همان مسیر را اصلاح و همزمان mountها و ویژگیها را بررسی کنید.
rg -n 'vpn_file|detectVpnFiles|findings.emplace_back' app/src/main/cpp/native_signs_probe.cpp app/src/main/java/com/notcvnt/rknhardering/NativeSignalCatalog.kt
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
حذف دستی /data/adb یا دادهٔ بسته ممکن است مدیر روت و ماژولهایش را خراب کند.
از روش نصب مجدد عادی ابزار استفاده کنید. پوشهها را بدون label درست SELinux با کپی ساده بازسازی نکنید.
رجیستری/سازگاری. نگاشت و پیشوندهای واقعی C++ راستیآزمایی شدهاند.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.NativeSignsChecker.kt — منطق اصلی حکم بومی/قدیمی.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.NativeSignalId.kt — رجیستری کامل شناسهها.سیگنالهای مرتبط: vpnhide, lsposed, unknown-signals.