پیش از انتخاب ماژول، بازرسی را به سه لایهٔ مستقل تقسیم کنید. بیشتر پیکربندیهای ناموفق فقط یکی از این لایهها را میپوشانند و همان را با bypass کامل اشتباه میگیرند.
این لایه بیرون از فرایند Android قرار دارد. RKNHardering نشانی خارجی، کشور، ASN/ISP، پاسخ سرویسهای RU و non-RU، مسیر DNS، redirectهای CDN، STUN و پروبهای transport را مقایسه میکند. نه LSPosed و نه ماژول هسته نمیتواند IP خارجی یک data center را به نشانی خانگی روسیه تبدیل کند. فقط مسیریابی و egress مناسب میتوانند این لایه را تغییر دهند.
پرسش عملی این است: سمت دور واقعاً کدام نشانی و مسیر را مشاهده میکند؟ پاسخ به split tunneling، DNS، IPv4/IPv6، UDP و endpoint مشخص بستگی دارد. برای جزئیات، بخش مسیر شبکه را ببینید.
این لایه از APIهای Binder/Java و رابطهای بومی هسته تشکیل میشود:
NetworkCapabilities، NetworkInfo، LinkProperties و callbackها؛NetworkInterface، getifaddrs()، ioctl(SIOCGIF*) و netlink از نوع RTM_GET*؛/proc/net/*، /sys/class/net، policy ruleها، qdisc و هویت سوکت؛VpnService.محدودیت بنیادی بدون روت در همینجاست. برنامهٔ عادی VPN میتواند packageای را از تونل خودش خارج کند، اما نمیتواند پاسخهای system_server و هسته را برای UID دیگری بازنویسی کند. روتر خارجی سیگنالهای محلی را حذف میکند، زیرا روی دستگاه Android تحت آزمون اصلاً VPN ساخته نمیشود. راهکارهای روت میتوانند دادهها را در system_server و هسته فیلتر کنند.
خود ماژول پنهانسازی میتواند به سیگنال تبدیل شود. RKNHardering فایلها و propertyهای روت، mountها، SELinux، هوکها، ناحیههای RWX، یکپارچگی library، ناسازگاری Java/بومی، نشانگرهای شبیهساز و پروفایل کاربر جاری را بررسی میکند. ماژولی که مستقیم داخل فرایند RKNHardering inject شود ممکن است TRANSPORT_VPN را حذف کند، اما اثر قویتری از هوک یا دستکاری بر جا بگذارد.
معماری روت درست این مسئولیتها را جدا نگه میدارد: دادهٔ Java در system_server فیلتر میشود، دادهٔ بومی در سطح هسته و فرایند هدف هیچ injection از Xposed یا Zygisk دریافت نمیکند. به همین دلیل VPNHide یک لایهٔ Java سیستمی را همراه با یک backend هسته توصیه میکند و Zygisk را فقط fallback میداند.
بدون روت چهار اقدام واقعبینانه وجود دارد.
نخست، مسیر واقعی ترافیک را تغییر دهید. برای نمونه، com.notcvnt.rknhardering را از VPN خارج کنید و آن را مستقیم یا از egress مورد انتظار بفرستید. این کار به بررسیهای GeoIP و اجماع IP کمک میکند، اما TUN Active Probe فعلی میتواند ترکیب «TUN وجود دارد، ولی این برنامه transportِ VPN ندارد» را تشخیص دهد.
دوم، VPN را از تلفن خارج کنید. روتر، gateway جدا یا hotspot پاکترین نمای محلی را فراهم میکند: Android بهجای VpnService یک Wi‑Fi عادی میبیند. این تنها راه عمومی بدون روت است که سیگنالهای Binder، TUN، netlink و packageِ کلاینت VPN را همزمان از دستگاه تحت آزمون حذف میکند.
سوم، نشتهای تنظیماتی غیرضروری را حذف کنید: proxy سیستم، تنظیمات PAC، listenerهای loopback، APIهای Clash/sing-box/Xray، احراز هویت ضعیف و مسیر جداگانهٔ DNS. این کار رابط TUN را پنهان نمیکند، اما تشخیصهای مستقل را میبندد.
چهارم، از پروفایل یا کاربر جدا استفاده کنید. این کار دادهها و packageهای نصبشده را جدا میکند، اما نامرئی نیست: Android برای پروفایل user ID و بازهٔ UID جدا تعیین میکند و RKNHardering هم سیگنالهای پایدار و هم beta برای جداسازی دارد. در VerdictEngine فعلی، یک سیگنال پروفایل معمولاً به review منتهی میشود، اما در ترکیب با ناسازگاری شبکه quorumِ beta ممکن است DETECTED تولید کند.
روت دامنهٔ تغییرات را گسترش میدهد، اما لایهٔ شبکه را حذف نمیکند. پیکربندی عملی چهار جزء مستقل دارد:
system_server.ioctl، netlink، مسیرها و proc/sysfs.برای هستهٔ GKI پشتیبانیشده، ماژول هستهٔ VPNHide مناسبتر است. روی هستههای قدیمی یا غیر GKI ممکن است backendِ KPM/KernelPatch قابلاستفاده باشد. راهاندازی Zygisk سادهتر است، اما syscall خام میتواند از هوکهای libc آن عبور کند و بررسی یکپارچگی فرایند نیز آن را ببیند. VPNHide Next ادعا میکند پوشش بیشتری برای MTU/MSS/TCP_INFO، PMTU/GSO، eBPF، qdisc، timing و مسیرهای link-local در IPv6 دارد. خود پروژه دربارهٔ boot loop و kernel panic هشدار میدهد؛ بنابراین این شاخه آزمایشی است، نه «حالت حداکثری» امن و پیشفرض.
بررسیشده در پروژه: نتیجهٔ نهایی جمع سادهٔ همهٔ سطرها نیست. منبع، استقلال و domainِ شواهد اهمیت دارند.
NEEDS_REVIEW میبرند.beta.vpn_binder و beta.tun_fd هستند و آنها هم به نمونههای پایدار تکرارشده نیاز دارند. سایر سیگنالهای beta از quorumِ گروههای مستقل یا در ترکیب با شواهد پایدار به DETECTED میرسند.پیامد عملی مهم است: تلاش برای «اصلاح» همهٔ سطرهای اطلاعاتی بیهوده است. ابتدا قویترین منابع مستقل را حل کنید—egress واقعی، وضعیت VPN در Binder، فهرست رابط و مسیر در لایهٔ بومی، APIهای localhost و آثار صریح روت یا هوک.
فقط split tunnel. ترافیک مستقیم خارج میشود، اما رابط TUN و شبکهٔ VPN باقی میمانند. بررسی فعلی مشخصاً همین ترکیب را جستوجو میکند.
فقط هوک LSPosed داخل برنامه. APIهای Java پاک بهنظر میرسند، اما getifaddrs()، netlink و syscallهای خام دیده میشوند و فرایند نشانگر هوک پیدا میکند.
فقط پنهانسازی بومی Zygisk. مسیرهای رایج libc پوشش داده میشوند، اما syscall مستقیم، تابعهای جایگزین دریافت و بررسیهای یکپارچگی فرایند ممکن است مداخله را آشکار کنند.
فقط تغییر نام tun0. RKNHardering بیش از نام را میسنجد: نوع TUN/TAP، index رابط، netlink، مسیرها، MTU/MSS، policy ruleها، qdisc و سیگنالهای غیرمستقیم سوکت.
فقط فضای دوم. packageها و داده جدا میشوند، اما user ID و وضعیت پروفایل دیده میماند. سامانههای cloneِ OEM اغلب user IDهای قابلشناسایی دارند که کد جداگانه بررسی میکند.
فقط ماژول پنهانسازی روت. IP خارجی، DNS، STUN یا رفتار CDN را تغییر نمیدهد. ماژول ناسازگار میتواند ناهنجاری تازهای در mount، RWX یا linker ایجاد کند.
چهار سناریو را بدون تغییر همزمان چند متغیر اجرا کنید:
برای قابلیت بازتولید، زمان، شبکه، user ID، فهرست ماژولها، کلاینت VPN، پروفایل و دو نتیجهٔ پیاپی را ثبت کنید. قالب کامل در روش آزمایشگاهی آمده است.