English | 简体中文 | 繁體中文 | Русский язык | Français | Español | Português | Deutsch | 日本語 | 한국어 | Italiano | بالعربية
مبدأ الت打包 المتعدد القنوات باستخدام التوقيع القديم
مقدمة
بسبب إطلاق Android 7.0 لنظام التوقيع الجديد، تم تعزيز تحصين التوقيع، مما أدى إلى عدم القدرة على الاستمرار في ضم ملفات قنوات متعددة باستخدام طريقة Wemei تحت نظام التوقيع الجديد. ومع ذلك، قبل الحديث عن تأثير نظام التوقيع الجديد على خطة الت打包
قبل أن نتعرف على تأثيرات وسبب تأثيرنا على نظام الت打包 الحالي، يجب أن نفهم ببساطة مبادئ الت打包 والوظيفة التي تقوم بها التوقيع في عملية الت打包.
مسار ضم Android
يبدو عملية ضم Android كما هو موضح في الشكل، ويتم خلال هذه العملية دمج كود Java ومستندات الموارد والمكتبات الثالثة في ملف Apk، وتحسين وتنظيم الملف المدمج. يمكن اختصار العملية ببساطة
يتم تقسيم العملية إلى الخطوات التالية:
خطوات إنشاء APK تقريبًا تبدو هكذا، لا نحتاج إلى الاهتمام بالتفاصيل الفنية، فقط يجب أن نفهم هذه العمليات بشكل عام لفهم مبادئ مشروع الت打包 الخاص بنا. بالطبع، يبدو هذا الشكل يجعلنا نعتقد أن APK
هو ملف رائع يمكنه التثبيت والعمل. في الواقع، APK هو نوع من ملفات zip المميزة، يمكن للجهاز الخاص بنا التعرف عليه وتثبيته كتطبيق، يمكننا فك ضغط ملف APK لرؤية محتواه.
يمكن رؤية أن محتوى الملف مشابه لما ذكرناه من قبل، والآن دعونا نرى الأهم من جميع الملفات، وهي الملفات الموجودة في مجلد 第三章图، هذه الملفات موجودة في مجلد META-INF، وهي الملفات التي نضيفها أثناء عملية التوقيع كعلامة فريدة للAPK. وما هو معنى ذلك بالنسبة لتحسين الت打包، لنحافظ على الغموض ونتحدث عن ذلك لاحقًا. قبل فهم هذا، يجب أن نفهم أولاً عملية التوقيع.
دور التوقيع والسبب
دور التوقيع
يتمتع تطبيق Android بمعرف فريد أثناء التطوير، نسميه اسم الحزمة، مثل اسم الحزمة الخاص بالعميل الكبير هو com.Quanr، واسم الحزمة يشبه رقم الهوية الشخصية، وهو مرتبط بكل شخص بشكل مباشر، عند تثبيت التطبيق، يتم تحديد التطبيق من خلال اسم الحزمة أيضًا، لا يمكن لتطبيقين ذاتيًا أن يحتويان على نفس اسم الحزمة في جهاز واحد، هذا هو التميز الفريد للتطبيق في الجهاز. عند تحديث التطبيق، مثل التثبيت المغطى، يتم التعرف على التطبيق والتعامل معه من خلال اسم الحزمة، مما يضمن أن يتم تحديث التطبيق بشكل سلس دون تغطية تطبيقات أخرى، وبالمثل، لا يمكن لتطبيق آخر ذو اسم حزمة مختلف أن يغطي تطبيقنا. على الرغم من أن Android يقدم مجموعة من آليات التعرف على الأسماء، لكن هل يكفي فقط اسم الحزمة. لنفكر في ذلك، إذا قام شخص آخر بإنشاء تطبيق جديد باستخدام اسم حزمةنا لغرض تغطية تطبيقنا أو حتى للهجوم غير المشروع على تطبيقنا
يضيف التطبيق بعض المحتويات الخاصة به، مثل الإعلانات المدمجة للربح، ينشر التطبيق المعدل إلى المستخدمين للتحديث التلقائي، قد نتعرض إلى خسائر كبيرة. بالطبع، لن يحدث هذا الأمر، Google أضاف ميكانيكية التوقيع لكل تطبيق، مثل الذهاب إلى البنك لإنجاز المعاملات، ليس فقط أنك بحاجة إلى تقديم بطاقة الهوية، بل يجب أيضًا التوقيع، يمكن لكل شخص رؤية رقم بطاقة الهوية، لكن التوقيع هو شيء يمكن القيام به فقط من قبلك، لا يمكن للآخرين تقليدك، والتطبيق يضمن بذلك uniqueness و safety الخاصة به.
إذن، كيف يتم تحقيق هذه الأشياء بالتوقيع؟
مبدأ التوقيع
هناك عدة أدوات للتوقيع على APK، ولكن مبادئها متشابهة نسبيًا، هنا نأخذ أداة signapk كمثال، للتوقيع على APK، يمكننا استخدام هذه الأداة مع بعض المعلمات وأيضًا ملف التوقيع الفريد لدينا، يمكن إكمال التوقيع باستخدام الأداة بسهولة، لكننا نحتاج إلى الانتباه أكثر إلى مبادئها وكيفية تنفيذها، لأن هذا يمكن أن يساعدنا في العثور على أسرار إنتاج الحزم. قبل استخدام أداة التوقيع، يجب علينا إعداد مفتاح التوقيع الخاص ومفتاح التوقيع العام (a–(المفتاح الخاص)–>b–(المفتاح العام)–>a)، من الأفضل استخدام الصور لعرض ذلك، ثم استخدام أداة التوقيع لتوقيع APK، بعد ذلك، سيتم إنشاء مجلد META-INF الجديد في APK وإنشاء ثلاثة ملفات فيه، هذه الملفات هي المفتاح لعملية التوقيع والتحقق.
من الصورة يمكننا رؤية أن الثلاثة ملفات هي:
الآن دعونا نتحدث عن كيفية إنشاء هذه الثلاثة ملفات.
MANIFEST.MF
نحن نبدأ بالنظر إلى محتواه، يمكننا رؤية أن هناك قيم SHA1 مرتبطة بالنامات، يمكننا فهم بسهولة أن هذا الملف يحتوي على قيمة فريدة مرتبطة بكل ملف. وظيفة ملف MANIFEST.MF هي كما قلنا من قبل، عند التوقيع على APK، أولاً، سيتم إجراء تشفير رقمي لكل ملف، لإنتاج قيمة SHA1 فريدة، القيم المختلفة للSHA1 تختلف بناءً على محتوى الملفات المختلفة، لذا إذا قام شخص ما بتغيير محتوى الملف، فإن قيمة SHA1 المترتبة عليه ستتغير أيضًا. عند التوقيع على APK، يجب التحقق من كل ملف من ملفاتنا، وإنتاج قيمة SHA1 المترتبة عليه، ثم حفظ هذه المحتويات في ملف MANIFEST.MF جديد، ثم وضع هذا الملف في مجلد META-INF، ويتم إنشاء ملف التوقيع الأول.
CERT.SF
بعد إنشاء ملف MANIFEST.MF، يمكننا تسجيل القيمة الفريدة لكل ملف لدينا، مما يضمن عدم تعديل الملفات، وبالرغم من أن هذا يضمن أمان ملفاتMANIFEST المسجلة، إلا أنه لا يمكن ضمان أمان نفس الملف، يمكن للآخرين تعديل الملفات الموجودة وإنشاء قيمة SHA1 الم对应ة ثم تعديل ملف MANIFEST، لذا يجب علينا تعزيز MANIFEST للحفاظ على الأمان. بعد إنشاء الملف الأول، تبدأ أداة التوقيع في إنشاء الملف الثاني، وهو ملف CERT.RSA. في هذه الخطوة، يتم ت编码 مرة أخرى للملف الذي تم إنشاؤه في الخطوة السابقة، ويتم حفظ النتيجة في رأس ملف CERT.RSA الجديد، ويتم أيضًا ت编码 مرة أخرى لكل كتلة من كتل MANIFEST.MF، ويتم حفظ النتيجة في كتلة واحدة من ملف CERT.SF.
CERT.RSA
هذه الملفات جميعها ثنائية النسق، بعد إنشاء ملف CERT.SF، نستخدم مفتاح السر لتحقيق عملية التشفير على CERT.SF للحصول على التوقيع، نحفظ التوقيع الحاصل ومعلومات التوقيع الرقمي للملف العام في ملف CERT.RSA، وبهذا ينتهي عملية التوقيع.
إليك شرحًا بسيطًا لخطوات التحقق في عملية تثبيت APK، وهي مشابهة جدًا لخطوات إنشاء ملف التوقيع:
من خلال العملية المذكورة أعلاه، يمكن ملاحظة مشكلة واضحة، حيث لم يتم أي ت编码 أو تشفير رقمي لأي ملف داخل مجلد META-INF في هذا السياق، لأن هذا المجلد يتم إنشاؤه أثناء التوقيع، لم يتم ت编码 أي ملف في هذا المجلد عند إنشاء الملف الأول MANIFEST.MF، لأن هذا المجلد يجب أن يكون فارغًا، والملف الثاني يتم إنشاؤه بناءً على الملف الأول، والملف الثالث يتم إنشاؤه بناءً على الملف الثاني، لذا فإن مجلد META-INF كله تقريبًا خارج نطاق التحكم في هذه العملية. يمكننا إضافة بعض الملفات إلى هذا المجلد لتجنب عملية التوقيع هذه. هذا هو نقطة انطلاق حلقة معالجة الملفات المتعددة لمتجر مأموني.
تستخدم Maimai مبادئ التوقيع لإنجاز تعبئة القنوات المختلفة
من خلال فهم عملية التعبئة السابقة، يمكننا معرفة أننا نريد تعبئة أكوام من القنوات بسرعة، لذا يجب تجنب مرحلة التعبئة مباشرة وتحديد السبل لتحرير ملف APK، ولكن هذا يتطلب تحدي قواعد التحقق من التوقيع الخاصة بـ Android، ومع ذلك، وبفضل التحليل الذي قمنا به للعملية التوقيعية، اكتشفنا أنه يمكننا إضافة ملفات عشوائية في مجلد META-INF لتجنب التحقق من قواعد التوقيع، وقد ولدت خطة جديدة، بعد تعبئة ملف APK بدون قنوات، نقوم بالنسخ هذا APK وإضافة ملف في مجلد META-INF، ثم نحدد رقم القناة من خلال اسم الملف، وإضافة ملفات مختلفة في مجلد META-INF في كل APK يمكن تحديد قنوات مختلفة، وبعد ذلك، كل ما علينا القيام به هو الذهاب إلى هذا الملف عند الحاجة إلى معرفات القناة، مما يتيح تجاوز عملية التعبئة هذه تمامًا. إذن، فترة الزمن لهذه الخطة هي مجرد نسخ وإدراج ملف في ملف APK، والذي يمكن القيام به على جهاز كمبيوتر محمول ذو مواصفات عالية في 900 مرة في الدقيقة. لذا، يلزم 4 دقائق لتعبئة قناة واحدة، و100 قناة تحتاج إلى أربعة دقائق وأقل، بالطبع، هذا ليس الحد الأقصى، إذا كان هناك 900 قناة، فإن وقت تعبئة كل قناة يتطلب 900x4 دقائق، بينما تستغرق خطة Maimai 5 دقائق فقط، مما يزيد من الكفاءة بمئات المرات، يمكن القول إن خطة Maimai هي مثالية تحت التوقيع القديم.
تأثير الطريقة الجديدة للتوقيع على الخطة الحالية
بعد Android 7.0، أقدم جوجل على تعزيز أمان التوقيعات من خلال استخدام قواعد التحقق من التوقيع الجديدة، وليس التوجه نحو كل ملف لتحويله إلى شيفرة رقمية كما هو موضح في الشكل التالي:
يتم إجراء التوقيع الجديد بناءً على بنية ملف ZIP للتوصل إلى التوقيع، وبشكل أساسي فإن ملف APK هو ملف ZIP، كما هو موضح في الشكل التالي، يمكن تقسيمه إلى ثلاثة أجزاء قبل التوقيع.
الب partida الزرقاء في الصورة التالية تمثل محتويات مدخلات ZIP، والب partida الوردية تمثل الملف المركزي.
File Entry يعبر عن كيان ملف، يحتوي ملف مضغوط على عدة كيانات ملف.
يُكون الملف المادي من رأس وبيانات الملف (مضغوط، ويُحدد خوارزمية الضغط في الرأس)
يُكون مجلد المركزي من عدة "عناوين الملف"، ويُحفظ لكل "عنوان ملف" موقع م实体ية للملف
يُنتهي الملف بنظام "نهاية مجلد المركزي".
لننظر في دور "نهاية مجلد المركزي"، إنه يحدد موقع "مجلد المركزي" بالنسبة للرأس، لننظر في بيانات التوقيع الجديدة الخاصة بنا "كتلة التوقيع APK" التي يتم وضعها بين "محتويات مدخلات ZIP" و "مجلد المركزي"، إنها بيانات فريدة يتم إنشاؤها بعد تشفير وتوقيع جميع المحتويات الثلاثة للمجلدات غير الموقعة للZIP. يمكن فهمها بناءً على الرقم الم编码 المذكور من قبل، إذا تغير أي محتوى في هذه الثلاثة أجزاء، فإن بيانات هذا الجزء ستكون مختلفة، لذا لا يمكن تعديل أي محتوى في APK بعد التوقيع، ولكن لم نعدل أي محتوى خارج توقيع APK من قبل، لذا في هذه اللحظة، هل يمكن النظر في تعديل محتوى "كتلة التوقيع APK" هذا؟ سنضيف الذيل الصغير فيما بعد. من الواضح أن هذا الأسلوب لا يمكن أن يكون، قلت من قبل أن هناك جزءًا يُدعى "نهاية مجلد المركزي"، إنه يحدد موقع "مجلد المركزي" بالنسبة للرأس، حيث يقع "كتلة التوقيع APK" قبل "مجلد المركزي"، إذا تم تغيير طول "كتلة التوقيع APK"، فإن موقع "مجلد المركزي" بالنسبة للرأس سيغير، وسيتغير المحتوى، وسيتناقض مع المعلومات المحددة في "نهاية مجلد المركزي"، مما يؤدي إلى تدمير كامل حزمة APK. هل يمكن تعديل هذا التحديد؟ بالطبع لا، بعد تعديل هذا التحديد، سيغير "كتلة التوقيع APK" أيضًا، وسيعتمد فقط المطورون الذين يمتلكون ملف التوقيع على الحصول على بيانات "كتلة التوقيع APK" الصحيحة، والذين يرغبون في التلاعب بهذا سيكون عليهم البحث في البحر. هذا هو مبدأ عمل نظام التوقيع الجديد. تحت هذا النظام الجديد، قد تحتاج إشاراتنا القديمة إلى تعديل مناسب.
فكرة تحسين الخطة
لقد قلت من قبل، خطة تعبئةنا الجديدة ستواجه صعوبة مرة أخرى تحت نظام التوقيع الجديد (بالطبع، إذا كنت لا تزال تستخدم التوقيع القديم، فإنك لا تحتاج إلى النظر في هذه المشكلة)، ولكن، لدي Google حيلة، ولدينا سقالة للعبور~
لقد قلت من قبل أن هناك عدة طرق لإضافة حزمة القناة:
تم تحليل ذلك مسبقًا، إذا تم تعديل أي جزء من محتويات ملف zip، فإن APK Signing Block سيغير، مما يجعله غير قادر على تجاوز آلية التوقيع.
لكن هذا لا يهم، آلية التوقيع هي فقط لضمان أمان Apk الخاص بنا، نحن بالتأكيد لا نريد تعديل تطبيقنا بشكل غير قانوني، نحن مطورون، نملك مفتاح السر الخاص بملف التوقيع ومفتاح الجمهور، لأن آلية التوقيع لا يمكن تجاوزها، فإننا نعدل ملف Apk ثم نقوم بتوقيعه مرة أخرى. على الرغم من أن هذا الإجراء ليس بفعالية عالية كما يمكن تجاوز آلية التوقيع، لكن مقارنة بعملية التعبئة التي تستغرق عدة دقائق، فإن هذا الوقت يمكن تقبله. في العادة، يتطلب التوقيع مرة أخرى حوالي ثوانٍ ثلاثة إلى أربعة، مما يجعله مقبولًا ومستمرًا في الاستخدام. بالنسبة لعملية التعبئة التي تستغرق أربعة دقائق، فإن هذا الوقت يمكن تقبله.
بالطبع، هذا هو مجرد خطة تم إنشاؤها بناءً على آلية التوقيع الخاصة بنا، تم تحليلي سابقًا عملية التعبئة والتوقيع بأكملها والآلية، قد يكون هناك طرق أفضل يمكن استخراجها منها، مما يتطلب منا أن نستفيد من أفكارنا الجماعية، نحلل هذه العمليات والأسس بعناية ونفكر في ذلك، قد تجد حلولًا أفضل لتحسين خطة التعبئة الخاصة بنا~
الخلاصة
هذا هو محتوى الكامل حول تأثير التوقيع الجديد لـ Android 7.0 على تعبئة القنوات، آمل أن تكون محتويات هذا المقال قد ساعدت المطورين الأندرويد، إذا كان لديك أي أسئلة، فلا تتردد في ترك تعليق للتفاعل.
البيان: محتوى هذا المقال تم جمعه من الإنترنت، ويتمتع المالك الأصلي بحقوق الطبع والنشر، ويتم جمع المحتوى من قبل المستخدمين عبر الإنترنت الذين يقدمون المساهمات بشكل تلقائي ويتم تحميلها، ويتمتع هذا الموقع بحقوق الملكية، ولا يتم تعديل المحتوى بشكل إنساني، ولا يتحمل هذا الموقع أي مسؤولية قانونية. إذا اكتشفت محتوى يشتبه في انتهاك حقوق النسخ، فلا تتردد في إرسال بريد إلكتروني إلى: notice#oldtoolbag.com (عند إرسال البريد الإلكتروني، يرجى استبدال #بـ @) لتقديم الشكوى، وقدم الدليل على الدليل، وإذا تم التحقق من ذلك، فإن هذا الموقع سيقوم بإزالة المحتوى المزعوم بسرعة.