أكد مطور XDA المعترف به topjohnwu للمستخدمين أن الإصدار التجريبي القادم من Magisk سيجتاز مرة أخرى اختبارات SafetyNet، على الرغم من التغييرات الأخيرة التي أجرتها Google.
في وقت سابق من اليوم، بدأت التقارير ترد عن قيام Google بتحديث خدمات Play الخاصة بها وتسببت في فشل طرق الجذر "الآمنة" الحالية مثل Magisk في عمليات فحص SafetyNet مرة أخرى. وهذا يعني أن الأجهزة التي تحتوي على الجذر والتعديلات الأخرى تم اكتشافها مرة أخرى بواسطة SafetyNet، وبالتالي تم حظرها عند محاولة استخدام التطبيقات المعتمدة على SafetyNet مثل Android Pay.
مطور XDA المعترف به com.topjohnwu لديه تم التعليق عليه في موضوع منتدى Magisk لطمأنة المستخدمين بأنه على علم بالتغييرات وأنه قد أكمل المتطلبات بالفعل تعديلات لتجاوز فحص SafetyNet من Google مرة أخرى مع الاحتفاظ بالجذر ووحدة Magisk وظائف.
في وظيفة التوضيح اللاحقة, com.topjohnwu يذكر أن حالات فشل SafetyNet كانت بسبب قيام Google بجعل اكتشافها أكثر صرامة، لكن المطور كان قادرًا على التغلب على هذه المشكلة. لا توجد حاليًا إصدارات متاحة للمستخدمين لتحديث السياسات الجديدة وتجاوزها حتى الآن، ولكن يمكننا أن نتوقع إصدارًا في المستقبل
. الوضع تحت com.topjohnwuالتحكم، لذلك كل ما يمكننا فعله في الوقت الحالي هو انتظار الإصدار التجريبي التالي من Magisk.Topjohnwu يتوسع أيضًا أنه قد لا توجد أي طريقة فعالة لمنع Magiskhide تمامًا من العمل. لذا، عندما تقدم Google اختبارات جديدة لـ SafetyNet، لا يحتاج magiskhide إلا إلى التحديث ليعود إلى الأمام بخطوة واحدة. أصبح هذا ممكنًا لأن Magisk يمكن تشغيله كجذر، بينما لا يمكن لعمليات التحقق من SafetyNet ذلك. تتيح ميزة الامتياز لـ Magisk مزيدًا من التحكم فيما يمكن أن تراه عملية SafetyNet.
الأمر الصعب هو اكتشاف طريقة جيدة لإخفاء تطبيق Magisk Manager الرئيسي. بدأت العديد من التطبيقات في اكتشاف وجود تطبيق Magisk Manager من خلال اسم الحزمة الخاصة به، حيث يتيح Android لأي تطبيق معرفة التطبيقات الأخرى المثبتة على الجهاز. يعد هذا "الفحص" بدائيًا إلى حد ما لأن تغيير أسماء الحزم يعد مهمة تافهة لمطور التطبيق الرئيسي (على الرغم من أنه يظل قرارًا له عيوبه الخاصة). كما أن مجرد تثبيت تطبيق معين لا يثبت بشكل جوهري وجود تعديلات، وبالتالي فإن "الفحص" ينتج أيضًا قدرًا لا بأس به من النتائج الإيجابية الخاطئة.
ولكن نظرًا لأن هذا النوع من التحقق بدائي، فإن تنفيذه يعد أمرًا سهلاً للمطورين الذين يبحثون عن أجهزة "خالية من التعديلات" لتطبيقاتهم. يمكن لـ Magisk إخفاء نفسه من هذه التطبيقات بمجرد تغيير اسم الحزمة الخاصة به، ولكن يمكن للتطبيقات بعد ذلك البدء في التحقق من اسم الحزمة المعدلة؛ وهكذا دواليك، وبالتالي لا تقدم أي نهاية حقيقية لهذه المشكلة لأي من الجانبين.
الحل المحتمل لـ Magisk ضد هذا الفحص البدائي هو إدخال التعليمات البرمجية في PackageManager لنظام Android لتصفية Magisk Manager من قائمة التطبيقات المثبتة. يمكن القيام بذلك إما من خلال Xpose (ولكن Xpose نفسه يكسر SafetyNet، ويقتصر Xpose على إصدارات Android الأقدم) أو عن طريق تصحيح كود Java الخاص بإطار العمل مباشرة من خلال تعديل oat/dex ملفات.
في الوقت الراهن، Topjohnwu لا يرغب موقع magiskhide في التركيز على تجاوز عمليات التحقق الأولية هذه حيث أن نقطة الاهتمام الرئيسية لـ magiskhide هي تجاوز عمليات فحص SafetyNet من Google. يمكن للمستخدمين التطلع إلى تحديث قريبًا سيسمح للتطبيقات المعتمدة على SafetyNet ببدء العمل مرة أخرى جنبًا إلى جنب مع وحدات الجذر وMagisk، على الرغم من أننا نطلب من المستخدمين عدم إزعاج المطور من خلال طلب الوصول إلى الوقت المتوقع نفس الشيء.
ما هي أفكارك حول لعبة القط والفأر هذه بين SafetyNet من Google وMagiskhide؟ اسمحوا لنا أن نعرف في التعليقات أدناه!
المصدر: منتديات ماجيسك