एक अज्ञात संग्रह की जांच

चलती। नया शहर। नौकरी की खोज। यहां तक ​​कि एक आईटी पेशेवर के लिए, यह एक लंबा समय ले सकता है। साक्षात्कारों की एक श्रृंखला, जो सामान्य तौर पर, एक-दूसरे से बहुत मिलती-जुलती है। और जैसा कि आमतौर पर होता है जब आप पहले से ही नौकरी पा चुके होते हैं, तो थोड़ी देर बाद, एक दिलचस्प कार्यालय की घोषणा की जाती है।

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



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

हमारे पास क्या है: एक्सटेंशन ".apk" के साथ एक संग्रह। मैंने अपने आप को स्पॉइलर के नीचे रखा, ताकि यह खोज इंजन द्वारा अनुक्रमित न हो: अगर लोग इसे पसंद नहीं करते हैं, तो मैं इसका हल हैबर पर डालता हूं?

आस्तीन ऊपर रोल

यह कहा जाता है कि संग्रह में एक साहचर्य सरणी पर हस्ताक्षर करने की कार्यक्षमता है। फ़ाइल एक्सटेंशन द्वारा, हम तुरंत समझ जाते हैं कि हम Android के लिए लिखे गए एप्लिकेशन के साथ काम कर रहे हैं। सबसे पहले हम संग्रह को अनपैक करते हैं। वास्तव में, यह एक नियमित ज़िप संग्रह है, और कोई भी संग्रहकर्ता इसे हल्के ढंग से सामना करेगा। मैंने APKtool उपयोगिता का उपयोग किया, और, जैसा कि यह निकला, गलती से कुछ रेक को दरकिनार कर दिया। हां, ऐसा होता है (आमतौर पर विपरीत, हां?)। मंत्र बहुत सरल है:

 apktool d task.zip 

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

 ├── AndroidManifest.xml ├── apktool.yml ├── lib │   └── arm64-v8a ├── original │   ├── AndroidManifest.xml │   └── META-INF ├── res │   ├── anim │   ├── color │   ├── drawable │   ├── layout │   ├── layout-watch-v20 │   ├── mipmap-anydpi-v26 │   ├── values │   └── values-af ├── smali │   ├── android │   ├── butterknife │   ├── com │   ├── net │   └── org └── unknown   └── org 

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

के साथ शुरू करने के लिए, मैं फ़ाइलों के माध्यम से सिर्फ "चलने" का फैसला करता हूं। मैं AndroidManifest.xml खोलता हूं और सार्थक पढ़ना शुरू करता हूं। मेरा ध्यान एक अजीब विशेषता से आकर्षित होता है

 android:supportsRtl="true" 

यह पता चला है कि वह आवेदन में "राइट-टू-लेफ्ट" अक्षर के साथ भाषाओं का समर्थन करने के लिए जिम्मेदार है। हम तनाव शुरू करते हैं। अच्छा नहीं है।

इसके अलावा, मेरा टकटकी अज्ञात फ़ोल्डर में जाता है। इसके अंतर्गत प्रपत्र का एक पदानुक्रम है: org.apache.commons.codec.language.bm और अस्पष्ट सामग्री के साथ पाठ फ़ाइलों की एक बड़ी संख्या। Google पैकेज का पूरा नाम है और यह पता चला है कि यहां क्या संग्रहीत किया गया है, खोज एल्गोरिथ्म से संबंधित कुछ शब्द ध्वन्यात्मक रूप से दिए गए समान हैं। सच कहूँ तो, यहाँ मैं मुश्किल से तनाव शुरू किया। निर्देशिकाओं के बारे में थोड़ा सोचने के बाद, मुझे वास्तव में कोड ही मिला, और फिर मज़ा शुरू हुआ। मैं सामान्य जावा बाइटकोड से नहीं मिला था, जिसके साथ मैं एक बार आसपास खेलने में कामयाब रहा, लेकिन कुछ और। बहुत समान, लेकिन अलग।

जैसा कि यह निकला, एंड्रॉइड की अपनी वर्चुअल मशीन है - Dalvik। और, हर सम्मानित आभासी मशीन की तरह, इसका अपना बायोटेक है। ऐसा लगता है कि इस समस्या को हल करने के पहले प्रयास में, यह इस दुख की बात पर था कि मैंने प्रवेश की घोषणा की, झुकाया, पर्दा गिरा दिया और यह सब 4 महीने तक फेंक दिया जब तक कि मेरी जिज्ञासा ने मुझे पूरी तरह से खत्म नहीं कर दिया।

आस्तीन ऊपर रोल करें [2]

"लेकिन क्या ऐसा नहीं हो सकता है कि सब कुछ आसान है?" - यह वह सवाल है जो मैंने खुद से पूछा था जब मैंने दूसरी बार कार्य शुरू किया था। मैंने स्माली से जावा तक एक डिकम्पॉइलर के लिए इंटरनेट खोजना शुरू कर दिया। मैंने केवल यह देखा कि इस प्रक्रिया को स्पष्ट रूप से अंजाम देना असंभव है। थोड़ी दूर जाकर, वह गितुब गया और खोज पंक्ति में कुछ प्रमुख वाक्यांश निकाले। पहली बार smali2java आई।

 git clone gradle build java -jar smali2java.jar .. 

त्रुटि। मुझे टर्मिनल के कई पन्नों पर एक विशाल स्टैक ट्रेस और त्रुटियाँ दिखाई देती हैं। सामग्री के सार (और स्टैक ट्रेस के आकार से भावनाओं को रोकना) के बारे में थोड़ा पढ़ने के बाद, मुझे पता चलता है कि यह उपकरण एक निश्चित व्याकरण और बाइटकोड के आधार पर काम करता है जो उसे स्पष्ट रूप से मिला था। मैं स्माल बाईटेकोड खोलता हूं और इसमें एनोटेशन, सिंथेटिक तरीके और अन्य अजीब निर्माण देखता हूं। Java bytecode में ऐसा कुछ नहीं था! कब तक? हटाए गए!


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

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

मैं bytecode के माध्यम से पत्ता और मेरे लिए अज्ञात स्थिरांक पर ठोकर। Googling, मैं रिवर्स एंड्रॉइड एप्लिकेशन पर पुस्तक में समान मिलता हूं। मुझे याद है कि यह केवल कंपाइलर प्रीप्रोसेसर द्वारा दी गई आईडी है, जो एंड्रॉइड एप्लिकेशन के संसाधनों को सौंपा गया है (कोड लेखन समय निरंतर आर। * है)। अगले आधे घंटे - घंटा, मैं संक्षेप में जांच करूंगा कि कौन से रजिस्टर किस तर्क के लिए जिम्मेदार हैं, किस क्रम में तर्क पारित किए जाते हैं, और आम तौर पर वाक्यविन्यास में तल्लीन होते हैं।

यह कैसा दिखता है?

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

एनोटेशन को देखते हुए और कुछ निश्चित कोड को संदिग्ध रूप से जेनरेट किए गए के समान देखते हुए, मुझे गूगल करना शुरू होता है। प्रोजेक्ट ButterKnife लाइब्रेरी का उपयोग करता है, जो एनोटेशन का उपयोग करके फुलाया जाता है () -> बाइंड () UI तत्वों को स्वचालित रूप से। यदि वर्ग में एनोटेशन हैं, तो बटरकनी एनोटेशन प्रोसेसर अंतर्निहित रूप से एक और बाइंडर क्लास बनाता है <original_class> __ViewBinding , जो हुड के नीचे सभी गंदे काम करता है। वास्तव में, मुझे यह सारी जानकारी केवल एक MainActivity फाइल से मिली, जब मैंने मैन्युअल रूप से इसमें से जावा स्रोत की समानता को दोबारा बनाया। आधे घंटे के बाद, मुझे एहसास हुआ कि इस लाइब्रेरी के एनोटेशन से बटन क्रियाओं पर कॉलबैक भी हो सकता है और उन प्रमुख कार्यों को पाया गया, जो वास्तव में कंटेनर में एक कुंजी / मूल्य जोड़ी को जोड़ने और हस्ताक्षर बनाने के लिए जिम्मेदार थे।

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

आलस्य एक प्रोग्रामर का दोस्त है

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

और यह वास्तव में काम करता है! चेहरे पर प्रभाव:

सिपहेरो से मिलो

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

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

संक्षेप में, Cipher.so क्या करता है और यह कैसे काम करता है:

• हमारी परियोजना की ग्रेड फाइल में कुंजियाँ और संबंधित मान पंजीकृत हैं
  
• सभी प्रमुख मूल्यों को स्वचालित रूप से एक अलग गतिशील पुस्तकालय (.so) में पैक किया जाएगा, जो संकलन समय पर उत्पन्न होगा। हां - हां, उत्पन्न हो जाएगा।
  
• तब ये कुंजियाँ सिफर.एसओ द्वारा उत्पन्न जावा विधियों से प्राप्त की जा सकती हैं
  
• एपीके बनाने के बाद, एमडी 5 द्वारा मुख्य नाम हैशेड (अधिक सुरक्षा के लिए, निश्चित रूप से)
  

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

 brew install binuitls 

और पाथ में / usr / लोकल के लिए रास्ता लिखना न भूलें, क्योंकि काढ़ा आपको सौम्य तरीके से हर चीज से बचाता है ...

 greadelf -p .rodata lib/arm64-v8a/libcipher-lib.so | head -n 15 

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



निचले पतों में हम संदिग्ध रेखाएँ देखते हैं। जैसा कि मुझे पता चला है, सिपहेरो के स्रोतों का अध्ययन करते हुए, चाबियाँ और मान सामान्य एसटीडी :: मानचित्र में रखे जाते हैं : यह बहुत कम जानकारी देता है, लेकिन हम जानते हैं कि बिनार में एन्क्रिप्टेड पासवर्डों के साथ-साथ अस्पष्ट कुंजी भी हैं।

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

# 1 प्रयास करें: मैं मूल्यों को समझने के लिए आगे बढ़ता हूं और मानता हूं कि एन्क्रिप्शन कुंजी एक ही है। त्रुटि। ओपनएसएसएल संकेत देता है कि कुछ सही नहीं है। Cipher.so के स्रोतों को थोड़ा पढ़ने के बाद, मैं समझता हूं कि यदि उपयोगकर्ता असेंबली के दौरान एक कुंजी निर्दिष्ट नहीं करता है, तो डिफ़ॉल्ट कुंजी का उपयोग किया जाता है - Cipher.so@DEFAULT ।

# 2 प्रयास करें: फिर से त्रुटि। हम्म ... क्या यह वास्तव में इस निरंतर द्वारा पुनर्परिभाषित है? यह एक गलती करने के लिए काफी सरल है: ग्रेड में लिखे गए भ्रामक कोड, "चले गए" स्वरूपण के साथ। मैं फिर से जांच करता हूं। सब कुछ ऐसा लगता है।

चाबियों के बजाय उनके एमडी 5 हैश हैं, और फिर मैं अपनी किस्मत आजमाने और इंद्रधनुष तालिकाओं के साथ एक सेवा खोलने की कोशिश करता हूं। वोइला - कुंजी में से एक शब्द "पासवर्ड" है। कोई दूसरा नहीं है। यह हमें देता है, ज़ाहिर है, ज्यादा नहीं। ये दोनों कुंजियाँ क्रमशः २४० और २ अ २ पते पर हैं। सिद्धांत रूप में, उन्हें तुरंत पहचानना आसान है - 32 वर्ण (एमडी 5)।

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

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

एक पहेली (जो मैंने कभी हल नहीं की)

फ़ंक्शन में जो एन्क्रिप्शन के लिए ज़िम्मेदार है, शुरुआत में कंटेनर में चाबियाँ के लिए एक चेक है।

 public byte[] a(java/util/Map p1) { v0 = p1.size() v1 = 0x0; if (v0 != 0) goto :cond_0 p1 = new byte[v1]; return p1; :cond_0 v0 = "user"; v0 = p1.containsKey(v0) if (v0 == 0) goto :cond_1 p1 = new byte[v1]; return p1; ... 

वस्तुतः: यदि कोई "उपयोगकर्ता" कुंजी है, तो इस कंटेनर पर हस्ताक्षर नहीं किया गया है (एक शून्य हस्ताक्षर लौटाया गया है)। एक अजीब भावना: ऐसा लगता है कि समस्या हल हो गई है, लेकिन यह किसी भी तरह से संदिग्ध रूप से सरल लगता है। फिर बाकी सब चीजों का आविष्कार क्यों? भटकने का नेतृत्व करने के लिए? फिर मैंने पहले इस कोड का धाराप्रवाह अध्ययन क्यों नहीं किया? हम्म ...

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

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

मैं कोड की प्रत्येक पंक्ति के बारे में जितना संभव हो सके उलझन में बन गया - मैं अब किसी पर भरोसा नहीं कर सकता।

सरल समाधान # 2: मैंने देखा कि जिस प्रमाण पत्र के साथ आवेदन पर हस्ताक्षर किए गए थे, उसके हस्ताक्षर में कुछ मूल्य (स्ट्रिंग में प्रतिस्थापित) की उपस्थिति के लिए हस्ताक्षर करने की प्रक्रिया शुरू होती है।

 @OnClick //   protected void huvot324yo873yvo837yvo() { String signature = "no data"; boolean result = some_packages.isKeyInSignature(this); if result { Map map = new HashMap(); ... 

स्वयं का अर्थ, निश्चित रूप से, उस बीमार बिनर में निहित है। और वास्तव में, यदि यह मान हस्ताक्षर में नहीं है, तो एल्गोरिथ्म कुछ भी हस्ताक्षर नहीं करेगा, लेकिन केवल हस्ताक्षर के रूप में स्ट्रिंग "कोई डेटा नहीं" लौटाएं ... फिर से, हम सिफर के लिए ले जाते हैं ...

प्रमुख डिक्रिप्शन अंतिम लड़ाई

त्रासदी के पैमाने को समझने के लिए, मैं इस तरह से भ्रमित हो गया:

मैंने इस खंड का एक हेक्स डंप किया और पहले दो पंक्तियों में पेश किया, जिसमें से संदेह शुरू से ही कम नहीं हुआ।



यदि आप ध्यान दें, तो यहाँ लाइनों को अलग करने वाला वर्ण '0x00' है। यह आमतौर पर स्ट्रिंग कार्यों में भी मानक सी लाइब्रेरी द्वारा उपयोग किया जाता है। इससे यह कम दिलचस्प नहीं है कि पहली पंक्ति के बीच में किस तरह का अंतरिक्ष वर्ण है? अगला, पागल प्रयास शुरू होते हैं, जहां कुंजी है:

• पूरी पहली पंक्ति
  
• अंतरिक्ष से पहले पहली पंक्ति
  
• पहली पंक्ति अंतरिक्ष से अंत तक
  
• ...
  

व्यामोह की डिग्री का अनुमान पहले ही लगाया जा सकता है। जब आप यह नहीं समझ पाते हैं कि कार्य कितना कठिन और चालाक होना चाहिए, तब आप गाड़ी चलाना शुरू करें। और फिर भी, ऐसा नहीं है। फिर मेरे दिमाग में यह विचार आया: "क्या एल्गोरिथ्म मेरी मशीन के मुद्दे से सही ढंग से काम करता है?"। सामान्य तौर पर, क्रियाओं का क्रम तार्किक होता है और उन्होंने सवाल नहीं उठाए हैं, लेकिन सवाल यह है: क्या मेरी मशीन पर कमांड्स करते हैं कि उन्हें इसकी क्या आवश्यकता है? तो आपको क्या लगता है?

मैन्युअल रूप से सभी चरणों की जाँच करने के बाद, यह पता चला है कि

 echo "some_base64_input" | openssl base64 -d 

कुछ इनपुट तर्कों पर यह अचानक एक खाली स्ट्रिंग लौटाता है। हम्म।

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

एक प्रमाण पत्र से एक हस्ताक्षर प्राप्त करना

 class a { public static boolean isKeyInSignature(android.content.Context p1) { v0 = 0x0; try TRY_0{ v1 = p1.getPackageManager() p0 = p1.getPackageName() v2 = 0x40; // GET_SIGNATURES PackageInfo p0 = v1.getPackageInfo(p0, v2) android.content.pm.Signature[] p0 = p0.signatures; // Order are not guaranteed v1 = p0.length; v2 = 0x0; :goto_0 if (v2 >= v1) goto :cond_1 v3 = p0[v2]; String v3 = v3.toCharsString() String v4 = net.idik.lib.cipher.so.CipherClient.a() v3 = v3.contains(v4) }TRY_0 catch TRY_0 (android/content/pm/PackageManager$NameNotFoundException) goto :catch_0; if (v3 == 0) goto :cond_0 p1 = 0x1; return p1; :cond_0 v2 = v2 + 0x1; goto :goto_0 :catch_0 p0 = Thrown Exception p1.printStackTrace() :cond_1 return v0; } 

यह वह चीज़ है जो मेरे मामूली संपादनों के बाद उत्पन्न छद्मकोड की तरह दिखती है। कुछ चीजों को भ्रमित करता है:

• क्रिप्टोग्राफी का खराब ज्ञान और डिवाइस सर्टिफिकेट की "रसोई"
  
• प्रलेखन के अनुसार, यह विधि लौटे संग्रह में प्रमाण पत्र के आदेश की गारंटी नहीं देती है, और तदनुसार, एक ही क्रम में चारों ओर लूप करना संभव नहीं होगा - अगर एक से अधिक प्रमाण पत्र के साथ आवेदन पर हस्ताक्षर किए गए तो क्या होगा?
  
• एपीके से प्रमाण पत्र कैसे निकाला जाए, इस पर ज्ञान की कमी है, यह देखते हुए कि यह स्पष्ट नहीं है कि इस मामले में एंड्रॉइड रनटाइम क्या करता है
  

मुझे इन सभी मुद्दों को हल करना था और परिणाम इस प्रकार था:

• प्रमाण पत्र मूल निर्देशिका / मेटा- INF / CERT.RSA में है
  
  इस निर्देशिका में इस एक्सटेंशन के साथ केवल एक फ़ाइल है - जिसका अर्थ है कि आवेदन केवल एक प्रमाण पत्र के साथ हस्ताक्षरित है
  
• एंड्रॉइड अनुप्रयोगों के अनुसंधान इंजीनियरिंग के बारे में साइट पर, एक लिस्टिंग मिली थी जो कि एंड्रॉइड के रूप में हमारी ज़रूरत के हस्ताक्षर को निकाल सकती है। लेखक के अनुसार, कम से कम।
  

इस कोड को चलाकर, मैं हस्ताक्षर का पता लगा सकता हूं, और वास्तव में, हमें जो कुंजी चाहिए वह एक विकल्प है। आगे बढ़ो। सरल समाधान # 2 बह रहा है।

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

दस्तावेज को ध्यान से लिखें!

इस तथ्य पर आगे शोध कि पाठ फ़ील्ड से दर्ज किए गए डेटा को बदल दिया गया है सबूत की कमी के लिए छोड़ दिया गया है। नए सिरे से व्यामोह रोल करता है: हो सकता है कि जिस कोड ने प्रमाण पत्र से हस्ताक्षर खींचा है वह गलत है या यह एंड्रॉइड रिलीज़ के लिए एक कोड कार्यान्वयन है? मैं फिर से दस्तावेज खोलता हूं और निम्नलिखित देखता हूं: ( https://developer.android.com/reference/android/content/pm/Signature.html#toChars () ):



नोट: फ़ंक्शन ASCII टेक्स्ट के रूप में हस्ताक्षर को एनकोड करता है। मुझे जो आउटपुट मिला वह डेटा का एक हेक्स प्रतिनिधित्व था। यह एपीआई मुझे अजीब लग रहा था, लेकिन अगर आप दस्तावेज़ पर विश्वास करते हैं, तो यह पता चला है कि मैं फिर से रोक दिया गया था, और एन्क्रिप्ट की गई कुंजी हस्ताक्षर का एक विकल्प नहीं है। थोड़ी देर के लिए कोड पर विचारपूर्वक बैठने के बाद, मैं इसे बर्दाश्त नहीं कर सका और इस वर्ग के लिए स्रोत कोड खोल दिया। https://android.googlesource.com/platform/frameworks/base/+/e639da7/core/java/android/content/pm/Signature.java

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

परिणाम

निम्नलिखित n घंटे बीत चुके हैं:

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

सामान्य तौर पर, इस कोड ने शेष तर्कों पर हस्ताक्षर करने से इनकार कर दिया (क्रिप्टोग्राफी के साथ काम करते समय कोड में इन तर्कों ने मुझे दूर से फेंक दिया)।

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

वास्तव में, मैंने इस कार्य पर बहुत समय बिताया, और साथ ही ज्ञान अंतराल की बहाली पर भी। यह वास्तव में मददगार था। आप सभी तरह से ट्रेस कर सकते हैं और इस बात पर ध्यान दे सकते हैं कि कैसे मैं पहली बार बिल्कुल गैर-निर्णय भागों से जुड़ा हुआ हूं। शायद यह किसी को यह समझने में मदद करेगा कि शुरुआती लोग इस तरह की समस्याओं को कैसे हल करते हैं, क्योंकि हम आमतौर पर "सफलता की कहानियां" पढ़ते हैं, जहां सभी कदम तार्किक, सुसंगत हैं और सही परिणाम की ओर ले जाते हैं।

यदि कोई इस कार्य के साथ गहराई से खुदाई करने की कोशिश करना चाहता है या एक सवाल पूछना चाहता है - मुझे नीले आर्टब्रिज मेसेंजर में लिखें ।

देखते रहो।