RKNHardering Help

آشکارساز عمیق بومی هیچ سطری برنگرداند

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

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

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

VpnNativeDetectorChecker فقط زمانی GENERAL_DIAGNOSTICS را می‌افزاید که پس از تجزیه، findings خالی باشد. این وضعیت ممکن است یعنی همهٔ توابع تولیدکننده ساکت بوده‌اند، اسکن پیش از ایجاد خروجی لغو شده یا تجزیه‌گر سطرها را کنار گذاشته است. برای دردسترس‌نبودن library بومی شناسهٔ دیگری استفاده می‌شود.

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

پس از detectVpnDetector() و parseRow() شرط findings.isEmpty() برقرار باشد.

معنای نتیجه

پیام «ناهنجاری‌ای یافت نشد» فقط به دستهٔ عمیق و سطرهایی که با موفقیت تجزیه شده‌اند مربوط است. نبود VPN را تضمین نمی‌کند و نتایج legacy، Java، سمت سرور یا beta را خنثی نمی‌کند.

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

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

بعضی پروب‌ها وقتی پاک‌اند عمداً خروجی ندارند، اما route_count، normal_pmtu، timing و UDP PMTU معمولاً telemetry تولید می‌کنند. خروجی کاملاً خالی می‌تواند نشانهٔ لغو، رفتار parser یا مشکل مخصوص ABI هم باشد. gso_ok اکنون به‌دلیل نداشتن فیلد detail کنار گذاشته می‌شود، اما سطرهای دیگر معمولاً باقی می‌مانند.

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

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

بدون روت

تأیید کنید اسکن کامل شده، library بومی بارگذاری شده و دسته لغو نشده است. log را بررسی کنید و اسکن را روی شبکهٔ پایدار تکرار کنید.

با روت

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

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

adb logcat -c
adb shell am force-stop com.notcvnt.rknhardering
# یک اسکن کامل اجرا کنید، سپس:
adb logcat -d | grep -Ei 'RKNHardering|native|vpn detector|cancel|JNI' | tail -200

نتیجهٔ مجاور native-library را نیز بررسی کنید.

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

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

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

خطرها

مختل‌کردن عمدی JNI یا اسکن می‌تواند خطاهای واقعی را پنهان کند و روش معتبری برای عبور از بررسی نیست.

بازگردانی

APK رسمی را بازیابی کنید، ماژول مزاحم را غیرفعال و دستگاه را راه‌اندازی مجدد کنید. اسکن کامل خط مبنا را تکرار کنید.

سطح شواهد

سرویسی. شاخهٔ findings.isEmpty() و رفتار تجزیه‌گر بررسی شده‌اند.

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

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

سیگنال‌های مرتبط: native-library, unknown-signals, route-count.

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