Android सुरक्षा परीक्षण सुइट विकास किट (STS SDK)

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

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

नवीनतम एसटीएस एसडीके प्राप्त करें

आवश्यक शर्तें

• 64-बिट लिनक्स पीसी।
• Android Studio (आपके डिस्ट्रो के पैकेज मैनेजर से भी इंस्टॉल किया जा सकता है।
• Android प्लेटफ़ॉर्म टूल ( adb , fastboot ) को स्थापित करने और आपके $PATH में होने की आवश्यकता है (यानी आपको कमांड लाइन से adb चलाने में सक्षम होना चाहिए)। प्लेटफ़ॉर्म टूल इंस्टॉल करने का सबसे आसान तरीका आपके डिस्ट्रो के पैकेज मैनेजर के माध्यम से है।
  • यदि स्टैंडअलोन प्लेटफ़ॉर्म टूल के बजाय Android स्टूडियो के SDK प्रबंधक का उपयोग कर रहे हैं, तो SDK की platform-tools निर्देशिका को अपने $PATH में जोड़ना याद रखें।
• aapt , जिसे आपके डिस्ट्रो के पैकेज मैनेजर के माध्यम से भी इंस्टॉल किया जा सकता है।

Android स्टूडियो का उपयोग करना प्रारंभ करें

संग्रह को निकालने के बाद, मौजूदा प्रोजेक्ट के रूप में Android स्टूडियो में निर्देशिका खोलें। लक्ष्य एंड्रॉइड डिवाइस की वास्तुकला के आधार पर, कंकाल परीक्षण बनाने के लिए assembleSTSARM चलाएं या assembleSTSx86 बिल्ड लक्ष्य बनाएं। कनेक्टेड डिवाइस पर कंकाल परीक्षण चलाने के लिए runSTS बिल्ड लक्ष्य चलाएं (एडीबी अधिकृत होना चाहिए)।

ग्रैडल का उपयोग करना प्रारंभ करें

आर्काइव निकालने के बाद, sdk.dir गुण को local.properties फ़ाइल में Gradle प्रोजेक्ट के रूट पर सेट करें, फिर कंकाल परीक्षण बनाने के लिए assembleSTSARM Gradle कार्य चलाएँ। बिल्ड समाप्त होने के बाद, परीक्षण ( cd ) को build/android-sts/tools में नेविगेट करके और sts-tradefed रैपर को निष्पादित करके चलाया जा सकता है।

$ echo 'sdk.dir=/home/<myusername>/Android/Sdk' > local.properties
$ ./gradlew assembleSTSARM
$ cd build/android-sts/tools
$ ./sts-tradefed run sts-dynamic-develop -m hostsidetest

एक एसटीएस परीक्षण लिखें

एसटीएस परीक्षण के तीन भाग हैं:

1. एक होस्ट-साइड ट्रेडफेड टेस्ट जो एसटीएस sts-test उपनिर्देशिका में एडीबी के माध्यम से डिवाइस के साथ इंटरैक्ट करता है।
2. एक वैकल्पिक नेटिव प्रूफ-ऑफ-कॉन्सेप्ट अटैक जिसे adb push के माध्यम से डिवाइस पर धकेला जाता है और native-poc उपनिर्देशिका में होस्ट-साइड टेस्ट द्वारा निष्पादित किया जाता है।
3. एक वैकल्पिक ऐप या सेवा एपीके जो adb install के माध्यम से डिवाइस पर स्थापित है और होस्ट-साइड टेस्ट द्वारा भी लॉन्च किया गया है। ऐप या सेवा में JUnit अभिकथनों का अपना सेट भी हो सकता है जो होस्ट-साइड रनर को रिपोर्ट किया जाता है। यह test-app उपनिर्देशिका में है।

एक विशिष्ट एसटीएस परीक्षण प्रवाह आमतौर पर दो पैटर्नों में से एक का अनुसरण करता है:

• अवधारणा के मूल प्रमाण:

  1. होस्ट-साइड टेस्ट डिवाइस पर मूल निष्पादन योग्य को धक्का देता है और लॉन्च करता है।
  2. मूल प्रोग्राम क्रैश हो जाता है या एक विशिष्ट निकास कोड लौटाता है।
  3. होस्ट-साइड टेस्ट क्रैश के लिए जाँच करता है, लॉगकैट बैकट्रेस को देखता है, या यह निर्धारित करने के लिए विशिष्ट निकास कोड की तलाश करता है कि क्या हमला सफल हुआ।

• इंस्ट्रूमेंटेड टेस्ट ऐप:

  1. होस्ट-साइड परीक्षण डिवाइस पर ऐप या सेवा से युक्त एपीके को पुश करता है।
  2. होस्ट-साइड परीक्षण डिवाइस-साइड JUnit परीक्षण शुरू करता है जिसे एपीके के साथ runDeviceTest() के माध्यम से बंडल किया जाता है
  3. डिवाइस-साइड JUnit टेस्ट बटन को टैप करता है और UIAutomator का उपयोग करके ऐप को देखता है, या अन्यथा एंड्रॉइड सिस्टम को उन तरीकों से एक्सेस करता है जो सुरक्षा कमजोरियों को प्रकट करते हैं।
  4. डिवाइस-साइड JUnit परीक्षणों की सफलता या विफलता होस्ट-साइड टेस्ट में वापस आ जाती है, जिसका उपयोग यह निर्धारित करने के लिए किया जा सकता है कि टेस्ट पास हुआ या नहीं।

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

मेरे प्रूफ-ऑफ-कॉन्सेप्ट अटैक के लिए टेस्ट ऐप और/या नेटिव एक्जीक्यूटेबल की जरूरत नहीं है

अधिकांश परीक्षणों को डिवाइस-साइड ऐप और मूल निष्पादन योग्य दोनों की आवश्यकता नहीं होगी।

यदि आपके परीक्षण में ऑन-डिवाइस ऐप/सेवा का उपयोग शामिल नहीं है, तो बस test-app उपनिर्देशिका को हटा दें। इसी तरह, यदि आपका परीक्षण मूल निष्पादन योग्य का उपयोग नहीं करता है, तो native-poc उपनिर्देशिका को हटा दें, फिर प्रोजेक्ट को ग्रैडल-सिंक करें। जब वे मौजूद नहीं होते हैं तो उन मॉड्यूल को स्वचालित रूप से छोड़ने के लिए प्रोजेक्ट की स्थापना की जाती है।

मेरे प्रूफ-ऑफ-कॉन्सेप्ट अटैक में एक दूसरा ऐप/सेवा शामिल है

सबसे पहले, अपने दूसरे ऐप/सेवा के लिए अपने प्रोजेक्ट में एक नया मॉड्यूल जोड़ें और लिखें कि आप किसी अन्य एपीके की तरह लिखेंगे।

इसके बाद, इस निर्देशिका के मूल में build.gradle को संपादित करें और copyArtifacts , assembleStsARM , और assembleStsx86 में दिए गए निर्देशों का पालन करते हुए अपना मॉड्यूल जोड़ें। यह सुनिश्चित करेगा कि संकलित एपीके को एसटीएस की आउटपुट निर्देशिका में कॉपी किया गया है और नए ऐप को परीक्षण के रूप में इंस्टॉल/कॉल करने में सक्षम बनाता है।

अंत में, प्रोजेक्ट को ग्रैडल-सिंक करें।

एसटीएस परीक्षण जमा करना

zipForSubmission टास्क चलाएं (या तो एंड्रॉइड स्टूडियो के साथ या कमांड लाइन पर ग्रैडल के साथ)। एक नई फ़ाइल, codesubmission.zip , प्रोजेक्ट के रूट पर build डायरेक्टरी में बनाई जानी चाहिए। Android भेद्यता पुरस्कार कार्यक्रम में अपने सबमिशन के साथ उस फ़ाइल को अपलोड करें।