شناسه:
BACKPRESSUREدسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: پایین
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
پروب آگاه از لغو تلاش میکند با MSG_DONTWAIT تا 50,000 دیتاگرام 1,400 بایتی به 127.0.0.1:53 بفرستد. در نخستین خطا متوقف میشود و شمار ارسالشده/کل، زمان سپریشده و MB/s برآوردی را گزارش میکند. نتیجه اطلاعاتی است.
اگر اسکن لغو نشده و سوکت ساخته شده باشد، خط معمولاً با هر تعداد فراخوانی موفق send تولید میشود؛ آستانهای وجود ندارد.
throughput محلی مسیر ارسال و نقطهٔ وقوع backpressure را نشان میدهد. تحویل را تأیید نمیکند و throughput اینترنت یا VPN را نمیسنجد.
تأثیر این خط بر گزارش: این خط اطلاعاتی یا تشخیصی است. برای مقایسهٔ اجراها مفید است، اما بهتنهایی وجود VPN یا دستکاری را ثابت نمیکند.
رفتار loopback، بافرهای سوکت، بار CPU، زمانبندی و دورریختن بسته همگی روی نتیجه اثر دارند. بار حدود 70 مگابایت در فضای کاربر فشار محسوس اما کوتاهی ایجاد میکند. اگر عملیات لغو شود، ممکن است خط وجود نداشته باشد.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
برای سیگنال تشخیصی، ابتدا هیچ چیزی را «اصلاح» نکنید. روی همان دستگاه بدون VPN خط مبنا ثبت کنید و سپس آزمون را با VPN و تحت همان شبکه، دما و بار تکرار کنید. فقط تفاوت تکرارپذیر میان مجموعهها برای تحلیل مفید است. یک مقدار MTU، زمانبندی یا GSO بهتنهایی مدرک نیست. روی دستگاه ضعیف یا داغ، تکرارهای زیاد را پشت سر هم اجرا نکنید. پس از خنکشدن دستگاه سه تا پنج مجموعه کافی است.
ماژول روت میتواند این معیار را تغییر دهد، اما تنظیم برای رسیدن به عددی خاص بهآسانی TCP/UDP، DNS، تماسها یا مصرف انرژی را مختل میکند. VPNHide Next ادعا میکند چند پارامتر غیرمستقیم را فیلتر میکند، ولی این قابلیتها باید جدا از پنهانسازی پایهٔ رابط آزموده شوند. پیش از داشتن خط مبنای پاک و مسیر بازگردانی عملی، بیشترین مجموعهٔ هوکهای هسته را فعال نکنید. فقط برای ساختن عددی زیبا، بافرهای سراسری سوکت را افزایش یا فایروال را غیرفعال نکنید. هر تغییر باید بخشی از benchmark جداگانه باشد، نه ضدتشخیص.
adb shell dumpsys thermalservice | head -80
adb shell 'cat /proc/net/softnet_stat 2>/dev/null | head'
مقادیر sent/time را میان حالتهای همارز مقایسه کنید، اما آستانهٔ فرضی «عادی» تعریف نکنید.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
سیل تکراری به CPU، باتری و پشتهٔ شبکهٔ محلی فشار میآورد. روی بعضی دستگاهها ممکن است کندی موقت یا فشار watchdog ایجاد کند.
اسکن را متوقف کنید، برنامه را بهاجبار ببندید و بگذارید دستگاه خنک شود. پروب هیچ تنظیم پایداری را تغییر نمیدهد.
پایین. حلقهٔ loopback با 50k × 1,400 بایت، بررسیهای لغو و نگاشت اطلاعاتی راستیآزمایی شدهاند.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.VpnNativeDetectorChecker.kt — حکم و اطمینان بررسی عمیق VPN.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: timing-oracle, udp-pmtu-ok, gso-ok.