RKNHardering Help

دستگاه‌ها و سوکت‌های QEMU/Genymotion

شناسه: EMULATOR_QEMU_PIPE دسته: شبیه‌سازی، پروفایل‌ها و جداسازی وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: متوسط

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

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

پروب مسیرهای /dev/qemu_pipe، /dev/socket/qemud، /dev/socket/genyd و /dev/socket/baseband_genyd را بررسی می‌کند. قابل‌دسترسی‌بودن هر مسیر، qemu_pipe و یک finding بازبینی با اطمینان زیاد تولید می‌کند.

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

access(F_OK) برای یکی از چهار مسیر موفق شود.

معنای نتیجه

این یک نشانگر قوی node دستگاه شبیه‌ساز است. برخلاف propertyِ build، زیرساخت واقعی میان مهمان و میزبان را نشان می‌دهد.

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

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

SELinux ممکن است مسیر را از برنامه پنهان کند و از نظر نظری یک دستگاه آزمایشی vendor می‌تواند سوکت مشابهی داشته باشد. نبود این مسیرها hypervisor دیگری را رد نمی‌کند.

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

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

بدون روت

برای پرهیز از این دسته نشانه‌ها، از دستگاه فیزیکی با build تولیدی استفاده کنید. propertyهای QEMU، نشانگرهای goldfish/ranchu، دستگاه‌های ویژه و fingerprint ساخت بخشی از محیط‌اند؛ برنامهٔ عادی نمی‌تواند بدون تغییر سیستمی آن‌ها را به‌طور سازگار عوض کند. تلفن ابری یا clone سازنده را نیز محیطی جدا بدانید و با خط مبنای دستگاه فیزیکی مقایسه کنید.

با روت

spoof کردن چند مقدار getprop شبیه‌ساز را به دستگاه فیزیکی تبدیل نمی‌کند: driverها، nodeهای /dev، پروفایل سخت‌افزار، ABI و رفتار هسته باقی می‌مانند. ماژول‌های روت برای spoof ممکن است یک نشانگر را حذف کنند و هم‌زمان ناسازگاری هوک، property یا library بسازند. این کار برای آزمایش توسعه قابل‌قبول است، اما برای نتیجهٔ معتبر باید RKNHardering روی دستگاه واقعی اجرا شود. bind-mount کردن مسیر خالی یک نشانگر را پنهان می‌کند، ولی اثر mount جدید می‌سازد و driverها را تغییر نمی‌دهد.

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

adb shell ls -l /dev/qemu_pipe /dev/socket/qemud /dev/socket/genyd /dev/socket/baseband_genyd 2>/dev/null

در صورت وجود build قابل‌اشکال‌زدایی، دسترسی را مشخصاً از زمینهٔ برنامه بررسی کنید.

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

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

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

خطرها

حذف یا mask کردن QEMU pipe ارتباط شبیه‌ساز با میزبان، telephony و توابع خاموش‌کردن/کنترل را خراب می‌کند.

بازگردانی

snapshot را بازیابی کنید یا ماژول پنهان‌سازی mount را حذف و AVD را دوباره اجرا کنید.

سطح شواهد

متوسط. آرایهٔ kPipePaths بررسی شده است؛ بررسی‌کننده سطح اطمینان زیاد می‌دهد.

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

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

سیگنال‌های مرتبط: emulator-qemu-property, emulator-qemu-driver, emulator-build-profile.

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