NetworkInterface و getifaddrs بومیشناسه:
JVM_NATIVE_MISMATCHدسته: رابطها وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: ترکیبی
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
بررسیکننده دو تصویر مستقل میسازد: getifaddrs() در C/C++ و NetworkInterface.getNetworkInterfaces() در Java. مجموعهٔ نامها، شاخص یک رابط یکسان و مجموعهٔ نشانیها را با هم مقایسه میکند. نام شبیه VPN که فقط در یکی از دو لایه دیده شود اطمینان بالا دارد؛ تفاوت عادی در شاخص یا نشانی یک یافتهٔ بازبینی با اطمینان متوسط ایجاد میکند.
بالا: رابط شبیه VPN فقط برای کد بومی یا فقط برای JVM قابل مشاهده باشد. متوسط: هر رابط گمشدهٔ دیگر، ifindex متفاوت یا مجموعههای نشانی غیرخالی و ناسازگار.
این سیگنال اغلب بیش از آنکه خود VPN را نشان دهد، پنهانسازی ناقص یا هوکی را نشان میدهد که فقط روی یکی از APIها اعمال شده است. به همین دلیل، هوک صرفاً Java بدون پوشش بومی یا هوک صرفاً libc بدون پوشش framework یک اوراکل میسازد.
تأثیر این خط بر گزارش: همین شناسه هم برای خلاصههای اطلاعاتی و هم برای خطوط مشکوک استفاده میشود. نتیجه به جزئیات همان خط و شاخهٔ بررسیکننده بستگی دارد.
دو تصویر پشت سر هم گرفته میشوند؛ بنابراین هنگام handover، جابهجایی Wi‑Fi/دادهٔ همراه، تغییرات CLAT یا تغییر کوتاه نشانی IPv6 امکان رقابت واقعی وجود دارد. آزمون را روی شبکهای پایدار تکرار کنید.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
شبکه را پایدار کنید و هنگام آزمون از جابهجایی میان Wi‑Fi و دادهٔ همراه جلوگیری کنید. اگر VPN روی همان دستگاه باقی بماند، نرمافزار عادی بدون روت نمیتواند دو API سیستمی را وادار کند رابط برنامهای دیگر را بهطور سازگار پنهان کنند؛ دروازهٔ خارجی علت اصلی را حذف میکند.
هر دو لایه لازماند: فیلتر framework در system_server و فیلتر بومی/هسته. خود RKNHardering را در دامنهٔ Xposed قرار ندهید؛ ممکن است فهرست Java را پاک کند و همزمان هوکهای فرایندی بیفزاید. پس از تغییر، نامها، شاخصها و نشانیها را بررسی کنید، نه فقط نبود tun0 را.
adb shell ip -o address show
adb shell ip -o link show
برای مقایسهٔ دقیق از جزئیات داخلی RKNHardering یا یک APK آزمایشی سفارشی استفاده کنید که در یک فرایند هم NetworkInterface و هم JNI getifaddrs() را فراخوانی کند. فرمانهای پوسته فضای نام برنامه را بهطور کامل بازتولید نمیکنند.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
جعل ناقص از نبود جعل آشکارتر است، زیرا تناقضی قابل مشاهده ایجاد میکند. هوکهای ناسازگار هسته میتوانند کتابخانههای شبکه را خراب کنند و باعث گیرکردن فهرستبرداری شوند.
آخرین تغییر را برگردانید: ماژول یا قاعدهٔ افزودهشده را با مدیر معمول خودش غیرفعال کنید، دستگاه را دوباره راهاندازی کنید و اسکن خط مبنا را تکرار کنید. روی وضعیتی ناشناخته هوک دیگری لایه نکنید.
ترکیبی. با evaluateJvmNativeMismatch() راستیآزمایی شده است؛ شاخههای رابط VPN گمشده اطمینان بالا دارند و ناسازگاری شاخص/نشانی اطمینان متوسط.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
NativeSignsChecker.kt — منطق اصلی حکم بومی/قدیمی.native_signs_probe.cpp — پیادهسازی پروب بومی.NetworkInterfacePatterns.kt — قواعد نام رابطها.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: interface-enumeration, getifaddrs-vpn, library-integrity, trim-oracle.