SafetyNet مقابل Play Integrity API: كيف تجتازه مع الروت (2026)

أوقفت Google رسمياً في بداية 2024 واجهة SafetyNet API التي عرفها مجتمع روت Android لعقد من الزمن، وحلّت محلها Play Integrity API. وكل دليل كُتب قبل 2024 أصبح قديماً، وتبقى معلومات مغلوطة كثيرة في المنتديات القديمة. هذا الدليل هو الشرح العملي الحالي لعام 2026: ما الذي تغيّر، وماذا تعني نتائج Play Integrity الثلاث فعلاً، وأي أدوات تجاوز تعمل في 2026، وتعليمات إعداد خطوة بخطوة تشمل أوامر Magisk المحددة. وهو موجَّه للمستخدمين المتقدمين الذين يملكون جهازاً مروّتاً بالفعل ويحتاجون إلى تشغيل التطبيقات البنكية وتطبيقات الدفع.

لمحة تاريخية: من SafetyNet إلى Play Integrity

SafetyNet (2014-2024) كانت واجهة Google لإثبات سلامة الجهاز (device attestation). وكانت تعيد حقلين منطقيين هما ctsProfileMatch (هل يطابق هذا الجهاز ملف Compatibility Test Suite معروفاً؟) وbasicIntegrity (هل يجتاز هذا الجهاز فحوص السلامة الأساسية مثل حالة قفل البوتلودر؟). كانت التطبيقات البنكية تستدعيها عبر خدمات Google Play، وتحصل على القيمتين، وترفض العمل إذا كانت إحداهما false. وتطورت طرق التجاوز على مدى عقد: MagiskHide في البداية، ثم Zygisk + DenyList بعد إيقاف MagiskHide في Magisk 24، ثم Shamiko فوقهما لإخفاء أقوى.

Play Integrity API (2023 حتى الآن) هي البديل الرسمي. والجدول الزمني للإيقاف:

• يونيو 2023: إطلاق Play Integrity API بوصفها البديل المفضّل
• منتصف 2023 حتى مطلع 2024: بدأت التطبيقات الانتقال من SafetyNet إلى Play Integrity
• يناير 2024: إيقاف SafetyNet رسمياً، ولم تعد الاستجابات الجديدة للواجهة مضمونة
• بحلول منتصف 2026: تعتمد جميع تطبيقات البنوك والدفع الكبرى تقريباً على Play Integrity وحدها

تعيد Play Integrity ثلاث نتائج بدلاً من قيمتين منطقيتين، وتستخدم إثبات المفاتيح المدعوم بالعتاد (hardware key attestation) لأشد المستويات صرامة، ما يجعل تجاوزها بالطرق البرمجية وحدها أصعب بكثير من حيث المبدأ.

شرح نتائج Play Integrity الثلاث

يعيد كل فحص Play Integrity ثلاث قيم منطقية:

MEETS_DEVICE_INTEGRITY

المستوى الأساسي. يعني أن الجهاز يعمل بنظام Android غير معدّل، وأن خدمات Google Play مثبّتة عليه، وأنه يجتاز فحوص التوافق الأساسية. يمكن تجاوزه على الأجهزة المروّتة بالأدوات الحالية (Magisk + Zygisk + DenyList + Shamiko + وحدة Play Integrity Fix). ويشترط نحو 60 بالمئة من التطبيقات هذه النتيجة كي تعمل بشكل طبيعي.

MEETS_BASIC_INTEGRITY

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

MEETS_STRONG_INTEGRITY

أصعب مستوى. يستخدم إثبات المفاتيح المدعوم بالعتاد: يوقّع الـ TEE (بيئة التنفيذ الموثوقة) في الجهاز استجابةً يمكن التحقق منها وصولاً إلى شهادة الجذر لدى الشركة المصنّعة للجهاز. ويعمل هذا حتى عندما يكون البوتلودر مقفلاً لأن المفاتيح محمية بالعنصر الآمن. لا يمكن تجاوزه بالطرق البرمجية الحالية على جهاز بوتلودره مفتوح القفل لأن فتح القفل يكسر سلسلة الإقلاع الموثّق (verified boot) التي تعتمد عليها مفاتيح TEE.

ويشترط STRONG_INTEGRITY نحو 10 إلى 20 بالمئة من التطبيقات:

• الدفع بالتلامس عبر Google Wallet في بعض المناطق
• عدة بنوك رقمية (Revolut وWise وN26 في بعض المناطق)
• بعض تطبيقات الهوية الحكومية (جوازات السفر الرقمية، وبطاقة الناخب)
• تطبيقات الرعاية الصحية ذات متطلبات الامتثال الصارمة
• بعض تطبيقات العمل التي تصدرها جهة العمل وتحميها أنظمة MDM

إذا كانت تطبيقاتك الأساسية تشترط STRONG_INTEGRITY، فالروت لا يتوافق معها ولا يوجد حل بديل حالي يغيّر ذلك.

أدوات التجاوز: Magisk Hide مقابل Shamiko مقابل TrickyStore

تعمل ثلاث أدوات رئيسية معاً لتجاوز Play Integrity على الأجهزة المروّتة في 2026:

خطوة بخطوة: اجتياز Play Integrity للتطبيقات البنكية الأساسية

يفترض هذا أنك أنجزت ما يلي:

• البوتلودر مفتوح القفل
• Magisk مثبّت عبر boot.img مرقّع
• الروت يعمل وتم التحقق منه في Magisk Manager

إذا لم تنجزها بعد، فراجع أولاً دليل فتح قفل البوتلودر وMagisk مقابل KernelSU مقابل APatch.

الخطوة 1: فعّل Zygisk في Magisk

افتح تطبيق Magisk ← Settings (أيقونة الترس) ← فعّل مفتاح Zygisk. ثم أعد التشغيل.

بعد إعادة التشغيل، عد إلى Settings في Magisk وفعّل Enforce DenyList.

الخطوة 2: ثبّت Shamiko

نزّل أحدث ملف zip لـ Shamiko من إصدارات LSPosed/LSPosed الرسمية على GitHub. في تطبيق Magisk ← تبويب Modules ← اضغط أيقونة + ← اختر ملف Shamiko المضغوط ← ثبّت. ثم أعد التشغيل.

بعد إعادة التشغيل، تأكد من تحميل Shamiko: في تطبيق Magisk ← تبويب Modules يُفترض أن يظهر Shamiko في القائمة ومفعّلاً.

الخطوة 3: ثبّت وحدة Play Integrity Fix

نزّل أحدث ملف zip لـ PIF من إصدارات chiteroman/PlayIntegrityFork على GitHub (أو من أي fork يُصان حالياً، وراجع مواضيع XDA Recognized Developer لمعرفة التوصيات الحالية).

تطبيق Magisk ← Modules ← + ← ثبّت ملف PIF المضغوط ← أعد التشغيل.

الخطوة 4: حدّث fingerprint في PIF إلى واحد ناجح حالياً

يجب أن يطابق fingerprint داخل PIF جهازاً معروفاً ينجح حالياً في Play Integrity. وتتضمن وحدة PIF نصاً برمجياً للتحديث التلقائي. افتح تطبيق طرفية (Termux مناسب) ونفّذ:

su -c sh /data/adb/modules/playintegrityfix/action.sh

يجلب هذا أحدث fingerprint ناجح يصونه المجتمع ويطبّقه. ثم أعد التشغيل.

الخطوة 5: اضبط DenyList لتطبيقاتك

تطبيق Magisk ← Configure DenyList ← ابحث عن كل تطبيق بنكي أو تطبيق دفع أو تطبيق يفحص Play Integrity تحتاج إلى استخدامه. اضغط المفتاح بجانب كل تطبيق لتفعيل الإخفاء. وعادةً تُفعَّل إدخالات العمليات الفرعية تلقائياً.

تطبيقات شائعة لإضافتها:

• تطبيق البنك الرئيسي لديك (HDFC وSBI وBank of America وLloyds وغيرها)
• تطبيقات المحافظ المالية على الجوال (bKash وGCash وM-Pesa وJazzCash)
• تطبيقات الدفع (Google Pay وPayPal وVenmo وCash App)
• تطبيقات الوساطة المالية (Robinhood وZerodha وGroww)
• التطبيقات الحكومية (DigiLocker وAadhaar وتطبيق NHS)
• تطبيقات البث المحمية بـ DRM (Netflix وDisney+ وAmazon Prime، وهي تفحص Play Integrity لتشغيل HD/4K)

الخطوة 6: تحقق باستخدام Play Integrity API Checker

ثبّت Play Integrity API Checker من Play Store (توجد عدة نسخ، فجرّب نسخة gkkang أو النسخة التي يصونها فريق LSPosed).

افتحه واضغط Check. وابحث عن:

• MEETS_DEVICE_INTEGRITY: يُفترض أن تكون true
• MEETS_BASIC_INTEGRITY: يُفترض أن تكون true
• MEETS_STRONG_INTEGRITY: ستكون false على جهاز بوتلودره مفتوح القفل، وهذا متوقع

إذا أعاد DEVICE وBASIC كلاهما true فالتجاوز يعمل على مستوى النتيجة. وستعمل معظم تطبيقات البنوك والدفع الآن بشكل طبيعي.

الخطوة 7: اختبر كل تطبيق بنكي على حدة

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

1. تأكد من أن التطبيق مفعّل في DenyList
2. أعد تنفيذ أمر التحديث التلقائي في PIF لتحديث fingerprint
3. إعادة التشغيل
4. إذا استمر الفشل فقد يستخدم ذلك التطبيق كشفاً إضافياً يتجاوز Play Integrity، فجرّب TrickyStore طبقةً إضافية، أو اقبل أن التطبيق غير متوافق مع إعداد الروت الحالي لديك

عندما تفشل التطبيقات رغم نجاح النتيجة

تستخدم بعض التطبيقات وسائل كشف إضافية تتجاوز واجهة Play Integrity API الرسمية:

• فحص الملفات مباشرة: بحثاً عن /system/bin/su أو مسارات ملفات Magisk التنفيذية أو مسارات تثبيت الوحدات المعروفة. الحل: فعّل ميزة إخفاء الملفات المكافئة لـ MagiskHide (مدمجة في إصدارات Magisk الحديثة).
• فحص مساحة أسماء العمليات: فحص /proc/self/status وما يشبهه بحثاً عن بصمات hooks الخاصة بـ Zygisk. الحل: يعالج Shamiko معظم الحالات.
• تحديات إثبات TEE المستقلة عن Play Integrity. الحل: TrickyStore لبعض التطبيقات، وهو مستحيل مع غيرها.
• قوائم حظر خاصة بالتطبيق يصونها مطوّر التطبيق وتضم أسماء حزم معروفة مرتبطة بالروت. الحل: غيّر اسم تطبيق Magisk عبر Settings ← Hide the Magisk app، وامنحه اسماً لا يشبه Magisk.

حالة التطبيقات البنكية بحسب المنطقة: ما الذي يعمل حالياً على Android مروّت

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

بنغلاديش

• bKash: يعمل مع Magisk + Shamiko + PIF لدى معظم المستخدمين، وقد يلزم أحياناً تحديث fingerprint بعد تحديثات Google
• Nagad: يعمل مع المجموعة نفسها، لكنه أكثر حساسية قليلاً لحداثة fingerprint
• Rocket (DBBL): يعمل مع المجموعة القياسية
• تطبيقات City Bank وBRAC Bank وEBL وDutch-Bangla Bank: يعمل معظمها مع المجموعة القياسية، فتحقق منها بعد كل تحديث لـ Play Integrity
• الدفع بالتلامس الخاص بالبنك: يشترط عموماً STRONG_INTEGRITY، ولا يمكن تجاوزه على الأجهزة المروّتة

الهند

• Google Pay (Tez): يعمل UPI مع المجموعة القياسية، بينما يشترط الدفع بالتلامس (في المناطق المدعومة) STRONG_INTEGRITY
• PhonePe وPaytm: يعمل UPI مع المجموعة القياسية
• HDFC وICICI وSBI YONO وAxis Mobile: يعمل معظمها، وHDFC وAxis أشد صرامة قليلاً وقد يحتاجان إلى TrickyStore لبعض الميزات
• تطبيقات الوساطة المالية (Zerodha Kite وGroww وUpstox): تعمل مع المجموعة القياسية
• تطبيق mAadhaar لـ Aadhaar: يعمل لمعظم الميزات، وقد تتطلب ميزات القياسات الحيوية إعداد إخفاء إضافياً

باكستان

• JazzCash وEasypaisa: كلاهما يعمل مع المجموعة القياسية لدى معظم المستخدمين
• HBL Mobile وUBL Digital وMeezan Bank Mobile: يعمل معظمها، وMeezan هو الأشد صرامة بين الثلاثة
• NayaPay وSadaPay (بنوك رقمية): متفاوت، فتحقق منهما قبل أن تعتمد على الروت معهما

بريطانيا والاتحاد الأوروبي

• معظم تطبيقات البنوك التجارية الكبرى (Lloyds وBarclays وHSBC وSantander وNatWest): تعمل مع المجموعة القياسية حتى منتصف 2026
• البنوك الرقمية (Revolut وWise وN26 وMonzo): يُعرف Revolut وWise بصرامتهما وكثيراً ما يشترطان STRONG_INTEGRITY في بعض المسارات، بينما يكون Monzo وStarling أكثر تساهلاً عادةً
• ما يعادل الدفع بالتلامس من Apple وGoogle: يشترط STRONG_INTEGRITY ولا يمكن تجاوزه

تعكس هذه القائمة الوضع وقت الكتابة وتتغير باستمرار. اختبر تطبيقاتك بنفسك دائماً قبل أن تعتمد على الروت في استخدام مالي لا يحتمل التأخير.

ما الذي يتضمنه STRONG_INTEGRITY فعلاً على مستوى TEE

سياق تقني سريع للمستخدمين المتقدمين يوضح لماذا يستحيل من حيث المبدأ تجاوز STRONG_INTEGRITY على الأجهزة التي بوتلودرها مفتوح القفل.

تتضمن أجهزة Android الحديثة بيئة تنفيذ موثوقة (TEE)، وهي معالج آمن منفصل له ذاكرته ونظام تشغيله الخاص، ومعزول عن نظام Android الرئيسي. وتحتفظ TEE بمفاتيح تشفير فريدة لكل جهاز تُهيَّأ في المصنع وتوقّعها جهة الشهادات الجذر لدى الشركة المصنّعة.

عندما يطلب تطبيق STRONG_INTEGRITY، يمر الطلب عبر TEE التي توقّع الاستجابة بهذه المفاتيح المُهيَّأة في المصنع. وتتضمن الاستجابة حالة الإقلاع الموثّق الحالية، وهي سلسلة تجزئة (hash chain) تثبت أن البوتلودر مقفل وأن أقسام boot وsystem وvendor تطابق المواصفات المتوقعة الموقّعة من الشركة المصنّعة.

عندما تفتح قفل البوتلودر، تحدّث TEE حالة الإقلاع الموثّق إلى «yellow» (مفاتيح يثبّتها المستخدم) أو «orange» (دون إقلاع موثّق). وتبقى TEE توقّع استجابات STRONG_INTEGRITY، لكن الاستجابة ستتضمن صراحةً حالة فتح القفل. والتطبيقات التي تشترط STRONG_INTEGRITY تفحص هذا الحقل وترفض العمل إذا كانت الحالة غير green (بوتلودر مقفل وسلسلة إقلاع موقّعة من الشركة المصنّعة).

لا يستطيع التجاوز البرمجي تزييف ذلك لأن TEE توقّع بمفاتيح لا يستطيع النظام الرئيسي الوصول إليها. ويستطيع TrickyStore اعتراض استدعاء keystore قبل وصوله إلى TEE واستبداله باستجابة «سليمة» مسجّلة مسبقاً من جهاز مشابه، وهذا ينجح مع بعض التطبيقات التي لا تتحقق من المصدر العتادي للاستجابة كما ينبغي، لكن التطبيقات التي تتحقق (الصارمة منها) ستكشف الاستبدال.

الطرق الموثوقة الوحيدة لاجتياز STRONG_INTEGRITY:

• شغّل boot.img من الفيرموير الأصلي مع إعادة قفل البوتلودر. تدعم بعض الأجهزة (Pixel وبعض طرازات OnePlus) إعادة قفل البوتلودر بعد فلاش صور موقّعة من الشركة المصنّعة. وهذا يعيد STRONG_INTEGRITY لكنه يفقدك الروت.
• استخدم جهازاً ثانوياً غير مروّت للعدد القليل من التطبيقات التي تشترط STRONG_INTEGRITY.

لا يوجد خيار ثالث خفي. فتصميم TEE مقصود تحديداً لمنع ذلك.

ما لا نوصي به أبداً

• تشغيل عدة وحدات لتجاوز Play Integrity في الوقت نفسه دون سبب محدد، فهي كثيراً ما تتعارض وتعطّل تطبيقات أكثر مما تصلحه.
• استخدام forks عشوائية من PIF من مصادر مجهولة. التزم بالـ fork الرئيسي الذي يُصان، وراجع مواضيع XDA لمعرفة التوصية الحالية.
• الاعتماد على التجاوز في المعاملات المالية عالية القيمة. استخدم جهازاً احتياطياً غير مروّت للمبالغ التي لا تتحمل خسارتها، واقرأ شروط خدمة بنكك بشأن المسؤولية عن الاحتيال على الأجهزة المروّتة.
• تفعيل الروت لـ Play Store نفسه. لا حاجة إلى وجود Play Store في DenyList، وقد يعطّل ذلك ميزات Play Store دون أي فائدة.

متى تستعين بمختص

إذا كان هناك تطبيق بنكي بعينه يرفض العمل بعد تثبيت الروت وقد جرّبت المجموعة القياسية، فراسلنا عبر WhatsApp أو Telegram. لدينا إعدادات مراجَعة ومعروفة بنجاحها لمعظم البنوك الكبرى في أسواق بنغلاديش والهند وباكستان والمملكة المتحدة والولايات المتحدة والاتحاد الأوروبي، ويمكننا عادةً تشغيل التطبيق في جلسة عن بُعد تستغرق 30 إلى 60 دقيقة. راجع خدمة روت Android لدينا لمعرفة ما تشمله.

أما تفاصيل مستوى الوحدات خلف DenyList وShamiko، فيغطي دليل وحدات Magisk لدينا مجموعة إخفاء Play Integrity الحالية وأي forks لا تزال تُصان.