RKNHardering Help

خلاصهٔ نشانگرهای شبیه‌ساز

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

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

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

این شناسهٔ چتریِ دسته است. evaluateEmulator() فعلی برای propertyهای QEMU، pipeها، goldfish/ranchu، driver، BlueStacks و پروفایل build شناسه‌های مشخص تعیین می‌کند. در حال حاضر سطر مثبت مستقلی با EMULATOR_INDICATORS تولید نمی‌شود.

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

خود این شناسه تولیدکننده‌ای ندارد؛ به‌عنوان ورودی پایدار مستندات و جای‌نگهدار برای تجمیع آینده استفاده می‌شود.

معنای نتیجه

سطرهای فرزند را ارزیابی کنید. نبود همهٔ نشانگرهای فهرست‌شده ثابت نمی‌کند دستگاه فیزیکی است؛ شبیه‌ساز مدرن ممکن است نشانه‌های استاندارد را پنهان کند.

تأثیر این خط بر گزارش: این یک شناسهٔ چتری یا پشتیبان است. گروهی از خطوط را به مستندات پیوند می‌دهد، اما همیشه تولیدکنندهٔ مثبت مستقلی ندارد.

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

این فهرست attestation سخت‌افزاری، حسگرها، telephony، زمان‌بندی گرافیک یا تحلیل کامل fingerprint را شامل نمی‌شود.

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

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

بدون روت

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

با روت

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

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

adb shell getprop ro.kernel.qemu
adb shell getprop ro.hardware
adb shell getprop ro.product.board
adb shell getprop ro.build.fingerprint
adb shell ls -l /dev/qemu_pipe /dev/socket/qemud 2>/dev/null

معیارهای دقیق را در صفحهٔ جداگانهٔ هر سیگنال فرزند ببینید.

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

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

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

خطرها

spoof کردن مجموعهٔ بزرگی از propertyهای build می‌تواند OTA، سرویس‌های Play و سازگاری برنامه‌ها را مختل کند.

بازگردانی

ماژول spoof یا قواعد property را حذف کنید و به snapshot شبیه‌ساز یا image استاندارد بوت بازگردید.

سطح شواهد

سرویسی. کاتالوگ و evaluateEmulator() بررسی شده‌اند؛ در نسخهٔ 2.10.0 شناسهٔ چتری به findingهای مثبت اختصاص داده نمی‌شود.

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

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

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

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