android - ماهو - متجر ap




كيف تتجنب الهندسة العكسية لملف APK؟ (20)

أقوم بتطوير تطبيق معالجة دفع لنظام Android ، وأريد منع المتطفلين من الوصول إلى أي موارد أو أصول أو شفرة مصدر من ملف APK .

إذا غيّر أحدهم امتداد .apk إلى .zip ، فيمكنه فك ضغطه والوصول إلى جميع موارد وأصول التطبيق بسهولة ، واستخدام dex2jar جافا ، يمكنهم أيضًا الوصول إلى شفرة المصدر. من السهل جدًا إجراء هندسة عكسية لملف APK لنظام Android - لمزيد من التفاصيل ، راجع سؤال Stack Overflow عكس الهندسة من ملف APK إلى مشروع .

لقد استخدمت أداة Proguard المتوفرة مع Android SDK. عندما أعد مهندس ملف APK تم إنشاؤه باستخدام مخزن مفاتيح موقّع و Proguard ، أحصل على شفرة مبهمة. ومع ذلك ، تظل أسماء مكونات Android بدون تغيير ، كما تبقى بعض الرموز ، مثل قيم المفاتيح المستخدمة في التطبيق ، دون تغيير. وفقًا لوثائق Proguard ، لا تستطيع الأداة تشويش المكونات المذكورة في ملف البيان.

الآن أسئلتي هي:

  1. كيف يمكنني تجنب الهندسة العكسية لملف APK Android؟ هل هذا ممكن؟
  2. كيف يمكنني حماية جميع موارد التطبيق وأصوله ورمز المصدر بحيث لا يتمكن الهاكرز من اختراق ملف APK بأي طريقة؟
  3. هل هناك طريقة لجعل القرصنة أكثر صعوبة أو حتى مستحيلة؟ ما الذي يمكنني فعله لحماية رمز المصدر في ملف APK الخاص بي؟

1. كيف يمكنني تجنب الهندسة العكسية لملف APK Android؟ هل هذا ممكن؟

AFAIK ، ليس هناك أي خدعة للتجنب الكامل للهندسة العكسية.

وقال جيد جدا من قبل @ thezaruk: مهما فعلت لرمزك ، يمكن للمهاجمين المحتملين تغييره بأي طريقة وجدها مجدية . لا يمكنك حماية تطبيقك من التعديل في الأساس. وأي حماية تضعها هناك يمكن تعطيلها / إزالتها.

2. كيف يمكنني حماية جميع موارد التطبيق وأصوله وكود المصدر بحيث لا يتمكن الهاكرز من اختراق ملف APK بأي طريقة؟

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

3. هل هناك طريقة لجعل القرصنة أكثر صعوبة أو حتى مستحيلة؟ ما الذي يمكنني فعله لحماية رمز المصدر في ملف APK الخاص بي؟

كما يقول الجميع ، وكما تعرف على الأرجح ، لا يوجد أمان بنسبة 100٪. ولكن مكان البدء في Android ، الذي أنشأته Google ، هو ProGuard. إذا كان لديك خيار تضمين مكتبات مشتركة ، فيمكنك تضمين الشفرة المطلوبة في C ++ للتحقق من أحجام الملفات ، والتكامل ، وما إلى ذلك. إذا كنت بحاجة إلى إضافة مكتبة محلية خارجية إلى مجلد مكتبة APK في كل إصدار ، فيمكنك استخدامه من خلال الاقتراح أدناه.

ضع المكتبة في مسار المكتبة الأصلية الذي يتم تعيينه افتراضيًا على "libs" في مجلد المشروع. إذا بنيت الشفرة الأصلية لهدف "armeabi" ، ضعها تحت libs / armeabi . إذا تم بناؤه باستخدام armeabi-v7a ، ضعه تحت libs / armeabi-v7a.

<project>/libs/armeabi/libstuff.so

1. كيف يمكنني تجنب الهندسة العكسية لملف APK Android؟ هل هذا ممكن؟

غير ممكن

2. كيف يمكنني حماية جميع موارد التطبيق وأصوله وكود المصدر بحيث لا يتمكن الهاكرز من اختراق ملف APK بأي طريقة؟

غير ممكن

3. هل هناك طريقة لجعل القرصنة أكثر صعوبة أو حتى مستحيلة؟ ما الذي يمكنني فعله لحماية رمز المصدر في ملف APK الخاص بي؟

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


1. كيف يمكنني تجنب الهندسة العكسية لملف APK Android؟ هل هذا ممكن؟

هذا مستحيل

2. كيف يمكنني حماية جميع موارد التطبيق وأصوله وكود المصدر بحيث لا يتمكن الهاكرز من اختراق ملف APK بأي طريقة؟

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

إنها أداة رائعة بالفعل ويمكن أن تزيد من صعوبة "عكس" شفرتك بينما تقوم بتقليص بصمة الكود الخاص بك.

دعم ProGuard المتكامل: الآن يتم حزم ProGuard باستخدام أدوات SDK. يمكن للمطورين الآن تشويش التعليمات البرمجية الخاصة بهم كجزء متكامل من إصدار إصدار.

3. هل هناك طريقة لجعل القرصنة أكثر صعوبة أو حتى مستحيلة؟ ما الذي يمكنني فعله لحماية رمز المصدر في ملف APK الخاص بي؟

أثناء البحث ، تعرفت على HoseDex2Jar . هذه الأداة ستحمي شفرتك من إلغاء ترجمتها ، لكن يبدو أنه ليس من الممكن حماية شفرتك بالكامل.

بعض الروابط المفيدة ، يمكنك الرجوع إليها.


القاعدة الأولى لأمن التطبيقات: أي جهاز تمكّن مهاجمًا من الوصول إليه بشكل فعلي أو إلكتروني غير مقيد الآن ينتمي إلى المهاجم ، بصرف النظر عن مكانه الفعلي أو ما دفعته مقابل ذلك.

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

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

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

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

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

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

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

خذ بعين الاعتبار المخطط التالي. يقوم المستخدم بإدخال بيانات اعتمادهم الخاصة بالتطبيق من الذاكرة إلى الجهاز. يجب عليك ، لسوء الحظ ، أن تثق في أن جهاز المستخدم لم يتم اختراقه بالفعل من قِبل كلوغر أو طروادة ؛ أفضل ما يمكنك القيام به في هذا الصدد هو تنفيذ أمان متعدد العوامل ، من خلال تذكر معلومات تعريفية يصعب الكشف عنها حول الأجهزة التي استخدمها المستخدم (MAC / IP ، IMEI ، إلخ) ، وتوفير قناة إضافية واحدة على الأقل التي يمكن التحقق من محاولة تسجيل الدخول على جهاز غير مألوف.

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

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

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

الآن ، الكمبيوتر الذي يريده المهاجم هو الخادم الخاص بك ، لأنه وليس تطبيق / جهاز العميل هو الشيء الذي يمكن أن يجعله مالا أو يسبب ألما آخر لاستمتاعه. هذا حسن؛ تحصل على المزيد من الدوي لجهودكم المال والجهد لتأمين الخادم من محاولة تأمين جميع العملاء. يمكن للخادم أن يكون خلف جميع أنواع جدران الحماية والأمان الإلكتروني الآخر ، بالإضافة إلى أنه يمكن تأمينه بشكل فعلي خلف الفولاذ والخرسانة و keycard / pin والوصول إلى المراقبة بالفيديو على مدار 24 ساعة. سوف يحتاج المهاجم الخاص بك إلى أن يكون متطورًا للغاية بالفعل للحصول على أي نوع من الوصول إلى الخادم مباشرة ، ويجب عليك (معرفته) فورًا.

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


Nothing is secure when you put it on end-users hand but some common practice may make this harder for attacker to steal data.

  • Put your main logic (algorithms) into server side.
  • Communicate with server and client; make sure communication b/w server and client is secured via SSL or HTTPS; or use other techniques key-pair generation algorithms (ECC, RSA). Ensure that sensitive information is remain End-to-End encrypted.
  • Use sessions and expire them after specific time interval.
  • Encrypt resources and fetch them from server on demand.
  • Or you can make Hybrid app which access system via webview protect resource + code on server

Multiple approaches; this is obvious you have to sacrifice among performance and security


100٪ تجنب الهندسة العكسية لـ Android APK غير ممكن ، ولكن يمكنك استخدام هذه الطرق لتجنب استخراج المزيد من البيانات ، مثل شفرة المصدر والأصول التي تشكل ملف APK والموارد الخاصة بك:

  1. استخدم ProGuard لتعتيم رمز التطبيق

  2. استخدم NDK باستخدام C و C ++ لوضع الجزء الأساسي .so من التعليمات البرمجية في ملفات .so

  3. لتأمين الموارد ، لا تُضمِّن جميع الموارد المهمة في مجلد الأصول باستخدام ملف APK. قم بتنزيل هذه الموارد في وقت بدء تشغيل التطبيق لأول مرة.


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

السؤال لا يكشف عن الدافع وراء الرغبة في حماية هذا التطبيق بشيء من الغيرة.

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

إذا كان الهدف هو منع الاستنساخ ، أي أقل من شريحة الحماية من التلاعب ، فلا يوجد أي شيء يمكنك القيام به لحماية البرنامج من إجراء هندسة عكسية ونسخه ، بحيث يشتمل أحدهم على طريقة دفع متوافقة في تطبيقه الخاص ، ترتفع إلى "عملاء غير مصرح بهم". هناك طرق لجعل من الصعب تطوير عملاء غير مصرح بهم. واحد هو إنشاء اختباري يعتمد على لقطات للحالة الكاملة للبرنامج: كل متغيرات الحالة ، لكل شيء. واجهة المستخدم الرسومية والمنطق ، أيا كان. لن يحتوي برنامج النسخ على الحالة الداخلية نفسها بالضبط. من المؤكد أنها آلة حكومية لديها تحولات حالة مرئية خارجية واضحة (كما يمكن ملاحظتها بواسطة المدخلات والمخرجات) ، لكنها بالكاد تكون نفس الحالة الداخلية. يمكن لتطبيق الخادم استجواب البرنامج: ما هي حالتك التفصيلية؟ (أي أعطني المجموع الاختباري على جميع متغيرات الحالة الداخلية الخاصة بك). ويمكن مقارنة ذلك برمز العميل الوهمي الذي ينفذ على الخادم بشكل متواز ، ويمر عبر التحولات الحقيقية للدولة. A third party clone will have to replicate all of the relevant state changes of the genuine program in order to give the correct responses, which will hamper its development.


الإجابات الأخرى المدروسة هنا صحيحة. أنا فقط أريد أن أقدم خيارًا آخر.

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


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

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

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


في ما يلي بعض الأساليب التي يمكنك تجربتها:

  1. استخدام obfuscation والأدوات مثل ProGuard .
  2. تشفير جزء من المصدر والبيانات.
  3. استخدام اختباري يحمل في ثناياه عوامل الملكية في التطبيق للكشف عن العبث.
  4. قدم التعليمات البرمجية لتجنب التحميل في مصحح الأخطاء ، أي السماح للتطبيق بالقدرة على اكتشاف مصحح الأخطاء والخروج / إنهاء المصحح.
  5. قم بفصل المصادقة كخدمة عبر الإنترنت.
  6. استخدم تنوع التطبيقات
  7. استخدم تقنية طباعة الإصبع على سبيل المثال ، توقيعات الأجهزة للأجهزة من نظام فرعي مختلف قبل مصادقة الجهاز.

يمكن للمطورين اتخاذ الخطوات التالية لمنع APK من السرقة بطريقة ما ،

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

  • كما سمعت عن أداة HoseDex2Jar . يتوقف Dex2Jar عن طريق إدخال رمز غير مؤذٍ في ملف APK لنظام Android والذي يربك ويعطل Dex2Jar ويحمي الشفرة من Dex2Jar . يمكن أن تمنع المتسللين بطريقة أو بأخرى من تحويل ملف APK إلى شفرة جافا قابلة للقراءة.

  • استخدم بعض تطبيقات جانب الخادم للتواصل مع التطبيق فقط عند الحاجة إليه. يمكن أن يساعد في منع البيانات الهامة.

على الإطلاق ، لا يمكنك حماية رمزك بالكامل من المتسللين المحتملين. بطريقة ما ، يمكن أن تجعل من الصعب ومهمة محبطة بعض الشيء بالنسبة لهم لفك شفرتك. واحدة من أكثر الطرق فعالية هي الكتابة في الكود الأصلي (C / C ++) وتخزينها كمكتبات مترجمة.


APK signature scheme v2 in Android N

The PackageManager class now supports verifying apps using the APK signature scheme v2. The APK signature scheme v2 is a whole-file signature scheme that significantly improves verification speed and strengthens integrity guarantees by detecting any unauthorized changes to APK files.

To maintain backward-compatibility, an APK must be signed with the v1 signature scheme (JAR signature scheme) before being signed with the v2 signature scheme. With the v2 signature scheme, verification fails if you sign the APK with an additional certificate after signing with the v2 scheme.

APK signature scheme v2 support will be available later in the N Developer Preview.

http://developer.android.com/preview/api-overview.html#apk_signature_v2


Agreed with @Muhammad Saqib here: https://.com/a/46183706/2496464

And @Mumair give a good starting steps: https://.com/a/35411378/474330

It is always safe to assume that everything you distribute to your user's device, belong to the user. Plain and simple. You may be able to use the latest tools and procedure to encrypt your intellectual properties but there is no way to prevent a determined person from 'studying' your system. And even if the current technology may make it difficult for them to gain unwanted access, there might be some easy way tomorrow, or even just the next hour!

Thus, here comes the equation:

When it comes to money, we always assume that client is untrusted.

Even in as simple as an in-game economy. (Especially in games! There are more 'sophisticated' users there and loopholes spread in seconds!)

How do we stay safe?

Most, if not all, of our key processing systems (and database of course) located on the server side. And between the client and server, lies encrypted communications, validations, etc. That is the idea of thin client.


Aren't TPM chips (Trusted Platform Module) supposed to manage protected code for you ? They are becoming common on PCs (especially Apple ones) and they may already exist in today's smartphone chips. Unfortunately there is no OS API to make use of it yet. Hopefully Android will add support for this one day. That's also the key to clean content DRM (which Google is working on for WebM).


Basically it's not possible. It will never be possible. However, there is hope. You can use an obfuscation to make it so some common attacks are a lot harder to carry out including things like:

  1. Renaming methods/classes (so in the decompiler you get types like aa )
  2. Obfuscating control flow (so in the decompiler the code is very hard to read)
  3. Encrypting strings and possibly resources

I'm sure there are others, but that's the main ones. I work for a company called PreEmptive Solutions on a .NET obfuscator. They also have a Java obfuscator that works for Android as well one called DashO .

Obfuscation always comes with a price, though. Notably, performance is usually worse, and it requires some extra time around releases usually. However, if your intellectual property is extremely important to you, then it's usually worth it.

Otherwise, your only choice is to make it so that your Android application just passes through to a server that hosts all of the real logic of your application. This has its own share of problems, because it means users must be connected to the Internet to use your app.

Also, it's not just Android that has this problem. It's a problem on every app store. It's just a matter of how difficult it is to get to the package file (for example, I don't believe it's very easy on iPhones, but it's still possible).


Basically, there are 5 methods to protect your APK. Isolate Java Program, Encrypt Class Files, Convert to Native Codes, Code Obfuscation and Online Encryption I suggest you use online encryption because it is safe and convenient. You needn't spend to much time to achieve this. Such as APK Protect , it is an online encryption website for APK. It provides Java codes and C++ codes protection to achieve anti-debugging and decompile effects. The operation process is simple and easy.


If your app is this sensitive then you should consider the payment processing part at server side. Try to change your payment processing algorithms. Use android app only for collecting and displaying user information (ie account balance) and rather than processing payments within java codes, send this task to your server using a secure SSL protocol with encrypted parameters. Create fully encrypted and secure API to communicate with your server.

Of course, It can also be hacked too and it has nothing to do with source codes protection but consider it another security layer to make it harder for hackers to trick your app.


Its not possible to completely avoid RE but By making them more complex internally, you put make it more difficult for attackers to see the clear operation of the app, which may reduce the number of attack vectors.

If the application handles highly sensitive data, Various techniques exist which can increase the complexity of reverse engineering your code. One technique is to use C/C++ to limit easy runtime manipulation by the attacker. There are ample C and C++ libraries that are very mature and easy to integrate with Android offers JNI. An attacker must first circumvent the debugging restrictions in order to attack the application on a low level. This adds further complexity to an attack. Android applications should have android:debuggable=”false” set in the application manifest to prevent easy run time manipulation by an attacker or malware.

Trace Checking – An application can determine whether or not it is currently being traced by a debugger or other debugging tool. If being traced, the application can perform any number of possible attack response actions, such as discarding encryption keys to protect user data, notifying a server administrator, or other such type responses in an attempt to defend itself. This can be determined by checking the process status flags or using other techniques like comparing the return value of ptrace attach, checking parent process, blacklist debuggers in the process list or comparing timestamps on different places of the program.

Optimizations - To hide advanced mathematical computations and other types of complex logic, utilizing compiler optimizations can help obfuscate the object code so that it cannot easily be disassembled by an attacker, making it more difficult for an attacker to gain an understanding of the particular code. In Android this can more easily be achieved by utilizing natively compiled libraries with the NDK. In addition, using an LLVM Obfuscator or any protector SDK will provide better machine code obfuscation.

Stripping binaries – Stripping native binaries is an effective way to increase the amount of time and skill level required of an attacker in order to view the makeup of your application's low level functions. By stripping a binary, the symbol table of the binary is stripped, so that an attacker cannot easily debug or reverse engineer an application.You can refer techniques used on GNU/Linux systems like sstriping or using UPX.

And at last you must be aware about obfuscation and tools like ProGuard.


There is no way to completely avoid reverse engineering of an APK. To protect application assets, resources, you can use encryption.

  • Encryption will make harder to use it without decryption.choosing some strong encryption algorithm will make cracking harder.
  • Adding some spoof code into your main logic to make more harder for cracking.
  • If you can write your critical logic in any native language and that surely make harder for decompile.
  • Using any third party security frameworks like Quixxi

While I agree there's no 100% solution that's going to protect your code, v3 of HoseDex2Jar is now up if you want to give it a try.





reverse-engineering