إنشاء برامج جافا غير قابلة للهندسة العكسية
https://stackoverflow.com/questions/149937
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
هل هناك طريقة لنشر برنامج Java بتنسيق غير قابل للهندسة العكسية؟
أعرف كيفية تحويل تطبيقي إلى ملف JAR قابل للتنفيذ، ولكنني أريد التأكد من عدم إمكانية إجراء هندسة عكسية للكود، أو على الأقل ليس بسهولة.
لا يتم احتساب تشويش الكود المصدري ...فهو يزيد من صعوبة فهم الكود، لكنه لا يخفيه.
سؤال ذو صلة هو كيفية قفل فئات Java المترجمة لمنع إلغاء الترجمة؟
بمجرد الانتهاء من البرنامج، سيظل بإمكاني الوصول إلى المصدر الأصلي، لذا لن تكون صيانة التطبيق هي المشكلة.إذا تم توزيع التطبيق، فلا أريد أن يتمكن أي من المستخدمين من فك ترجمته.لا يحقق التشويش ذلك لأن المستخدمين سيظلون قادرين على فك ترجمته، وعلى الرغم من أنهم سيواجهون صعوبة في متابعة تدفقات الإجراء، إلا أنهم سيكونون قادرين على رؤية الكود، ومن المحتمل أن يأخذوا معلومات منه.
ما يقلقني هو ما إذا كانت هناك أي معلومات في الكود تتعلق بالوصول عن بعد.يوجد مضيف يتصل به التطبيق باستخدام معرف المستخدم وكلمة المرور المقدمة من قبل المستخدم.هل هناك طريقة لإخفاء عنوان المضيف عن المستخدم، إذا كان هذا العنوان موجودًا داخل كود المصدر؟
المحلول
يمكنك التعتيم على ملف JAR الخاص بك باستخدام YGuard. لا يحجب كود المصدر الخاص بك, ، ولكن الفئات المترجمة، لذلك لا توجد مشكلة في الحفاظ على الكود لاحقًا.
إذا كنت تريد إخفاء بعض السلاسل، فيمكنك تشفيرها، مما يجعل من الصعب الحصول عليها من خلال النظر إلى الكود المصدري (من الأفضل أن تقوم بتشويش ملف JAR).
نصائح أخرى
الإجابة المختصرة هي "لا، غير موجودة".
الهندسة العكسية هي عملية لا تعني النظر إلى الكود على الإطلاق.إنها تحاول بشكل أساسي فهم الآليات الأساسية ثم تقليدها.على سبيل المثال، هذه هي الطريقة التي تظهر بها JScript من مختبرات MS، عن طريق نسخ سلوك JavaScript الخاص بـ Netscape، دون الوصول إلى التعليمات البرمجية.كانت النسخة مثالية جدًا لدرجة أنه تم نسخ الأخطاء أيضًا.
إذا كنت تعرف الأنظمة الأساسية التي تستهدفها، فاحصل على شيء يقوم بتجميع Java الخاص بك إلى تعليمات برمجية أصلية، مثل اكسلسيور جيت أو GCJ.
وبخلاف ذلك، لن تتمكن أبدًا من إخفاء كود المصدر، نظرًا لأن المستخدم لديه دائمًا رمز البايت الخاص بك ويمكنه جاد هو - هي.
أنت تكتب بلغة تعتبر الاستبطان جزءًا من اللغة الأساسية.إنه يولد .class الملفات ذات المواصفات المعروفة على نطاق واسع (وبالتالي تمكين البائعين الآخرين من إنتاج تطبيقات غرفة نظيفة لمترجمي ومترجمي Java).
هذا يعني أن هناك برامج فك ترجمات متاحة للعامة.كل ما يتطلبه الأمر هو القليل من عمليات البحث على Google، وسيكون لديك بعض أكواد Java التي تفعل نفس الشيء الذي تفعله كودك.فقط بدون التعليقات وبعض أسماء المتغيرات (لكن أسماء الوظائف تظل كما هي).
في الواقع، التشويش هو كل ما يمكنك الحصول عليه (على الرغم من أن التعليمات البرمجية التي تم فك ترجمتها ستكون مبهمة قليلاً بالفعل) دون الانتقال إلى لغة C أو أي لغة أخرى مجمعة بالكامل، على أي حال.
لا تستخدم لغة مترجمة؟ما الذي تحاول حمايته على أي حال؟إذا كان ذا قيمة كافية، فيمكن إجراء هندسة عكسية لأي شيء.إن فرص وجود شخص يهتم بما يكفي لإجراء هندسة عكسية لمعظم المشاريع ضئيلة للغاية.يوفر التشويش الحد الأدنى من العوائق على الأقل.
تأكد من أن الخاص بك الملكية الفكرية (IP) محمي عبر آليات أخرى.بالنسبة لرمز الأمان بشكل خاص، من المهم أن يتمكن الأشخاص من فحص عمليات التنفيذ، بحيث يكون الأمان في الخوارزمية، وليس في المصدر.
أميل إلى السؤال عن سبب رغبتك في القيام بذلك، لكنني سأترك ذلك وشأنه...
المشكلة التي أراها هي أن JVM، مثل CLR، يجب أن يكون قادرًا على ترجمة التعليمات البرمجية الخاصة بك من أجل تجميع JIT وتشغيله.يمكنك جعل الأمر أكثر "تعقيدًا" ولكن نظرًا لأن مواصفات الرمز الثانوي موثقة جيدًا إلى حد ما، وموجودة على مستوى أعلى بكثير من شيء مثل مواصفات المجمع x86، فمن غير المحتمل أن تتمكن من "إخفاء" تدفق العملية، نظرًا لأنه حصل على ليكون هناك للبرنامج للعمل في المقام الأول.
لا يمكن القيام بذلك.
يمكن إلغاء تجميع أي شيء يمكن تجميعه.أفضل ما يمكنك فعله هو التعتيم على الجحيم.
ومع ذلك، هناك بعض الأشياء المثيرة للاهتمام التي تحدث في التشفير الكمي.في الأساس، أي محاولة لقراءة الرسالة تغيرها.لا أعرف ما إذا كان يمكن تطبيق ذلك على الكود المصدري أم لا.
حتى إذا قمت بترجمة التعليمات البرمجية إلى لغة الآلة الأصلية، فهناك جميع أنواع البرامج التي تتيح لك فك ترجمتها بشكل أساسي إلى لغة التجميع ومتابعة تدفق العملية (OlyDbg، IDA Pro).
تحويلها إلى خدمة ويب.إذن أنت الوحيد الذي يمكنه رؤية الكود المصدري.
لا يمكن القيام بذلك.هذه ليست مشكلة جافا.أي لغة يمكن ترجمتها يمكن فك ترجمتها لـ Java، الأمر أسهل.
أنت تحاول أن تُظهر لشخص ما صورة دون أن تظهره فعليًا.ليس من الممكن.لا يمكنك أيضًا إخفاء مضيفك حتى لو قمت بالاختباء على مستوى التطبيق.لا يزال بإمكان شخص ما الاستيلاء عليها عبر وايرشارك أو أي شبكة أخرى الشم.
كما قال أحد الأشخاص أعلاه، يمكن للهندسة العكسية دائمًا فك الملف القابل للتنفيذ.الطريقة الوحيدة لحماية كود المصدر (أو الخوارزمية) هي عدم توزيع الملف القابل للتنفيذ.
افصل تطبيقك إلى رمز خادم وتطبيق عميل، وقم بإخفاء الجزء المهم من الخوارزمية الخاصة بك في رمز الخادم الخاص بك وقم بتشغيله في خادم سحابي، ما عليك سوى توزيع رمز العميل الذي يعمل فقط كمرسل ومرسل بيانات.
بهذا يتم فك شفرة رمز العميل الخاص بك.أنت لا تخسر أي شيء.
ولكن من المؤكد أن هذا سوف يقلل من الأداء وراحة المستخدم.
أعتقد أن هذا قد لا يكون هو الجواب الذي تبحث عنه، ولكن فقط لإثارة فكرة مختلفة حول حماية كود المصدر.
مع أي شيء يتم تفسيره في مرحلة ما، يجب معالجته "بشكل واضح".ستظهر السلسلة واضحة كاليوم بمجرد تشغيل الكود من خلال JAD.يمكنك نشر مفتاح تشفير مع تطبيقك أو إجراء تشفير قيصري أساسي لتشفير معلومات اتصال المضيف وفك التشفير في وقت التشغيل...
ولكن في مرحلة ما أثناء معالجة معلومات اتصال المضيف يجب أن تكون واضحة حتى يتمكن تطبيقك من الاتصال بالمضيف...
لذلك يمكنك إخفاؤه بشكل ثابت، لكن لا يمكنك إخفاؤه أثناء وقت التشغيل إذا كانوا يقومون بتشغيل مصحح أخطاء
هذا مستحيل.سيتعين على وحدة المعالجة المركزية تنفيذ البرنامج الخاص بك، أي.يجب أن يكون برنامجك بتنسيق يمكن لوحدة المعالجة المركزية فهمه.وحدات المعالجة المركزية أغبى بكثير من البشر.لذا، إذا كانت وحدة المعالجة المركزية قادرة على فهم برنامجك، فيمكن للبشر ذلك.
بسبب مخاوفي بشأن إخفاء الرمز، كنت سأهرب بروجارد على أي حال.
