RKNHardering Help

بازگشت EACCES از ارسال UDP روی loopback با TTL=1

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

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

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

پروب یک سوکت عادی UDP می‌سازد، IP_TTL=1 و timeout ارسال 100 میلی‌ثانیه را تنظیم و سپس 64 بایت به 127.0.0.1:33434 می‌فرستد. خط فقط وقتی ظاهر می‌شود که sendto() مقدار -1 را مشخصاً با EACCES برگرداند. پاسخ ICMP، hop یا traceroute خارجی اندازه‌گیری نمی‌شود.

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

بازگشت EACCES از sendto() محلی UDP پس از تنظیم TTL روی 1.

معنای نتیجه

این نتیجه ردشدن توسط policy یا فایروال در همان مسیر سوکت را نشان می‌دهد. encapsulation مربوط به VPN را ثابت نمی‌کند. بررسی‌کننده یافتهٔ بازبینی با اطمینان متوسط می‌سازد.

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

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

نام «traceroute» تقریبی است: مقصد loopback است، سوکت raw استفاده نمی‌شود و کشف hop رخ نمی‌دهد. EPERM، ENETUNREACH و errnoهای دیگر اصلاً گزارش نمی‌شوند.

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

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

بدون روت

برای اجرای کنترل، فایروال محلی شخص ثالث، DNS و مؤلفه‌های VPN را غیرفعال و ثبت کنید آیا EACCES ناپدید می‌شود. تلاش نکنید traceroute خارجی را فعال کنید؛ بررسی محلی است.

با روت

قواعد مختص UID در iptables/nftables و پیام‌های AVC را بررسی کنید. ruleset را flush نکنید؛ قاعدهٔ دقیق اعمال‌شده به UDP/33434 روی loopback یا ترافیک دارای نشان TTL را پیدا کنید.

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

adb logcat -d | grep -E 'avc: denied|33434|traceroute' | tail -80
adb shell su -c 'iptables-save | grep -E "33434|owner|uid|lo"; ip6tables-save | grep -E "33434|owner|uid|lo"'

ممکن است بستهٔ پوسته عبور کند، در حالی که UID برنامه مسدود است.

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

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

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

خطرها

flush سراسری فایروال ممکن است ترافیک را افشا، kill switch را غیرفعال و امنیت را تضعیف کند. فقط قاعدهٔ تأییدشده و مختص UID را تغییر دهید.

بازگردانی

ruleset یا ماژول ذخیره‌شده را بازگردانید و فایروال و VPN را دوباره راه‌اندازی کنید. DNS و kill switch را راستی‌آزمایی کنید.

سطح شواهد

متوسط. مقصد loopback، TTL=1 و تنها شاخهٔ EACCES راستی‌آزمایی شده‌اند؛ به‌طور پیش‌فرض متوسط.

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

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

سیگنال‌های مرتبط: udp-pmtu-fail, syscall-unavailable, inet-diag-denied.

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