Android Security Test Suite डेवलपमेंट किट (एसटीएस SDK टूल)

सिक्योरिटी टेस्ट सुइट ट्रेड फ़ेडरेशन (एसटीएस-ट्रेडिफ़ाइड) का निर्माण Android ट्रेड फ़ेडरेशन सुरक्षा के लिए सभी Android डिवाइसों की जांच करने के लिए हार्नेस की जांच करें पैच टेस्ट जो कंपैटबिलिटी टेस्ट सुइट में शामिल नहीं हैं. ये टेस्ट खास तौर पर, उन सुधारों के लिए इस्तेमाल किया जाता है जो सामान्य जोखिम की आशंका और एक्सपोज़र (सीवीई).

SDK टूल की मदद से, Android सोर्स ट्री के बाहर एसटीएस टेस्ट डेवलप किए जा सकते हैं Android Studio या स्टैंडर्ड Android SDK का इस्तेमाल कर रहे हों. इसमें सभी सुविधाएं शामिल हैं जो एसटीएस टेस्ट बनाने और चलाने के लिए ज़रूरी हैं.

एसटीएस SDK टूल का नया वर्शन डाउनलोड करें

ज़रूरी शर्तें

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

ध्यान दें: अगर आपको ज़रूरत हो, तो सीटीएस गाइड देखें ADB और AAPT को सेट अप करने में मदद मिलती है.

चेतावनी: आधिकारिक तौर पर, STS सिर्फ़ 64-बिट Linux मशीनों के साथ काम करता है. जब टेस्ट लिखे गए हों STS SDK टूल को Windows या MacOS पर Android Studio की मदद से बनाया जा सकता है. उन प्लैटफ़ॉर्म पर चलाया जा सकता है जो इस दस्तावेज़ में शामिल नहीं हैं.

Android Studio का इस्तेमाल शुरू करना

संग्रह को एक्सट्रैक्ट करने के बाद, डायरेक्ट्री को Android Studio में मौजूदा प्रोजेक्ट के दायरे में आता है. assembleSTSARM या assembleSTSx86 बिल्ड टारगेट चलाएं टारगेट किए गए Android के आर्किटेक्चर के आधार पर, स्केलेटन टेस्ट बना सकते हैं डिवाइस. कनेक्ट किए गए डिवाइसों पर स्केलेटन टेस्ट करने के लिए, runSTS बिल्ड टारगेट चलाएं डिवाइस (ADB को अनुमति दी जानी चाहिए).

Gradle का इस्तेमाल शुरू करना

संग्रह एक्सट्रैक्ट करने के बाद, sdk.dir प्रॉपर्टी को local.properties फ़ाइल को Gradle प्रोजेक्ट के रूट में रखें, इसके बाद assembleSTSARM स्केलेटन टेस्ट बनाने के लिए, टास्क को ग्रेड करें. बिल्ड के बाद खत्म हो गया है, तो परीक्षण (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

एसटीएस टेस्ट का डेटा सेव करने की अनुमति दें

ध्यान दें: एसटीएस जांच तब पास हो जाती है, जब डिवाइस जोखिम की स्थिति में न हो. साथ ही, डिवाइस पर किसी जोखिम की आशंका है या दूसरे शब्दों में, जब हमला काम करता है. जांच में ASSUMPTION_FAILURE रिटर्न करें (उदाहरण के लिए, इसके बजाय Assume का इस्तेमाल करना Assert) के बाद तब यह पता नहीं चल सकता कि डिवाइस की सुरक्षा को खतरा है या नहीं.

एसटीएस टेस्ट के तीन हिस्से होते हैं:

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

एसटीएस की जांच का सामान्य फ़्लो, आम तौर पर दो में से एक पैटर्न के साथ होता है:

• नेटिव कॉन्सेप्ट का सबूत:

  1. होस्ट-साइड टेस्ट, पुश नोटिफ़िकेशन भेजता है और डिवाइस.
  2. नेटिव प्रोग्राम क्रैश हो जाता है या कोई खास एग्ज़िट कोड दिखाता है.
  3. होस्ट-साइड टेस्ट, क्रैश की जांच करता है, और Logcat बैकट्रेस को देखता है, या यह तय करने के लिए खास एग्ज़िट कोड देखता है कि हमला सफल रहा.

• इंस्ट्रुमेंट्ड टेस्ट ऐप्लिकेशन:

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

दो पैटर्न का कॉम्बिनेशन. उदाहरण के लिए, से जोड़ा जा सकता है. कोई अन्य इंस्ट्रुमेंटेशन frida-inject जैसे फ़्रेमवर्क भी उपलब्ध हैं. जानकारी के लिए, यह देखें Security Test Suite रेफ़रंस दस्तावेज़ और ट्रेड किए गए रेफ़रंस दस्तावेज़.

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

ज़्यादातर जांचों के लिए डिवाइस-साइड ऐप्लिकेशन और मूल एक्ज़ीक्यूटेबल ऐप्लिकेशन, दोनों की ज़रूरत नहीं होगी.

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

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

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

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

आखिर में, प्रोजेक्ट को Gradle-सिंक करें.

एसटीएस टेस्ट सबमिट करें

zipForSubmission टास्क (Android Studio या Gradle के साथ) कमांड लाइन). build में एक नई फ़ाइल codesubmission.zip बनाई जानी चाहिए निर्देशिका को प्रोजेक्ट के रूट में रखा जा सकता है. अपने 'Android के जोखिम की आशंका के लिए इनाम कार्यक्रम' के लिए फ़ॉर्म सबमिट करना.