شناسه:
GETSOCKNAME_LEAKدسته: آثار VPN و سوکتها وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: بالا
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
detectGetsocknameLeak() یک سوکت AF_INET/SOCK_DGRAM میسازد و بلافاصله، بدون bind() یا connect()، getsockname() را فراخوانی میکند. اگر نشانی 0.0.0.0 نباشد و در بازهٔ 10/8، 172.16/12 یا 192.168/16 قرار گیرد، getsockname_leak همراه با IP تولید میشود.
سوکت UDP بدون اتصال و بدون bind بلافاصله پس از ساخت نشانی خصوصی IPv4 غیرصفر داشته باشد.
بررسیکننده این وضعیت را شاخصی با اطمینان بالا از interposition نامعمول سوکت یا رفتار غیرعادی محیط میداند، زیرا سوکت عادی Linux معمولاً تا bind یا connect روی 0.0.0.0 میماند. خود IP خصوصی ثابت نمیکند نشانی VPN است.
تأثیر این خط بر گزارش: این خط detected=true را تنظیم میکند و بهعنوان یک نشانهٔ محلی با اطمینان بالا در نظر گرفته میشود.
برچسب «نشت IP مربوط به VPN» از چیزی که پروب واقعاً ثابت میکند قویتر است. نشانی خصوصی میتواند متعلق به Wi‑Fi یا LAN فیزیکی باشد. احتمالاً سیگنال روی Android عادی وجود ندارد؛ اگر ظاهر شد، بازتولیدش کنید و هوک یا virtualization را بررسی کنید.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
ابتدا آزمون را با APK release روی دستگاه پاک تکرار کنید. virtualization بدون روت، LSPatch، SDKهای VPN و sandboxهای شبکه را غیرفعال کنید. فقط برای این سیگنال نشانی LAN را تغییر ندهید.
RKNHardering را از هوکهای درونفرایندی Zygisk/Xposed خارج و یکپارچگی libc/socket را بررسی کنید. IP خصوصی را با IP عمومی جایگزین نکنید؛ خط مبنای درست پیش از bind/connect برابر 0.0.0.0 است.
برای بازتولید دقیق، آزمون بومی حداقلی بسازید:
int fd = socket(AF_INET, SOCK_DGRAM, 0);
struct sockaddr_in a = {}; socklen_t n = sizeof(a);
getsockname(fd, (struct sockaddr *)&a, &n);
نشانی مورد انتظار پیش از bind/connect برابر 0.0.0.0 است. فرمان ss این پروب را بازتولید نمیکند.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
هوک سراسری getsockname() برنامهها را خراب میکند و ممکن است نشت شبکه بسازد. libc سیستم را تغییر ندهید.
آخرین تغییر را برگردانید: ماژول یا قاعدهٔ افزودهشده را با مدیر معمول خودش غیرفعال کنید، دستگاه را دوباره راهاندازی کنید و اسکن خط مبنا را تکرار کنید. روی وضعیتی ناشناخته هوک دیگری لایه نکنید.
بالا. نبود bind/connect و بازههای دقیق خصوصی راستیآزمایی شدهاند؛ بررسیکنندهٔ فعلی این نوع را اطمینان بالا میداند.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.VpnNativeDetectorChecker.kt — حکم و اطمینان بررسی عمیق VPN.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: so-bindtodevice, library-integrity, hook-markers.