RKNHardering Help

مبدأ نمادهای کلیدی libc

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

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

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

کد C++ برای getifaddrs، if_nametoindex، socket، fopen، inet_ntop و ioctl توابع dlsym(RTLD_DEFAULT) و dladdr() را فراخوانی می‌کند. اگر نمادی وجود نداشته باشد یا نام کتابخانهٔ آن شامل libc.so، libc++ یا libm.so نباشد، مشکوک در نظر گرفته می‌شود. هر خط از این نوع یافتهٔ بازبینی با اطمینان متوسط ایجاد می‌کند.

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

نمادی یافت نشود یا نشانی آن به کتابخانه‌ای غیرمنتظره resolve شود.

معنای نتیجه

این سیگنال بعضی شکل‌های interposition در PLT/ELF و wrapperهای غیراستاندارد libc را تشخیص می‌دهد. وجود VPN را ثابت نمی‌کند، اما می‌تواند توضیح دهد چرا نتایج API دست‌کاری شده‌اند.

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

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

هوک inline داخل libc.so اصلی، trampolineها و syscallهای خام ممکن است نتیجهٔ dladdr را تغییر ندهند. کتابخانهٔ سازنده یا sanitizer در build اشکال‌زدایی نیز می‌تواند مشروع باشد.

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

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

بدون روت

از APK رسمی و بدون بسته‌بندی مجدد، sanitizer یا loader شخص ثالث استفاده کنید. اگر این build اشکال‌زدایی خودتان است، آزمون را با build انتشار تکرار کنید. مجازی‌سازی بدون روت یا LSPatch باید کاملاً از فرایند حذف شود، نه اینکه فقط تغییر نام داده شود.

با روت

RKNHardering را از دامنهٔ Zygisk/Xposed خارج کنید. برای پنهان‌سازی VPN از پس‌زمینهٔ خارج‌ازفرایند در system_server/هسته استفاده کنید. پس از ریبوت راستی‌آزمایی کنید، چون force-stop چارچوب را از zygote خارج نمی‌کند.

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

جزئیات داخلی برنامه نماد، نشانی و کتابخانه را نشان می‌دهد. یک harness بومی می‌تواند فراخوانی‌های dlsym/dladdr را تکرار کند؛ خروجی عادی ldd برای APK فضای نام زمان اجرا را بازتولید نمی‌کند. فرمان مفید برای توسعه‌دهنده:

rg -n 'nativeLibraryIntegrity|dlsym|dladdr' app/src/main/cpp/native_signs_probe.cpp

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

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

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

خطرها

جایگزینی libc سیستم یا تغییر پیکربندی linker می‌تواند دستگاه را غیرقابل بوت کند. برای «اصلاح» نشانی‌ها روی تلفن تولیدی وصلهٔ باینری اعمال نکنید.

بازگردانی

آخرین تغییر را برگردانید: ماژول یا قاعدهٔ افزوده‌شده را با مدیر معمول خودش غیرفعال کنید، دستگاه را دوباره راه‌اندازی کنید و اسکن خط مبنا را تکرار کنید. روی وضعیتی ناشناخته هوک دیگری لایه نکنید.

سطح شواهد

متوسط. فهرست دقیق شش نماد و allowlist کتابخانه‌ها در evaluateLibraryIntegrity() راستی‌آزمایی شده است.

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

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

سیگنال‌های مرتبط: hook-markers, rwx-memory-regions, jvm-native-mismatch.

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