شناسه:
ROUTE_COUNTدسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: پایین
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
detectRouteCount() تابع مشترک netlinkRouteDump(0) را فراخوانی میکند، ردیفهای دارای پیشوند route| و مقادیر یکتای پس از |dev= را میشمارد. همیشه route_count|total=N interfaces=M را تولید میکند، حتی وقتی N برابر 0 باشد. بررسیکننده این نوع را دادهٔ اطلاعاتی با اطمینان پایین میداند.
هر بار که تابع کامل شود خط تولید میشود؛ این تلهمتری است، نه آستانهٔ ناهنجاری.
اعداد خط مبنا فراهم میکنند و تغییر ناگهانی پس از فعالکردن VPN یا ماژول را نشان میدهند. شمار «عادی» جهانی برای مسیرها وجود ندارد و مقدار روی detected اثر نمیگذارد.
تأثیر این خط بر گزارش: این خط اطلاعاتی یا تشخیصی است. برای مقایسهٔ اجراها مفید است، اما بهتنهایی وجود VPN یا دستکاری را ثابت نمیکند.
تصویر به Wi‑Fi یا دادهٔ همراه، IPv4 و IPv6، OEM، tethering، پروفایلها و زمان اجرا وابسته است. تابع فقط ردیفهایی را میشمارد که تجزیهگر داخلی با موفقیت تولید کرده است؛ خطای netlink ممکن است بهشکل صفر ظاهر شود.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
برای سیگنال تشخیصی، ابتدا هیچ چیزی را «اصلاح» نکنید. روی همان دستگاه بدون VPN خط مبنا ثبت کنید و سپس آزمون را با VPN و تحت همان شبکه، دما و بار تکرار کنید. فقط تفاوت تکرارپذیر میان دو مجموعه برای تحلیل مفید است. یک مقدار MTU، زمانبندی یا GSO بهتنهایی مدرک نیست. در همان شبکه دستکم سه تا پنج اجرا بدون VPN و با VPN ثبت کنید. فقط برای برابرکردن شمار، مسیرها را حذف نکنید.
ماژول روت میتواند این شاخص را تغییر دهد، اما تنظیم آن برای رسیدن به عددی خاص بهآسانی TCP/UDP، DNS، تماسها یا مصرف انرژی را مختل میکند. VPNHide Next ادعا میکند چند پارامتر غیرمستقیم را فیلتر میکند، ولی این قابلیتها باید جدا از پنهانسازی پایهٔ رابط آزموده شوند. پیش از داشتن خط مبنای پاک و روش بازگردانی عملی، بیشترین مجموعهٔ هوکهای هسته را فعال نکنید. اگر فیلتری شمار را تغییر میدهد، باید با RTM_GETLINK، getifaddrs() و جستوجوی واقعی مسیر سازگار بماند؛ هدف رسیدن به N ثابت نیست.
adb shell 'ip -4 route show table all; ip -6 route show table all'
adb shell 'ip -o link show | wc -l'
بهجای انتظار برابری دقیق میان تصویر پوسته و برنامه، روند را مقایسه کنید.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
حذف دستی مسیرها میتواند فوراً ADB شبکهای، DNS، اتصال همراه و VPN را قطع کند.
برای یک خط اطلاعاتی مسیریابی را تغییر ندهید. اگر پیشتر تغییر دادهاید، ماژول آزمایشی را غیرفعال و شبکه یا دستگاه را دوباره راهاندازی کنید.
پایین. با نتیجهٔ بدونشرط و INFORMATIONAL_KINDS راستیآزمایی شده است.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.VpnNativeDetectorChecker.kt — حکم و اطمینان بررسی عمیق VPN.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: route-table, vpn-policy-rules-netlink, trim-oracle.