IP_RECVERRشناسه:
IP_RECVERRدسته: آثار VPN و سوکتها وضعیت در RKNHardering 2.10.0: شناسه برای سازگاری حفظ شده است؛ در 2.10.0 تولیدکنندهٔ جداگانهای ندارد نقش در حکم نهایی: رجیستری/سازگاری
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
detectIpRecvErr() فقط تلاش میکند IP_RECVERR را فعال کند. در صورت موفقیت چیزی تولید نمیکند. در EACCES/EPERM یا ENOPROTOOPT، نتیجهٔ unavailable|ip_recverr|... میسازد که Kotlin آن را به SYSCALL_UNAVAILABLE نگاشت میکند، نه IP_RECVERR. بنابراین شناسهٔ مثبت فعلاً ظاهر نمیشود.
تولیدکنندهٔ جداگانهای برای ip_recverr وجود ندارد. خطای دسترسپذیری به شناسهٔ مجاور تعلق دارد.
خط IP_RECVERR در رابط کاربری معمولاً «یافت نشد» است. این را نه نشانهٔ پشتیبانی و نه نبود VPN بدانید؛ syscall-unavailable را ببینید.
تأثیر این خط بر گزارش: این شناسه در کاتالوگ و رابط کاربری باقی مانده است، اما نسخهٔ 2.10.0 خط مثبت جداگانهای از این نوع تولید نمیکند. معمولاً یک سیگنال مجاور و دقیقتر این حالت را پوشش میدهد.
کاتالوگ و توضیح قدیمی از طراحی گستردهتری باقی ماندهاند. کد صف خطا را نمیخواند و خطاهای PMTU را تحلیل نمیکند.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
برای این شناسه چیزی را تغییر ندهید. اگر نتیجهٔ unavailable ظاهر شد، errno و نسخهٔ ROM را ثبت کنید.
فقط برای موفقشدن setsockopt به برنامه CAP_NET_ADMIN ندهید: IP_RECVERR معمولاً به آن نیاز ندارد و مجوز گستردهتر سیگنالهای جدید میسازد. policy را فقط برای باگ تأییدشدهٔ پلتفرم تغییر دهید.
rg -n 'detectIpRecvErr|ip_recverr|SYSCALL_UNAVAILABLE' app/src/main
در زمان اجرا از جزئیات syscall-unavailable استفاده کنید.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
تضعیف policy سوکت یا SELinux برای یک پروب تشخیصی سطح حمله را افزایش میدهد.
فقط قاعدهٔ sepolicy یا capability افزودهشده را حذف و دستگاه را ریبوت کنید.
رجیستری/سازگاری. شاخههای EACCES/EPERM/ENOPROTOOPT و نگاشت unavailable راستیآزمایی شدهاند.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.NativeSignsChecker.kt — منطق اصلی حکم بومی/قدیمی.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.NativeSignalId.kt — رجیستری کامل شناسهها.سیگنالهای مرتبط: syscall-unavailable, udp-pmtu-fail.