هل التعتيم التجارية الخاصة بك جافا رمز ؟ [مغلقة]

Question

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

هل التعتيم?وإذا كان الأمر كذلك, لماذا التعتيم?

هل هو حقا وسيلة لحماية رمز أو هو مجرد شعور أفضل للمطورين/المدراء ؟

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

@ستيفان له وجهة نظر:

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

Answer 1

إذا كنت تفعل التعتيم البقاء بعيدا عن obfuscators أن تعديل التعليمات البرمجية عن طريق تغيير رمز التدفق و/أو إضافة كتل الاستثناء مثل أن تجعل من الصعب تفكيكه.لجعل رمز غير قابل للقراءة وهي عادة ما تكون كافية لمجرد تغيير جميع أسماء الطرق والحقول الطبقات.

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

Answer 2

أعتقد أن القديم (الكلاسيكي) من التشويش تفقد تدريجيا أهميتها.لأنه في معظم الحالات الكلاسيكية obfuscators كسر تتبع المكدس (أنها ليست جيدة بالنسبة دعم العملاء الخاص بك)

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

حقيقة مثيرة للاهتمام:لدينا كل هذه البيانات الحساسة في السلاسل.فعلا سلاسل حوالي 50-80% من منطق من التطبيقات لدينا.يبدو لي أن المستقبل من التشويش هو "سلسلة أدوات التشفير".

ولكن الآن "سلسلة التشفير" الميزة متوفرة فقط في التجاري obfuscators ، مثل: Allatori, Zelix KlassMaster, ستار, ركيزة جافا التشويش أدوات, داشو.

N. B.أنا التنفيذي في Licel ذ. م. م.المطور من بالقطعة جافا Obfuscator.

Answer 3

يمكنني استخدام proguard على JavaME التنمية.انها ليست فقط جيدة جدا جدا في صنع جرة ملفات أصغر (ضروري للجوال) ولكن من المفيد كما أجمل طريقة القيام الجهاز-رمز معين دون اللجوء إلى IDE-ودي تجهيزها أدوات مثل الهوائي.

E. g.

public void doSomething()
{
    /* Generated config class containing static finals: */
    if (Configuration.ISMOTOROLA)
    {
        System.out.println("This is a motorola phone");
    }
    else
    {
        System.out.println("This is not a motorola phone");
    }
}

هذا يحصل المترجمة ، غموض ، وفئة ملف ينتهي كما لو كنت قد كتبت:

public void doSomething()
{
    System.out.println("This is a motorola phone");
}

حتى تتمكن من المتغيرات من قانون العمل حول المصنعة الخلل في JVM/مكتبة تطبيقات دون يستكثر النهائي للتنفيذ فئة ملفات.

وأعتقد أن بعض تجاري obfuscators يمكن أيضا دمج ملفات فئة معا في بعض الحالات.وهذا مفيد لأن أكثر الفئات التي لديها أكبر حجم النفقات العامة في الرمز البريدي (جرة) الملف.

Answer 4

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

    if(i < ll1) goto _L6; else goto _L5
_L5:
    char ac[] = run(stop(lI1l));
    l7 = (long)ac.length << 32 & 0xffffffff00000000L ^ l7 & 0xffffffffL;
    if((int)((l7 & 0xffffffff00000000L) >> 32) != $5$)
    {
        l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
    } else
    {
        for(l3 = (long)III & 0xffffffffL ^ l3 & 0xffffffff00000000L; (int)(l3 & 0xffffffffL) < ll1; l3 = (long)(S$$ + (int)(l3 & 0xffffffffL)) ^ l3 & 0xffffffff00000000L)
        {
            for(int j = III; j < ll1; j++)
            {
                l2 = (long)actionevent[j][(int)(l3 & 0xffffffffL)] & 65535L ^ l2 & 0xffffffffffff0000L;
                l6 = (long)(j << -351) & 0xffffffffL ^ l6 & 0xffffffff00000000L;
                l1 = (long)((int)(l6 & 0xffffffffL) + j) & 0xffffffffL ^ l1 & 0xffffffff00000000L;
                l = (long)((int)(l1 & 0xffffffffL) + (int)(l3 & 0xffffffffL)) << 16 & 0xffffffff0000L ^ l & 0xffff00000000ffffL;
                l = (long)ac[(int)((l & 0xffffffff0000L) >> 16)] & 65535L ^ l & 0xffffffffffff0000L;
                if((char)(int)(l2 & 65535L) != (char)(int)(l & 65535L))
                {
                    l = (long)III << 50 & 0x4000000000000L ^ l & 0xfffbffffffffffffL;
                }
            }

        }

    }

لم تعلم جافا كان غوتو ؟ حسنا, JVM يعتمد عليها =)

Answer 5

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

Answer 6

أعتقد أن الجزء الأكبر من التشويش لا طائل:حتى مع كامل شفرة المصدر عموما من الصعب بما فيه الكفاية لمعرفة ما هيك النية (على افتراض أنه لا توجد تعليقات لا معنى أسماء المتغيرات المحلية -- كما هو الحال عند إعادة توليد مصادر من رمز بايت).التشويش فقط تزين الكعكة.

أعتقد أن المطورين وخاصة المديرين يميلون إلى حد كبير أكثر من المبالغة في المخاطر من شخص رؤية شفرة المصدر.بينما جيد الطفولية يمكن أن تنتج لطيفة تبحث البرمجية المصدر انها ليست تافهة للعمل معها ، والتكاليف المرتبطة بها (ناهيك عن المخاطر القانونية) مرتفعة بما يكفي لجعل هذا النهج أحيانا مفيدة.لدي فقط decompiled لتصحيح مشاكل مغلقة المصدر البائعين المنتجات (الجمود في DB طبقة تجريد, لاف).بايت كود فعلا غموض, أعتقد, ولكن نحن مع ذلك وجدت المشكلة الأساسية -- كان التصميم الفعلي المشكلة.

Answer 7

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