شناسه:
LOOPBACK_PORT_CONFLICTدسته: آثار VPN و سوکتها وضعیت در RKNHardering 2.10.0: بررسی فعال نقش در حکم نهایی: بالا
این صفحه پیادهسازی واقعی RKNHardering 2.10.0 را توضیح میدهد. در آن مشخص شده است چه اقدامهایی بدون روت ممکناند، چه چیزهایی به روت نیاز دارند و کدام راهکار فقط یک سیگنال را کاهش میدهد، بیآنکه VPN را بهطور کامل پنهان کند.
پروب برای پورتهای 51820، 1194، 443 و 8443 یک سوکت TCP با SO_REUSEADDR میسازد و آن را به 127.0.0.1 bind میکند. فقط EADDRINUSE خط loopback_port_conflict تولید میکند؛ سیاست قدیمی آن را با اطمینان بالا طبقهبندی میکند.
bind کردن پورت TCP انتخابشده روی localhost ممکن نباشد، زیرا نشانی از قبل در حال استفاده است.
این نتیجه وجود listener یا bind متعارض را نشان میدهد، اما مالک آن را مشخص نمیکند. پورتهای 443 و 8443 ممکن است متعلق به رابط وب محلی، سرور توسعه یا برنامهٔ امنیتی باشند و لزوماً به VPN مربوط نیستند.
تأثیر این خط بر گزارش: این خط detected=true را تنظیم میکند و بهعنوان یک نشانهٔ محلی با اطمینان بالا در نظر گرفته میشود.
SO_REUSEADDR و رفتار سوکت در Android بر نتیجه اثر میگذارند. پروب همهٔ پورتها، IPv6 روی ::1 یا UDP را اسکن نمیکند.
این خط باید همراه با سیگنالهای مجاور ارزیابی شود. پاکبودن نتیجهٔ یک API بهتنهایی Java Binder، libc، netlink خام/فراخوانی مستقیم سامانه، procfs/sysfs، سوکتهای محلی و نشانههای سمت سرور را همزمان پوشش نمیدهد.
ابتدا خود اثر واقعی را حذف کنید: listener، پورت API، daemon محلی یا سرویسگیرندهٔ VPN غیرضروری را متوقف کنید؛ سپس برنامهها را force-stop و آزمایش را تکرار کنید. اگر VPN لازم است، دروازهٔ خارجی معمولاً از هر راهکار محلی تمیزتر است. پروفایل دوم شاید دید بستهها را محدود کند، اما پنهانشدن اشیای شبکه را تضمین نمیکند و سیگنال کاربر/پروفایل خودش را ایجاد میکند. فرایند را شناسایی و API محلی غیرضروری را غیرفعال کنید. تغییر سادهٔ پورت فقط در برابر فهرست ثابت کمک میکند و راهحل کامل نیست.
روت میتواند داده را برای UID مشخص فیلتر کند، اما سطح تشخیص تازهای میافزاید. در VPNHide نقشهای Apps و Ports بهترتیب PackageManager و localhost را هدف میگیرند و backend بومی مسیرهای پشتیبانیشدهٔ رابط و route را پوشش میدهد. برای پورت غیراستاندارد، پیش از تلاش برای پوشاندن آن API کنترل را غیرفعال کنید. هر قاعدهٔ iptables یا nftables را از طریق ماژولی با مسیر بازگردانی روشن اعمال کنید و loopback نسخهٔ IPv4 و IPv6 را جداگانه بیازمایید. VPNHide Ports برای محدودکردن دسترسی UID هدف به loopback طراحی شده است، اما بسته به پیادهسازی ممکن است تعارض واقعی bind همچنان دیده شود. بهتر است listener اصلاً اجرا نشود.
adb shell ss -ltn 2>/dev/null | grep -E '127\.0\.0\.1:(51820|1194|443|8443)'
adb shell lsof -iTCP -sTCP:LISTEN 2>/dev/null | grep -E ':(51820|1194|443|8443)'
پیام address already in use یعنی پورت اشغال است.
پس از هر تغییر، RKNHardering و سرویسگیرندهٔ VPN را بهاجبار متوقف کنید، هر دو را دوباره اجرا کنید و اسکن کامل را تکرار کنید. Zygisk، Xposed و ماژولهای هسته معمولاً به راهاندازی مجدد دستگاه نیاز دارند. فقط همین خط را مقایسه نکنید؛ سیگنالهای مجاور را نیز بررسی کنید، زیرا یک هوک ناقص اغلب میان APIها ناسازگاری ایجاد میکند.
خود پروب با مجوزهای معمول برنامه اجرا میشود و روت درخواست نمیکند. دستورهای ADB زیر فقط برای جهتیابی تشخیصیاند: adb shell با UID دیگری اجرا میشود و ممکن است نسبت به فرایند برنامه اطلاعات بیشتر یا کمتری ببیند. آزمون تعیینکننده، اجرای دوبارهٔ بررسی درون برنامه پس از توقف اجباری است.
توقف listener سیستمی ناشناخته ممکن است برنامهای را از کار بیندازد. فایروال سراسری loopback، IPC و APIهای محلی را مختل میکند.
سرویس را بازگردانید یا فقط قاعدهٔ ویژهٔ UID را که افزودهاید حذف کنید. بهجای bind روی localhost، پورت را در معرض شبکهٔ خارجی قرار ندهید.
بالا. چهار پورت، loopback با AF_INET و شرط EADDRINUSE راستیآزمایی شدهاند؛ kind دارای اطمینان بالا است.
وضعیت یک راهکار شخص ثالث خودبهخود به این دستگاه تعمیم پیدا نمیکند. ادعای سازندهٔ ماژول فقط فرضیهٔ آغازین است؛ تأیید واقعی به نتیجهای تکرارپذیر از RKNHardering روی همان نسخهٔ Android، میانافزار و هسته نیاز دارد.
native_signs_probe.cpp — پیادهسازی پروب بومی.NativeSignsChecker.kt — منطق اصلی حکم بومی/قدیمی.NativeSignalId.kt — رجیستری کامل شناسهها.NativeSignalCatalog.kt — نگاشت دسته، slug و خط خروجی.سیگنالهای مرتبط: tcp-vpn-port, udp-port-conflict-physical, tcp-mss-low.