دليل: الهندسة العكسية للتعتيم على الكود

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

التعتيم على الكود؟

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

لماذا من الضروري التعتيم على الكود؟

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

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

تقنيات التشويش على الكود

يعمل التعتيم على مستويات مختلفة: يمكن تنفيذه على مستوى بنية الكود الدلالية / المعجمي أو على مستوى هيكل البيانات / التحكم في التدفق. تختلف استراتيجيات التعتيم أيضًا اعتمادًا على الإجراء على الكود. في الأساس ، يحدد الفريق الأمني ​​نوع التشويش الذي يجب استخدامه على الكود بالتعاون مع فريق التطوير.

يجب إعادة تسمية التشويش.

يستلزم هذا النهج تسمية المتغيرات بشكل مربك بحيث يتم إخفاء الهدف الفعلي لاستخدامها بذكاء. تواجه برامج فك التشفير صعوبة في فهم تدفق التحكم حيث يتم إعادة تسمية الطرق والمتغيرات باستخدام رموز وأرقام مختلفة. تُستخدم طريقة التشويش هذه بشكل شائع لإخفاء كود تطبيق Java و .NET و Android الأساسي. تم تصنيف هذا على أنه تشويش في التخطيط لأنه يستهدف رمز المصدر مباشرةً لتوفير طبقة حماية للتطبيق.

التعتيم على البيانات

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

1. غموض الجماعة
نتيجة لذلك ، تتغير طريقة حفظ البيانات في البرنامج. يمكن تقسيم المصفوفات ، على سبيل المثال ، إلى مصفوفات فرعية متعددة يمكن الرجوع إليها بعد ذلك خلال البرنامج.

2. التشويش على تخزين البيانات
هذا له تأثير على طريقة تخزين البيانات في الذاكرة. يمكن للمطورين ، على سبيل المثال ، التبديل بين التخزين المتغير المحلي والعالمي لإخفاء الطبيعة الحقيقية للسلوك المتغير.

3. الحصول على التعتيم عند الطلب
يغير هذا الأسلوب ترتيب البيانات دون تغيير وظائف البرنامج / مقتطف الشفرة. يحقق المطورون ذلك عن طريق إنشاء وحدة نمطية مميزة يتم استدعاؤها لكل مثيل لمرجع المتغير.

4. تشفير السلاسل
تقوم هذه التقنية بتشفير جميع السلاسل القابلة للقراءة ، مما ينتج عنه رمز غير مقروء. عند تشغيل البرنامج ، يجب فك تشفيرها في وقت التشغيل.

5. التشويش على التحكم / تدفق الكود
تعد الطريقة التي يتم بها نقل التحكم من جزء من قاعدة البيانات إلى جزء آخر أمرًا بالغ الأهمية في تحديد هدف البرنامج. غالبًا ما يكون التعتيم على هذا التدفق هو الطريقة الأكثر ربحية لإفساد تدفق اللعبة. تعمل استراتيجية التعتيم هذه على إبقاء المتسللين في مأزق عن طريق جعل من الصعب عليهم معرفة كيف ولماذا تتبع الشفرة مسارًا محددًا.

يعد تضمين العبارات العشوائية وغير المتوقعة ، بالإضافة إلى عبارات تبديل الحالة غير الضرورية (رمز ميت) التي لن يتم تنفيذها أبدًا ، أحد أكثر الطرق شيوعًا لإنجاز استراتيجية التشويش هذه. هذه التأكيدات ليس لها وظيفة أخرى سوى إرباك المخترق المستهدف. في حالة التوجيه الشرطي للبرنامج ، يكون هذا التغيير في تسلسل عبارات تنفيذ البرنامج مفيدًا للغاية.

جاري تصحيح أخطاء التعتيم.

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

يجب معالجة التشويش.

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

ترميز شخصي

يستخدم المطورون هذا الأسلوب لتشفير السلاسل باستخدام خوارزمية مخصصة ثم توفير وظيفة وحدة فك ترميز لاستعادة الكود الأصلي.

مرت الحجج في وقت التشغيل

من الممكن تعديل البرنامج بحيث يتوقع المعلمات في وقت التشغيل. لفك تشفير المتغيرات ، يجب أن يكون لدى المستخدم الرمز ومفتاح فك التشفير.

لتطوير طريقة دفاع متعدد الطبقات لحماية التطبيقات من التهديدات الأمنية المتنوعة ، قد يختار فريق الأمان نشر أكثر من أسلوب واحد في نفس الوقت.

خاتمة

باختصار ، التوجيه الخاطئ وحده غير فعال في مكافحة المخاوف الأمنية المتقدمة. من الصعب تفكيك الكود نظرًا لتوفر برنامج ذكاء اصطناعي ومهارة المتسللين ، لكن هذا ليس مستحيلًا. نتيجة لذلك ، لا يعتبر التشفير حلاً سحريًا لجميع مخاوف أمان البرامج.
قد يستخدم فريق التطوير مجموعة متنوعة من أساليب التعتيم على الكود لتأمين الكود الخاص بهم في بيئة غير موثوق بها ، اعتمادًا على الحاجة الأمنية ، وطبيعة البرنامج ، ومعيار الأداء. يجب تنفيذ ذلك مع مراعاة مزايا وعيوب كل نهج. يجب أن تدعم هذه الإستراتيجية مبادرات AppSec الأخرى ، مثل التشفير و RASP ولوائح الاحتفاظ بالبيانات وما إلى ذلك. عندما يتم دمجها مع حلول RASP مثل AppSealing ، فإنها تصبح ترياقًا قويًا للمخاوف الأمنية الحالية.