ADB عبر الإنترنت على Android: إعدادات آمنة مع الروت وبدونه

لا تحتاج إلى الروت للوصول إلى ADB في هاتفك من بلد آخر. ما تحتاجه هو طريقة لتشغيل ADB عبر TCP، ومسار خاص بين حاسوبك والهاتف. والروت يغيّر الجزء الأول فقط: فهو يتيح للهاتف تشغيل ADB بنفسه والإبقاء عليه بعد إعادة التشغيل دون كابل. أما بقية ما في هذا الدليل فيعمل بالطريقة نفسها على هاتف بنظامه الأصلي.

يقع الناس في الخطأ بطريقتين، وهما نفسهما مع الروت وبدونه: إما أن يتبعوا شرحاً يمرّر المنفذ 5555 على راوتر المنزل، أو يثقوا باتصال يعمل على Wi-Fi ويفشل بصمت على بيانات الجوال.

هذا الدليل للهاتف الذي تملكه: جهاز احتياطي يشغّل اختباراتك، أو هاتف في المنزل تريد الوصول إليه أثناء السفر، أو مجموعة صغيرة من الأجهزة. ولا يشمل الوصول إلى جهاز يخص غيرك. يشرح كيف يعمل ADB عن بُعد، وكيف تفعّله مع الروت وبدونه، وثلاث طرق اتصال لا تعرّض ADB للإنترنت العام أبداً. والخطوات التي تحتاج إلى الروت موسومة بعبارة للروت فقط.

الخلاصة: فعّل TCP ADB على الهاتف، واجعله متاحاً عبر مسار خاص مشفّر فقط، واستخدم هذا المسار من حاسوبك. Tailscale أسهل مسار. ونفق SSH عكسي عبر خادم صغير تملكه هو الأوسع توافقاً. أما تمرير المنفذ 5555 مباشرة فهو الإعداد الذي يجب تجنبه.

مع الروت أو بدونه: ما الذي يتغير

الفرق العملي هو الموثوقية وليس القدرات. يعمل الهاتف بنظامه الأصلي عن بُعد بشكل جيد حتى يُعاد تشغيله، وعندها يتعذر الوصول إليه إلى أن يعيد شخص بحوزته الهاتف والحاسوب إعداده. وبالنسبة لهاتف في مدينة أخرى، فهذا هو سبب الحصول على الروت فيه. أما الهاتف الذي تستطيع الوصول إليه بيدك، أو الاختبار القصير، فلا حاجة إلى الروت.

ما الذي يحمي ADB فعلاً وما الذي لا يحميه

تقول معظم نصائح ADB عن بُعد إن ADB عبر الشبكة «بلا تشفير وبلا مصادقة». هذا صحيح جزئياً، والجزء الخاطئ منه يؤثر في طريقة إعدادك للنظام.

ADB الكلاسيكي عبر الشبكة، أي وضع adb tcpip 5555، غير مشفّر. تصف ملاحظات تصميم ADB في Android النقل القديم بأنه حزم غير مشفّرة، بينما يلف وضع Wi-Fi الذي أُدخل في Android 11 الجلسة بطبقة TLS.المصدر 2 وبذلك يستطيع أي طرف يراقب المسار بينك وبين الهاتف قراءة ما ترسله.

المصادقة مسألة مختلفة. في إصدار الإنتاج العادي، يطلب ADB من الهاتف الموافقة على مفتاح RSA الخاص بحاسوبك. عند أول اتصال يعرض adb devices الحالة unauthorized ويعرض الهاتف نافذة: «Allow USB debugging?» مع بصمة المفتاح. وتنص وثائق Android على أن أوامر adb لا تعمل إلا بعد أن تفتح قفل الجهاز وتقرّ بهذه النافذة.المصدر 1 تُحفظ المفاتيح التي توافق عليها على الهاتف، وتحديد الخيار «Always allow from this computer» هو ما يجعل الاتصالات اللاحقة تتم دون سؤال.

يترتب على ذلك أمران عمليان. الأول أن المنفذ المكشوف ليس باباً مفتوحاً أمام غريب على هاتف غير مروّت، لكنه باب مفتوح أمام أي شخص يحصل على مفتاح يثق به الهاتف أصلاً، وهو باب مشرّع تماماً في أي جهاز تكون فيه المصادقة معطّلة. والبرمجيات الخبيثة التي انتشرت عبر المنفذ 5555 وجدت في الغالب هذه الأجهزة: أجهزة TV box، وأجهزة العرض، وإصدارات المطوّرين، وهواتف عطّل فيها أحدهم إعداد secure. والثاني أن أول اتصال من حاسوب جديد يحتاج إلى يد على الشاشة. خطّط للموافقة على مفتاحك وأنت بجوار الهاتف، عبر كابل USB أو على Wi-Fi المنزل، وحدّد الخيار الذي يحفظ هذه الموافقة.

لماذا Wireless debugging أداة غير مناسبة للوصول عن بُعد دون إشراف

يبدو Wireless debugging الخيار الأكثر أماناً، وهو كذلك لحاسوب محمول على Wi-Fi المنزل. أما للوصول عن بُعد فهو يعمل ضدك. فمنفذ الاتصال عشوائي ويتغير عند إيقاف الميزة وتشغيلها، والاكتشاف يعتمد على mDNS الذي لا يعبر VPN، وإصدارات Android الأحدث توقفه من تلقاء نفسها. ويضيف Android 17 مع ADB 37 ميزة «ADB Wi-Fi 2.0» التي توقف Wireless debugging على الشبكات التي لم تعلّمها موثوقة، وتعيد الاتصال تلقائياً على الشبكات التي علّمتها.المصدر 4 هذا سلوك ممتاز لمكتب مطوّر، وهو خاطئ تماماً لهاتف تحتاج إلى الوصول إليه من بلد آخر.

إذا أردت تفاصيل هذه الميزة، فإن دليلنا عن ADB اللاسلكي على Android 17 يشرح الإقران والشبكات الموثوقة ومشكلة الجهاز المقترن لكنه غير متصل. أما للاستخدام عن بُعد فاللبنة الأفضل هي منفذ TCP الثابت، الذي يمكنك تفعيله مع الروت أو بدونه ثم حمايته بما هو أقوى من المنفذ نفسه.

الخطوة 1: فعّل TCP ADB

اختر القسم المناسب لهاتفك. كلاهما ينتهي بالحالة نفسها: تستمع خدمة ADB الخلفية في الهاتف على المنفذ 5555، وتتولى الخطوة 2 حمايته.

بدون روت

على أي هاتف Android، فعّل Developer options وUSB debugging، ووصّل الهاتف بحاسوب بكابل، ووافق على المفتاح عندما يطلب الهاتف ذلك، ثم نفّذ:

adb tcpip 5555

افصل الكابل. يقبل الهاتف الآن ADB عبر الشبكة على المنفذ 5555 إلى أن يُعاد تشغيله. وبعض الإصدارات تعيد ضبط الإعداد أيضاً عند تبديل USB debugging، فإذا توقف المنفذ عن الاستجابة فنفّذ الأمر مرة أخرى. ولأن الإعداد يُفقد عند إعادة التشغيل، يحتاج الهاتف غير المروّت إلى شخص ومعه كابل بعد كل إعادة تشغيل. وهذا مقبول لهاتف تتحكم فيه، لكنه غير مناسب لهاتف لا تستطيع الوصول إليه.

على Android 11 وما بعده توجد طريقة لتنفيذ الخطوة نفسها دون حاسوب إطلاقاً، وهي شائعة الاستخدام في المجتمع، لكننا لم نختبرها على كل جهاز. تفعّل Wireless debugging، وتثبّت Termux وحزمة أدوات Android الخاصة به، وتقرن Termux بالهاتف نفسه باستخدام رمز الإقران، ثم تتصل بعنوان الهاتف نفسه وتنفّذ adb tcpip 5555 من هناك. وهي تتطلب أن يكون الهاتف متصلاً بشبكة Wi-Fi في تلك اللحظة. اعتبرها خياراً احتياطياً ليوم نسيت فيه الكابل، وراجع دليل Termux حديثاً للحصول على الأوامر الدقيقة، لأنها تتغير بحسب الحزمة وإصدار Android.

مع الروت (للروت فقط)

على هاتف مروّت، افتح تطبيق طرفية مثل Termux واحصل على shell بصلاحية root. الخاصية التي تتحكم في المنفذ تقرؤها خدمة ADB الخلفية نفسها، ويفحص الكود المصدري للخدمة service.adb.listen_addrs أولاً، ثم service.adb.tcp.port، ثم persist.adb.tcp.port.المصدر 3

su
setprop service.adb.tcp.port 5555
stop adbd
start adbd

تؤدي إعادة تشغيل الخدمة الخلفية إلى قطع أي جلسة USB debugging مفتوحة، لذا نفّذ الأمر من الهاتف لا من حاسوب موصول بالكابل. وتحقق من أنها تستمع:

getprop service.adb.tcp.port
ss -ltn | grep 5555

لا تتضمن بعض إصدارات Android الأداة ss، بينما تعمل netstat -ltn على إصدارات أخرى. وإذا لم تتوفر أي منهما، فإن اختبار الاتصال من حاسوبك في الخطوة 2 هو الدليل الحقيقي.

تُفقد الخاصية service. عند إعادة تشغيل الهاتف. والهاتف الذي لا تصل إليه بعد انقطاع الكهرباء ليس هاتفاً عن بُعد، لذا اجعل الإعداد دائماً. هناك طريقتان، وتعملان معاً بشكل جيد. الأولى هي الخاصية الدائمة:

setprop persist.adb.tcp.port 5555

الثانية نص برمجي للإقلاع. مع Magisk، يعمل نص shell محفوظ في /data/adb/service.d/ ومعيّن كملف قابل للتنفيذ في وقت متأخر من الإقلاع؛ أما KernelSU وAPatch فيستخدمان وحدة صغيرة فيها ملف service.sh بدلاً من ذلك. راجع وثائق مدير الروت لديك لمعرفة الموقع الدقيق، فهو يتغير بين الأدوات والإصدارات.

#!/system/bin/sh
until [ "$(getprop sys.boot_completed)" = "1" ]; do sleep 5; done
setprop service.adb.tcp.port 5555
stop adbd
start adbd

أعد التشغيل مرة واحدة واختبر. تتعامل الشركات المصنّعة مع هذه الخصائص بطرق مختلفة، وبعض الرومات تتجاهلها أو تعيد ضبطها. وعلى Android 11 وما بعده، حجبت قاعدة SELinux مرة قدرة ADB على ضبط خاصية المنفذ في بعض الإصدارات، ثم خُففت لاحقاً.المصدر 5 فإذا لم تبقَ الخاصية بعد إعادة التشغيل على هاتفك فالنص البرمجي للإقلاع هو الحل، وإذا لم تستمع الخدمة الخلفية إطلاقاً فقد يكون الروم الذي تستخدمه يحجب الخاصية. في هذه الحالة يكون البديل جلسة USB واحدة بالأمر adb tcpip 5555 بعد كل إقلاع، وهي طريقة عدم الروت المذكورة أعلاه.

لإيقافه مرة أخرى مع الروت:

setprop service.adb.tcp.port -1
setprop persist.adb.tcp.port ""
stop adbd
start adbd

بدون روت، يؤدي إيقاف USB debugging في Developer options، أو إعادة تشغيل الهاتف، الغرض نفسه.

في هذه المرحلة يستمع الهاتف على كل واجهات الشبكة لديه. وهذا مقبول ما دام الوحيدون القادرون على الوصول إلى هذه الواجهات هم أنت وشبكتك الموثوقة، وهذه مهمة الخطوة التالية.

الخطوة 2: اختر مساراً خاصاً إلى الهاتف

كل طريقة أدناه تعمل مع الروت وبدونه. وهدفها واحد: منح حاسوبك مساراً مشفّراً وموثّقاً إلى المنفذ 5555 في الهاتف، دون قبول أي اتصال وارد من الإنترنت المفتوح. والجزء الثاني أهم مما يبدو. فمعظم الهواتف على بيانات الجوال تقع خلف carrier-grade NAT (CGNAT)، فلا يصل إليها تمرير المنافذ على الراوتر حتى لو أردت ذلك.

الطريقة أ: Tailscale

يبني Tailscale شبكة خاصة بين أجهزتك ويتجاوز NAT نيابةً عنك، ولهذا يعمل من هاتف على بيانات الجوال. ثبّته على الهاتف وعلى حاسوبك وسجّل الدخول إلى الحساب نفسه. يحصل كل جهاز على عنوان ثابت يبدأ بـ 100.، ويظهر عنوان الهاتف في التطبيق وفي لوحة الإدارة.

من الحاسوب:

adb connect 100.x.y.z:5555
adb devices

في المرة الأولى يطلب الهاتف منك الموافقة على المفتاح، وهذا سبب إجراء ذلك مرة واحدة والهاتف بين يديك. ولا يحتاج تطبيق Tailscale إلى الروت. بعد ذلك تعمل adb shell وadb push وadb logcat وscrcpy كلها كما لو كان الهاتف على مكتبك.

ثلاثة إعدادات تنقل هذا الإعداد من مريح إلى موثوق. أولاً، يسمح Tailscale افتراضياً لكل جهاز في شبكتك بالوصول إلى كل جهاز آخر، وملف السياسات هو المكان الذي تضيّق فيه ذلك. وتبدو القاعدة التي تسمح لحسابك وحده بالوصول إلى الهاتف الموسوم على المنفذ 5555 هكذا في سياسة الوصول:المصدر 6

{ "action": "accept", "src": ["you@example.com"], "dst": ["tag:phone:5555"] }

ثانياً، عطّل انتهاء صلاحية المفتاح للهاتف في لوحة الإدارة، وإلا فسيخرج من شبكتك في موعده ولن تتمكن من إعادته من مكان بعيد. ثالثاً، امنح تطبيق Tailscale استهلاكاً غير مقيّد للبطارية في إعدادات Android. يفيد المستخدمون بأن التطبيق يتوقف أو ينقطع كل بضع دقائق في ظل إدارة الطاقة الصارمة، وانقطاع الاتصال في منتصف النقل هو العَرَض المعتاد.المصدر 8

هناك قيدان يستحقان المعرفة. خادم SSH المدمج في Tailscale لا يعمل على Android، لأن المنصة تدعم دور العميل فقط في هذه الميزة، لذا استخدم منفذ ADB مباشرة أو نفق SSH أدناه إذا احتجت إلى shell دون ADB.المصدر 7 ولا تستخدم Tailscale Funnel لهذا الغرض. فهو مخصص لنشر خدمات الويب على الإنترنت العام، وهذا عكس ما تريد تحقيقه.

الطريقة ب: نفق SSH عكسي عبر خادمك الخاص

لا تحتاج هذه الطريقة إلى أي شيء من طرف ثالث. تستأجر أصغر خادم افتراضي تجده، فيتصل الهاتف به من الداخل إلى الخارج ويُبقي الاتصال مفتوحاً. ثم يتصل حاسوبك بالخادم نفسه ويصل إلى الهاتف من خلاله. ولأن الهاتف هو من يبادر بالاتصال، فهي تعمل خلف CGNAT وعلى Wi-Fi الفنادق.

على الهاتف، في Termux الذي لا يحتاج إلى الروت، ثبّت عميل SSH وأنشئ مفتاحاً:

pkg install openssh autossh
ssh-keygen -t ed25519

على الخادم، أنشئ مستخدماً مخصصاً وأضف المفتاح العام للهاتف إلى ملف authorized_keys الخاص به، مع تقييده بحيث لا يستطيع المفتاح فعل شيء سوى فتح منفذ الاستماع الواحد على واجهة loopback:

restrict,port-forwarding,permitlisten="127.0.0.1:15555" ssh-ed25519 AAAA... phone

ثم أبقِ النفق مفتوحاً من الهاتف. تجعل الخيارات أدناه الاتصال يفشل بوضوح إذا تعذر ربط المنفذ، وتمنعه من التعلّق بصمت على شبكة ميتة:

ssh -N -R 127.0.0.1:15555:127.0.0.1:5555 \
  -o ServerAliveInterval=30 -o ServerAliveCountMax=3 \
  -o ExitOnForwardFailure=yes tunnel@your-server.example

يستطيع autossh مراقبة هذا الأمر وإعادة تشغيله، وتستطيع الإضافة Termux:Boot تشغيله بعد إعادة التشغيل، مع termux-wake-lock لإبقاء المعالج مستيقظاً ما دام النفق قائماً. اضبط خيار البطارية في Termux على غير مقيّد أيضاً. وتعتمد هذه العناصر على إصدار Android وعلى مدى صرامة الشركة المصنّعة في إغلاق تطبيقات الخلفية، لذا اختبرها والشاشة مطفأة لمدة ساعة قبل أن تعتمد عليها.

من حاسوبك، مرّر منفذاً محلياً إلى النفق واتصل من خلاله:

ssh -N -L 5556:127.0.0.1:15555 you@your-server.example
adb connect 127.0.0.1:5556

لاحظ المنفذ المحلي 5556. فخادم ADB لديك يشغل المنفذ 5555 غالباً، والتعارض هناك يسبب أخطاء محيّرة. والتمرير البعيد مربوط بعنوان loopback للخادم، فلا يستطيع أي شيء على الإنترنت الوصول إليه مباشرة، كما أن الإعداد الافتراضي في OpenSSH للتمرير البعيد يرفض أصلاً الربط بواجهة عامة ما لم تغيّر GatewayPorts.

استخدم تسجيل الدخول بالمفاتيح فقط على الخادم، وأبقِ كلمة المرور لذلك المستخدم معطّلة. فالنفق العكسي مع تسجيل دخول بكلمة مرور على خادم SSH مكشوف للإنترنت ليس أكثر أماناً بكثير من تمرير المنفذ الذي يحل محله.

الطريقة ج: WireGuard على خادمك الخاص

يمنحك WireGuard التأثير نفسه الذي يمنحه Tailscale، مع بقاء كل جزء متحرك تحت سيطرتك. شغّل نقطة نهاية WireGuard على خادم بعنوان عام، وأضف الهاتف وحاسوبك كنظيرين (peers)، واضبط PersistentKeepalive = 25 من جهة الهاتف لتُبقي شبكات الجوال على تعيين NAT نشطاً. وتطبيق WireGuard لـ Android، الذي لا يحتاج إلى الروت، ينتقل بين Wi-Fi وLTE ويمكن تشغيله كـ VPN دائم التشغيل. ثم تتصل من حاسوبك بعنوان WireGuard الخاص بالهاتف على المنفذ 5555، تماماً كما في Tailscale. وهذا هو الخيار المناسب عندما تريد إعداداً ثابتاً ودائماً ولا تمانع في صيانة الخادم.

ملاحظة على بديل شائع: يُوثَّق Cloudflare Tunnel لاستخدام SSH، لكننا لم نتحقق من إعداد سليم لحركة ADB الخام، لذا لا نوصي به هنا.

الإعداد الذي يجب تجنبه: تمرير المنفذ 5555 على الراوتر

من المغري تمرير المنفذ الخارجي 5555، أو منفذ مخصص «ذكي»، إلى الهاتف والاكتفاء بذلك. لا تفعل. فهذا يرسل ADB غير مشفّر عبر الإنترنت العام، ويعتمد كلياً على نافذة مفتاح واحدة، ويعلن عن نفسه للماسحات التي تبحث عن هذا بالضبط.

هذا ليس نظرياً. ففي 2020 أفاد باحثون في Keysight، أثناء تحليل شبكة Trinity الخبيثة (botnet)، بنحو 40,000 جهاز ADB مكشوف ظاهر على Shodan، نحو ربعها هواتف، وكانت البرمجية الخبيثة تتصل بها باستخدام adb connect نفسه.المصدر 9 وأزالت شبكة منافسة هي Fbot شبكة Trinity من الأجهزة المصابة، لكن Trinity عادت خلال ساعات. وفي فبراير 2021 انتشرت شبكة Matryosh، المبنية على كود Mirai، عبر المنفذ نفسه.المصدر 10 وتغيير رقم المنفذ الخارجي لا يغيّر شيئاً، لأن الماسحات تفحص كل المنافذ.

تلجأ بعض الأدلة إلى حل وسط، هو تمرير منفذ SSH لخادم Termux بدلاً من ذلك. وهذا أفضل من تمرير ADB، لكنه ما زال ينشر خدمة SSH على عنوان IP منزلك، وتسجيل دخول Termux بكلمة مرور أمر سيئ تركه على الإنترنت. أما النفق العكسي أو الشبكة المغطّاة (overlay network) فتمنحك النتيجة نفسها دون أي منفذ وارد على الإطلاق.

قائمة التحصين الأمني

وافق على الحواسيب التي تستخدمها فعلاً فقط، وألغِ القديمة منها. في Developer options يمسح الخيار «Revoke USB debugging authorizations» كل المفاتيح المخزّنة، وهي عادة جيدة قبل تسليم الهاتف لشخص آخر. أبقِ تصحيح ADB معطّلاً على أي هاتف لا يحتاج إليه، واعتبر المنفذ الذي فتحته في الخطوة 1 جزءاً من القرار نفسه. ولا تحدّد «Always allow» على حاسوب مشترك أو عام.

ترى جلسة ADB المصرّح بها ما يراه مستخدم shell، وهذا كثير أصلاً: التطبيقات المثبّتة والملفات التي يمكنك قراءتها والشاشة والإدخال. للروت فقط: على هاتف مروّت يستطيع adb shell su الوصول إلى ما هو أكثر بكثير إذا منحه مدير الروت لمستخدم shell، لذا اضبط المدير على أن يسألك عند طلب shell بدلاً من السماح به بصمت.

للروت فقط: يضيف بعض الناس قاعدة جدار ناري على الهاتف بحيث يستجيب المنفذ 5555 على واجهة VPN فقط. الفكرة سليمة، لكننا لم نستطع التأكد من أنها موثوقة على Android. فقد تعيد خدمة الشبكة في النظام ترتيب القواعد أو تمسحها عند تغير الشبكة، ولا ينشئ تطبيق Tailscale القياسي واجهة tailscale0 لتطابقها. وإذا جرّبتها فأعد تطبيق القاعدة من النص البرمجي للإقلاع، واختبر من جهاز ليس على VPN.

العمل عبر اتصال بطيء

يبدو الهاتف خلف نفق أبطأ من هاتف على مكتبك، والحل عادةً هو طلب بيانات أقل. لعرض الشاشة بـ scrcpy، خفّض الدقة ومعدل البت، مثلاً scrcpy -s 100.x.y.z:5555 -m 1280 -b 4M؛ وتختلف أسماء الخيارات قليلاً بين الإصدارات، لذا راجع scrcpy --help. ويستطيع scrcpy أيضاً تفعيل وضع TCP نيابةً عنك بالأمر --tcpip، وتوصي وثائقه بقطع الاتصال عند الانتهاء.المصدر 11 والمسار المباشر في Tailscale أسرع من المسار الذي يمر عبر خوادم الشركة، وتخبرك حالة الاتصال في التطبيق بأيهما لديك.

عند اتصال أكثر من جهاز، حدّد لـ ADB الجهاز المقصود بالخيار adb -s 100.x.y.z:5555 ...، أو استخدم -d لجهاز USB و-e للمحاكي. ونقل الملفات وadb logcat هما أكثر المهام تحملاً لزمن التأخير.

حل المشكلات

مع الروت يمكنك التحقق مما يستخدمه الهاتف فعلاً بتنفيذ getprop service.adb.tcp.port وgetprop persist.adb.tcp.port في shell بصلاحية root. وبدون روت فالاختبار هو adb connect من الحاسوب. وإذا كان الهاتف يستخدم Wireless debugging أيضاً، فتذكّر أن منفذ TLS العشوائي الخاص به يُخزَّن بشكل منفصل، لذا فإن اتصالاً لاسلكياً يعمل لا يدل على شيء بخصوص المنفذ الثابت.

الأسئلة الشائعة

هل يحتاج هذا إلى الروت؟ لا. بدون روت تفعّل TCP ADB عبر USB مرة واحدة وتستخدم Tailscale أو النفق العكسي أو WireGuard تماماً كما هو موضح. الثمن أن الإعداد يُفقد عند كل إعادة تشغيل، فيحتاج أحدهم إلى إعادة توصيل كابل. والروت يزيل هذه الخطوة ويضيف خياري الجدار الناري وsu، ولا يعتمد عليه شيء آخر في هذا الدليل.

هل يعمل هذا عبر بيانات الجوال؟ نعم، لأن Tailscale وWireGuard والنفق العكسي كلها تتصل من الهاتف إلى الخارج. أما تمرير المنافذ على الراوتر فهو الطريقة التي تفشل هناك.

هل من الآمن تركه مفعّلاً طوال الوقت؟ هو آمن بقدر أمان المسار الذي يحميه. خلف شبكة مغطّاة (overlay network) مع سياسة وصول، يكون التعرّض صغيراً. اتركه مفعّلاً فقط إذا كنت ستستخدمه فعلاً، وأوقفه عندما لا تحتاج إليه.

هل يمكن لأحد إساءة استخدامه دون نافذة المفتاح؟ في الإصدار العادي يجب الموافقة على أي حاسوب جديد من الهاتف. أما في أي إصدار تكون فيه مصادقة التصحيح معطّلة، فيمكنهم الاتصال دونها، ولهذا يجب ألا تكشف ذلك المنفذ للإنترنت أبداً مهما كان الإصدار.

لماذا لا أستخدم تطبيق سطح مكتب بعيد فحسب؟ لاستخدام الشاشة لا بأس بذلك، وتطبيق مشاركة الشاشة لا يحتاج إلى الروت إطلاقاً. أما ADB فهو الأداة المناسبة عندما تحتاج إلى أوامر shell أو تثبيت تطبيقات أو نقل ملفات أو سجلات عن بُعد.

قبل أن تعتمد عليه

اختبر كل شيء والهاتف على بيانات الجوال والحاسوب على شبكة مختلفة. أعد تشغيل الهاتف وتحقق مما يعود من تلقاء نفسه: على هاتف مروّت يُفترض أن يعود، وعلى هاتف غير مروّت ينبغي أن تعرف بالضبط ما عليك إعادته. جرّبه والشاشة مطفأة لبعض الوقت. وإذا تعذر عليك الوصول إلى الهاتف بعد أي من هذه الاختبارات، فقد اكتشفت المشكلة وهي ما زالت رخيصة الإصلاح.

إذا كنت ما زلت تختار هاتفاً لمشاريع كهذه وتريد هاتفاً يقبل الروت، فإن فهرس الهواتف القابلة للروت لدينا يوضح الطرازات التي يُفتح قفل بوتلودرها بسلاسة، ويغطي دليل وحدات Magisk جانب الوحدات في النص البرمجي للإقلاع المخصص للروت. ولمحطة Linux الطرفية التي لا تعتمد على الروت، راجع Linux Terminal في Android مقابل Termux.

المصادر والنطاق

جرى البحث لإعداد هذا الدليل في أكتوبر 2026 اعتماداً على وثائق Android والكود المصدري الخاص به، وعلى منشورات الشركات المصنّعة وأبحاث الأمن. لم نختبر كل إصدار من Android وكل روم. ويختلف سلوك الخاصية، والنصوص البرمجية للإقلاع، وحيلة التفعيل من الهاتف نفسه، وأسلوب الجدار الناري، وسلوك البطارية في Termux من جهاز إلى آخر، لذا تحقق من كل منها على هاتفك قبل أن تعتمد عليه.

• المصدر 1: Android Developers، Android Debug Bridge (adb) عرض المصدر
• المصدر 2: Android Open Source Project، ملاحظات تصميم ADB Wi-Fi: TCP القديم غير مشفّر، ووضع Wi-Fi يستخدم TLS عرض المصدر
• المصدر 3: Android Open Source Project، الملف adbd main.cpp، اختيار المنفذ من الخصائص عرض المصدر
• المصدر 4: Android Developers Blog، Wireless debugging وADB Wi-Fi 2.0 عرض المصدر
• المصدر 5: OmniROM، تغيير سياسة SELinux لخصائص adbd عرض المصدر
• المصدر 6: Tailscale، قوائم التحكم في الوصول (Access control lists) عرض المصدر
• المصدر 7: Tailscale، دعم المنصات في Tailscale SSH عرض المصدر
• المصدر 8: منتدى مجتمع Tailscale، انقطاعات Android واستهلاك البطارية عرض المصدر
• المصدر 9: Keysight، برمجية TrinityP2P الخبيثة عبر ADB عرض المصدر
• المصدر 10: The Hacker News، شبكة Matryosh الخبيثة لهجمات DDoS، فبراير 2021 عرض المصدر
• المصدر 11: وثائق scrcpy، قسم Connection عرض المصدر