شناسه:
GSO_OKدسته: مسیرها و پشتهٔ شبکه وضعیت در RKNHardering 2.10.0: تولیدکنندهٔ بومی وجود دارد، اما تجزیهگر فعلی رابط کاربری این خط را حذف میکند نقش در حکم نهایی: رجیستری/سازگاری
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
UDP_SEGMENT=1200 پذیرفته میشود و سپس sendto() با موفقیت 4,800 بایت به درگاه 53 روی loopback میفرستد. در نتیجهٔ بومی، kind جزئیات ندارد؛ بنابراین تجزیهگر فقط وقتی میتواند gso_ok را دریافت کند که ردیف با جداکننده serial شود. کد فعلی C++ دقیقاً gso_ok را بدون | اضافه میکند، در حالی که parseRow() در خط لولهٔ deep به kind و جزئیات غیرخالی پس از جداکنندهٔ دوم نیاز دارد. با پیشوند، ردیف به vdet|gso_ok تبدیل میشود و تجزیهگر فعلی Kotlin آن را دور میاندازد.
در سطح C++، هم setsockopt و هم sendto موفقاند. در سطح رابط کاربری نسخهٔ 2.10.0، تولیدکننده به یافته تبدیل نمیشود، زیرا قالب فیلد جزئیات ندارد.
نمایشندادن خط بهمعنای شکست GSO نیست؛ این نتیجهٔ ناسازگاری فعلی میان قالب تولیدکننده و تجزیهگر است. پس از اصلاح قالب، سیگنال باید همچنان اطلاعاتی باقی بماند.
تأثیر این خط بر گزارش: این شناسه در کاتالوگ و رابط کاربری باقی مانده است، اما نسخهٔ 2.10.0 خط مثبت جداگانهای از این نوع تولید نمیکند. معمولاً یک سیگنال مجاور و دقیقتر این حالت را پوشش میدهد.
جدا از شکاف تجزیهگر، GSO روی loopback مسیر VPN را اندازه نمیگیرد و offload سختافزاری را تأیید نمیکند. خود موفقیت نتیجهٔ ضدتشخیص نیست.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
فقط بهدلیل غیبت خط در رابط کاربری چیزی را تغییر ندهید. برای توسعه، خروجی C++ را به gso_ok|sent=4800 تغییر دهید یا جزئیات خالی را در تجزیهگر بپذیرید و آزمون واحد اضافه کنید.
روت نه لازم است و نه مناسب. فقط برای ظاهرشدن یک خط تشخیصی هسته را patch نکنید.
rg -n 'gso_ok|parseRow|indexOf' app/src/main/cpp/native_signs_probe.cpp app/src/main/java/com/notcvnt/rknhardering/checker/VpnNativeDetectorChecker.kt
پس از اصلاح، آزمون واحد بررسیکننده را اجرا کنید و روی دستگاه واقعی دارای پشتیبانی UDP_SEGMENT بیازمایید.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
تغییر تجزیهگر روی همهٔ ردیفهای deep بدقالب اثر میگذارد؛ آزمونی اضافه کنید تا kindهای خالی یا خراب بدون اعتبارسنجی پذیرفته نشوند.
اگر آزمونها یا تلهمتری پسرفت کردند فقط تغییر کد را برگردانید. تغییری پایدار روی دستگاه وجود ندارد.
رجیستری/سازگاری. ردیف C++ بدون جداکننده/جزئیات و parseRow() در Kotlin با شرط sep <= 0 و رد فیلد خالی راستیآزمایی شدهاند. شناسه در کاتالوگ باقی مانده است.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.VpnNativeDetectorChecker.kt — حکم و اطمینان بررسی عمیق VPN.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.NativeSignalId.kt — رجیستری کامل شناسهها.سیگنالهای مرتبط: gso-failed, gso-send-failed, general-diagnostics.