RKNHardering Help

نوع بومی ناشناخته یا نگاشت‌نشده

شناسه: UNKNOWN دسته: سیگنال‌های سرویس وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: سرویسی

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

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

توابع NativeSignalCatalog.info(null) و شناسه‌های ناشناخته از UNKNOWN استفاده می‌کنند. در نگاشت‌گرهای قدیمی و عمیق، نوع ناشناخته معمولاً به null resolve می‌شود؛ پس از آن ممکن است یافته مقالهٔ جایگزین دریافت کند یا اصلاً از parser مشخصی عبور نکند. این صفحه برای سازگاری رو‌به‌جلو وجود دارد، نه برای یک پروب C++ خاص.

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

رابط کاربری یا لینک یک NativeSignalId تهی/ناشناخته دریافت کند، یا ردیف بومی جدید هنوز به نگاشت کاتالوگ افزوده نشده باشد.

معنای نتیجه

این نقص هم‌ترازی نسخه میان تولیدکننده، parser، enum و مستندات است. از یک ردیف ناشناخته نمی‌توان اطمینان یا راهکار کاهش اثر تعیین کرد؛ ابتدا نوع/جزئیات خام و commit/نسخه لازم است.

تأثیر این خط بر گزارش: این یک شناسهٔ چتری یا پشتیبان است. گروهی از خطوط را به مستندات پیوند می‌دهد، اما همیشه تولیدکنندهٔ مثبت مستقلی ندارد.

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

APK انتشار ممکن است ردیف خام کامل را نمایش ندهد. وقتی نسخه‌های APK و مستندات مخلوط شوند، slugها و عنوان‌ها ممکن است متفاوت باشند. نتیجهٔ ناشناخته نباید خودکار پاک یا detected تلقی شود.

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

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

بدون روت

گزارش export‌شده، نسخهٔ APK، ABI و جزئیات دقیق را ذخیره کنید. نسخهٔ رسمی را بدون بسته‌بندی مجدد دوباره نصب و آزمون را تکرار کنید. فقط حداقل گزارش لازم را با حذف داده‌های شخصی به issue پیوست کنید.

با روت

آزمون را بدون ماژول‌هایی تکرار کنید که JNI یا رشته‌ها را تغییر می‌دهند. هنگام افزودن پروب بومی سفارشی، NativeSignalId، NativeSignalCatalog، نگاشت‌گر، رشته‌های رابط کاربری، مقالهٔ فارسی و آزمون‌های واحد را با هم به‌روز کنید.

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

rg -n 'NativeSignalId|fromLegacyVpnKind|fromDeepVpnKind|UNKNOWN' app/src/main/java/com/notcvnt/rknhardering
./gradlew testDebugUnitTest --tests com.notcvnt.rknhardering.NativeSignalCatalogTest

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

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

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

خطرها

گزارش خام منتشرشده ممکن است نام رابط‌ها، نشانی‌های IP، مسیرها و نام بسته‌ها را دربر داشته باشد. پیش از ثبت issue، اسرار و داده‌های شخصی را حذف کنید.

بازگردانی

تغییر ناسازگار تولیدکننده/کاتالوگ را برگردانید یا نسخه‌های هماهنگ APK و مستندات را نصب کنید.

سطح شواهد

ساختاری. fallback کاتالوگ و جدول‌های نگاشت راستی‌آزمایی شده‌اند. این یک سیگنال سطح سرویس است.

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

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

سیگنال‌های مرتبط: native-library, general-diagnostics, syscall-unavailable.

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