شناسه:
SO_BINDTODEVICEدسته: آثار VPN و سوکتها وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: متوسط
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
تابع detectSocketLeaks() در واقع SO_BINDTODEVICE را فراخوانی نمیکند. یک سوکت UDP/IPv4 بدون اتصال میسازد، getsockname() را اجرا میکند و فقط زمانی so_bindtodevice|local_ip=... میسازد که نشانی محلی صفر نباشد. سوکت بدون اتصال معمولاً 0.0.0.0 برمیگرداند، بنابراین این خط نادر است. سیاست قدیمی آن را یافتهٔ بازبینی با اطمینان متوسط میداند.
سوکت UDP بدون اتصال بلافاصله یک نشانی IPv4 محلی غیرصفر داشته باشد.
این هویت سوکت مشکوک است، اما نام صفحه از نظر تاریخی دقیق نیست. بررسی واقعی SO_BINDTODEVICE در bindtodevice-leak مستند شده است.
تأثیر این خط بر گزارش: این خط بهتنهایی حکم نهایی صادر نمیکند، اما needsReview=true را تنظیم و شاهدی با اطمینان متوسط اضافه میکند.
در Linux استاندارد، نشانی پس از connect() یا bind() انتخاب میشود؛ بنابراین پروب فعلی معمولاً چیزی تولید نمیکند. container یا هوک میتواند این رفتار را تغییر دهد.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
وقتی خط وجود ندارد، هیچ تغییر شبکهای لازم نیست. اگر ظاهر شد، آزمایش را روی دستگاه پاک تکرار و مجازیسازی یا SDKهای proxy را بررسی کنید.
بهجای پوشاندن جزئیات، هوکی را پیدا کنید که سوکت را خودکار bind یا connect میکند. برنامهٔ هدف را از ماژولهای درونفرایندی خارج کنید.
بازسازی به یک آزمایش بومی کوچک نیاز دارد: socket(AF_INET, SOCK_DGRAM) و سپس getsockname() بدون bind() یا connect(). فرمان ss سوکت کوتاهعمر و ثبتنشده را نشان نمیدهد. در کد منبع:
rg -n 'detectSocketLeaks|so_bindtodevice' app/src/main/cpp/native_signs_probe.cpp
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
تغییر سراسری رفتار bind سوکت، مسیریابی برنامهها را خراب میکند.
آخرین تغییر را برگردانید: ماژول یا قاعدهٔ افزودهشده را از مدیر معمولش غیرفعال کنید، دستگاه را ریبوت و اسکن خط پایه را تکرار کنید. روی وضعیت ناشناخته هوک دیگری اضافه نکنید.
متوسط. پیادهسازی واقعی راستیآزمایی شده است؛ این مستند ناسازگاری نام تاریخی را اصلاح میکند.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.NativeSignsChecker.kt — منطق اصلی حکم بومی/قدیمی.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: bindtodevice-leak, getsockname-leak.