RKNHardering Help

ورودی‌های ARP با نشانی MAC صفر یا broadcast

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

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

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

detectArpNeighbors() فایل /proc/net/arp را می‌خواند، همهٔ ردیف‌ها را می‌شمارد و ردیف‌هایی را که MAC آن‌ها 00:00:00:00:00:00 است یا شامل ff:ff:ff:ff:ff:ff می‌شود جداگانه می‌شمارد. اگر hidden بزرگ‌تر از صفر باشد، سیاست قدیمی این نوع را با اطمینان بالا طبقه‌بندی می‌کند.

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

دست‌کم یک ردیف ARP دارای نشانی MAC صفر یا broadcast باشد.

معنای نتیجه

سیاست اطمینان‌بالای پروژه این وضعیت را شاهدی از همسایه‌های پنهان می‌داند، اما تکمیل‌نشدن ARP/NUD و ورودی‌های کهنه نیز می‌توانند وضعیت عادی شبکه باشند. جزئیات total/hidden اهمیت دارد.

تأثیر این خط بر گزارش: این خط detected=true را تنظیم می‌کند و به‌عنوان یک نشانهٔ محلی با اطمینان بالا در نظر گرفته می‌شود.

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

ARP فقط برای IPv4 و لایهٔ ۲ کاربرد دارد. MAC صفر می‌تواند تا زمان resolve شدن نشانی موقتی باشد و MAC از نوع broadcast نیز ممکن است مشروع باشد. رابط از نظر ویژگی‌های VPN بررسی نمی‌شود.

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

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

بدون روت

پس از پایدارشدن Wi‑Fi و ایجاد مقدار کمی ترافیک به‌سوی دروازه، بررسی را تکرار کنید. اگر ورودی گیر کرده است، شبکه را یک‌بار خاموش و روشن کنید. فقط برای سبزشدن خط، بدون شناخت نشانی، ARP را flush نکنید.

با روت

کل جدول ARP را پنهان نکنید؛ این کار ناسازگاری در شمارش ایجاد می‌کند و عیب‌یابی LAN را مختل می‌سازد. اگر ماژول VPN ردیف همسایهٔ مصنوعی تولید می‌کند، پیکربندی آن را اصلاح کنید یا از دروازهٔ خارجی استفاده کنید.

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

adb shell cat /proc/net/arp 2>&1
adb shell ip neigh show 2>/dev/null

دو اجرا با فاصلهٔ کوتاه ثبت کنید؛ ممکن است ورودی موقت INCOMPLETE ناپدید شود.

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

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

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

خطرها

flush کردن جدول همسایه اتصال‌های محلی را موقتاً قطع و ترافیک ARP را بیشتر می‌کند.

بازگردانی

Wi‑Fi یا شبکه را دوباره وصل کنید؛ کش همسایه خودکار پر خواهد شد.

سطح شواهد

بالا. با شرایط دقیق MAC راستی‌آزمایی شده است؛ سیاست قدیمی آن را با اطمینان بالا علامت می‌زند، هرچند مثبت کاذب ممکن است.

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

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

سیگنال‌های مرتبط: arp-vpn-interface, interface-enumeration.

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