RKNHardering Help

روش آزمایشگاهی، فرمان‌های راستی‌آزمایی و بازگردانی

یک اجرای تصادفی هیچ چیزی را ثابت نمی‌کند. شبکه‌ها تغییر می‌کنند، ارائه‌دهندگان GeoIP با هم اختلاف دارند، Android شبکهٔ پیش‌فرض را عوض می‌کند و سیاست beta عمداً مشاهده‌های ناپایدار را سرکوب می‌کند. آنچه در ادامه می‌آید حداقل پروتکل بازتولیدپذیر است.

پروفایل‌های آزمایش

دست‌کم چهار پروفایل بسازید و هر بار فقط یک متغیر را تغییر دهید.

شناسه	وضعیت	هدف
B0	دستگاه پاک، VPN غیرفعال	خط پایه برای مثبت‌های کاذب OEM/ROM/روت/شبیه‌ساز
B1	VPN فعال، RKNHardering داخل VPN	مجموعهٔ کامل سیگنال‌های VPN و سمت سرور
B2	VPN فعال، RKNHardering مستثنا شده	نمایش صریح TUN همراه با bypass ناشی از split tunnel و خروج مستقیم
H1	روش پنهان‌سازی انتخاب‌شده	مقایسه با B1/B2 و تشخیص سیگنال‌های تازهٔ هوک/روت
R1	روتر خارجی، VPN محلی غیرفعال	بهترین خط پایهٔ معماری بدون روت
P1	پروفایل کاری، خصوصی یا clone	آزمایش جداسازی مستقل از مسیر شبکه

برای سناریوهای روت‌شده، H1 را همچنین با حالت فقط framework، فقط native و پیکربندی ترکیبی اجرا کنید. این کار سریعاً نشان می‌دهد کدام لایه کار نمی‌کند.

داده‌هایی که پیش از هر اجرا باید ثبت شوند

• مدل دستگاه و build fingerprint؛
• نسخهٔ Android، نسخهٔ هسته از uname -r و وضعیت SELinux؛
• شناسهٔ کاربر و پروفایل فعلی؛
• مدیر روت/framework و نسخهٔ دقیق ماژول‌ها؛
• سرویس‌گیرندهٔ VPN، حالت TUN یا proxy، MTU، وضعیت IPv4/IPv6 و مسیر بسته؛
• Wi-Fi یا شبکهٔ موبایل و زمان آزمایش؛
• مسیر خروج و DNS مورد انتظار؛
• شناسهٔ epoch شبکه، زمانی که برنامه آن را نمایش می‌دهد.

SuperKey، جزئیات اشتراک، اسرار API، پیکربندی کامل VPN یا نشانی‌های IP و hostnameهای خصوصی را بدون حذف داده‌های حساس منتشر نکنید.

گردآوری وضعیت بدون روت

adb shell getprop ro.build.fingerprint
adb shell uname -a
adb shell getenforce
adb shell pm list users
adb shell am get-current-user
adb shell cmd package list packages -U | grep com.notcvnt.rknhardering
adb shell dumpsys connectivity
adb shell ip -details addr
adb shell ip -details route show table all
adb shell ip rule
adb shell settings get global http_proxy

در بعضی ROMها، shell معمولی نمی‌تواند همهٔ قواعد policy یا فایل‌های /proc/net را ببیند. این محدودیت مجوز تشخیصی است، نه شاهد پاک‌بودن سامانه.

بین اجراها برنامه را force-stop کنید:

adb shell am force-stop com.notcvnt.rknhardering
adb shell monkey -p com.notcvnt.rknhardering 1

monkey فعالیت launcher برنامه را اجرا می‌کند، اما وقتی برنامه ورودی launcher ندارد یا دستگاه قفل است ممکن است شکست بخورد. در این حالت برنامه را دستی باز کنید.

تشخیص‌های تکمیلی با روت

adb shell su -c 'id'
adb shell su -c 'ls -la /data/adb/modules'
adb shell su -c 'cat /data/system/vpnhide_config.json 2>/dev/null'
adb shell su -c 'cat /proc/vpnhide_ctl 2>/dev/null || cat /proc/vpnhide_targets 2>/dev/null'
adb logcat -c
# یک آزمون را به‌صورت دستی اجرا کنید
adb logcat -d | grep -iE 'RKNHardering|VpnHide|Vector|LSPosed|Zygisk'

برای خواندن یک فایل، chmod 777 اجرا نکنید، SELinux را غیرفعال نکنید و مالکیت را تغییر ندهید. این اقدام‌ها مدل امنیتی را تخریب و سیگنال‌های تشخیص تازه‌ای ایجاد می‌کنند.

بررسی localhost بدون اسکن کامل

RKNHardering خود اسکن را انجام می‌دهد. برای بررسی دستی endpointهای شناخته‌شدهٔ کنترل، همین نشانی‌های مشخص کافی‌اند:

adb shell 'toybox nc -z -w 1 127.0.0.1 9090; echo exit=$?'
adb shell 'toybox nc -z -w 1 127.0.0.1 19090; echo exit=$?'

وجود nc به ROM وابسته است. connection refused یعنی هیچ listenerای اتصال روی آن نشانی و پورت را نمی‌پذیرد؛ timeout یعنی عملیات در زمان مقرر تمام نشده است؛ not found یعنی فرمان در shell وجود ندارد. UID مربوط به shell و UID مربوط به RKNHardering ممکن است زیر قواعد متفاوت فایروال باشند، بنابراین نتیجهٔ برنامه معیار نهایی باقی می‌ماند.

معیارهای پذیرش بر اساس لایه

مسیر شبکه

• IP مورد انتظار در دست‌کم دو اجرا پایدار بماند؛
• گروه‌های RU و non-RU بدون توضیح از هم جدا نشوند؛
• IPv4/IPv6 و DNS از policyهای متناقض پیروی نکنند؛
• رفتار STUN/UDP با مدل انتخاب‌شده سازگار باشد؛
• تغییر شبکه به‌جای مخلوط تصادفی نتایج، epoch مورد انتظار تازه‌ای بسازد.

چارچوب Android

• هیچ‌یک از TRANSPORT_VPN، IS_VPN یا VpnTransportInfo باقی نماند؛
• NOT_VPN و شبکهٔ فعال با هم سازگار باشند؛
• LinkProperties فاقد رابط، route یا DNS مربوط به VPN باشد؛
• مسیرهای beta مربوط به callback و Binder با API معمول تناقض نداشته باشند.

لایهٔ بومی

• هیچ رابط TUN/TAP، چه بر اساس نام و چه بر اساس نوع، باقی نماند؛
• نماهای getifaddrs()، ioctl، netlink، route/proc/sysfs و نماهای مرتبط با هم سازگار باشند؛
• index رابط‌ها و SIOCGIFCONF اوراکل رگرسیون باقی نگذارند؛
• هویت سوکت، MTU/MSS/PMTU و رفتار qdisc با رابط فیزیکی ادعاشده تناقض نداشته باشند.

یکپارچگی

• فرایند هدف هیچ backend مربوط به Xposed یا Zygisk دریافت نکند، مگر آنکه کاملاً ضروری باشد؛
• هیچ ناسازگاری تازه‌ای در RWX، maps، linker یا یکپارچگی کتابخانه ظاهر نشود؛
• SELinux در حالت enforcing و سامانه read-only باقی بماند؛
• مسیرها و mountهای روت برای UID هدف قابل مشاهده نباشند؛
• کاربر/پروفایل با سناریوی مورد نظر مطابقت داشته باشد.

تعیین محل علت

مشاهده	محتمل‌ترین علت	اصلاح
Java پاک است، native نیست	backend بومی غیرفعال، UID نادرست یا هوک پشتیبانی‌نشده	backend، UID و نسخهٔ هسته را بررسی کنید؛ backend دوم اضافه نکنید
Native پاک است، TRANSPORT_VPN باقی مانده	ماژول framework در system_server بارگذاری نشده	Vector/LSPosed، scope مربوط به System Framework و ریبوت را بررسی کنید
VPN پنهان است، localhost پیدا می‌شود	نقش Ports یا listener مربوط به API پوشش داده نشده	API را غیرفعال کنید یا از فایروال UID/قاعدهٔ پنهان‌سازی پورت استفاده کنید
همه‌چیز محلی پاک است، حکم detected است	GeoIP، اجماع IP، CDN، STUN یا موقعیت مکانی	به‌جای افزودن هوک، route و مسیر خروج را اصلاح کنید
پس از Zygisk یافته‌های RWX/linker ظاهر می‌شوند	backend درون‌فرایندی قابل تشخیص است	به backend هسته منتقل شوید و برنامهٔ هدف را از injection خارج کنید
فقط ردیف‌های work profile باقی مانده‌اند	سناریو واقعاً زیر شناسهٔ کاربر بزرگ‌تر از 0 اجرا می‌شود	زیر کاربر مالک اجرا کنید یا review را به‌عنوان سیگنال دقیق بپذیرید
permission denied در shell	مجوز ناکافی یا محدودیت SELinux	آن را پاک تلقی نکنید؛ بدون تضعیف SELinux از تشخیص‌های موجود استفاده کنید
address already in use	listener دیگری پورت را اشغال کرده است	مالک را شناسایی یا API را غیرفعال کنید؛ تغییر پورت اسکن کامل را شکست نمی‌دهد
invalid config	خطای JSON یا schema	نسخهٔ پشتیبان را برگردانید، فایل را اعتبارسنجی و از طریق رابط کاربری اعمال کنید

خطرها و برنامهٔ بازگردانی

پیش از آزمایش روت یا هسته، یک روند بازگردانی مستند آماده کنید:

1. محل ذخیرهٔ image اصلی boot/init_boot و image patch‌شدهٔ سالم را ثبت کنید.
2. روش ورود به bootloader یا recovery را بدانید.
3. روش فعال‌کردن حالت امن مدیر روت انتخاب‌شده را بدانید.
4. آخرین ماژول نصب‌شده را ثبت کنید.
5. از /data/system/vpnhide_config.json و پیکربندی VPN نسخه‌ای ذخیره کنید.
6. داده‌های ذخیره‌شده در پروفایل‌های کاری یا خصوصی را export کنید.

وقتی چیزی خراب شد، آخرین تغییر را غیرفعال کنید. روی وضعیت خراب ماژول دیگری نصب نکنید. اگر دسترسی شبکه از بین رفت، ابتدا backend بومی و قواعد پورت را به حالت اصلی برگردانید، سپس لایهٔ framework را بررسی کنید. اگر پس از نصب ZIP هسته boot loop آغاز شد، ماژول هستهٔ دیگری را برای «اصلاح» آن بارگذاری نکنید؛ image سالم شناخته‌شده را بازگردانید یا ماژول مسئول را از سازوکار رسمی خودش غیرفعال کنید.

بررسی کامل‌بودن این راهنما

ماتریس کامل از enum و منابع رجیستری جاری ساخته می‌شود و با docs/help/fa/anti-detection/_validate.py بررسی می‌شود. اسکریپت باید موارد زیر را تأیید کند:

• 65 از 65 ورودی EvidenceSource؛
• 85 از 85 ورودی NativeSignalId؛
• 41 از 41 شناسهٔ beta؛
• تکمیل ستون‌های «بدون روت» و «با روت» برای همهٔ ردیف‌ها؛
• نبود پیوند داخلی خراب در Markdown.

اسکریپت عمداً هیچ درخواست شبکه‌ای انجام نمی‌دهد و پروژه را با آرشیو خارجی مقایسه نمی‌کند. فایل‌های خارج از docs هنگام ساخت آرشیو با hash کردن درخت جداگانه بررسی می‌شوند.

بازگشت به نمایهٔ anti-detection

This site is open source. Improve this page.