RKNHardering Help

ناسازگاری شمار رابط‌ها میان if_indextoname و RTM_GETLINK

شناسه: TRIM_ORACLE دسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: متوسط

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

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

پروب شمار فراخوانی‌های موفق if_indextoname() برای شاخص‌های 1 تا 127 (bind_probe) را محاسبه و جداگانه پیام‌های RTM_NEWLINK را در dump کامل RTM_GETLINK می‌شمارد. اگر دو شمار متفاوت باشند، MISMATCH گزارش می‌شود. این نوع یافتهٔ بازبینی با اطمینان متوسط است.

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

پس از دو فهرست‌برداری مستقل، bindCount != rtmCount باشد.

معنای نتیجه

این وضعیت اغلب فیلتر ناقص را نشان می‌دهد: یک API رابط را پنهان کرده، اما API دیگر شاخص یا ورودی آن را نمایش می‌دهد. ناسازگاری می‌تواند از شاخص بالاتر از 127، رقابت هنگام ساخته یا حذف‌شدن رابط یا dump ناقص netlink نیز ناشی شود.

تأثیر این خط بر گزارش: این خط به‌تنهایی حکم نهایی صادر نمی‌کند، اما needsReview=true را تنظیم و شاهدی با اطمینان متوسط اضافه می‌کند.

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

نام bind_probe تاریخی است: پیاده‌سازی در واقع از if_indextoname() استفاده می‌کند، نه bind(). سقف 127 می‌تواند روی سامانه‌ای با شاخص رابط بزرگ‌تر مثبت کاذب بسازد. تصویر اتمی نیست و برای تأیید تکرار نمی‌شود.

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

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

بدون روت

برای سیگنال تشخیصی، ابتدا هیچ چیزی را «اصلاح» نکنید. روی همان دستگاه بدون VPN خط مبنا ثبت کنید و سپس آزمون را با VPN و تحت همان شبکه، دما و بار تکرار کنید. فقط تفاوت تکرارپذیر میان دو مجموعه برای تحلیل مفید است. یک مقدار MTU، زمان‌بندی یا GSO به‌تنهایی مدرک نیست. بررسی را چند بار تکرار کنید. اگر ناسازگاری فقط هنگام جابه‌جایی Wi‑Fi، دادهٔ همراه یا VPN ظاهر می‌شود، رقابت زمانی است نه دورزدن پایدار.

با روت

پنهان‌سازی در سطح آزمایشگاه معمولاً هم به یک لایهٔ Java سیستمی و هم به یک پس‌زمینهٔ بومی نیاز دارد. در VPNHide یعنی APK به‌همراه Vector/LSPosed با دامنه‌ای محدود به System Framework، و دقیقاً یکی از kmod، KPM یا Zygisk. برای بررسی‌ای که ممکن است syscall مستقیم یا netlink به‌کار ببرد، kmod یا KPM ترجیح دارد: هوک Zygisk در فضای کاربر قابل دورزدن است و داخل فرایند رد باقی می‌گذارد. ابتدا نقشهٔ پوشش VPNHide را بررسی کنید و ساخت‌ها را فقط از صفحهٔ رسمی انتشار بگیرید. VPNHide Next پوشش گسترده‌تری ادعا می‌کند، اما دربارهٔ احتمال حلقهٔ بوت و کرنل پنیک نیز هشدار می‌دهد؛ آن را فقط روی دستگاه اختصاصی آزمون کنید. سازگاری باید در همهٔ مسیرها بازگردانده شود. فقط dump را با حذف RTM_NEWLINK کوتاه نکنید؛ if_indextoname()، SIOCGIFNAME، مسیرها و نشانی‌ها نیز باید نمای سازگاری ارائه دهند.

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

adb shell 'ip -o link show | wc -l'
adb shell 'ip -o link show'

مقایسهٔ دقیق به harness بومی نیاز دارد که بلافاصله پس از dump مربوط به RTM_GETLINK، if_indextoname(1..127) را پیمایش کند. آزمون را روی شبکهٔ پایدار دست‌کم پنج بار تکرار کنید.

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

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

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

خطرها

فیلتر نادرست پیام‌های چندبخشی netlink می‌تواند حلقهٔ dump را بی‌نهایت کند یا فراخوانی‌های شبکهٔ سیستم را از کار بیندازد.

بازگردانی

آخرین تغییر را برگردانید: ماژول یا قاعدهٔ افزوده‌شده را با مدیر معمول خودش غیرفعال کنید، دستگاه را دوباره راه‌اندازی کنید و اسکن خط مبنا را تکرار کنید. روی وضعیتی ناشناخته هوک دیگری لایه نکنید.

سطح شواهد

متوسط. الگوریتم دو شمار راستی‌آزمایی شده است؛ نوع نتیجه اطمینان متوسط دارد و detected را تنظیم نمی‌کند. محدودیت 127 و رقابت زمانی نیز مستند شده‌اند.

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

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

سیگنال‌های مرتبط: rtm-getlink-vpn, ifindexname-vpn, vpnhide.

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