شناسه:
TIMING_ORACLEدسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: پایین
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
روی arm64، پروب 10 بار این چرخه را انجام میدهد: شمارندهٔ cycle را میخواند، سوکت UDP میسازد، 64 بایت به 127.0.0.1:53 میفرستد، سوکت را میبندد و شمارنده را دوباره میخواند. حداقل، حداکثر و میانگین cycle گزارش میشوند. روی ABI دیگر not_arm64 گزارش میشود. هر دو حالت دادهٔ اطلاعاتی با اطمینان پاییناند.
هنگام اجرای تابع همیشه یک خط تولید میشود: مقادیر عددی روی arm64 یا not_arm64 در غیر این صورت. آستانهٔ «VPN شناسایی شد» وجود ندارد.
این تلهمتری خام کارایی است. بدون خط مبنا، تحلیل آماری و کنترل فرکانس CPU، مقادیر قابل تفسیر نیستند. در نسخهٔ فعلی زمانبندی بر detected یا وضعیت بازبینی اثر ندارد.
تأثیر این خط بر گزارش: این خط اطلاعاتی یا تشخیصی است. برای مقایسهٔ اجراها مفید است، اما بهتنهایی وجود VPN یا دستکاری را ثابت نمیکند.
ده اندازهگیری کافی نیست؛ زمانبندی scheduler، DVFS، throttling حرارتی، شبیهسازی، بار پسزمینه و فرکانس تایمر اثر بسیار بزرگتری از VPN دارند. ارسال loopback از مسیر دادهٔ VPN عبور نمیکند. نتیجه بر پایهٔ cntfrq نرمالسازی نشده است.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
برای سیگنال تشخیصی، ابتدا هیچ چیزی را «اصلاح» نکنید. روی همان دستگاه بدون VPN خط مبنا ثبت کنید و سپس آزمون را با VPN و تحت همان شبکه، دما و بار تکرار کنید. فقط تفاوت تکرارپذیر میان دو مجموعه برای تحلیل مفید است. یک مقدار MTU، زمانبندی یا GSO بهتنهایی مدرک نیست. پیش از هر مجموعه، بار پسزمینه را متوقف کنید، دمای دستگاه را پایدار نگه دارید و دستکم 20 اجرا جمعآوری کنید. توزیعها را مقایسه کنید، نه یک میانگین را.
ماژول روت میتواند این شاخص را تغییر دهد، اما تنظیم آن برای رسیدن به عددی خاص بهآسانی TCP/UDP، DNS، تماسها یا مصرف انرژی را مختل میکند. VPNHide Next ادعا میکند چند پارامتر غیرمستقیم را فیلتر میکند، ولی این قابلیتها باید جدا از پنهانسازی پایهٔ رابط آزموده شوند. پیش از داشتن خط مبنای پاک و روش بازگردانی عملی، بیشترین مجموعهٔ هوکهای هسته را فعال نکنید. برای این مستندات CNTVCT یا رفتار scheduler را جایگزین نکنید؛ چنین کاری روی رمزنگاری، تایمرها و منطق ضد دستکاری اثر میگذارد. برای benchmark از Perfetto یا Simpleperf در build اختصاصی استفاده کنید.
adb shell getprop ro.product.cpu.abi
adb shell dumpsys thermalservice | head -80
adb shell top -b -n 1 | head -30
از مقادیر چند گزارش RKNHardering که در شرایط یکسان ثبت شدهاند استفاده کنید.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
ثابتکردن فرکانس یا governor پردازنده به روت نیاز دارد، گرما را افزایش میدهد و در آزمایش طولانی ممکن است به باتری آسیب بزند. حالت performance را پیوسته فعال نگذارید.
governor و تنظیمات حرارتی پیشفرض را بازگردانید و دستگاه را ریبوت کنید. سیگنال اطلاعاتی به دورزدن نیاز ندارد.
پایین. ده تکرار، CNTVCT_EL0 و INFORMATIONAL_KINDS راستیآزمایی شدهاند.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.VpnNativeDetectorChecker.kt — حکم و اطمینان بررسی عمیق VPN.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: backpressure, gso-ok, general-diagnostics.