شناسه:
LSPOSEDدسته: هوکها و یکپارچگی فرایند وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: متوسط
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
پروب قدیمی فایل مسیرهای /data/adb/lspd، /data/adb/modules/lsposed، /data/misc/lspd و /data/data/org.lsposed.manager را بررسی میکند. مسیر قابلدسترسی نتیجهٔ lsposed میسازد؛ سیاست قدیمی آن را یافتهٔ بازبینی با اطمینان متوسط میداند، نه تشخیص مستقیم.
یکی از چهار مسیر ثابت وجود داشته باشد و برای برنامه قابل مشاهده باشد.
این وضعیت اثر یک چارچوب یا نصب قدیمی است. نسخههای جدید Vector ممکن است نامهای دیگری داشته باشند و مسیر نیز ممکن است پس از حذف چارچوب باقی بماند.
تأثیر این خط بر گزارش: این خط بهتنهایی حکم نهایی صادر نمیکند، اما needsReview=true را تنظیم و شاهدی با اطمینان متوسط اضافه میکند.
بررسی فقط مبتنی بر مسیر است و ثابت نمیکند RKNHardering در دامنهٔ چارچوب قرار دارد. برعکس، چارچوب ممکن است بدون مسیر ثابت قابل مشاهده کار کند، اما همچنان در بررسیهای maps یا یکپارچگی کتابخانه دیده شود.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
بدون روت، بهترین گزینه APK پاک و دریافتشده از منبع مورداعتماد است؛ بدون بستهبندی مجدد، LSPatch، Frida Gadget، مجازیسازی یا Xposed بدون روت. انتقال برنامه به «فضای دوم» فرایند آن را خودکار پاک نمیکند: کانتینر ممکن است کتابخانههای خودش را تزریق کند و ناسازگاریهای بیشتری باقی بگذارد. چارچوب بدون روت یا نسخهٔ بستهبندیشده را با روند حذف عادی خودش پاک و یک APK سالم نصب کنید.
روی دستگاه روتشده، برنامهٔ هدف را در دامنهٔ Xposed/Vector قرار ندهید و ماژول Zygisk را بیدلیل داخل آن بار نکنید. برای پنهانسازی VPN، معماریای را ترجیح دهید که پالایش Java در system_server و پالایش بومی در هسته انجام شود. DenyList/App Profile، NoHello، Zygisk Next، SUSFS و ابزارهای مشابه ممکن است برخی ردها را کاهش دهند، اما هیچکدام حفاظت همزمان در برابر بررسیهای maps، linker، mount و syscall خام را تضمین نمیکنند. برای VPNHide، دامنه فقط باید System Framework را دربر گیرد، نه RKNHardering. چارچوب فعلی را از انتشارهای Vector دریافت کنید؛ مخزن اصلی LSPosed صرفاً منبع آرشیوی است.
adb shell 'for p in /data/adb/lspd /data/adb/modules/lsposed /data/misc/lspd /data/data/org.lsposed.manager; do [ -e "$p" ] && echo "$p"; done'
همچنین hook-markers و library-integrity را بررسی کنید.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
حذف چارچوب بدون غیرفعالکردن ماژولهایش ممکن است سیستم را در وضعیتی نیمهپیکربندیشده رها کند. قراردادن برنامهٔ هدف در دامنه، ردهای درونفرایندی ایجاد میکند.
ماژول را غیرفعال کنید، دستگاه را ریبوت و سپس چارچوب را از طریق مدیر عادی آن حذف کنید. اگر دستگاه وارد حلقهٔ بوت شد، از safe mode مدیر روت استفاده کنید.
متوسط. چهار مسیر و سیاست قدیمی اطمینان متوسط راستیآزمایی شدهاند.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.NativeSignsChecker.kt — منطق اصلی حکم بومی/قدیمی.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: hook-markers, hook-property, library-integrity, vpnhide.