घिड्रा के साथ एक साधारण दरार को तोड़ना - भाग 2

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

इस भाग में, जैसा कि मैंने वादा किया था, हम _construct_key () फ़ंक्शन का विश्लेषण करेंगे, जो कि हमें पता चला, प्रोग्राम में स्थानांतरित बाइनरी फ़ाइल को पढ़ने और डेटा पढ़ने की जांच करने के लिए जिम्मेदार है।

चरण 5 - _construct_key () फ़ंक्शन का अवलोकन

आइए इस समारोह की पूरी सूची को तुरंत देखें:


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

• फ़्रेड ()
• strncmp ()
• स्ट्रलेन ()
• फुटेल ()
• fseek ()
• डालता है ()

हमने अपने कोड में संबंधित आवरण कार्यों का नाम बदल दिया है (जो कि डिकंपाइलर ने _text शब्द के पीछे छिपाया है) सूचकांक 2 को जोड़कर (ताकि मूल सी-फ़ंक्शन के साथ कोई भ्रम न हो)। लगभग ये सभी कार्य फाइल धाराओं के साथ काम करने के लिए हैं। यह आश्चर्य की बात नहीं है - कोड पर एक त्वरित नज़र यह समझने के लिए पर्याप्त है कि यह क्रमिक रूप से एक फ़ाइल से डेटा पढ़ता है (जिसका विवरण केवल पैरामीटर के रूप में फ़ंक्शन को पास किया जाता है) और स्थानीय_14 बाइट्स के एक निश्चित दो आयामी सरणी के साथ रीड डेटा की तुलना करता है।

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

इसलिए, स्थानीय चर की घोषणा के तुरंत बाद, एक निश्चित कार्य _prepare_key () कहा जाता है :

 key_array = (char **)__prepare_key(); if (key_array == (char **)0x0) { key_array = (char **)0x0; } 

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

तब प्रोग्राम फ़ाइल से पहले 4 बाइट्स पढ़ता है और key_array सरणी के संबंधित अनुभाग के साथ तुलना करता है। (नीचे दिया गया कोड नाम बदलने के बाद है, जिसमें स्थानीय_19 चर भी शामिल है , मैंने पहले_4bytes का नाम बदला ।)

 first_4bytes = 0; /*   4    */ fread2(&first_4bytes,1,4,param_1); /*   key_array[1][0...3] */ iVar1 = strncmp2((char *)&first_4bytes,*(char **)key_array[1],4); if (iVar1 == 0) { ... } 

इस प्रकार, आगे निष्पादन केवल तभी होता है जब पहले 4 बाइट्स संयोग करते हैं (यह याद रखें)। तब हम फ़ाइल से 2 2-बाइट ब्लॉक पढ़ते हैं (और डेटा लिखने के लिए बफर के रूप में एक ही key_array का उपयोग किया जाता है):

 fread2(key_array[1] + 4,2,1,param_1); fread2(key_array[1] + 6,2,1,param_1); 

और फिर - आगे की स्थिति सही होने पर ही कार्य करता है:

 if ((*(short *)(key_array[1] + 6) == 4) && (*(short *)(key_array[1] + 4) == 5)) { //   ... } 

यह देखना आसान है कि ऊपर पढ़े गए 2-बाइट ब्लॉक में से पहला नंबर 5 होना चाहिए, और दूसरा नंबर 4 होना चाहिए (डेटा प्रकार केवल 32-बिट प्लेटफॉर्म पर 2 बाइट्स हैं)।

अगला यह है:

 local_30[0] = *key_array; // .. key_array[0] local_30[1] = *key_array + 0x10c; local_30[2] = *key_array + 0x218; local_30[3] = *key_array + 0x324; local_20 = *key_array + 0x430; 

यहाँ हम देखते हैं कि local_30 सरणी (char * local_30 [4] के रूप में घोषित) में key_array पॉइंटर के ऑफ़सेट शामिल हैं। यही है, स्थानीय_30 मार्कर लाइनों की एक सरणी है जिसमें फ़ाइल से डेटा संभवतः पढ़ा जाएगा। इस धारणा के तहत, मैंने स्थानीय_30 को मार्करों में बदल दिया। कोड के इस खंड में, केवल अंतिम पंक्ति थोड़ी संदिग्ध लगती है, जहां अंतिम ऑफसेट का काम (सूचकांक 0x430 पर, अर्थात 1072) अगले मार्कर तत्व द्वारा नहीं, बल्कि एक अलग स्थानीय_20 चर ( चार * ) द्वारा किया जाता है। लेकिन हम इसे अभी तक समझ लेंगे, लेकिन अभी के लिए - चलो आगे बढ़ते हैं!

आगे हम एक चक्र की प्रतीक्षा कर रहे हैं:

  i = 0; // local_10   i while (i < 5) { // ... i = i + 1; } 

यानी 0 से 4 समावेशी तक केवल 5 पुनरावृत्तियों। लूप में, फ़ाइल से पढ़ना और हमारे मार्कर सरणी के अनुपालन की जांच तुरंत शुरू होती है:

 char c_marker = 0; //   local_35 /*  .    */ fread2(&c_marker, 1, 1, param_1); if (*markers[i] != c_marker) { /*    -      */ _free_key(key_array); return (char **)0x0; } 

यही है, फ़ाइल से अगला बाइट c_marker चर (मूल विघटित कोड - local_35 में ) पढ़ा जाता है और ith मार्कर तत्व के पहले चरित्र के अनुपालन के लिए जाँच की जाती है। एक बेमेल के मामले में, key_array सरणी शून्य हो जाती है और एक खाली डबल पॉइंटर वापस आ जाता है। आगे कोड के साथ, हम देखते हैं कि यह तब भी किया जाता है जब रीड डेटा सत्यापन डेटा से मेल नहीं खाता है।

लेकिन यहां, जैसा कि वे कहते हैं, "कुत्ते को दफन किया गया है।" आइए इस चक्र पर करीब से नज़र डालें। यह 5 पुनरावृत्तियों है, जैसा कि हमें पता चला है। यदि आप कोडांतरक कोड को देख कर यह जाँच कर सकते हैं:





दरअसल, सीएमपी कमांड स्थानीय_10 चर (हमारे पास पहले से ही i ) के मूल्य की तुलना 4 नंबर के साथ करता है और यदि मान 4 (JLE कमांड) से कम या बराबर है , तो LAB_004017eb लेबल पर संक्रमण किया जाता है , अर्थात चक्र के शरीर की शुरुआत। यानी शर्त I = 0, 1, 2, 3 और 4 के लिए पूरी होगी - केवल 5 पुनरावृत्तियों! सबकुछ ठीक होगा, लेकिन मार्कर भी एक लूप में इस चर द्वारा अनुक्रमित होते हैं , और आखिरकार, यह सरणी केवल 4 तत्वों के साथ घोषित की जाती है:

 char *markers [4]; 

तो, कोई व्यक्ति स्पष्ट रूप से किसी को धोखा देने की कोशिश कर रहा है :) याद रखें, मैंने कहा कि यह रेखा संदिग्ध है?

 local_20 = *key_array + 0x430; 

बस ऐसे ही! फ़ंक्शन की संपूर्ण सूची को देखें और स्थानीय_20 चर के कम से कम एक और संदर्भ को खोजने का प्रयास करें। वह वहाँ नहीं है! हम इससे निष्कर्ष निकालते हैं: इस ऑफसेट को भी मार्करों सरणी में संग्रहीत किया जाना चाहिए, और सरणी में 5 तत्व होने चाहिए। चलो इसे ठीक करते हैं। चर घोषणा पर जाएं, Ctrl + L (रिटाइप चर) दबाएं और साहसपूर्वक सरणी के आकार को 5 में बदलें:



हो गया। मार्करों को पॉइंटर ऑफ़सेट असाइन करने के कोड के लिए नीचे स्क्रॉल करें, और - लो और निहारना! - एक असंगत अतिरिक्त चर गायब हो जाता है और सब कुछ जगह में गिर जाता है:

 markers[0] = *key_array; markers[1] = *key_array + 0x10c; markers[2] = *key_array + 0x218; markers[3] = *key_array + 0x324; markers[4] = *key_array + 0x430; //   ...   ! 

हम अपने लूप में लौटते हैं (स्रोत कोड में, यह सबसे अधिक संभावना है, लेकिन हम ध्यान नहीं देते हैं)। अगला, फ़ाइल से बाइट को फिर से पढ़ा जाता है और उसके मूल्य की जाँच की जाती है:

 byte n_strlen1 = 0; //   local_36 /*  .    */ fread2(&n_strlen1,1,1,param_1); if (n_strlen1 == 0) { /*      */ _free_key(key_array); return (char **)0x0; } 

ठीक है, यह n_strlen1 nonzero होना चाहिए। क्यों? अब आप देखेंगे, लेकिन साथ ही आप यह समझ पाएंगे कि मैंने इस चर को निम्न नाम क्यों दिया है:

  /*   n_strlen1)  (markers[i] + 0x104) */ *(uint *)(markers[i] + 0x104) = (uint)n_strlen1; /*    (n_strlen1)  (-->  ?) */ fread2(markers[i] + 1,1,*(size_t *)(markers[i] + 0x104),param_1); n_strlen2 = strlen2(markers[i] + 1); //   sVar2 if (n_strlen2 != *(size_t *)(markers[i] + 0x104)) { /*    (n_strlen2)  == n_strlen1 */ _free_key(key_array); return (char **)0x0; } 

मैंने उन टिप्पणियों को जोड़ा, जिन पर सब कुछ स्पष्ट होना चाहिए। N_strlen1 बाइट्स फ़ाइल से पढ़े जाते हैं और वर्णों के अनुक्रम के रूप में सहेजे जाते हैं (अर्थात एक स्ट्रिंग) मार्करों में [i] सरणी - अर्थात्, "स्टॉप-सिंबल" के बाद, जो पहले से ही key_array से वहां लिखे गए हैं । अंक 0x104 (260) पर मार्कर [i] में मान n_strlen1 सहेजना यहां कोई भूमिका नहीं निभाता है (ऊपर कोड में पहली पंक्ति देखें)। वास्तव में, इस कोड को निम्नानुसार अनुकूलित किया जा सकता है (और निश्चित रूप से स्रोत कोड में यही स्थिति है):

 fread2(markers[i] + 1, 1, (size_t) n_strlen1, param_1); n_strlen2 = strlen2(markers[i] + 1); if (n_strlen2 != (size_t) n_strlen1) { ... } 

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

आगे पानी इस कोड (जो मैंने भी तुरंत टिप्पणी की):

 uint n_pos = 0; //   local_3c /*  .    */ fread2(&n_pos,1,1,param_1); /*   7 */ n_pos = n_pos + 7; /*     */ uint n_filepos = ftell2(param_1); //   uVar3 if (n_pos < n_filepos) { /* n_pos   >= n_filepos */ _free_key(key_array); return (char **)0x0; } 

यह अभी भी यहां सरल है: हम फ़ाइल से अगला बाइट लेते हैं, 7 जोड़ते हैं और परिणामी मान की तुलना फेल () फ़ंक्शन द्वारा प्राप्त फ़ाइल स्ट्रीम में वर्तमान कर्सर स्थिति के साथ करते हैं। N_pos का मान कर्सर की स्थिति से कम नहीं होना चाहिए (यानी फ़ाइल की शुरुआत से बाइट्स में ऑफसेट)।

लूप में अंतिम पंक्ति:

 fseek2(param_1,n_pos,0); 

यानी फ़ाइल कर्सर को (शुरुआत से) स्थिति में fseek () फ़ंक्शन द्वारा n_pos द्वारा पुन: व्यवस्थित करें। ठीक है, हम इन सभी ऑपरेशनों को 5 बार लूप में करते हैं। _Construct_key () फ़ंक्शन निम्नलिखित कोड के साथ समाप्त होता है :

 int i_lastmarker = 0; //   local_34 /*   4    (int32) */ fread2(&i_lastmarker,4,1,param_1); if (*(int *)(*key_array + 0x53c) == i_lastmarker) { /*    == key_array[0][1340] ...   :) */ puts2("Markers seem to still exist"); } else { _free_key(key_array); key_array = (char **)0x0; } 

इस प्रकार, फ़ाइल में डेटा का अंतिम ब्लॉक 4-बाइट पूर्णांक मान होना चाहिए और यह key_array [0] [1340] में मूल्य के बराबर होना चाहिए। इस मामले में, हम कंसोल में एक बधाई संदेश प्राप्त करेंगे। अन्यथा, खाली सरणी अभी भी किसी भी प्रशंसा के बिना लौटती है :)

चरण 6 - __prepare_key () फ़ंक्शन का अवलोकन

हमारे पास केवल एक अनसैबल्ड फंक्शन बचा है - __prepare_key () । हमने पहले ही अनुमान लगा लिया है कि यह इस बात में है कि सत्यापन डेटा key_array सरणी के रूप में उत्पन्न होता है, जिसका उपयोग फ़ाइल से डेटा को सत्यापित करने के लिए _construct_key () फ़ंक्शन में किया जाता है। यह पता लगाना बाकी है कि वहां किस तरह का डेटा है!

मैं इस फ़ंक्शन का विस्तार से विश्लेषण नहीं करूंगा और तुरंत चर के सभी आवश्यक नाम बदलने के बाद टिप्पणियों के साथ पूरी सूची दूंगा:


विचार करने लायक एकमात्र स्थान यह रेखा है:

 *(undefined4 *)key_array[1] = 0x404024; 

मैं कैसे समझ सकता हूँ कि यहाँ "VOID" लाइन है? तथ्य यह है कि 0x404024 प्रोग्राम के एड्रेस स्पेस में एड्रेस है । इस मूल्य पर डबल-क्लिक करने से हम स्पष्ट रूप से देख सकते हैं कि क्या है:



वैसे, इस लाइन के लिए कोडांतरक कोड से समझा जा सकता है:

004015da c7 00 24 MOV dword ptr [EAX], .rdata = 56h V
40 40 00

VOID लाइन से संबंधित डेटा .rdata सेक्शन के बहुत शुरुआत में है (संबंधित पते से शून्य ऑफसेट पर)।

इसलिए, इस फ़ंक्शन से बाहर निकलने पर, निम्न डेटा के साथ एक दो-आयामी सरणी बनाई जानी चाहिए:

[0] [0]:'b' [268]:'l' [536]:'W' [804]:'p' [1072]:152 [1340]:1122
[1] [0-3]:"VOID" [4-5]:5 [6-7]:4


चरण 7 - दरार के लिए द्विआधारी तैयार करें

अब हम बाइनरी फ़ाइल के संश्लेषण को शुरू कर सकते हैं। हमारे हाथों में सभी प्रारंभिक डेटा:
1) सत्यापन डेटा ("प्रतीकों को रोकें") और सत्यापन सरणी में उनकी स्थिति;
2) फ़ाइल में डेटा का क्रम

आइए हम _construct_key () फ़ंक्शन के एल्गोरिथ्म के अनुसार जिस फ़ाइल की तलाश कर रहे हैं, उसकी संरचना को पुनर्स्थापित करें। तो, फ़ाइल में डेटा का क्रम निम्नानुसार होगा:


स्पष्टता के लिए, मैंने एक्सेल में वांछित फ़ाइल के डेटा के साथ ऐसा टैबलेट बनाया है:



यहां 7 वीं पंक्ति में - वर्णों और संख्याओं के रूप में स्वयं डेटा, 6 वीं पंक्ति में - उनकी हेक्साडेसिमल अभ्यावेदन, 8 वीं पंक्ति में - प्रत्येक तत्व का आकार (बाइट्स में), 9 वीं पंक्ति में - फ़ाइल की शुरुआत के सापेक्ष ऑफसेट। यह दृश्य बहुत सुविधाजनक है क्योंकि आपको भविष्य की फ़ाइल में किसी भी पंक्तियों को दर्ज करने की अनुमति देता है (एक पीले रंग की भरण के साथ चिह्नित), जबकि इन पंक्तियों की लंबाई के मूल्यों, साथ ही अगले स्टॉप प्रतीक के स्थिति ऑफसेट को स्वचालित रूप से सूत्रों द्वारा गणना की जाती है, जैसा कि प्रोग्राम एल्गोरिथ्म की आवश्यकता है। ऊपर (लाइनों 1-4 में), key_array चेक ऐरे की संरचना दिखाई गई है ।

लेख के लिए एक्सेल ही प्लस अन्य स्रोत सामग्री यहाँ से डाउनलोड की जा सकती है ।

बाइनरी फ़ाइल पीढ़ी और सत्यापन

केवल एक चीज बची है जो वांछित फ़ाइल को बाइनरी प्रारूप में उत्पन्न करती है और इसे हमारी दरार के साथ खिलाती है। फ़ाइल जनरेट करने के लिए, मैंने एक साधारण पायथन स्क्रिप्ट लिखी:


स्क्रिप्ट एकल पैरामीटर के रूप में दरारें के लिए रास्ता लेती है, फिर उसी निर्देशिका में कुंजी के साथ एक द्विआधारी फ़ाइल उत्पन्न करता है और प्रोग्राम पैरामीटर को कंसोल में अनुवाद करते हुए, इसी पैरामीटर के साथ दरार को कॉल करता है।

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

एक पूरे के रूप में सभी कोड प्रोग्राम एल्गोरिथ्म को पुन: पेश करता है जो हमने पाया। सफल होने पर मुद्रित होने वाली रेखा के रूप में, मैंने निर्दिष्ट किया "मैंने इस क्रैकमे को हल किया है!" (आप इस स्क्रिप्ट को संशोधित कर सकते हैं ताकि किसी भी पंक्ति को निर्दिष्ट करना संभव हो)।

आउटपुट की जाँच करें:



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

लेख के लिए सामग्री।