SIOCSHWTSTAMP روی loopbackشناسه:
HW_TIMESTAMPدسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: پایین
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
پروب برای رابط lo و با HWTSTAMP_TX_ON، ioctl(SIOCSHWTSTAMP) را فراخوانی میکند. فقط rc=0 نتیجهٔ hw_timestamp|lo configured را تولید میکند. جداگانه تلاش میکند SO_TIMESTAMPING نرمافزاری را فعال کند، اما نتیجهٔ آن گزارش نمیشود. یافته دادهٔ اطلاعاتی با اطمینان پایین است.
هسته به یک سوکت برنامهٔ عادی اجازه دهد SIOCSHWTSTAMP را روی loopback تنظیم کند.
این رفتار مجوزهای درایور و هسته را بازتاب میدهد، نه VPN را. در بسیاری سامانهها loopback از timestamp سختافزاری پشتیبانی نمیکند یا عملیات به دسترسی ویژه نیاز دارد؛ بنابراین نبود خط عادی است.
تأثیر این خط بر گزارش: این خط اطلاعاتی یا تشخیصی است. برای مقایسهٔ اجراها مفید است، اما بهتنهایی وجود VPN یا دستکاری را ثابت نمیکند.
پروب پیکربندی مذاکرهشده را نمیخواند، timestamp دریافت نمیکند و رابط تونل یا فیزیکی را نمیآزماید. موفقیت ممکن است خاص هستهٔ سازنده یا یک هوک باشد.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
برای سیگنال تشخیصی، ابتدا هیچ چیزی را «اصلاح» نکنید. روی همان دستگاه بدون VPN خط مبنا ثبت کنید و سپس آزمون را با VPN و تحت همان شبکه، دما و بار تکرار کنید. فقط تفاوت تکرارپذیر میان مجموعهها برای تحلیل مفید است. یک مقدار MTU، زمانبندی یا GSO بهتنهایی مدرک نیست. تغییری لازم نیست. با دستگاه پاک دارای همان میانافزار مقایسه کنید.
ماژول روت میتواند این معیار را تغییر دهد، اما تنظیم برای رسیدن به عددی خاص بهآسانی TCP/UDP، DNS، تماسها یا مصرف انرژی را مختل میکند. VPNHide Next ادعا میکند چند پارامتر غیرمستقیم را فیلتر میکند، ولی این قابلیتها باید جدا از پنهانسازی پایهٔ رابط آزموده شوند. پیش از داشتن خط مبنای پاک و مسیر بازگردانی عملی، بیشترین مجموعهٔ هوکهای هسته را فعال نکنید. به برنامه CAP_NET_ADMIN ندهید. برای benchmark معتبر timestamp از ابزار آزمایشی ممتاز جداگانه روی دستگاه آزمایشی استفاده کنید.
adb shell uname -r
adb shell 'ethtool -T lo 2>/dev/null || true'
ممکن است ethtool در دسترس نباشد؛ خود پروب بومی نتیجهٔ دقیق SIOCSHWTSTAMP را گزارش میکند.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
تغییر درایورها یا مجوزهای timestamp ممکن است روی PTP، ثبت گزارش و کارایی شبکه اثر بگذارد. این سیگنال اطلاعاتی به دورزدن نیاز ندارد.
capability یا قاعدهٔ sepolicy آزمایشی را حذف و دستگاه را ریبوت کنید. اگر هسته تعویض شده است، هستهٔ اصلی را بازگردانید.
پایین. با شرط rc==0 برای SIOCSHWTSTAMP و نگاشت اطلاعاتی راستیآزمایی شده است.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.VpnNativeDetectorChecker.kt — حکم و اطمینان بررسی عمیق VPN.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: timing-oracle, gso-ok, normal-pmtu.