AdMob SDK अपने कोड की सुरक्षा के लिए रिवर्स या दूसरा तरीका

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

05-14 15:06:06.312: D/dalvikvm(1379): DexOpt: --- BEGIN 'ads2133480362.jar' (bootstrap=0) --- 05-14 15:06:06.632: D/dalvikvm(1413): creating instr width table 05-14 15:06:06.671: D/dalvikvm(1413): DexOpt: load 2ms, verify+opt 18ms 05-14 15:06:06.703: D/dalvikvm(1379): DexOpt: --- END 'ads2133480362.jar' (success) --- 05-14 15:06:06.703: D/dalvikvm(1379): DEX prep '/data/data/by.squareroot.kingsquare/cache/ads2133480362.jar': unzip in 0ms, rewrite 391ms 

डेक्सटॉप , DEX फ़ाइलों की जाँच और अनुकूलन के लिए एक कार्यक्रम है । यह स्पष्ट नहीं है कि उसे क्यों काम करना चाहिए, विशेष रूप से आवेदन शुरू करने के बाद और अजीब विज्ञापनों 2133480362.jar फ़ाइल के साथ। चूँकि इस फाइल से मेरा कोई लेना-देना नहीं था, और ऐसा पहले कभी नहीं हुआ, सभी संदेह AdMob पर पड़े। जाहिरा तौर पर, AdMob SDK एप्लिकेशन की कैश निर्देशिका में कुछ जार फ़ाइल सहेजता है, वहां से कक्षाएं लोड करता है, और बैनर लोड करते और प्रदर्शित करते समय उनका उपयोग करता है। यह देखा जाना बाकी है कि AdMob SDK डेवलपर्स हमसे कितनी लगन से छिपते हैं।

रिवर्सीम AdMob एसडीके

बेशक, एसडीके में कक्षाएं बाधित हैं, लेकिन यह हमारे कार्य को बहुत जटिल नहीं करता है। कुछ शुरुआती बिंदु खोजने के लिए, आइए देखें कि कौन सी कक्षाओं में कॉन्टेक्स्ट.गेट कैशेडिर () पद्धति का कॉल है। वे कुछ ही निकले, केवल दो। उनमें से एक में, इस विधि का उपयोग WebSettings.setAppCachePath () सेट करने के लिए किया जाता है, ताकि पहले से खाली नाम ak.class के साथ केवल एक संदिग्ध वर्ग हो।
व्यक्तिगत रूप से, मैं जद को विघटित करने के लिए उपयोग करता हूं। आइए इस वर्ग में विधि के उस भाग को देखें जहाँ Context.getCacheDir () के लिए एक कॉल है:

 byte[] arrayOfByte1 = an.a(ao.a()); byte[] arrayOfByte2 = an.a(arrayOfByte1, ao.b()); File localFile2 = File.createTempFile("ads", ".jar", paramContext.getCacheDir()); FileOutputStream localFileOutputStream = new FileOutputStream(localFile2); localFileOutputStream.write(arrayOfByte2, 0, arrayOfByte2.length); localFileOutputStream.close(); 

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

 String keyBase64 = Base64Consts.getKeyBase64(); byte[] keyBytes = Decrypter.decodeKey(keyBase64); String classBase64 = Base64Consts.getClassBase64(); byte[] classBytes = Decrypter.decodeClassBytes(keyBytes, classBase64); File classFile = File.createTempFile("ads", ".jar", context.getCacheDir()); FileOutputStream out = new FileOutputStream(classFile); out.write(classBytes, 0, classBytes.length); out.close(); 

अब आप उस क्रम में पार्स कर सकते हैं जहां जार फ़ाइल आती है। Base64Consts वर्ग (पूर्व में Ao ) में Base64- एन्कोडेड स्ट्रिंग्स हैं:

 public class Base64Consts { public static String getKeyBase64() { return "ARuhFl7nBw/97YxsDjOCIqF0d9D2SpkzcWN42U/KR6Q="; } public static String getClassBase64() { return "SuhNEgGjhJl/XS1FVuhqPkUehkYsZY0198PVH9C0C..."; //    ,      } } 

KeyBase64 स्ट्रिंग को Decrypter.decodeKey () विधि का उपयोग करके एक कुंजी में बदल दिया गया है:

 public static byte[] decodeKey(String keyBase64) { byte[] keyBytes = Base64Util.decode(keyBase64); ByteBuffer byteBuffer = ByteBuffer.wrap(keyBytes, 4, 16); byte[] key128 = new byte[16]; byteBuffer.get(key128); for (int i = 0; i < key128.length; i++) { key128[i] = ((byte)(key128[i] ^ 0x44)); } return key128; } 

विधि स्ट्रिंग को बाइट्स के एक सरणी में बदल देती है (AdMob SDK इन उद्देश्यों के लिए अपनी कक्षा का उपयोग करता है, क्योंकि android.util.Base64 केवल एपीआई स्तर 8 में दिखाई दिया है) और 16 बाइट्स का एक ब्लॉक लिया गया है जिसके परिणामस्वरूप 32 बाइट्स 5 वीं से शुरू होती हैं। । प्रत्येक बाइट xor मैजिक नंबर 0x44 है। इन जोड़तोड़ों के परिणामस्वरूप, 128-बिट एईएस कुंजी प्राप्त की जाती है।

ClassBase64 स्ट्रिंग को बाइट सरणी में परिवर्तित किया जाता है, जो कि एक फ़ाइल है, जिसमें Decrypter.decodeClassBytes () विधि का उपयोग किया जाता है:

 public static byte[] decodeClassBytes(byte[] keyBytes, String cryptedBytesBase64) { byte[] cryptedBytes = Base64Util.decode(cryptedBytesBase64); ByteBuffer buffer = ByteBuffer.allocate(cryptedBytes.length); buffer.put(cryptedBytes); buffer.flip(); byte[] initializationVector = new byte[16]; byte[] input = new byte[cryptedBytes.length - 16]; buffer.get(initializationVector); buffer.get(input); SecretKeySpec keySpec = new SecretKeySpec(keyBytes, "AES"); Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); cipher.init(Cipher.DECRYPT_MODE, keySpec, new IvParameterSpec(initializationVector)); return cipher.doFinal(input); } 

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

रहस्यमय विज्ञापन

AdMob SDK इस जार फ़ाइल से कक्षाएं लोड करने के लिए DexClassLoader का उपयोग करता है। इस तरह आंतरिक रूप से उपयोग किया जाता है:

 DexClassLoader classLoader = new DexClassLoader(classFile, context.getCacheDir()), null, context.getClassLoader()); Class clazz = classLoader.loadClass(b(keyBytes, Base64Consts.getClassNameBase64())); Method m = clazz.getMethod(b(keyBytes, Base64Consts.getMethodNameBase64()), new Class[0]); 

उसके बाद, जार फ़ाइल हटा दी जाती है। कक्षाओं और विधियों के नाम उसी तरह से एन्क्रिप्ट किए जाते हैं जैसे कि जार फ़ाइल खुद (बेस 64 + एईएस), इसलिए यह जार फ़ाइल के अंदर तुरंत देखने के लिए तेज़ और आसान होगा।

यह उम्मीद की जा रही थी कि classes.dex फ़ाइल अंदर की ओर निकली हुई है। इसे dex2jar के माध्यम से चलाने के बाद, हमें इस बार कक्षाओं के साथ एक और जार-फ़ाइल मिली।

धन्यवाद मारियो! लेकिन हमारी राजकुमारी दूसरे महल में है!

यहां निराशा ने मेरा इंतजार किया। अंदर पाँच मोटे वर्ग थे जो किसी भी दिलचस्प चीज़ का प्रतिनिधित्व नहीं करते थे। उदाहरण के लिए, इस तरह एक वर्ग:

 public class a { public static Long a() { return Long.valueOf(Calendar.getInstance().getTime().getTime() / 1000L); } } 

और इस तरह:

 public class d { public static String a() { new Build.VERSION(); return Build.VERSION.RELEASE; } } 

वर्गों में से एक मान Settings.Secure.ANDROID_ID लेता है और इसे md5 हैश मानता है। एक और पूरी apk फ़ाइल के SHA-2 हैश को मानता है। जाहिर है, इन मापदंडों का उपयोग सर्वर को भेजे गए अनुरोधों में किया जाता है।
सामान्य तौर पर, कोई गुप्त एल्गोरिदम, कोई छिपा हुआ संदेश, कुछ भी नहीं। ऐसा तुच्छ कोड क्यों छिपाया जाए, यह मेरे लिए एक रहस्य है।

एक सुई में एक अंडा, एक बतख में एक अंडा ...

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

यद्यपि यह हो सकता है कि इस तरह के मुश्किल तरीके Google Play डेवलपर प्रोग्राम नीतियों से खतरनाक उत्पादों की परिभाषा के तहत आते हैं:

Google Play से डाउनलोड किया गया एक ऐप Google Play के अपडेट तंत्र के अलावा किसी अन्य विधि का उपयोग करके अपने स्वयं के एपीके बाइनरी कोड को संशोधित, प्रतिस्थापित या अपडेट नहीं कर सकता है।

सिद्धांत रूप में, कोड बदलता है - एक पुस्तकालय हवा से बनता है, जिसमें से कक्षाएं भरी हुई हैं। लेकिन AdMob निश्चित रूप से ऐसा कर सकता है।