Android कठपुतलियाँ

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


मैं आँकड़ों से शुरू करता हूँ। पहला एंड्रॉइड-आधारित डिवाइस - एचटीसी ड्रीम / जी 1 - अमेरिका और यूके में अक्टूबर 2008 में लॉन्च किया गया था। प्लेटफॉर्म के तेजी से प्रसार की शुरुआत नवंबर 2009 में मोटोरोला ड्रॉयड स्मार्टफोन के आगमन से जुड़ी है। तब से, दैनिक रूप से सक्रिय होने वाले उपकरणों की संख्या अभूतपूर्व रूप से बढ़ रही है। अंतिम Google I / O सम्मेलन में, एक शानदार आंकड़ा घोषित किया गया था: हर दिन 400,000 सक्रियण! ज़रा सोचिए: यह साइप्रस की आधी आबादी है या, उदाहरण के लिए, पूरी ब्रुनेई। कुल मिलाकर, वर्तमान में 100 मिलियन से अधिक Android डिवाइस सक्रिय हैं। बुरा नहीं है। अब कल्पना करें कि उनमें से प्रत्येक Google कम से कम, लेकिन प्रबंधन कर सकता है। शायद मैं थोड़ा अतिरंजना कर रहा हूं और "मैनेज" शब्द यहां सबसे उपयुक्त नहीं है। यह विश्वसनीय रूप से ज्ञात है कि Google GTalkService तंत्र के माध्यम से मनमाने ढंग से एप्लिकेशन इंस्टॉल और हटा सकता है। नए उपकरणों, विली-नीली के सक्रियण के प्रभावशाली आंकड़ों के साथ इसे मिलाकर आप दुनिया में संभावित सबसे बड़े बॉटनेट के बारे में सोचते हैं, जिसमें सैकड़ों हजारों उपयोगकर्ता स्वेच्छा से लॉग इन करते हैं। और यद्यपि यह विचार विज्ञान कथाओं की स्मैक है, मुझे GTalkService तंत्र के इनसाइड को समझने में दिलचस्पी थी। इसकी व्यवस्था कैसे की जाती है? सर्वर से संदेश किस रूप में उपकरणों पर आते हैं? ट्रांसमिशन चैनल कितना सुरक्षित है? क्या कोई खतरा है कि कोई और मेरे डिवाइस पर नियंत्रण आदेशों के साथ एक संदेश भेज सकता है?

Google द्वारा हटाए गए ऐप्स

यह सब GTalkService के बारे में है

कोई भी Android डिवाइस GTalk सर्वर के साथ एक निरंतर टीसीपी / एसएसएल / एक्सएमपीपी कनेक्शन का समर्थन करता है। हर समय जब वह नेटवर्क तक पहुंचता है। कनेक्शन को एक विशेष GTalkSerive सेवा द्वारा नियंत्रित किया जाता है। यदि कनेक्शन सक्रिय है, और यह कनेक्शन हानि होने की स्थिति में यह स्वचालित रूप से पुन: जुड़ता है, तो यह जांचने के लिए Google के सर्वर पर पिंग्स (तथाकथित "दिल की धड़कन संदेश") भेजता है। यह संचार चैनल Google को दूरस्थ रूप से नियंत्रण उपकरणों की अनुमति देता है। GTalkService के माध्यम से भेजा गया एक संदेश निश्चित रूप से प्रत्येक स्मार्टफोन तक पहुंच जाएगा। इस तंत्र के साथ, C2DM सेवा (क्लाउड टू डिवाइस मैसेजिंग फ्रेमवर्क) काम करती है, जिसके साथ डेवलपर्स उपयोगकर्ताओं के स्मार्टफ़ोन पर स्थापित अनुप्रयोगों के लिए विशेष कमांड भेज सकते हैं (उदाहरण के लिए, अपडेट डाउनलोड करना)। हालांकि, जबकि C2DM केवल कुछ डेवलपर्स के लिए सीमित रूप से उपलब्ध है, जिन्होंने एक विशेष अनुरोध छोड़ा है। Android को कम से कम दो आदेशों का समर्थन करने के लिए जाना जाता है: REMOVE_ASSET और INSTALL_ASSET, जो Google को मनमाने ढंग से अनुप्रयोगों को हटाने और स्थापित करने की अनुमति देते हैं। इस प्रकार, एंड्रॉइड मार्केट में मैलवेयर की खोज करने के बाद, कंपनी के इंजीनियर GTalkService के माध्यम से एक REMOVE_ASSET संदेश भेज सकते हैं, और दुर्भावनापूर्ण प्रोग्राम को इंटरनेट से जुड़े सभी उपकरणों से तुरंत हटा दिया जाएगा। यह, जैसा कि हम समाचारों से जानते हैं, कंपनी ने इसे एक से अधिक बार उपयोग किया है। और रिवर्स स्थिति। जैसे ही Google INSTALL_ASSET कमांड जारी करता है, संदेश प्राप्त करने वाला प्रत्येक एंड्रॉइड स्मार्टफोन प्रोग्राम के साथ एपीके वितरण किट डाउनलोड करता है और इसे इंस्टॉल करता है। यह संभावना एक तरफ अच्छी है: Google सभी उभरते हुए मैलवेयर को जल्दी से हटा सकता है। लेकिन दूसरी ओर, यह डरावना है। लेकिन क्या होगा यदि कोई व्यक्ति किसी विशेष फोन के SSL कनेक्शन पर MITM हमले को GTalkService पर लागू कर सकता है और फोन पर किसी प्रकार के संक्रमण को भरने के लिए INSTALL_ASSET संदेश को बिगाड़ सकता है? क्या सिस्टम सुरक्षित है?

डेटा चैनल विश्वसनीयता

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

1. एंड्रॉइड एमुलेटर की छवि प्राप्त करें, जिसमें एंड्रॉइड मार्केट के साथ काम करने की क्षमता शामिल है।
2. अपने CA प्रमाणपत्र को /tystem/etc/security/cacerts.bk रिपॉजिटरी में keytool या portecle का उपयोग करके जोड़ें।
3. CA प्रमाणपत्र के साथ sslsnif का उपयोग करके MITM हमले को लागू करें।

अब जब GTalkService एक कनेक्शन स्थापित करना चाहता है, तो हम ट्रैफ़िक को रोक सकते हैं क्योंकि डिवाइस उस CA प्रमाणपत्र पर भरोसा करता है जिसे हमने बनाया था। यदि हम एमुलेटर पर एंड्रॉइड मार्केट से कुछ एप्लिकेशन इंस्टॉल करने का प्रयास करते हैं, तो, तदनुसार, हम INSTALL_ASSET संदेश की स्थापना रद्द करेंगे। यह कुछ इस तरह दिखेगा:

tickle_id: 1277687266074
assetid: -155863831473120556
asset_name: Replica Island
asset_type: GAME
asset_package: com.replica.replicaisland
asset_blob_url: android.clients.google.com/market/download/Download?assetId=-155863831473120556&userId=986032118775&deviceId=1094117203906638597
asset_signature: Ayn2bWDqckQkKsBY4JurvCFpYN0
asset_size: 5144485

अधिकांश पैरामीटर उस एप्लिकेशन का वर्णन करते हैं जो उपयोगकर्ता एंड्रॉइड मार्केट से अनुरोध करता है। ब्याज का आस्तित्व_संस्थान विशेषता है। यह माना जा सकता है कि यह INSTALL_ASSET संदेश का क्रिप्टोग्राफिक हस्ताक्षर है, जिसकी मदद से इसकी अखंडता की गारंटी है। काश, ऐसा नहीं होता। यह लंबे समय से उत्साही लोगों द्वारा स्थापित किया गया है कि यह एपीके फ़ाइल (यानी प्रोग्राम वितरण किट) के बेस 64 एनकोडेड हैश से अधिक कुछ नहीं है जो उपयोगकर्ता एंड्रॉइड मार्केट से अनुरोध करता है। हम केवल इस बार यह सुनिश्चित कर सकते हैं कि एपीके पैकेज डाउनलोड करके और उसके चेकसम के साथ उचित रूपांतरण का प्रदर्शन किया जाए। यह स्पष्ट हो जाता है कि INSTALL_ASSET संदेश (और इसलिए, किसी भी अन्य) के लिए कोई अतिरिक्त सुरक्षा नहीं है। यदि कोई हमलावर GTalkService के बीच SSL कनेक्शन को बाधित कर सकता है, तो सैद्धांतिक रूप से वह फोन पर मनमाने संदेश भेज सकता है, जिसमें एप्लिकेशन इंस्टॉल करना शामिल है! बेशक, ऐसे कई "बट," हैं और इस तरह के हमले की कल्पना करना मुश्किल है। ऐसा करने के लिए, कम से कम आपको MITM हमले को लागू करने में सक्षम होने के लिए पीड़ित के साथ समान नेटवर्क पर होना चाहिए। उपयोगकर्ताओं के किसी भी बड़े संक्रमण का कोई सवाल नहीं हो सकता है। यह संचार चैनल की सुरक्षा की कमी से अलग नहीं होता है, लेकिन यहां खामियों का फायदा उठाने की संभावनाएं स्पष्ट रूप से कमजोर हैं। इसलिए, हम अब इस पर ध्यान नहीं देंगे, लेकिन आइए देखते हैं कि एंड्रॉइड प्लेटफॉर्म और GTalkService तंत्र क्या आश्चर्यचकित करते हैं।

GTalk सेवा मॉनिटर इंटरफ़ेस

Android Market के साथ सहभागिता

मैंने ऊपर कहा कि GTalkService Android मार्केट से एप्लिकेशन इंस्टॉल करने की प्रक्रिया में शामिल है। यह आम तौर पर एक दिलचस्प कहानी है। यहां दिलचस्प बारीकियां भी हैं। शुरू करने के लिए, उन चरणों पर विचार करें, जो उपयोगकर्ता बाज़ार से प्रोग्राम इंस्टॉल करने के लिए करता है:

1. Android Market लॉन्च करें।
2. इंस्टॉल करने के लिए इच्छित एप्लिकेशन खोजें।
3. "इंस्टॉल" बटन पर क्लिक करना।
4. आवेदन के लिए आवश्यक विशेषाधिकारों की पुष्टि।
5. एप्लिकेशन डाउनलोड करें और इंस्टॉल करें।

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

1. उपयोगकर्ता एंड्रॉइड मार्केट में ऐप इंस्टॉल बटन पर क्लिक करता है।
2. एप्लिकेशन Android मार्केट सर्वरों के लिए POST अनुरोध भेजता है।
3. Android Market सर्वर C2DM सिस्टम पर एप्लिकेशन इंस्टॉल करने के अनुरोध के बारे में जानकारी भेजता है।
4. C2DM सर्वर उपयोगकर्ता के स्मार्टफोन को GTalkService कनेक्शन के माध्यम से INSTALL_ASSET संदेश भेजते हैं।
5. GTalkService घटक INSTALL_ASSET संदेश प्राप्त करता है और वेंडिंग घटक को सक्रिय करता है।
6. वेंडिंग घटक एप्लिकेशन के एपीके पैकेज को डाउनलोड करता है और अंततः एप्लिकेशन इंस्टॉल करता है।

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

POST /market/api/ApiRequest HTTP/1.1
Content-Length: 524
Content-Type: application/x-www-form-urlencoded
Host: android.clients.google.com
Connection: Keep-Alive
User-Agent: Android-Market/2 (dream DRC83); gzip
version=2&request=CuACCvYBRFFBQUFLOEFBQUJvZWVEVGo4eGV4OVRJaW9 . . .

अनुरोध पैरामीटर को छोड़कर सब कुछ ट्राइट है, जिसमें सब कुछ स्पष्ट और छिपाना है। Google को जानने के बाद, कोई भी आसानी से यह मान सकता है कि यह प्रोबॉफ मालिकाना संरचना में पैक किया गया डेटा है और इसके बाद base64 में इनकोड किया गया है। तो यह है। हैश को डिकोड करने और संरचना को अनपैक करने के बाद, हमें अनुरोध डेटा मिलता है:

1 {
1: "DQAAAK8AAABoeeDTj8xex9TIio . . ."
2: 0
[... ...]
13: "-606db3000d480d63"
}
2 {
10 {
1: "353999319718585473"
}
}

प्रोटोबुफ से डिकोडिंग के बाद संरचना का अनुरोध करें

पहले से ही कुछ है, लेकिन एक समस्या है: हम नहीं जानते कि यह या उस पैरामीटर के लिए क्या जिम्मेदार है। सबसे अधिक संभावना है, ये डिवाइस के कुछ पहचानकर्ता हैं, प्लेटफ़ॉर्म के बारे में जानकारी, प्राधिकरण के लिए कुछ जानकारी, और, ज़ाहिर है, बाज़ार से अनुरोध किए गए एप्लिकेशन की पहचानकर्ता। यहां यह कहा जाना चाहिए कि एंड्रॉइड मार्केट के साथ काम करने में भाग लेने वाले कई प्रोटोबॉफ़ संरचनाओं के लिए, उत्क्रमण के परिणामस्वरूप उत्साही लोगों द्वारा किए गए विवरण उपलब्ध हैं। और साइट पर कोड. google.com/p/android-market-api यहां तक ​​कि एक सामूहिक रूप से लिखित एपीआई पोस्ट किया गया है जो आपको बाजार से विभिन्न डेटा (विवरण, प्रोग्राम आइकन, आदि) का अनुरोध करने की अनुमति देता है। सच है, अनुप्रयोगों को स्थापित करने के लिए अनुरोध की संरचना पर कोई डेटा नहीं है। लेकिन उलटफेर प्रसिद्ध एंड्रॉइड प्लेटफ़ॉर्म शोधकर्ता जॉन ओबेरहिद द्वारा किया गया था, जिन्होंने बाद में एक दिलचस्प हमला किया, जिसके बारे में मैं आपको बताना चाहता हूं। अतः, संक्षिप्त रूप में अनुरोध की संरचना इस प्रकार है:

[.. ..]
message InstallRequest {
optional string appId = 1;
}
message RequestContext {
required string authToken = 1;
[.. ..]
required string androidId = 4;
optional string deviceAndSdkVersion = 5;
[.. ..]

अनुरोध से अधिकांश फ़ील्ड डिवाइस से ही निकाले जा सकते हैं (उदाहरण के लिए, इंटरफ़ेस भाषा, सिस्टम संस्करण, आदि)। लेकिन नहीं appId और CortToken मापदंडों:

• appId - Android Market में एक अद्वितीय एप्लिकेशन पहचानकर्ता है। यह पहचानकर्ता कहीं भी प्रदर्शित नहीं होता है, इसलिए इसे प्राप्त करने का एकमात्र तरीका एंड्रॉइड मार्केट से एक आवेदन का अनुरोध करना और इसके पहचानकर्ता को प्रोटोबॉफ संरचना से खींचकर ट्रैफ़िक लेना है।
• ऑर्टोटोकैन क्लाइंटलॉगिन सिस्टम का एक टोकन है, जिसके साथ एंड्रॉइड मार्केट सर्वर आपके अनुरोध को प्रमाणित कर सकते हैं।

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

AccountManager accountManager = AccountManager.get(getApplicationContext());
Account acct = getAccount(accountManager);
accountManager.getAuthToken(acct, "android", false, new GetAuthTokenCallback(), null);

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

एप्लिकेशन के माध्यम से हमला

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

यह लेख शोधकर्ता जॉन ओबेरिड की सामग्री के आधार पर तैयार किया गया था।


हैकर पत्रिका, जुलाई (07) 150

हैकर की सदस्यता लें

• 1 999 पी। पेपर विकल्प के 12 नंबरों के लिए
• 1249 आरयूआर iOS / iPad की वार्षिक सदस्यता के लिए (Android रिलीज़ जल्द ही आ रहा है!)
• एंड्रॉइड पर हैकर