من الرائع أن نرى الاعتماد المتزايد لتثبيت الشهادات في تطبيقات Android. عندما أواجه تطبيقًا يتسبب في حدوث أخطاء في الاتصال أثناء محاولة تقديم طلبات الوكيل، فإنني أميل إلى أن أصبح أكثر اهتمامًا بالتعمق أكثر. كان هذا هو الحال عندما استخدمت تطبيق Subway مؤخرًا. كشف عكس APK عن تثبيت الشهادة من بين بعض النتائج الأخرى المثيرة للاهتمام.
تسبب بدء تشغيل التطبيق أثناء إنشاء وكيل للطلبات في حدوث هذا الخطأ:
التثبيت بسيط بما يكفي لتجاوزه. لقد بدأت بتفكيك التطبيق وتحليل الكود المصدري لتثبيت الكلمات الرئيسية. لقد وجدت بالفعل تثبيت التطبيقات في فئتين منفصلتين تم تنفيذهما X509TrustManager. فيما يلي إحدى الطرق التي فرضت التثبيت:
// Code removed at request of Subway leadership
كان تجاوز ذلك أمرًا بسيطًا مثل إضافة عبارة إرجاع في كود smali لتخطي رمز التثبيت بالطريقة المذكورة أعلاه. لاحظ إضافة عودة فارغة بيان أدناه:
// Code removed at request of Subway leadership
بعد إعادة ترجمة التطبيق وتثبيته، تفاجأت برؤية هذا الخطأ الجديد:
كانت شركة Subway تستخدم عملية مخصصة للتحقق من توقيع التطبيق لمنع عكس ملف APK الخاص بها. من خلال الحصول على مصدر الإشارات إلى هذه العملية، قمت بتتبعها إلى الطريقة التالية:
// Code removed at request of Subway leadership
كانت هذه محاولة مثيرة للاهتمام لمنع الهندسة العكسية، على الرغم من أنها تسببت في تأخير بسيط فقط. لتجاوز هذه العملية، قمت ببساطة بإضافة سطر لتخطي تنفيذ الطريقة عن طريق إضافة سطر آخر عودة فارغة خط، مشابه لعملية تجاوز التثبيت المذكورة أعلاه.
// Code removed at request of Subway leadership
بعد إعادة ترجمة التطبيق وتثبيته، تمكنت من تلبية طلبات الوكيل بنجاح:
خلال بحثي تعثرت هذا رديت وظيفة. ومن الواضح أن Subway كان يحدد أيضًا ما إذا كان جهاز المستخدم قد تم تجذيره أم لا. لقد بحثت في المصدر وأكدت الإشارات إلى طرق اكتشاف الجذر.
// Code removed at request of Subway leadership
يعد هذا مثالًا رائعًا لتطبيق يأخذ الأمان على محمل الجد، لكنني لست متأكدًا تمامًا من السبب وراء عملية التحقق من الجذر. على الرغم من أن تقنيات تثبيت الشهادات والتحقق من التوقيع تعتبر فكرة جيدة بشكل عام، إلا أنها تعيق عملية الهندسة العكسية قليلاً.