RKNHardering Help

شکست ارسال دیتاگرام 1500 بایتی UDP به loopback

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

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

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

این شاخهٔ جایگزین همان پروب است: sendto(127.0.0.1:53, 1500) مقدار -1 برگردانده و جزئیات شامل errno است. برخلاف udp-pmtu-ok، این نوع در مجموعهٔ اطلاعاتی قرار ندارد؛ بنابراین بررسی‌کنندهٔ فعلی یافتهٔ needsReview با اطمینان متوسط می‌سازد.

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

هر خطای sendto()، مستقل از مقدار errno.

معنای نتیجه

خطا روی loopback نامعمول است، اما وجود VPN را ثابت نمی‌کند. علت‌های ممکن شامل هوک SELinux یا فایروال، محدودیت منابع، وضعیت نامعتبر سوکت، رقابت هنگام لغو یا پشتهٔ شبکهٔ تغییریافته است.

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

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

کد errnoها را طبقه‌بندی نمی‌کند و IP_MTU_DISCOVER را تنظیم نمی‌کند. بنابراین EMSGSIZE را نمی‌توان خودکار نتیجهٔ PMTU دانست، در حالی که EACCES و ENOBUFS معنای کاملاً متفاوتی دارند.

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

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

بدون روت

errno دقیق را ثبت کنید، دستگاه را ریبوت و آزمون را بدون VPN، فایروال یا برنامهٔ فیلتر DNS تکرار کنید. فقط برای ناپدیدشدن خطا MTU را پایین نیاورید.

با روت

پیام‌های dmesg و AVC، قواعد iptables/nftables و ماژول‌های هوک سوکت را بررسی کنید. فقط قاعده‌ای را حذف کنید که با مدرک loopback را مسدود می‌کند. به برنامه capability ندهید.

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

adb logcat -d | grep -E 'avc: denied|udp_pmtu|sendto' | tail -80
adb shell iptables-save 2>/dev/null | grep -E 'lo|127[.]0[.]0[.]1|dport 53'
adb shell ip6tables-save 2>/dev/null | grep -E 'lo|::1|dport 53'

برای مقدار errno از جزئیات RKNHardering استفاده کنید؛ ارسال از پوسته با UID دیگری انجام می‌شود.

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

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

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

خطرها

بازنشانی تمام قواعد فایروال مخرب است: ممکن است kill switch مربوط به VPN و حفاظت‌های سیستم را غیرفعال کند. ruleset را سراسری flush نکنید.

بازگردانی

قواعد ذخیره‌شده را بازگردانید یا ماژول مسئول را از مدیر خودش غیرفعال کنید؛ دستگاه را ریبوت و نام‌گشایی DNS را بررسی کنید.

سطح شواهد

متوسط. با شاخهٔ عمومی شکست و ارزیابی پیش‌فرض با اطمینان متوسط راستی‌آزمایی شده است.

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

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

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

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