रिवर्स इंजीनियरिंग से निष्पादन योग्य की रक्षा करना?


210

मैं इस बात पर विचार कर रहा हूं कि अपने C / C ++ कोड को disassembly और रिवर्स इंजीनियरिंग से कैसे बचाया जाए। आम तौर पर मैं इस व्यवहार को कभी भी अपने कोड में शामिल नहीं करूंगा; हालाँकि, मैं जिस मौजूदा प्रोटोकॉल पर काम कर रहा हूँ, उसे विभिन्न लोगों की सुरक्षा के लिए कभी भी निरीक्षण या समझने योग्य नहीं होना चाहिए।

अब यह मेरे लिए एक नया विषय है, और इंटरनेट रिवर्स इंजीनियरिंग के खिलाफ रोकथाम के लिए वास्तव में संसाधनपूर्ण नहीं है , बल्कि इंजीनियर को रिवर्स करने के तरीके के बारे में जानकारी को दर्शाया गया है।

मैंने अभी तक जिन चीजों के बारे में सोचा है उनमें से कुछ हैं:

  • कोड इंजेक्शन (वास्तविक फ़ंक्शन कॉल से पहले और बाद में डमी फ़ंक्शन को कॉल करना)
  • कोड अवरोधन (द्विआधारी के disassembly का प्रबंधन करता है)
  • मेरी खुद की स्टार्टअप दिनचर्या लिखें (डिबगर के लिए बाध्य करने के लिए कठिन)

    void startup();  
    int _start()   
    {  
        startup( );  
        exit   (0)   
    }  
    void startup()  
    {  
        /* code here */  
    }
    
  • डिबगर्स के लिए रनटाइम जांच (और यदि पता चला है तो बल से बाहर निकलें)

  • समारोह trampolines

     void trampoline(void (*fnptr)(), bool ping = false)  
     {  
       if(ping)  
         fnptr();  
       else  
         trampoline(fnptr, true);  
     }
    
  • व्यर्थ आबंटन और सौदेबाजी (ढेर सारे बदलाव)

  • व्यर्थ डमी कॉल और trampolines (disassembly उत्पादन में कूद का टन)
  • कास्टिंग के टन (obfuscated disassembly के लिए)

मेरा मतलब है कि ये कुछ चीजें हैं जिनके बारे में मैंने सोचा है, लेकिन वे सभी के आसपास काम कर सकते हैं या कोड विश्लेषकों द्वारा सही समय सीमा दी गई है। क्या मेरे पास और कोई विकल्प है?


172
"हालांकि, मैं जिस मौजूदा प्रोटोकॉल पर काम कर रहा हूं, उसे कभी भी विभिन्न लोगों की सुरक्षा के लिए निरीक्षण या समझने योग्य नहीं होना चाहिए।" -- उसके साथ अच्छा भाग्य।
अंबर

62
आप रिवर्स इंजीनियर के लिए अपने आवेदन को कठिन बना सकते हैं। आप इसे असंभव नहीं बना सकते, जब तक कि दूसरे व्यक्ति के हाथों में आपके बिट्स का एक बड़ा हिस्सा न हो। पूर्ण सुरक्षा की गारंटी के बारे में सावधान, खासकर अगर जीवन दांव पर है - आप वितरित नहीं कर सकते।
माइकल पेट्रोत्ता

127
यदि आपका कंप्यूटर कोड को समझ सकता है, तो एक व्यक्ति कर सकता है।
ऑर्बिट

78
कोड ओपन सोर्स बनाएं, और कोई भी इसे रिवर्स इंजीनियर नहीं करेगा।
उपयोगकर्ता अज्ञात

28
"अस्पष्टता से सुरक्षा ने कभी काम नहीं किया।"
बॉट 47

जवाबों:


151

अम्बर ने जो कहा वह बिल्कुल सही है। आप रिवर्स इंजीनियरिंग को कठिन बना सकते हैं, लेकिन आप इसे कभी नहीं रोक सकते। आपको "सुरक्षा" पर भरोसा नहीं करना चाहिए जो रिवर्स इंजीनियरिंग की रोकथाम पर निर्भर करता है

उस ने कहा, सबसे अच्छी एंटी-रिवर्स इंजीनियरिंग तकनीकें जो मैंने देखी हैं, उन्होंने कोड को बाधित करने पर ध्यान केंद्रित नहीं किया है, बल्कि उन उपकरणों को तोड़ने पर जो लोग आमतौर पर यह समझने के लिए उपयोग करते हैं कि कोड कैसे काम करता है। डिस्सेम्बलर्स, डिबगर, आदि को तोड़ने के लिए रचनात्मक तरीके ढूंढना दोनों ही अधिक प्रभावी होने की संभावना है और साथ ही भयानक स्पेगेटी कोड के केवल उत्पन्न करने की तुलना में अधिक बौद्धिक रूप से संतोषजनक है। यह एक निर्धारित हमलावर को अवरुद्ध करने के लिए कुछ भी नहीं करता है, लेकिन यह इस संभावना को बढ़ाता है कि जे रैंडम क्रैकर भटक जाएगा और इसके बजाय कुछ आसान काम करेगा।


14
मैं इसे समझता हूं, और मैंने स्काइप सुरक्षा पर कुछ पेपरों को पढ़ा है और समझाया गया है और मैं उन विचारों पर विचार कर रहा हूं जो स्काइप ने पहले से ही मेरे प्रोटोकॉल को रोकने के लिए नहीं बल्कि एक विधि के रूप में कोशिश की है। कुछ ऐसा है जो काफी योग्य साबित हुआ है जो स्काइप के लिए स्पष्ट परिस्थितियां हैं।
ग्रेफाइटमास्टर

8
स्काइप वास्तव में पहला उदाहरण है जो दिमाग में आया था, इसलिए मुझे खुशी है कि आप पहले से ही उनके तरीकों का अनुकरण कर रहे हैं।
Ricket

176

लेकिन वे सभी के आसपास काम किया जा सकता है या सही समय सीमा को देखते हुए कोड एनालिस्टों द्वारा पता लगाया जा सकता है।

यदि आप लोगों को एक कार्यक्रम देते हैं जिसे वे चलाने में सक्षम हैं, तो वे इसे पर्याप्त समय दिए गए रिवर्स-इंजीनियर करने में सक्षम होंगे। यही कार्यक्रमों की प्रकृति है। जैसे ही बाइनरी किसी ऐसे व्यक्ति के लिए उपलब्ध होती है जो इसे समझना चाहता है, आप अंततः रिवर्स-इंजीनियरिंग को रोक नहीं सकते हैं। आखिरकार, इसे चलाने के लिए कंप्यूटर को इसे समझने में सक्षम होना चाहिए, और एक इंसान केवल एक धीमा कंप्यूटर है।


113
+1। Apple II पर कॉपी प्रोटेक्शन के गौरव के दिनों के बारे में पढ़ें, ऑबफ्यूज़र्स और क्रैकर्स के बीच लगातार बढ़ते युद्ध, फ्लॉपी डिस्क के स्टेपर मोटर और अनजाने में 6502 निर्देशों के साथ पागल चालें और इसी तरह और फिर खुद को रोना नींद, क्योंकि आप लगभग इतने विस्तृत रूप से कुछ भी लागू नहीं करने जा रहे हैं और वे सभी अंततः टूट गए।
निमो

2
एक सिम्युलेटर का उपयोग करना आसान है और इंजीनियर को नेत्रहीन या डिस्सेम्बलर के साथ रिवर्स करने की कोशिश से बेहतर दृश्यता प्राप्त करना है। यदि सुरक्षा आपके द्वारा उपयोग किए जा रहे हार्डवेयर में नहीं बनाई गई है, तो मुझे लगता है कि इंजीनियर को उलटने और बाहर आने वाली हर चीज को हराने के लिए दुनिया लगभग दो दिन से दो सप्ताह तक औसत है। यदि इसे बनाने और कार्यान्वित करने में आपको दो दिन से अधिक समय लगता है, तो आपने बहुत अधिक समय बिताया है।
old_timer

5
केवल उचित रूप से कार्य करने वाला DRM आज एक कुंजी और एक इंटरनेट सर्वर का संयोजन है जो यह सत्यापित करता है कि कुंजी का केवल एक उदाहरण एक समय पर सक्रिय है।
थोरबजोरन रावन एंडरसन 20

2
@ रॉटर्स: कंप्यूटर इसे समझ नहीं सकता क्योंकि हम इस प्रकार की बुद्धिमत्ता को एक एल्गोरिथ्म (अभी तक) में कम नहीं कर पाए हैं, इसलिए नहीं कि इसमें किसी प्रकार का भौतिक या तकनीकी अवरोध है। मानव इसे समझ सकता है क्योंकि वह कुछ भी कर सकता है ( कारण के रूप में धीमी) कंप्यूटर कर सकता है
एडम रॉबिन्सन

3
जिस बिंदु पर कोई व्यक्ति कंप्यूटर को रिवर्स-इंजीनियर करने की कोशिश करेगा, जब तक कि यह केवल आपके द्वारा नियंत्रित वातावरण में उपलब्ध न हो।
अंबर

41

सुरक्षित नेट प्रहरी (पूर्व में अलादीन)। कैविट्स हालांकि - उनके एपीआई बेकार है, प्रलेखन बेकार है, और उन दोनों को अपने एसडीके उपकरण की तुलना में महान हैं।

मैंने कई वर्षों से उनकी हार्डवेयर सुरक्षा पद्धति ( सेंटिनल एचएसपी एचएल ) का उपयोग किया है। इसके लिए एक मालिकाना USB कुंजी फ़ॉब की आवश्यकता होती है जो सॉफ़्टवेयर के लिए 'लाइसेंस' के रूप में कार्य करता है। उनके एसडीके आपके निष्पादन योग्य और पुस्तकालयों को एन्क्रिप्ट और बाधित करते हैं, और आपको कुंजी में जलाई गई सुविधाओं के लिए अपने आवेदन में विभिन्न विशेषताओं को टाई करने की अनुमति देते हैं। लाइसेंसकर्ता द्वारा प्रदान की और सक्रिय की गई USB कुंजी के बिना, सॉफ्टवेयर डिक्रिप्ट नहीं कर सकता है और इसलिए नहीं चलेगा। कुंजी भी एक अनुकूलित USB संचार प्रोटोकॉल का उपयोग करती है (मेरे ज्ञान के दायरे के बाहर, मैं एक डिवाइस ड्राइवर आदमी नहीं हूं) एक वर्चुअल कुंजी बनाने में मुश्किल है, या रनटाइम आवरण और कुंजी के बीच संचार के साथ छेड़छाड़ करना। उनका एसडीके बहुत डेवलपर अनुकूल नहीं है, और एक स्वचालित निर्माण प्रक्रिया (लेकिन संभव) के साथ सुरक्षा को जोड़ने के लिए काफी दर्दनाक है।

इससे पहले कि हम एचएसपी एचएल सुरक्षा को लागू करते, 7 ज्ञात समुद्री डाकू थे जिन्होंने उत्पाद से डॉटफसकेटर 'सुरक्षा' को छीन लिया था। हमने सॉफ़्टवेयर में एक प्रमुख अपडेट के रूप में एक ही समय में एचएसपी सुरक्षा को जोड़ा, जो वास्तविक समय में वीडियो पर कुछ भारी गणना करता है। जैसा कि सबसे अच्छा मैं प्रोफाइलिंग और बेंचमार्किंग से बता सकता हूं, एचएएसपी एचएल सुरक्षा ने केवल गहन गणना को लगभग 3% धीमा कर दिया। चूंकि उस सॉफ्टवेयर को लगभग 5 साल पहले जारी किया गया था, इसलिए उत्पाद का एक भी नया समुद्री डाकू नहीं मिला है। यह जिस सॉफ्टवेयर की सुरक्षा करता है, वह बाजार खंड में इसकी उच्च मांग में है, और ग्राहक कई प्रतियोगियों को सक्रिय रूप से रिवर्स इंजीनियर (अब तक सफलता के बिना) की कोशिश करने के बारे में पता है। हम जानते हैं कि उन्होंने रूस में कुछ समूहों से मदद लेने की कोशिश की है जो सॉफ्टवेयर सुरक्षा को तोड़ने के लिए एक सेवा का विज्ञापन करते हैं,

हाल ही में हमने एक छोटे प्रोजेक्ट पर उनके सॉफ्टवेयर लाइसेंस समाधान (एचएएसपी एसएल) की कोशिश की थी, जो सीधा काम करने के लिए पर्याप्त था यदि आप पहले से ही एचएल उत्पाद से परिचित हैं। यह काम करने के लिए प्रकट होता है; पाइरेसी की कोई घटना सामने नहीं आई है, लेकिन यह उत्पाद मांग में काफी कम है।

बेशक, कोई भी सुरक्षा सही नहीं हो सकती। यदि कोई व्यक्ति पर्याप्त रूप से प्रेरित है और उसके पास जलाने के लिए गंभीर नकदी है, तो मुझे यकीन है कि एचएएसपी द्वारा की गई सुरक्षा को दरकिनार किया जा सकता है।


19
मॉडरेटर नोट: इस जवाब के तहत टिप्पणियों को विरोधी शोर में पचने के कारण हटा दिया गया है।
टिम पोस्ट

2
अनुभव के लिए +1, लेकिन मैं कहना चाहता हूं कि यह सही नहीं है। माया (3 डी सूट) ने एक हार्डवेयर डोंगल का उपयोग किया (यदि यह एचएएसपी है तो निश्चित नहीं है), जो बहुत लंबे समय तक समुद्री डाकू का पता नहीं लगाता था। जहां चाह वहां राह।
रॉबर्ट फ्रेजर

1
ऑटोकैड एक समान प्रणाली का उपयोग करता है, जिसे कई बार क्रैक किया गया है। एचएएसपी और इसके जैसे अन्य लोग ईमानदार लोगों को ईमानदार रखेंगे, और आकस्मिक चोरी को रोकेंगे। यदि आप अगले कई-बिलियन डॉलर के डिज़ाइन उत्पाद का निर्माण कर रहे हैं, तो आपके पास हमेशा पटाखे होंगे । इसके सभी कम रिटर्न के बारे में - कितने घंटे के प्रयास के लिए यह आपके सॉफ़्टवेयर संरक्षण को क्रैक करने के लायक है।
रयान

6
मैं किसी ऐसे व्यक्ति के दृष्टिकोण से झंकार करना चाहता हूं जिसने एचएएसपी सुरक्षित सॉफ़्टवेयर का उपयोग किया है। एचएसपी अंत उपयोगकर्ता के लिए गधे में एक शाही दर्द है । मैं एक डलास iButton और एक अलादीन कुंडी के साथ पेश किया है, और दोनों थे वास्तव में गाड़ी, और बेतरतीब ढंग से रोकने, काम की आवश्यकता होती है डिस्कनेक्ट करने और कुंडी फिर से कनेक्ट करने के लिए सॉफ्टवेयर का कारण बना।
नकली नाम

4
इसके अलावा, यह ध्यान देने योग्य है कि जरूरी नहीं कि एचएएसपी सुरक्षा उपाय किसी भी अधिक सुरक्षित हैं तो कोड अवरोधन - सुनिश्चित करें कि उन्हें रिवर्स इंजीनियर के लिए एक अलग कार्यप्रणाली की आवश्यकता है, लेकिन उन्हें रिवर्स करना बहुत संभव है - देखें: flylogic.net/blog/?p/14 flylogic.net/blog/?p=16 flylogic.net/blog/?p=11
नकली नाम

22

विशेष रूप से सबसे अच्छा एंटी डिस्मेम्बलर ट्रिक्स, कोडांतर शब्द / मशीन कोड में हैं, उदाहरण के लिए, सी। उदाहरण के लिए नहीं

CLC
BCC over
.byte 0x09
over:

Disassembler को समस्या का समाधान करना है कि एक शाखा गंतव्य एक बहु बाइट अनुदेश में दूसरा बाइट है। एक निर्देश सेट सिम्युलेटर को हालांकि कोई समस्या नहीं होगी। गणना किए गए पतों की शाखा, जो आप C से पैदा कर सकते हैं, यह भी असम्पीडित को मुश्किल से असंभव बना देता है। निर्देश सेट सिम्युलेटर को इससे कोई समस्या नहीं होगी। आप के लिए शाखा स्थलों को छाँटने के लिए एक सिम्युलेटर का उपयोग करना disassembly प्रक्रिया की सहायता कर सकता है। संकलित कोड एक डिस्सेम्बलर के लिए अपेक्षाकृत साफ और आसान है। इसलिए मुझे लगता है कि कुछ विधानसभा की आवश्यकता है।

मुझे लगता है कि यह माइकल अब्रश की ज़ेन ऑफ़ असेंबली लैंग्वेज की शुरुआत के पास था जहाँ उन्होंने एक साधारण विरोधी असहमति और डिबगर विरोधी चाल दिखाई। 8088/6 में एक प्रीफ़ेच कतार थी जो आपने किया था उसके पास एक निर्देश था जो अगले निर्देश या एक जोड़े को आगे संशोधित करता है। यदि सिंगल स्टेपिंग करते हैं तो आपने संशोधित निर्देश निष्पादित किया है, यदि आपका निर्देश सेट सिम्युलेटर पूरी तरह से हार्डवेयर का अनुकरण नहीं करता है, तो आपने संशोधित निर्देश निष्पादित किया है। सामान्य रूप से चलने वाले वास्तविक हार्डवेयर पर वास्तविक निर्देश पहले से ही कतार में होगा और संशोधित मेमोरी लोकेशन तब तक कोई नुकसान नहीं पहुंचाएगा जब तक कि आप फिर से निर्देशों के उस स्ट्रिंग को निष्पादित नहीं करते। आप शायद आज भी इस तरह की एक चाल का उपयोग कर सकते हैं जैसे कि पाइपलाइज्ड प्रोसेसर अगला निर्देश लाते हैं। या यदि आप जानते हैं कि हार्डवेयर में एक अलग निर्देश और डेटा कैश है तो आप आगे कई बाइट्स को संशोधित कर सकते हैं यदि आप इस कोड को कैश लाइन में ठीक से संरेखित करते हैं, तो संशोधित बाइट अनुदेश कैश के माध्यम से नहीं लिखा जाएगा, लेकिन डेटा कैश, और एक निर्देश सेट सिम्युलेटर जिसमें उचित कैश सिमुलेटर नहीं था, ठीक से निष्पादित करने में विफल होगा। मुझे लगता है कि सॉफ्टवेयर केवल समाधान आपको बहुत दूर नहीं ले जाएगा।

उपरोक्त पुराने और अच्छी तरह से ज्ञात हैं, मुझे वर्तमान उपकरणों के बारे में पर्याप्त नहीं पता है कि क्या वे पहले से ही ऐसी चीजों के आसपास काम करते हैं। सेल्फ मोडिफ़ाइंग कोड डिबगर को सफ़ल कर सकता है / कर सकता है, लेकिन मानव समस्या को कम कर सकता है और फिर सेल्फ मॉडिफ़ाइंग कोड देख सकता है और इसके चारों ओर काम कर सकता है।

यह हुआ करता था कि हैकर्स उदाहरण के लिए, कुछ काम करने के लिए लगभग 18 महीने लगेंगे, डीवीडी। अब वे लगभग 2 दिनों से 2 सप्ताह (यदि प्रेरित) (नीली किरण, आईफ़ोन, आदि) के लिए औसत हैं। इसका मतलब है कि अगर मैं सुरक्षा पर कुछ दिन बिताता हूं, तो मैं अपना समय बर्बाद कर रहा हूं। एकमात्र वास्तविक सुरक्षा जो आपको मिलेगी, वह हार्डवेयर के माध्यम से है (उदाहरण के लिए आपके निर्देश एन्क्रिप्ट किए गए हैं और केवल चिप के अंदर प्रोसेसर कोर अच्छी तरह से निष्पादित होने से ठीक पहले, डिक्रिप्टेड निर्देशों को उजागर नहीं कर सकता है, इस तरह से)। हो सकता है कि आप दिनों के बजाय महीनों में खरीदें।

इसके अलावा, केविन मिटनिक की पुस्तक द आर्ट ऑफ डिसेप्शन पढ़ें। इस तरह का एक व्यक्ति एक फोन उठा सकता है और आपके पास या एक सहकर्मी इस प्रणाली के रहस्यों को सौंप सकता है यह सोचकर कि यह कंपनी के किसी अन्य हिस्से में प्रबंधक या अन्य सहकर्मी या हार्डवेयर इंजीनियर है। और आपकी सुरक्षा की धज्जियां उड़ाई जाती हैं। सुरक्षा सभी प्रौद्योगिकी के प्रबंधन के बारे में नहीं है, इंसानों को भी प्रबंधित करना होगा।


1
इसके अलावा, आपको सुरक्षा छेद खोजने के लिए स्रोत कोड (या यहां तक ​​कि डिस्सेम्ब्ल्ड स्रोत कोड) तक पहुंच नहीं है। यह दुर्घटना से हो सकता है, या इस तथ्य का उपयोग करके कि कोड में अधिकांश छेद समान समस्याओं से आते हैं (जैसे बफर ओवरफ्लो)।
asmeurer

2
स्व-संशोधित कोड के साथ बड़ी समस्याएं हैं। अधिकांश आधुनिक ओएस / हार्डवेयर आपको बहुत उच्च विशेषाधिकार के बिना ऐसा नहीं करने देंगे, कैश मुद्दे हो सकते हैं और कोड थ्रेड-सुरक्षित नहीं है।
मार्टिन जेम्स

1
आधुनिक x86 प्रोसेसर के साथ, इस तरह की चालें अक्सर प्रदर्शन के लिए खराब होती हैं। एक से अधिक अनुदेशों के भाग के रूप में एक ही मेमोरी लोकेशन का उपयोग करने से गलत शाखा के समान प्रभाव पड़ता है। सेल्फ-मॉडिफाइंग कोड प्रोसेसर को निर्देश और डेटा कैश के बीच तालमेल बनाए रखने के लिए कैश लाइनों को छोड़ने का कारण बनता है (यदि आप संशोधित कोड को अधिक बार संशोधित करते हैं, तो यह अभी भी एक जीत हो सकती है)।
जिल्स

2
मैं 20 साल पहले इसमें भाग गया था। हमें लगभग आधे घंटे का समय लगा कि क्या हुआ। बहुत अच्छा नहीं है अगर आपको लंबे समय तक सुरक्षा की आवश्यकता है।
बो पर्सन

1
"वास्तविक निर्देश पहले से ही कतार में होगा और संशोधित मेमोरी लोकेशन किसी भी नुकसान का कारण नहीं बनेगा" जब तक कि बीच में कोई व्यवधान न हो, निर्देश पाइपलाइन को फ्लश करके, और नया कोड दिखाई देने का कारण बनता है। अब आपके आक्षेप के कारण आपके वैध उपयोगकर्ताओं के लिए बग पैदा हो गया है।
बेन वोइगट

21

उदाहरण के लिए, एईएस एल्गोरिथ्म लो । यह एक बहुत, बहुत सार्वजनिक एल्गोरिथ्म है, और यह बहुत सुरक्षित है। क्यों? दो कारण: यह बहुत से स्मार्ट लोगों द्वारा समीक्षा की गई है, और "गुप्त" भाग एल्गोरिथ्म ही नहीं है - गुप्त भाग वह कुंजी है जो एल्गोरिथ्म के इनपुट में से एक है। यह अपने प्रोटोकॉल को एक उत्पन्न "गुप्त" के साथ डिजाइन करने के लिए बेहतर तरीका है जो आपके कोड के बाहर है, बजाय कोड को गुप्त बनाने के। कोड को हमेशा समझा जा सकता है कि आप क्या करते हैं, और (आदर्श रूप से) उत्पन्न रहस्य को केवल बड़े पैमाने पर क्रूर बल दृष्टिकोण या चोरी के माध्यम से खतरे में डाला जा सकता है।

मुझे लगता है कि एक दिलचस्प सवाल यह है कि " आप अपने कोड को बाधित क्यों करना चाहते हैं?" आप हमलावरों के लिए अपने एल्गोरिदम को क्रैक करना चाहते हैं? अपने कोड में शोषक कीड़े खोजने के लिए उन्हें कठिन बनाने के लिए? यदि कोड पहले स्थान पर अनुपयोगी था, तो आपको कोड को बाधित करने की आवश्यकता नहीं होगी। समस्या की जड़ दरार-रहित सॉफ्टवेयर है। अपनी समस्या की जड़ को ठीक करें, बस इसे बाधित न करें।

इसके अलावा, आप जितना अधिक भ्रामक अपना कोड बनाते हैं, आपके लिए सुरक्षा बग ढूंढना उतना ही कठिन होगा। हां, हैकर्स के लिए यह कठिन होगा, लेकिन आपको बग भी ढूंढने होंगे। कोड अब से वर्षों को बनाए रखना आसान होना चाहिए, और यहां तक ​​कि अच्छी तरह से लिखित स्पष्ट कोड को बनाए रखना मुश्किल हो सकता है। इसे बदतर मत बनाओ।


3
सामान्य ज्ञान के लिए +1: जब आप सिर्फ एक बेहतर सिस्टम डिज़ाइन कर सकते हैं, तो अपने लिए कठिन क्यों बनाएं।
नेक्रोलिस

1
जैसा कि मैं हमेशा कहता हूं, यदि आप सब कुछ सर्वर साइड रखते हैं, तो इसका अधिक सुरक्षित
liamzebedee

20

रिवर्स-इंजीनियर के लिए कोड को कठिन बनाना कोड ऑब्सफैक्शन कहलाता है।

आप जिन तकनीकों का उल्लेख करते हैं उनमें से अधिकांश काम करने में काफी आसान हैं। वे कुछ बेकार कोड जोड़ने पर केन्द्रित हैं। लेकिन बेकार कोड का पता लगाने और हटाने के लिए आसान है, आपको एक स्वच्छ कार्यक्रम के साथ छोड़कर।

प्रभावी आक्षेप के लिए, आपको अपने प्रोग्राम के व्यवहार को बेकार किए गए बिट्स पर निर्भर करने की आवश्यकता है। उदाहरण के लिए, ऐसा करने के बजाय:

a = useless_computation();
a = 42;

यह करो:

a = complicated_computation_that_uses_many_inputs_but_always_returns_42();

या ऐसा करने के बजाय:

if (running_under_a_debugger()) abort();
a = 42;

ऐसा करें (जहां running_under_a_debuggerएक फ़ंक्शन के रूप में आसानी से पहचाना नहीं जाना चाहिए जो यह परीक्षण करता है कि कोड डिबगर के तहत चल रहा है या नहीं - इसे डीबगर डिटेक्शन के साथ उपयोगी संगणना मिलाना चाहिए):

a = 42 - running_under_a_debugger();

प्रभावी obfuscation कुछ ऐसा नहीं है जो आप संकलन चरण में पूरी तरह से कर सकते हैं। कंपाइलर जो कुछ भी कर सकता है, एक डिकम्पॉइलर कर सकता है। निश्चित रूप से, आप डिकम्प्रेसर पर बोझ बढ़ा सकते हैं, लेकिन यह बहुत दूर नहीं जा रहा है। प्रभावी ओफिसकेशन तकनीक, इनमे मौजूद होने के कारण, इसमें दिन से ओब्सेक्टेड सोर्स लिखना शामिल है। अपने कोड को सेल्फ मोडिफाई करें। बड़ी संख्या में आदानों से प्राप्त गणना वाले कूद के साथ अपने कोड को लैटर करें। उदाहरण के लिए, एक साधारण कॉल के बजाय

some_function();

ऐसा करें, जहाँ आपको बिट्स के सटीक अपेक्षित लेआउट का पता हो some_data_structure:

goto (md5sum(&some_data_structure, 42) & 0xffffffff) + MAGIC_CONSTANT;

यदि आप मोटापे के बारे में गंभीर हैं, तो अपनी योजना में कई महीने जोड़ें; मोटापा सस्ता नहीं आता है। और यह विचार करें कि लोगों को इंजीनियरिंग से दूर रखने का सबसे अच्छा तरीका यह है कि आपका कोड इसे बेकार बना दे ताकि वे परेशान न हों। यह एक साधारण आर्थिक विचार है: वे रिवर्स-इंजीनियर होंगे यदि उनके लिए मूल्य लागत से अधिक है; लेकिन उनकी लागत बढ़ाने से आपकी लागत भी बहुत बढ़ जाती है, इसलिए उनके लिए मूल्य कम करने का प्रयास करें।

अब जब मैंने आपसे कहा है कि आपत्ति करना कठिन और महंगा है, तो मैं आपको बताने जा रहा हूं कि यह आपके लिए वैसे भी नहीं है । तुम लिखो

वर्तमान प्रोटोकॉल जो मैं काम कर रहा हूं, विभिन्न लोगों की सुरक्षा के लिए कभी भी निरीक्षण या समझने योग्य नहीं होना चाहिए

जो लाल झंडा उठाता है। यह अस्पष्टता से सुरक्षा है , जिसका रिकॉर्ड बहुत खराब है। यदि प्रोटोकॉल की सुरक्षा प्रोटोकॉल को न जानने वाले लोगों पर निर्भर करती है, तो आप पहले ही हार चुके हैं

अनुशंसित पाठ:


1
@ गिल्स, यह आपका कथन है, जो बहुत मजबूत है, इसलिए प्रमाण का बोझ आप पर है। हालांकि, मैं एक सरल उदाहरण प्रदान करूंगा: 2+2संकलक द्वारा सरलीकृत किया जा सकता है 4, लेकिन डिकंपाइलर इसे वापस नहीं ला सकता है 2+2(यदि यह वास्तव में था तो क्या 1+3?)।
रॉटस्टर

7
@ रॉटर्स 4और 2+2अवलोकन के समकक्ष हैं, इसलिए वे इस उद्देश्य के लिए समान हैं , अर्थात् यह पता लगाने के लिए कि कार्यक्रम क्या कर रहा है। हां, बेशक, डिकंपाइलर स्रोत कोड को फिर से संगठित नहीं कर सकता है, लेकिन यह अप्रासंगिक है। यह Q & A व्यवहार के पुनर्निर्माण (यानी एल्गोरिथ्म, और अधिक सटीक रूप से एक प्रोटोकॉल) के बारे में है।
गिल्स एसओ- बुराई को रोकें '

1
आपको व्यवहार के पुनर्निर्माण के लिए कुछ भी करने की ज़रूरत नहीं है। आपके पास पहले से ही कार्यक्रम है! आपको आमतौर पर प्रोटोकॉल को समझने और उसमें कुछ बदलने की ज़रूरत होती है (जैसे 2 2+2को 3 के +साथ बदलना, या उसकी जगह बदलना *)।
रॉटस्टर

1
यदि आप सभी व्यवहार-समान कार्यक्रमों को समान मानते हैं, तो हाँ, कंपाइलर कुछ भी नहीं कर सकता है क्योंकि यह सिर्फ एक इंडेंटिटी ट्रांसफॉर्मेशन करता है। डिकम्पॉइलर तब भी बेकार है, क्योंकि यह फिर से एक पहचान परिवर्तन है। यदि आप, हालांकि, तब 2+2-> 4संकलक द्वारा किए गए अपरिवर्तनीय परिवर्तन का एक वैध उदाहरण नहीं है। चाहे वह समझ को अधिक आसान बना दे या अधिक कठिन, एक अलग तर्क है।
रॉटस्टर

2
@ गिल्स मैं सेब के साथ आपकी सादृश्यता का विस्तार नहीं कर सकता क्योंकि मैं एक संरचनात्मक रूप से अलग, लेकिन व्यवहारिक रूप से समान सेब की कल्पना नहीं कर सकता। :)
रॉटर्स

13

कई बार, आपके उत्पाद के रिवर्स इंजीनियर होने का डर गलत होता है। हां, यह रिवर्स इंजीनियर हो सकता है; लेकिन यह समय की एक छोटी अवधि में इतना प्रसिद्ध हो जाएगा, कि हैकर्स रिवर्स रिवर्स के लायक पाएंगे। यह? (यह नौकरी कोड की पर्याप्त लाइनों के लिए एक छोटी सी गतिविधि नहीं है)।

यदि यह वास्तव में धन कमाने वाला बन जाता है, तो आपको कानूनी तरीकों जैसे पेटेंट और / या कॉपीराइट का उपयोग करके इसे बचाने के लिए पर्याप्त धन इकट्ठा करना चाहिए ।

IMHO, इसे लेने और जारी करने के लिए आप जो मूल सावधानियां बरतने जा रहे हैं। यदि यह रिवर्स इंजीनियरिंग का एक बिंदु बन जाता है, जिसका अर्थ है कि आपने वास्तव में अच्छा काम किया है, तो आप खुद ही इसे दूर करने के बेहतर तरीके पाएंगे। सौभाग्य।


1
मेरा मतलब है, यह एक व्यवहार्य और लागू होने वाला उत्तर है, लेकिन आपके द्वारा संरक्षण और दो करोड़ की आय के बीच रेखा जो दूसरों को आपके उत्पाद की रक्षा के लिए देती है वह वास्तव में लंबी रेखा है।
ग्रेफाइटमास्टर

12

Http://en.wikipedia.org/wiki/Security_by_obscurity#Arguments_nainst का पाठ लें । मुझे यकीन है कि अन्य लोग भी शायद इस बात का बेहतर स्रोत दे सकते हैं कि अस्पष्टता से सुरक्षा एक बुरी चीज क्यों है।

यह पूरी तरह से संभव होना चाहिए, आधुनिक क्रिप्टोग्राफिक तकनीकों का उपयोग करके, आपके सिस्टम का खुला होना (मैं यह नहीं कह रहा कि यह खुला होना चाहिए, बस यह हो सकता है), और अभी भी कुल सुरक्षा है, इसलिए जब तक क्रिप्टोग्राफ़िक एल्गोरिथ्म नहीं होता है इसमें एक छेद है (संभावना नहीं है यदि आप एक अच्छा चुनते हैं), आपकी निजी कुंजी / पासवर्ड निजी रहते हैं, और आपके पास आपके कोड में सुरक्षा छेद नहीं हैं ( यह वही है जिसके बारे में आपको चिंता होनी चाहिए)।


2
मैं इस बात से सहमत हो जाऊंगा। मुझे लगता है कि आपको एक वैचारिक या एक डिजाइन समस्या हो सकती है। क्या एक निजी-सार्वजनिक कुंजी जोड़ी समाधान के साथ एक एनालॉग है? आप निजी कुंजी को कभी नहीं विभाजित करते हैं, यह उस मालिक के पास रहता है जिसके सुरक्षित ग्राहक इसे संसाधित करते हैं। क्या आप उनके कंप्यूटर से सुरक्षित कोड रख सकते हैं और केवल परिणाम वापस उपयोगकर्ता के पास भेज सकते हैं?
डिज्ले

8

जुलाई 2013 के बाद से, क्रिप्टोग्राफिक रूप से मजबूत ऑबफ्यूशन ( Indistinguishability Obfuscation के रूप में ) में दिलचस्पी है, जो अमित सहाय के मूल शोध से प्रेरित है ।

आप इस क्वांटा पत्रिका के लेख में और उस IEEE स्पेक्ट्रम लेख में कुछ आसुत जानकारी पा सकते हैं ।

वर्तमान में इस तकनीक का उपयोग करने के लिए आवश्यक संसाधनों की मात्रा इसे अव्यावहारिक बना देती है, लेकिन AFAICT आम सहमति भविष्य के बारे में आशावादी है।

मैं इसे बहुत लापरवाही से कहता हूं, लेकिन हर किसी ने जो सहज प्रौद्योगिकी को खारिज कर दिया है - यह अलग है। अगर यह सही मायने में काम करने वाला और व्यवहारिक साबित होता है, तो यह वास्तव में प्रमुख है, न कि सिर्फ मोटापे के लिए।


7

अपने आप को सूचित करने के लिए, कोड प्रेफ़ेशन पर अकादमिक साहित्य पढ़ें । एरिज़ोना विश्वविद्यालय के क्रिश्चियन कॉलबर्ग इस क्षेत्र में एक सम्मानित विद्वान हैं; हार्वर्ड यूनिवर्सिटी के सलिल वदन ने भी कुछ अच्छे काम किए हैं।

मैं इस साहित्य पर पीछे हूं, लेकिन जिस आवश्यक विचार से मैं वाकिफ हूं, वह यह है कि आप किसी हमलावर को उस कोड को देखने से नहीं रोक सकते, जिसे आप निष्पादित करेंगे, लेकिन आप इसे उस कोड के साथ घेर सकते हैं जिसे निष्पादित नहीं किया गया है, और इसकी लागत है एक हमलावर घातीय समय (सर्वोत्तम ज्ञात तकनीकों का उपयोग करके) यह पता लगाने के लिए कि आपके कोड के कौन से टुकड़े निष्पादित किए गए हैं और कौन से नहीं हैं।


7

हाल ही में एक पेपर है जिसे " प्रोग्राम ऑब्सफेकशन और वन-टाइम प्रोग्राम " कहा जाता है। यदि आप अपने आवेदन की सुरक्षा के बारे में वास्तव में गंभीर हैं। सामान्य रूप से कागज सरल और सार्वभौमिक हार्डवेयर के उपयोग से सैद्धांतिक असंभवता के आसपास जाता है।

यदि आप अतिरिक्त हार्डवेयर की आवश्यकता को बर्दाश्त नहीं कर सकते हैं, तो एक और पेपर भी है जो समान कार्यक्षमता और समान आकार के साथ सभी कार्यक्रमों के बीच सैद्धांतिक रूप से सर्वोत्तम संभव ओफ़्सेशन "सर्वश्रेष्ठ-संभव ओफ़्स्क्यूशन" पर देता है । हालांकि कागज से पता चलता है कि सूचना-सिद्धांत सबसे अच्छा संभव बहुपद पदानुक्रम के पतन का अर्थ है।

उन पत्रों को कम से कम आपको पर्याप्त ग्रंथ सूची प्रदान करनी चाहिए ताकि संबंधित साहित्य में चल सकें यदि ये परिणाम आपकी आवश्यकताओं के लिए काम नहीं करते हैं।

अद्यतन: अपभ्रंश की एक नई धारणा, जिसे अप्रभेद्य आक्षेप कहा जाता है, असंभावना परिणाम को कम कर सकती है (कागज)


6

यदि कोई आपके द्विआधारी को उलटने के लिए समय बिताना चाहता है तो आपको रोकने के लिए कुछ भी नहीं है। आप कर सकते हैं अगर मामूली अधिक कठिन है, लेकिन इसके बारे में है। यदि आप वास्तव में इसके बारे में सीखना चाहते हैं तो http://www.hex-rays.com/idapro/ की एक प्रति प्राप्त करें और कुछ बायनेरिज़ को अलग करें।

तथ्य यह है कि सीपीयू को कोड को निष्पादित करने की आवश्यकता है जो आपके पूर्ववत है। सीपीयू केवल मशीन कोड निष्पादित करता है ... और प्रोग्रामर मशीन कोड पढ़ सकते हैं।

यह कहा जा रहा है ... आपके पास एक अलग मुद्दा है, जिसे दूसरे तरीके से हल किया जा सकता है। क्या आप की रक्षा करने की कोशिश कर रहे हैं? अपने मुद्दे के आधार पर आप अपने उत्पाद की सुरक्षा के लिए एन्क्रिप्शन का उपयोग कर सकते हैं।


6

सही विकल्प का चयन करने में सक्षम होने के लिए, आपको निम्नलिखित पहलुओं के बारे में सोचना चाहिए:

  1. क्या यह संभावना है कि "नए उपयोगकर्ता" भुगतान नहीं करना चाहते हैं लेकिन आपके सॉफ़्टवेयर का उपयोग करते हैं?
  2. क्या यह संभावना है कि मौजूदा ग्राहकों को उनके पास अधिक लाइसेंस की आवश्यकता है?
  3. संभावित उपयोगकर्ता कितना भुगतान करने को तैयार हैं?
  4. क्या आप प्रति उपयोगकर्ता / समवर्ती उपयोगकर्ता / कार्य केंद्र / कंपनी को लाइसेंस देना चाहते हैं?
  5. क्या आपके सॉफ़्टवेयर को उपयोगी होने के लिए प्रशिक्षण / अनुकूलन की आवश्यकता है?

यदि प्रश्न 5 का उत्तर "हाँ" है, तो अवैध प्रतियों के बारे में चिंता न करें। वे वैसे भी उपयोगी नहीं होंगे।

यदि प्रश्न 1 का उत्तर "हां" है, तो पहले मूल्य निर्धारण के बारे में सोचें (प्रश्न 3 देखें)।

यदि आप प्रश्न 2 "हां" का उत्तर देते हैं, तो "भुगतान प्रति उपयोग" मॉडल आपके लिए उपयुक्त हो सकता है।

मेरे अनुभव से, प्रति उपयोग भुगतान + अनुकूलन और प्रशिक्षण आपके सॉफ़्टवेयर के लिए सबसे अच्छा संरक्षण है, क्योंकि:

  • नए उपयोगकर्ता मूल्य निर्धारण मॉडल (कम उपयोग -> थोड़ा भुगतान) से आकर्षित होते हैं
  • लगभग कोई "अनाम उपयोगकर्ता" नहीं हैं, क्योंकि उन्हें प्रशिक्षण और अनुकूलन की आवश्यकता है।
  • कोई भी सॉफ्टवेयर प्रतिबंध संभावित ग्राहकों को नहीं डराता है।
  • मौजूदा ग्राहकों से पैसे की एक सतत धारा है।
  • लंबी अवधि के व्यापारिक संबंधों के कारण, आपको अपने ग्राहकों से विकास के लिए बहुमूल्य प्रतिक्रिया मिलती है।

इससे पहले कि आप डीआरएम या आपत्ति को शुरू करने के बारे में सोचें, आप इन बिंदुओं के बारे में सोच सकते हैं और यदि वे आपके सॉफ़्टवेयर पर लागू होते हैं।


बहुत अच्छी सलाह (और मैंने इसे
उखाड़ा

5

एक वर्चुअल मशीन में संरक्षित कोड पहली बार में रिवर्स इंजीनियर को असंभव लग रहा था। थमीडा पैकर

लेकिन यह अब सुरक्षित नहीं है .. और इससे कोई फर्क नहीं पड़ता कि आप अपना कोड कैसे पैक करते हैं, आप हमेशा किसी भी लोड किए गए निष्पादन योग्य की मेमोरी डंप कर सकते हैं और इसे आईडीए प्रो जैसे किसी भी असंतुष्ट के साथ इकट्ठा कर सकते हैं।

आईडीए प्रो भी निफ्टी असेंबली कोड के साथ सी सोर्स कोड ट्रांसफॉर्मर के साथ आता है, हालांकि उत्पन्न कोड एक पॉइंटर / एड्रेस गणितीय गड़बड़ी की तरह दिखाई देगा .. यदि आप इसे मूल के साथ तुलना करते हैं तो आप सभी त्रुटियों को ठीक कर सकते हैं और कुछ भी चीर कर सकते हैं।


5

कोई पासा नहीं, आप अपने कोड को असंतुष्ट होने से नहीं बचा सकते। आप क्या कर सकते हैं व्यापार तर्क के लिए सर्वर सेट करें और इसे अपने ऐप के लिए प्रदान करने के लिए webservice का उपयोग करें। बेशक, यह परिदृश्य हमेशा संभव नहीं है।


8
अच्छी तरह से कहा जाता है, अपने कोड को डिसाइड करने वाले लोगों से बचने का एकमात्र तरीका यह है कि उन्हें कभी भी उन तक शारीरिक पहुंच न दें, जिसका अर्थ है कि अपने आवेदन को विशेष रूप से एसएएएस के रूप में पेश करना, दूरस्थ ग्राहकों से अनुरोध लेना और संसाधित डेटा वापस सौंपना। एक मगरमच्छ खाई और 5 मीटर लंबे विद्युतीकृत रेजर तार से घिरे एक भूमिगत बंकर में एक बंद कमरे में सर्वर रखें, जिसे आप प्रबलित कंक्रीट के 10 मीटर तक कवर करने से पहले कुंजी को फेंक देते हैं, और फिर आशा करते हैं कि आप टन स्थापित करना भूल गए हैं सॉफ्टवेयर सिस्टम के नेटवर्क पर घुसपैठ को रोकने के लिए।
jwenting

6
मुझे आशा है कि मुझे आपके सर्वर को बनाए रखने का अनुबंध कभी नहीं मिलेगा
कॉलिन पिकार्ड

5

रिवर्स इंजीनियरिंग से बचने के लिए, आपको उपयोगकर्ताओं को कोड नहीं देना चाहिए। उस ने कहा, मैं एक ऑनलाइन आवेदन का उपयोग करने की सलाह देता हूं ... हालांकि (जब से आपने कोई संदर्भ नहीं दिया है) जो कि आप पर व्यर्थ हो सकता है।


यह वास्तविक समाधान है ... अर्थात् अपने मुकुट जवाहरात को अपने स्वयं के वीपीएस मशीन पर अपने स्वयं के सर्वर में डाल दें और केवल क्लाइंट (ब्राउज़र या एपीआई क्लाइंट) से इस सर्वर में एपीआई कॉल को उजागर करें
स्कॉट स्टेंसलैंड

5

संभवतः आपका सबसे अच्छा विकल्प अभी भी वर्चुअलाइजेशन का उपयोग कर रहा है, जो बायपास करने के लिए आवश्यक अप्रत्यक्ष / अप्रत्यक्षता के एक और स्तर का परिचय देता है, लेकिन जैसा कि एसएसपोक ने अपने जवाब में कहा , यह तकनीक भी 100% सुरक्षित नहीं है।


मुद्दा यह है कि आपको अंतिम सुरक्षा नहीं मिलेगी, क्योंकि ऐसी कोई बात नहीं है, और अगर कभी भी होगा, तो यह लंबे समय तक नहीं रहेगा, जिसका अर्थ है कि यह पहली जगह में अंतिम सुरक्षा नहीं थी।

जो भी आदमी इकट्ठा होता है, उसे असंतुष्ट किया जा सकता है।

यह आमतौर पर सच है कि (उचित) असहमति अक्सर (थोड़ा या अधिक) कठिन काम है, इसलिए आपके प्रतिद्वंद्वी को अधिक कुशल होना चाहिए , लेकिन आप मान सकते हैं कि हमेशा ऐसी गुणवत्ता का कोई है, और यह एक सुरक्षित शर्त है।

यदि आप आरईएस के खिलाफ कुछ की रक्षा करना चाहते हैं, तो आपको आरईएस द्वारा उपयोग की जाने वाली कम से कम सामान्य तकनीकों को जानना चाहिए।

इस प्रकार शब्द

इंटरनेट रिवर्स इंजीनियरिंग के खिलाफ रोकथाम के लिए वास्तव में संसाधनपूर्ण नहीं है, बल्कि इंजीनियर को रिवर्स करने के तरीके के बारे में जानकारी को दर्शाता है

अपना बुरा रवैया दिखाना। मैं यह नहीं कह रहा हूं कि सुरक्षा का उपयोग या एम्बेड करने के लिए आपको पता होना चाहिए कि इसे कैसे तोड़ना है, लेकिन बुद्धिमानी से इसका उपयोग करने के लिए आपको इसकी कमजोरियों और नुकसान को जानना चाहिए। आपको इसे समझना चाहिए ।

(एक गलत तरीके से सुरक्षा का उपयोग करके सॉफ़्टवेयर के उदाहरण हैं। इस तरह की सुरक्षा को व्यावहारिक रूप से कोई भी नहीं बना रहा है। अस्पष्ट बोलने से बचने के लिए मैं आपको इंटरनेट पर संक्षेप में वर्णित एक उदाहरण दूंगा: सीडी-रोम v4 पर ऑक्सफोर्ड इंग्लिश डिक्शनरी दूसरा संस्करण। आप इसके बारे में पढ़ सकते हैं। निम्नलिखित पेज में SecuROM का इसका असफल उपयोग: 16-, 32-, या 64-बिट विंडोज वातावरण में CD-ROM पर ऑक्सफोर्ड इंग्लिश डिक्शनरी (OED): हार्ड-डिस्क इंस्टॉलेशन, बग, वर्ड प्रोसेसिंग मैक्रोज़, नेटवर्किंग, फोंट, और आगे )

हर चीज में समय लगता है।

यदि आप इस विषय पर नए हैं और आरई सामान को ठीक से प्राप्त करने के लिए महीनों या सालों नहीं हैं, तो दूसरों द्वारा उपलब्ध समाधानों के साथ जाएं। यहाँ समस्या स्पष्ट है, वे पहले से ही वहाँ हैं, इसलिए आप पहले से ही जानते हैं कि वे 100% सुरक्षित नहीं हैं, लेकिन अपनी खुद की नई सुरक्षा बनाने से आपको संरक्षित होने का केवल एक गलत अर्थ मिलेगा, जब तक कि आप वास्तव में अच्छी तरह से कला की स्थिति को नहीं जानते हैं। रिवर्स इंजीनियरिंग और सुरक्षा (लेकिन आप इस समय कम से कम नहीं)।

सॉफ़्टवेयर सुरक्षा का उद्देश्य न्यूबीज़ को डराना, सामान्य आरईएस को रोकना है, और अपने आवेदन के केंद्र में उसकी (उसकी उम्मीद के मुताबिक दिलचस्प) यात्रा के बाद अनुभवी आरई के चेहरे पर एक मुस्कान डाल देना है।

व्यवसायिक बातचीत में आप कह सकते हैं कि यह प्रतिस्पर्धा में देरी करने के बारे में है, जितना संभव हो उतना संभव है।

( ब्लैक बोर्ड 2006 में दिखाए गए फिलिप बियोन्डी और फेब्रिस डेसक्लक्स द्वारा स्काइप में अच्छी प्रस्तुति सिल्वर नीडल पर एक नज़र डालें )।


आपको पता है कि वहाँ आरई के बारे में बहुत सारी चीजें हैं, इसलिए इसे पढ़ना शुरू करें। :)

मैंने वर्चुअलाइजेशन के बारे में कहा, इसलिए मैं आपको EXETOOLS मंच से एक अनुकरणीय सूत्र का लिंक दूंगा : सर्वश्रेष्ठ सॉफ्टवेयर रक्षक: Themida या Enigma Protector? । आगे की खोजों में यह आपकी थोड़ी मदद कर सकता है।


4

मुझे नहीं लगता कि कोई भी कोड अप्राप्य है, लेकिन किसी को यह प्रयास करने के लिए पुरस्कार के लिए महान होने की आवश्यकता है।

कहा जाता है कि ऐसी चीजें हैं जिन्हें आपको करना चाहिए जैसे:

  • उच्चतम अनुकूलन स्तर संभव का उपयोग करें (रिवर्स इंजीनियरिंग न केवल असेंबली अनुक्रम प्राप्त करने के बारे में है, यह कोड को समझने और इसे उच्च-स्तरीय भाषा में सी के रूप में पोर्ट करने के बारे में भी है)। अत्यधिक अनुकूलित कोड का पालन करने के लिए एक b --- h हो सकता है।
  • आवश्यक से बड़े डेटा प्रकार न होने से संरचनाएं घनी बनाएं। आधिकारिक कोड रिलीज़ के बीच संरचना सदस्यों को पुनर्व्यवस्थित करें। संरचनाओं में पुनर्व्यवस्थित बिट फ़ील्ड भी कुछ ऐसी चीजें हैं जिनका आप उपयोग कर सकते हैं।
  • आप कुछ मानों की उपस्थिति की जांच कर सकते हैं जिन्हें परिवर्तित नहीं किया जाना चाहिए (एक कॉपीराइट संदेश एक उदाहरण है)। यदि एक बाइट वेक्टर में "vwxyz" होता है, तो आपके पास एक अन्य बाइट वेक्टर हो सकता है, जिसमें "एबस्केड" होता है और मतभेदों की तुलना करता है। इसे करने वाले फ़ंक्शन को वैक्टर को पास नहीं किया जाना चाहिए, लेकिन अन्य मॉड्यूल में परिभाषित बाहरी बिंदुओं का उपयोग करें (छद्म-सी कोड) "char * p1 = & string1 [539];" और "char P2 = & string2 [-11731];"। इस तरह वहाँ कोई संकेत नहीं होगा दो तार पर बिल्कुल इशारा करते हैं। तुलना कोड में फिर आप " (p1-539 + i) - * (P2 + 11731 + i) == कुछ मान" के लिए तुलना करें। पटाखा यह सोचता है कि स्ट्रिंग 1 को बदलना सुरक्षित है क्योंकि कोई भी इसे संदर्भित नहीं करता है। परीक्षण को कुछ अप्रत्याशित स्थान पर दफनाना।

आसान क्या है और क्या करना मुश्किल है, यह देखने के लिए असेंबली कोड को स्वयं हैक करने का प्रयास करें। विचारों को पॉप अप करना चाहिए कि आप रिवर्स इंजीनियर को कोड को और अधिक कठिन बनाने के लिए प्रयोग कर सकते हैं और डिबगिंग को और अधिक कठिन बना सकते हैं।


2
आपका पहला बिंदु कोई मतलब नहीं है, अनुकूलित कोड cruft को काटता है, इससे रिवर्स में आसानी होती है (मैं अनुभव से बोलता हूं)। आपका थ्रिड पॉइंट भी समय की बर्बादी है, और उसके नमक के रिवर्स इंजीनियर को पता है कि मेमोरी एक्सेस ब्रेकपॉइंटिंग कैसे करना है। यही कारण है कि शायद सबसे अच्छा है कि हम खुद को एक सिस्टम डिज़ाइन न करें, लेकिन हमें 3 पार्टी लाइब्रेरी जो अभी तक '
क्रैक

चूंकि यह प्रतीत होता है कि मुझे इस विषय पर कुछ भी पता नहीं है, इसलिए शायद मुझे अपने कोड लिखने के बजाय अपने सॉफ़्टवेयर विकास की जरूरतों के लिए एक पेशेवर की ओर मुड़ना चाहिए।
ओलॉफ फोर्शेल

4

जैसा कि पहले ही कहा जा चुका है: एक नियमित सीपीयू पर आप उन्हें ऐसा करने से नहीं रोक सकते, आप बस उन्हें देरी कर सकते हैं। जैसा कि मेरे पुराने क्रिप्टो शिक्षक ने मुझसे कहा: आपको सही एन्क्रिप्शन की आवश्यकता नहीं है, कोड को तोड़ना लाभ से अधिक महंगा होना चाहिए। वही आपके स्थापन के लिए धारण करता है।

लेकिन 3 अतिरिक्त नोट:

  1. रिवर्स इंजीनियरिंग को असंभव बनाना संभव है, लेकिन (और यह बहुत बड़ा है लेकिन), आप इसे पारंपरिक सीपीयू पर नहीं कर सकते। मैंने बहुत अधिक हार्डवेयर विकास भी किया, और अक्सर FPGA का उपयोग किया जाता है। जैसे वीरटेक्स 5 एफएक्स में एक पावरपीसी सीपीयू है, और आप अपने हार्डवेयर में स्वयं के सीपीयू ऑपकोड को लागू करने के लिए एपीयू का उपयोग कर सकते हैं। आप इस सुविधा का उपयोग वास्तव में PowerPC के लिए इंक्रीजेशन को डिक्रिप्ट कर सकते हैं, जो कि बाहर या अन्य सॉफ्टवेयर द्वारा पहुंच योग्य नहीं है, या हार्डवेयर में कमांड को निष्पादित भी करता है। जैसा कि FPGA ने अपने विन्यास बिटस्ट्रीम के लिए AES एन्क्रिप्शन का निर्माण किया है, आप इसे रिवर्स नहीं कर सकते थे (सिवाय कोई व्यक्ति AES को तोड़ने का प्रबंधन करता है, लेकिन फिर मुझे लगता है कि हमारे पास अन्य समस्याएं हैं ...)। इस तरह से हार्डवेयर आईपी के विक्रेता भी अपने काम की रक्षा करते हैं।

  2. आप प्रोटोकॉल से बोलते हैं। आप यह नहीं कहते कि यह किस प्रकार का प्रोटोकॉल है, लेकिन जब यह एक नेटवर्क प्रोटोकॉल है, तो आपको कम से कम इसे नेटवर्क सूँघने से बचाना चाहिए। यह आप वास्तव में एन्क्रिप्शन द्वारा कर सकते हैं। लेकिन अगर आप सॉफ्टवेयर के मालिक से एन / डिक्रिप्शन की रक्षा करना चाहते हैं, तो आप वापस आ गए हैं।

  3. अपने प्रोग्राम को निर्विवाद / अप्राप्य बनाओ। डिबगिंग की किसी प्रकार की पहचान का उपयोग करने की कोशिश करें और इसे लागू करें उदाहरण के लिए कुछ फार्मूला ओडर में एक डिबग रजिस्टर सामग्री को एक जादू स्थिरांक में जोड़ें। यह बहुत कठिन है यदि आपका प्रोग्राम डिबग मोड में दिखता है, अगर यह सामान्य है, लेकिन पूरी तरह से गलत गणना, संचालन, या कुछ अन्य बनाता है। उदाहरण के लिए, मुझे कुछ इको गेम्स का पता है, जो वास्तव में एक बुरा कॉपी-प्रोटेक्शन था (मुझे पता है कि आपको नकल नहीं चाहिए, लेकिन यह समान है): चुराए गए संस्करण ने 30 मिनट के खेल खेलने के बाद खनन किए गए संसाधनों को बदल दिया, और अचानक आपको सिर्फ एक सिंगल मिला संसाधन। समुद्री डाकू ने केवल इसे फटा (यानी रिवर्स इंजीनियर इसे) - जाँच की कि क्या यह चलता है, और वोलिया ने इसे जारी किया। इस तरह के मामूली व्यवहार परिवर्तन का पता लगाना बहुत मुश्किल है, जासूसी। अगर वे तुरंत पता लगाने के लिए प्रकट नहीं होते हैं, लेकिन केवल देरी हो रही है।

तो अंत में मैं सुझाव दूंगा: अनुमान करें कि लोगों को आपके सॉफ़्टवेयर को उल्टा करने का क्या लाभ है, इसे कुछ समय में अनुवाद करें (जैसे कि सबसे सस्ता भारतीय वेतन का उपयोग करके) और रिवर्स इंजीनियरिंग को इतना समय महंगा बनाने में मदद करें कि यह बड़ा हो।


3

उनके अंतर्ज्ञान और व्यक्तिगत अनुभव के आधार पर, ज्यादातर लोग जो कहते हैं, उसके विपरीत, मुझे नहीं लगता कि क्रिप्टोग्राफिक रूप से सुरक्षित कार्यक्रम का सामान्य रूप से असंभव साबित होता है।

यह मेरी बात को प्रदर्शित करने के लिए एक पूरी तरह से obfuscated प्रोग्राम स्टेटमेंट का एक उदाहरण है:

printf("1677741794\n");

कोई भी कभी भी यह अनुमान नहीं लगा सकता है कि यह वास्तव में क्या करता है

printf("%d\n", 0xBAADF00D ^ 0xDEADBEEF);

इस विषय पर एक दिलचस्प पेपर है, जो कुछ असंभवता साबित करता है। इसे "ऑन (द इम) ओस्पुसेटिंग प्रोग्राम्स की संभावना" कहा जाता है ।

यद्यपि कागज यह साबित करता है कि कार्यक्रम को लागू करने वाले कार्य से गैर-अलग होने की आपत्ति असंभव है, यह असंभव है, कुछ कमजोर तरीके से परिभाषित ऑब्सेफिकेशन अभी भी संभव हो सकता है!


7
1. आपका उदाहरण यहां प्रासंगिक नहीं है; आपके द्वारा दिखाए गए दो प्रोग्राम व्यवहार के समकक्ष हैं, और यह प्रश्न किसी प्रोग्राम के व्यवहार का पता लगाने के बारे में है, न कि इसके स्रोत कोड को फिर से संगठित करना (जो, जाहिर है, असंभव है)। 2. यह पेपर एक सैद्धांतिक पेपर है; सही ओफ़्फ़सुसेटर लिखना असंभव है, लेकिन सही डिकम्पाइलर लिखना भी असंभव है (बहुत अधिक कारणों से यह सही प्रोग्राम विश्लेषक लिखना असंभव है)। व्यवहार में, यह एक हथियारों की दौड़ है: जो बेहतर (डी) ऑबफ्यूजेटर लिख सकता है।
गिल्स एसओ- बुराई को रोकें '

1
@Gilles, (सही) डिओफ़सकेशन का परिणाम हमेशा व्यवहारिक रूप से मोटापे से ग्रस्त कोड के बराबर होगा। मैं यह नहीं देखता कि समस्या का महत्व कैसे कम होता है।
रॉटर्स

इसके अलावा, हथियारों की दौड़ के बारे में: यह इस बारे में नहीं है कि कौन शोध में अधिक निवेश करता है, बल्कि इसके बारे में जो सही है। सही गणितीय प्रमाण गलत नहीं होते हैं क्योंकि कोई उन्हें वास्तव में बुरी तरह से चाहता है।
रॉटर्स

1
ठीक है, शायद आप अभ्यास में हथियारों की दौड़ के बारे में सही हैं। मुझे लगता है कि मैंने इसे गलत समझा। :) मुझे उम्मीद है कि हालांकि किसी प्रकार का क्रिप्टोग्राफिक रूप से सुरक्षित ओफ़्यूसकेशन संभव है।
रॉटस्टर

मोटापे के एक दिलचस्प मामले के लिए, स्मार्ट कार्ड का प्रयास करें, जहां समस्या यह है कि हमलावर के पास भौतिक पहुंच (सफेद-बॉक्स obfuscation) है। प्रतिक्रिया का हिस्सा भौतिक साधनों द्वारा पहुंच को सीमित करना है (हमलावर सीधे गुप्त कुंजियों को नहीं पढ़ सकता है); लेकिन मुख्य रूप से DPA जैसे हमलों को उपयोगी परिणाम नहीं देने के लिए सॉफ्टवेयर ऑबफस्यूशन भी एक भूमिका निभाता है । मेरे पास प्रस्ताव देने के लिए एक अच्छा संदर्भ नहीं है, क्षमा करें। मेरे उत्तर के उदाहरण अस्पष्ट रूप से उस डोमेन में प्रयुक्त तकनीकों से प्रेरित हैं।
गिल्स एसओ- बुराई को रोकें '

3

अस्पष्टता के माध्यम से सुरक्षा काम नहीं करती है क्योंकि लोगों को हम दोनों की तुलना में बहुत चतुर द्वारा प्रदर्शित किया गया है। यदि आपको अपने ग्राहकों के संचार प्रोटोकॉल की रक्षा करनी चाहिए, तो आप नैतिक रूप से सबसे अच्छे कोड का उपयोग करने के लिए बाध्य हैं जो खुले में है और विशेषज्ञों द्वारा पूरी तरह से जांच की गई है।

यह उस स्थिति के लिए है जहां लोग कोड का निरीक्षण कर सकते हैं। यदि आपका आवेदन एक एम्बेडेड माइक्रोप्रोसेसर पर चलना है, तो आप एक को चुन सकते हैं जिसमें एक सीलिंग सुविधा है, जो कोड का निरीक्षण करना या वर्तमान उपयोग जैसे तुच्छ मापदंडों से अधिक निरीक्षण करना असंभव बनाता है, जबकि यह चलता है। (यह हार्डवेयर हमलावर तकनीकों को छोड़कर है, जहां आप चिप को ध्यान से विघटित करते हैं और व्यक्तिगत ट्रांजिस्टर पर धाराओं का निरीक्षण करने के लिए उन्नत उपकरणों का उपयोग करते हैं।)

मैं x86 के लिए एक रिवर्स इंजीनियरिंग असेंबलर का लेखक हूं। यदि आप ठंडे आश्चर्य के लिए तैयार हैं, तो मुझे अपने सर्वोत्तम प्रयासों का परिणाम भेजें। (मेरी वेबसाइट के माध्यम से मुझसे संपर्क करें।) कुछ जवाबों में मैंने देखा है कि मेरे लिए एक बड़ी बाधा होगी। यदि आप यह देखना चाहते हैं कि रिवर्स इंजीनियरिंग कोड कितना परिष्कृत है, तो आपको वास्तव में रिवर्स इंजीनियरिंग चुनौतियों वाली वेबसाइटों का अध्ययन करना चाहिए।

आपका प्रश्न कुछ स्पष्टीकरण का उपयोग कर सकता है। यदि आप कंप्यूटर कोड रिवर्स इंजीनियरिंग के लिए उत्तरदायी हैं, तो किसी प्रोटोकॉल को गुप्त रखने की अपेक्षा कैसे करें? अगर मेरा प्रोटोकॉल RSA एन्क्रिप्टेड संदेश (यहां तक ​​कि सार्वजनिक कुंजी) भेजने के लिए होगा, तो प्रोटोकॉल को गुप्त रखकर आपको क्या हासिल होगा? सभी व्यावहारिक उद्देश्यों के लिए एक निरीक्षक यादृच्छिक बिट्स के अनुक्रम के साथ सामना किया जाएगा।

Groetjes अल्बर्ट


3

पारंपरिक रिवर्स इंजीनियरिंग तकनीक एक स्मार्ट एजेंट की क्षमता पर निर्भर करती है जो कोड के बारे में सवालों के जवाब देने के लिए डिस्सेम्बलर का उपयोग करता है। यदि आप मजबूत सुरक्षा चाहते हैं, तो आप उन चीजों को करें जो एजेंट को ऐसे उत्तर प्राप्त करने से रोकें।

आप हल्टिंग प्रोग्राम ("प्रोग्राम एक्स हाल्ट?") पर भरोसा करके ऐसा कर सकते हैं जिसे सामान्य रूप से हल नहीं किया जा सकता है। उन कार्यक्रमों को जोड़ना जो आपके कार्यक्रम के बारे में तर्क करना मुश्किल है, आपके कार्यक्रम को तर्क करने में मुश्किल बनाते हैं। उन्हें फाड़ने के बजाय ऐसे कार्यक्रमों का निर्माण करना आसान है। आप प्रोग्राम के लिए कोड भी जोड़ सकते हैं जिसमें तर्क के लिए कठिनाई की डिग्री बदलती है; एक महान उम्मीदवार उपनाम ("संकेत") के बारे में तर्क देने का कार्यक्रम है।

Collberg et al में एक पेपर ("मैन्युफैक्चरिंग सस्ता, रेजिलिएंट एंड स्टेल्थ अपैक कंस्ट्रक्शंस") है, जो इन विषयों पर चर्चा करता है और "अपारदर्शी" की एक किस्म को परिभाषित करता है, जो कोड के बारे में तर्क करना बहुत मुश्किल बना सकता है:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.1946&rep=rep1&type=pdf

मैंने कोलबर्ग के विशिष्ट तरीकों को उत्पादन कोड पर लागू नहीं देखा है, विशेष रूप से सी या सी ++ स्रोत कोड नहीं।

डैशो जावा के ओब्फ्यूसेटर समान विचारों का उपयोग करने लगता है। http://www.cs.arizona.edu/~collberg/Teaching/620/2008/Assignments/tools/DashO/


2

अपने कोड को छिपाने के बारे में याद दिलाने के लिए पहले : आपके सभी कोड को छिपाए जाने की आवश्यकता नहीं है।

END GOAL : अधिकांश सॉफ़्टवेयर प्रोग्रामों के लिए मेरा अंतिम लक्ष्य विभिन्न लाइसेंसों को बेचने की क्षमता है जो मेरे कार्यक्रमों के भीतर विशिष्ट सुविधाओं को चालू और बंद करेंगे।

BEST तकनीक : मुझे लगता है कि वर्डप्रेस ऑफ़र की तरह हुक और फिल्टर की एक इमारत में, अपने विरोधियों को भ्रमित करने की कोशिश करते समय पूर्ण सर्वोत्तम विधि है। यह आपको वास्तव में कोड को एन्क्रिप्ट किए बिना कुछ ट्रिगर संघों को एन्क्रिप्ट करने की अनुमति देता है।

कारण यह है कि आप ऐसा करते हैं, क्योंकि आप कम से कम मात्रा में कोड को एन्क्रिप्ट करना चाहते हैं।

अपने ग्राहकों को जानें: यह जानें: कोड क्रैक करने का मुख्य कारण लाइसेंस के दुर्भावनापूर्ण वितरण के कारण नहीं है, यह वास्तव में है क्योंकि आपके कोड को बदलने की आवश्यकता है और वे वास्तव में मुफ्त प्रतियां वितरित करने की आवश्यकता नहीं है।

STARTED GETTING STARTED : उस कोड की थोड़ी मात्रा सेट करें जिसे आप एन्क्रिप्ट करने जा रहे हैं, बाकी कोड को जटिलता और समझ बढ़ाने के लिए वन फ़ाइल में प्रयास करना चाहिए।

खोज के लिए तैयारी : आप मेरी प्रणाली के साथ परतों में एन्क्रिप्ट करने जा रहे हैं, यह भी एक बहुत ही जटिल प्रक्रिया होने जा रही है इसलिए एक और कार्यक्रम बनाएं जो एन्क्रिप्शन प्रक्रिया के लिए जिम्मेदार होगा।

एक कदम : सब कुछ के लिए base64 नामों का उपयोग करना। एक बार हो जाने के बाद, आधार कोड को ओफ़्फ़ुसेट किया गया और इसे एक अस्थायी फ़ाइल में सहेजें जिसे बाद में इस कोड को डिक्रिप्ट और चलाने के लिए उपयोग किया जाएगा। सही बात?

जब से आप बार-बार ऐसा कर रहे हैं, मैं दोहरा दूंगा। आप एक बेस 64 स्ट्रिंग बनाने जा रहे हैं और इसे एक चर के रूप में किसी अन्य फ़ाइल में सहेज सकते हैं जिसे डिक्रिप्ट और रेंडर किया जाएगा।

STEP TWO : आप इस अस्थायी फ़ाइल में एक स्ट्रिंग के रूप में पढ़ने जा रहे हैं और इसे आगे बढ़ाते हैं, फिर इसे आधार बनाते हैं और इसे एक दूसरी अस्थायी फ़ाइल में सहेजते हैं जिसका उपयोग अंत उपयोगकर्ता के लिए इसे डीक्रिप्ट और रेंडर करने के लिए किया जाएगा।

चरण तीन : जितनी बार आप चाहें, चरण दो को दोहराएं। एक बार जब आपके पास डिक्रिप्ट त्रुटियों के बिना यह ठीक से काम कर रहा है, तो आप अपने विरोधियों के लिए भूमि खानों में निर्माण शुरू करना चाहते हैं।

LAND MINE ONE : आप इस तथ्य को रखना चाहते हैं कि आपको एक पूर्ण रहस्य के बारे में सूचित किया जा रहा है। तो परत 2 के लिए एक पटाखा प्रयास सुरक्षा चेतावनी मेल सिस्टम में बनाएँ। यह आपको अपने प्रतिद्वंद्वी के बारे में बारीकियों को जानने के लिए निकाल दिया जाएगा, अगर कुछ भी गलत होना है।

भूमि खान दो : निर्भरताएँ। आप नहीं चाहते कि आपके प्रतिद्वंद्वी को परत 3 या 4 या 5 के बिना, एक लेयर चलाने में सक्षम होना चाहिए, या यहां तक ​​कि वास्तविक कार्यक्रम भी इसके लिए डिज़ाइन किया गया था। इसलिए सुनिश्चित करें कि एक परत के भीतर आप किसी प्रकार की किल स्क्रिप्ट को शामिल करते हैं, जो कि यदि प्रोग्राम मौजूद नहीं है, या अन्य लेयर्स को सक्रिय करेगा।

मुझे यकीन है कि आप खुद के लैंडमाइंस के साथ आ सकते हैं, इसके साथ मज़े कर सकते हैं।

रिमेंम्बर के लिए : आप वास्तव में आधार के बजाय अपने कोड को एन्क्रिप्ट कर सकते हैं। इस तरह एक साधारण base64 प्रोग्राम को डिक्रिप्ट नहीं करेगा।

समीक्षा : ध्यान रखें कि यह वास्तव में आपके और आइआर प्रतिद्वंद्वी के बीच सहजीवी संबंध हो सकता है। मैं हमेशा एक परत के अंदर एक टिप्पणी रखता हूं, टिप्पणी पटाखा को बधाई देती है और उन्हें आपसे नकद पुरस्कार प्राप्त करने के लिए उपयोग करने के लिए एक प्रोमो कोड देती है।

बिना किसी पूर्वाग्रह के साथ नकद इनाम को महत्वपूर्ण बनाएं। मैं आमतौर पर $ 500 जैसा कुछ कहता हूं। यदि आपका लड़का कोड क्रैक करने वाला पहला व्यक्ति है, तो उसे उसके पैसे का भुगतान करें और उसका दोस्त बनें। यदि वह आपका दोस्त है तो वह आपके सॉफ़्टवेयर को वितरित करने वाला नहीं है। उससे पूछें कि उसने यह कैसे किया और आप कैसे सुधार कर सकते हैं!

सौभाग्य!


4
क्या आपने प्रश्न भी पढ़ा है? मैंने पायरेसी से बचाव के तरीकों के बारे में कभी नहीं पूछा। आवेदन नि: शुल्क होगा, यह अंतर्निहित प्रोटोकॉल है जिसका उपयोग सुरक्षा की प्रकृति के कारण संरक्षित करने की आवश्यकता है।
ग्राफिटेमास्टर

2

क्या किसी ने कोडमार्ट की कोशिश की: http://www.sourceformat.com/code-obfuscator.htm ? या थेमिडा: http://www.oreans.com/themida_features.php ?

बाद में एक और आशाजनक लग रहा है।


पहली चीज़ जो मैं सुझाऊँगा, वह है कि हर कीमत पर व्यावसायिक पर्यवेक्षकों के उपयोग से बचना! क्योंकि अगर आप ऑब्सफैक्टर को क्रैक करते हैं, तो आप इसके साथ सभी एप्लिकेशनों को क्रैक कर सकते हैं!
गैलियम नाइट्राइड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.