نص غير مرئي على الشاشة يقود لتنفيذ أوامر على الحاسوب عبر وكلاء أندرويد الذكاء الاصطناعي مفتوحي المصدر

نظرة عامة

السياق: ما هي وكلاء أندرويد الذكاء الاصطناعي؟

هذا النوع من الأطر البرمجية يسمح لنموذج ذكاء اصطناعي (غالباً نموذج رؤية متعدد الوسائط Multimodal) بالتحكم فعلياً بجهاز أندرويد نيابة عن المستخدم — يرى الوكيل لقطة شاشة الجهاز، يقرر الإجراء المناسب (ضغطة، كتابة نص، فتح تطبيق)، وينفّذه فعلياً عبر أدوات تحكم بالجهاز مثل ADB (Android Debug Bridge). الهدف عادة أتمتة مهام معقدة (حجز، تسوق، اختبار تطبيقات) دون تدخل بشري مباشر بكل خطوة.

المشكلة الجوهرية التي يوثّقها هذا البحث: بما أن الوكيل “يقرأ” الشاشة بصرياً ويتصرف بناءً على ما يراه، فإن أي محتوى يظهر على الشاشة — حتى لو كان غير مرئي عملياً للعين البشرية — يمكن أن يُعامَل كتعليمات شرعية من قِبَل الوكيل.

خمس تقنيات هجوم موثَّقة

1. نص غير مرئي يخدع نماذج الرؤية

اختبر الباحثون ستة نماذج رؤية مختلفة (من ضمنها GPT-4o وClaude Opus 4.5) على قراءة نص بشفافية 2% فقط — مستوى شفافية أقل بكثير من أن يلاحظه أي إنسان بظروف مشاهدة عادية. النتيجة: النماذج المختبرة قرأت هذا النص “غير المرئي” بنجاح في 18 من أصل 20 محاولة مخبرية على الأقل، ووصلت أفضل النماذج لنسبة نجاح 20 من 20.

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

2. حقن أوامر عبر مخرجات النموذج غير المُنقَّاة

المشكلة التقنية الأعمق: كيفية تنفيذ الوكلاء لقرارات النموذج فعلياً على الجهاز. بإطار AppAgent تحديداً، الكود المسؤول عن التحكم يستدعي أوامر النظام عبر:

subprocess.run(adb_command, shell=True)

استخدام shell=True مع بيانات قادمة من مخرجات نموذج الذكاء الاصطناعي — دون تنقية كافية — يفتح باباً كلاسيكياً لحقن الأوامر. الكود الفعلي “يزيل المسافات والفواصل العليا المفردة قبل تضمين القيمة بالأمر”، لكنه يترك رموزاً خاصة بالصدفة (Shell Metacharacters) أخطر بكثير بدون تصفية، مثل الفاصلة المنقوطة (;)، والعطف (&)، وإعادة التوجيه (>) — وكلها تسمح بتقسيم الأمر الأصلي وإلحاق أمر إضافي خبيث به.

3. ثغرة سباق بالتقاط لقطات الشاشة (TOCTOU)

رصد الباحثون ثغرة توقيت كلاسيكية من نوع TOCTOU (فحص-ثم-استخدام — Time-Of-Check to Time-Of-Use) بآلية التقاط لقطة الشاشة نفسها. إطار Mobile-Agent-v3 تحديداً يكتب لقطة الشاشة لمسار ثابت (/sdcard/screenshot.png) وينتظر نصف ثانية قبل قراءتها. قاس الباحثون هذه الفجوة الزمنية فعلياً ووجدوها تتراوح بين 50 و500 ملي ثانية، بمتوسط 210 ملي ثانية على مدى 100 محاولة — فجوة كافية لمهاجم لديه وصول محلي (مثلاً تطبيق خبيث آخر على نفس الجهاز) لاستبدال محتوى لقطة الشاشة قبل أن يقرأها الوكيل.

4. اعتراض الإدخال عبر البث (Broadcast Interception)

إطار Open-AutoGLM يُرمِّز النص المُدخَل عبر بث نظام (Broadcast) باسم ADB_INPUT_B64، تلتقطه أداة اختبار آلي تُدعى ADB Keyboard. المشكلة أن أي تطبيق آخر على الجهاز يستطيع التسجيل لاستقبال هذا البث دون أي صلاحية خاصة مطلوبة — ما يسمح لتطبيق خبيث باعتراض أي إدخال حساس يمر عبر هذه الآلية، بما فيه كلمات المرور.

5. تزييف الواجهة وسرقة بيانات الاعتماد

باستخدام خدمات إمكانية الوصول (Accessibility Services)، أظهر الباحثون إمكانية تركيب واجهة تسجيل دخول مزيَّفة فوق الواجهة الحقيقية. بمائة محاولة اختبار ضد الأطر الخمسة جميعها، لم يتردد أي وكيل قبل إدخال بيانات اعتماد بواجهة مزيَّفة واحدة.

إثبات المفهوم: من نص غير مرئي إلى تشغيل برنامج فعلي

لإثبات الأثر العملي الكامل، صمَّم الباحثون حمولة (Payload) هدفها تشغيل الآلة الحاسبة (calc.exe) على الحاسوب المضيف — ونجحت هذه الحمولة في 20 من 20 محاولة ضد أربعة من الأطر الخمسة (AppAgent وAppAgentX وMobile-Agent-v3 وMobA). اختبار أعمق باستخدام حمولة test;pwd>rce_success نجح أيضاً بكتابة مسار العمل الحالي للجهاز المضيف داخل ملف — إثبات فعلي وموثَّق على تنفيذ أوامر حقيقي على جهاز الكمبيوتر المضيف، منطلقاً من مجرد نص ظهر على شاشة هاتف أندرويد.

لماذا لا يوجد رقم CVE؟

يوضّح الباحثون صراحة أنه لا يوجد رقم CVE مُخصَّص لأي من هذه المشكلات، ولا توجد أدلة على استغلال فعلي خارج البيئة المخبرية المضبوطة. هذا لا يقلل من الخطورة الفعلية للنتائج — فئة “أدوات الذكاء الاصطناعي الوكيلية مفتوحة المصدر” لا تزال حديثة العهد نسبياً، وآليات الإفصاح المسؤول (Responsible Disclosure) وتخصيص أرقام CVE لهذا النوع من المشاريع أقل نضجاً مقارنة بالبرمجيات التجارية الراسخة.

التوصيات الدفاعية (لمطوّري أطر مشابهة)

بحسب توصيات الباحثين أنفسهم:

• تجنّب shell=True نهائياً عند تنفيذ أوامر مبنية على مدخلات خارجية — استخدم قوائم وسيطة (argv Lists) بدلاً من دمج نصوص كأمر واحد.
• بث لقطات الشاشة مباشرة (Streaming) بدلاً من نمط “اكتب ثم اقرأ” الذي يفتح نافذة TOCTOU زمنية.
• فرض صلاحيات على مستوى التوقيع (Signature-Level Permissions) لأي بث نظام يحمل بيانات إدخال حساسة.
• قوائم سماح لكل مهمة (Per-Task Allowlists) مع مقارنة فعلية للنشاط المتوقَّع مقابل الفعلي.
• تعزيز التباين (Contrast Enhancement) كخطوة معالجة أولية قبل تحليل النموذج البصري — للحد من قابلية قراءة نص منخفض الشفافية جداً.

ملاحظات

• البحث نُشر أولاً على arXiv بتاريخ 1 تموز/يوليو 2026، وحُدِّث بتاريخ 14 تموز/يوليو 2026، من فرق بحثية بجامعة Simon Fraser، وجامعة هونغ كونغ الصينية، وجامعة شاندونغ، ومختبر Xingtu التابع لشركة QAX الأمنية.
• تم التواصل مع القائمين على صيانة الأطر الخمسة المتأثرة بشكل خاص قبل النشر، لكن الباحثين أفادوا بعدم تلقي أي رد حتى تاريخ نشر الخبر.
• هذه الحادثة تنضم لسلسلة متنامية من الأبحاث هذا الموسم حول ثغرات وكلاء الذكاء الاصطناعي (قارن مع حالات AWS Kiro وAzure DevOps MCP المغطاة سابقاً بهذه المدونة) — النمط المشترك في الجميع: إخفاء تعليمات عن الإدراك البشري مع إبقائها مقروءة آلياً يتكرر بأشكال مختلفة (نص شفاف هنا، تعليق HTML هناك، نص بحجم بكسل بمكان آخر).

المصدر

المقال الأصلي: Open-Source Android AI Agents Could Let Invisible Screen Text Run Code on Host PCs