description: Bluetooth-Worm:SymbOS/Cabir विश्लेषण

Bluetooth-Worm:SymbOS/Cabir विश्लेषण

पढ़ना शुरू करने से पहले, मुझे यह घोषणा करनी है: कृपया जो कुछ भी आप पढ़ते हैं उसे संदेह की दृष्टि से लें, क्योंकि मैं किसी भी तरह से SymbianOS डेवलपर नहीं हूँ और न ही SymbianOS वातावरण से कोई परिचित हूँ।

लेकिन इतनी पुरानी चीज़ का विश्लेषण क्यों? खैर, क्योंकि यह रिमोट हैकिंग में घुसने का सबसे आसान तरीका है, क्योंकि आजकल इस तरह की बकवास 1 मिलियन की ndays/0days से की जाती है 🤑🤑🤑। और क्योंकि मुझमें अभी तक उस तरह की विशेषज्ञता नहीं है।

ठीक है, अब जब हमने यह बकवास निकाल दी है, चलो इसे शुरू करते हैं। WTF है Cabir? यह एक Bluetooth-worm है जो Symbian मोबाइल फोन पर चलता है। उन लोगों के लिए जो सोच रहे हैं कि WTF है Symbian फोन और यह सब। खैर, मूल रूप से यह एक फोन है जो ARM चलाता है, तो यह बिल्कुल नई चीज़ है :) और अधिक संक्षिप्त जानकारी (https://en.wikipedia.org/wiki/S60_(software_platform))

अब हम भाग्यशाली थे कि इसका सोर्स कोड ऑनलाइन उपलब्ध था (vxug की सौजन्य से) (SymbianOS.Cabir.7z)। अब हम इसे संदर्भ के रूप में उपयोग करेंगे, लेकिन सच में उससे क्या। मैं ऐसा करने का एक और कारण यह है कि मैं ARM के साथ खिलवाड़ करना चाहता हूँ। तो हम इसे source/assembly/emulator/debugging/sniffing दृष्टिकोण से देखेंगे।

ठीक है, तो #1 हम सोर्स कोड को कैसे कंपाइल करें?

खैर, यह उतना जटिल नहीं है...

सबसे पहले carbide ++ इंस्टॉल करें (http://www.mediafire.com/file/6z54qrceef73x9s/Carbide_cpp_v2_7_en.exe/file)(from https://gist.github.com/artem78/cb2b9650af186844f7b5654964676284)

अगला, कोई भी perl engine इंस्टॉल करें

अगला, nokia pc suite इंस्टॉल करें (https://www.usitility.com/nokia-pc-suite/)

SDK इंस्टॉल करें (http://www.mediafire.com/file/9uc7fjb2ynmxlud/s60v3.1_SDK.zip/file )

c/c++ plugin इंस्टॉल करें (https://ia800905.us.archive.org/7/items/nokia_sdks_n_dev_tools/s60_open_c_cpp_plug_in_v1_7_en.zip)

और वोइला, हमारा वातावरण तैयार है :)

P.S. बेहतर होगा Windows 7 का उपयोग करें, क्योंकि जाहिर तौर पर Windows 10 पर चीज़ें टूट जाती हैं और सही ढंग से काम नहीं करतीं।

लाइव वातावरण संक्रमण

TBD

इस भाग के लिए जान लें कि आपको अपने फोन को jailbreak करने की आवश्यकता है (हाँ, आपने सही सुना, jailbreak)। यह कैसे होता है?

रिवर्स इंजीनियरिंग विश्लेषण

ठीक है, तो कोई इस चीज़ को कैसे कंपाइल करता है? बहुत अच्छा सवाल। तो मैंने जो किया, वह यह था कि caribe\group फ़ोल्डर से ABLT.BAT को इस तरह चलाया

ठीक है, अब हम जो करते हैं वह यह है कि जहां हमारा SDK इंस्टॉल है वहां जाएं, प्लेटफ़ॉर्म फ़ोल्डर की पहचान करें (मेरे मामले में S60_3rd_fp1), फिर epoc32 फ़ोल्डर ढूंढें, build फ़ोल्डर में जाएं, user फ़ोल्डर, username फ़ोल्डर चुनें और फिर दो या तीन और निर्देशिकाएं, और आप एक ऐसे फ़ोल्डर में पहुंचेंगे जो ऐसा दिखता है

यह वर्तमान पथ है जो लगभग उसी के समान होना चाहिए जो आपके पास होना चाहिए (C:\Symbian\9.2\S60_3rd_FP1\Epoc32\BUILD\Users\pwn\Desktop\CabirSourceCodes\caribe\group)

ठीक है, अब हमें caribe फ़ोल्डर (या जैसा आपने सोर्स कोड का नाम रखा है) में जाना है, और आपको अलग-अलग नामों वाला एक फ़ोल्डर मिलेगा जैसा यहां देखा गया है

यह किस बारे में है? खैर, मूल रूप से जब हम पहली बार ablt.bat चलाते हैं (आज भी मुझे इसका उद्देश्य नहीं पता, लेकिन जो भी हो) हमें अपनी pkg फ़ाइल बनाने के लिए अलग-अलग प्लेटफ़ॉर्म विकल्प मिलते हैं, जिससे हम अपनी sis फ़ाइल उत्पन्न करेंगे। यहां दिए गए मामले में हम GCCE और WINSCW देखते हैं। यदि आप डिफ़ॉल्ट रूप से कमांड ablt.bat build चलाते हैं, तो यह WINSCW के लिए बिल्ड करेगा (जो इम्यूलेटर प्लेटफ़ॉर्म के लिए दिया गया कोड नाम है)। सोर्स कोड कंपाइल करना सीखने के उद्देश्य से अभी हम GCCE का उपयोग करेंगे, लेकिन प्रक्रिया वही है यदि आप, जाने-अनजाने, ARM प्लेटफ़ॉर्म के लिए करते हैं ताकि आप इसे अपने फोन पर अपलोड कर सकें। तो मूल रूप से ablt build arm_whatever चलाएं और फिर यहां तक के बिल्कुल वही चरण करें। ठीक है, अब हम GCCE फ़ोल्डर में जाते हैं

urel फ़ोल्डर में जाएं और वहां caribe.app नामक एक फ़ाइल होनी चाहिए। वहां से आप कमांड लाइन खोलकर चलाना चाहेंगे

तो यह क्या करता है??? खैर, मूल रूप से हमने makesis चलाया जो एक sis फ़ाइल उत्पन्न करता है ताकि हम इसे अपने फोन पर इंस्टॉल कर सकें, और हम caribe सोर्स कोड से sis फ़ाइल में क्यों हैं? खैर, मूल रूप से हमें makesis को caribe.pkg निर्दिष्ट करने की आवश्यकता थी। ठीक है, तो build blah blah फ़ोल्डर तक पहुंचने के लिए यह सब परेशानी क्यों? क्योंकि आपको इसे -d पैरामीटर में निर्दिष्ट करने की आवश्यकता है ताकि यह .sis फ़ाइल उत्पन्न कर सके।

ठीक है, यह विधि केवल sdk v3 पर काम करती है, जिसे इस लेख में संदर्भित किया गया है। जाहिर तौर पर जब मैं प्रयोग कर रहा था, एक समर्पित symbian discord सर्वर के एक dev ने बताया कि cabir sdk v2 के लिए कोड किया गया है, और ऐसे में मैंने जो यहां प्रस्तुत किया है वह बेकार होगा..... यह TBD है जब भी मैं उस तक पहुंच सकता हूँ... क्योंकि वह इन दिनों discord पर काफी ऑफलाइन रहता है...

ठीक है, तो कोई .sis फ़ाइल को कैसे रिवर्स इंजीनियर करता है?

सीधे शब्दों में, .sis फ़ाइल एक संग्रह है। तो... हम unzip करने के लिए siscontents एप्लिकेशन का उपयोग करते हैं और फिर .app फ़ाइल को ida में डालते हैं।

असेंबली परिप्रेक्ष्य

तो पूरी प्रक्रिया ऐसी दिखती है

तो अब हम उस फ़ोल्डर में जाते हैं और अगले 2 में हमें app.app फ़ाइल मिलती है

ठीक है, यदि आप इसे ida में डालते हैं।

ठीक है, तो मूल रूप से एक ARM exe। कमाल है, यार! आगे चलें! हाँ, ज़रूर ~~~

फ़ाइल में symbols हैं, हाँ!!! वैसे हाँ, क्योंकि किसी अजीब कारण से हमने बाइनरी को debug symbols के साथ कंपाइल किया, हम भाग्यशाली रहे!

और चूंकि हमारे पास मूल रूप से कोड है, रिवर्स इंजीनियरिंग की प्रक्रिया लगभग वही है जैसा कि source code analysis अध्याय में वर्णित है :)

स्निफिंग दृष्टिकोण

दुर्भाग्यवश मैं यह नहीं कर सकता, क्योंकि मैंने Fts4bt का उपयोग करने की योजना बनाई थी, क्योंकि मैंने देखा कि यह काफी अच्छा था (https://www.diva-portal.org/smash/get/diva2:24278/FULLTEXT01.pdf)

लेकिन जाहिर तौर पर उत्पाद अपने जीवन के अंत (EOL) तक पहुंच गया। यदि आप संयोग से यह हिस्सा कर सकते हैं, तो कृपया मुझे डीएम करें और इस अध्याय को पूरा करने के लिए pull request भेजें।

डिबगर दृष्टिकोण

तो इस सेक्शन के बारे में क्या!>>~> खैर, इस पर मेरी राय यह है: हालांकि मेरे और आपके (पाठक) लिए अनुभव के रूप में यह सीखना मूल्यवान होगा कि USB के माध्यम से डिबगर को कैसे जोड़ा जाए और सीधे nokia फोन पर कोड डिबग किया जाए, फिर भी अभी इसमें मुझे बहुत समय और मेहनत लगेगी (मैं पहले से ही काफी थका हुआ हूँ... क्षमा करें, शायद किसी और समय)। एक और तर्क कि यह बेकार क्यों होगा, क्योंकि हमारे पास सोर्स कोड और एक विशेष रूप से डिज़ाइन किया गया symbian IDE है। तो यहां हम क्या करने वाले हैं। हम Carbide++ के डिबगर का उपयोग करके एक या दो फ़ंक्शनों को संक्षेप में डिबग करने जा रहे हैं, और यह पाठक द्वारा किया जा सकता है क्योंकि कोड का प्रवाह sca अनुभाग में समझाया गया था, और क्योंकि कोड का विश्लेषण करना कठिन बनाने के लिए कोई एन्क्रिप्शन/एंटी-कुछ भी तरीके नहीं हैं। तो... चलो चलें!

सच कहूँ तो

सोर्स कोड विश्लेषण

ठीक है, तो आइए इस तथ्य का लाभ उठाएं कि हमारे पास सोर्स कोड तक पहुंच है और इसे अधिकतम लाभ के लिए उपयोग करें।

तो हमारी डायरेक्टरी संरचना ऐसी दिखती है, जो काफी अच्छी तरह व्यवस्थित है

तो चलिए src फ़ोल्डर का निरीक्षण करें

हमारी यात्रा src फ़ोल्डर से शुरू होती है, विशेष रूप से caribe.cpp से। लेकिन क्यों? क्योंकि हालांकि यह काफी अच्छी तरह व्यवस्थित है, एक चीज़ जो अलग दिखती है वह है caribe.cpp नामक फ़ाइल। क्या इसमें कुछ खास है? नहीं, लेकिन मैंने शिक्षित अनुमान लगाया कि इस मामले में 29A (मैलवेयर विकसित करने वाला समूह) ने सॉफ्टवेयर डेवलपर्स के शास्त्रीय दृष्टिकोण का पालन किया, जहां ऐप का मुख्य तर्क name_of_project.extension में जाता है। ठीक है, तो यह कैसा दिखता है? ऐसे, युवा खून

बढ़िया, लेकिन यह क्या है? सच में मुझे नहीं पता, लेकिन चलो कुछ अनुमान लगाने की कोशिश करते हैं। केवल नाम के आधार पर मैं अनुमान लगाऊंगा कि CApaApplication इस एप्लिकेशन का मुख्य है। अगर हम इसे Google पर खोजते हैं तो हम देखते हैं कि

ठीक है, तो अब क्या? चलो और गहराई से देखते हैं, यार। चलो CCaribeApplication का निरीक्षण करें। लेकिन CCaribeApplication कहाँ है? CaribeApplication.h में। वह कहाँ है? inc फ़ोल्डर में, भाई, जो ऐसा दिखता है

ठीक है, तो यह ऐसा दिखता है

बढ़िया, तो हम एक क्लास देखते हैं जो किसी अन्य क्लास से विरासत में मिलती है, और हम CreateDocumentL नामक एक protected मेथड देखते हैं। ठीक है, लेकिन कुछ दिलचस्प नहीं। हाँ, यह मेरी गलती है, दोस्त!!

यह क्या गलती है, यो! और तुम खुद को मैलवेयर विश्लेषक कहते हो =))) शांत हो जाओ, भाई! नहीं, हमने कहा कि इस प्रोजेक्ट के लेखक ने शायद एक सामान्य सॉफ्टवेयर डेवलपर की तरह काम किया, इसलिए हमें स्वाभाविक रूप से src फ़ोल्डर में caribeapplication.cpp का निरीक्षण करना चाहिए। ठीक है, चलो करते हैं :)

ठीक है, तो हमारे लिए अज्ञात शब्दों का एक समूह और कुछ बकवास। आइए कुछ स्पष्टता लाएं...

पहले उस constant (0x10005B91) पर चर्चा करते हैं। इसका उद्देश्य क्या है? खैर, इसका प्रकार TUid है, जिसे इस प्रकार परिभाषित किया गया है

ठीक है, तो मोटे तौर पर एक id। लेकिन क्यों??? सच में मुझे नहीं पता, लेकिन जब आप एक ऐप बनाते हैं तो आपको एक uuid मिलता है। दिलचस्प बात यह है कि यदि आप इसके बारे में इंटरनेट पर खोजते हैं, तो आप देखेंगे कि यह हमेशा उस चीज़ के हिस्से के रूप में परिभाषित होता है जिसे .sis ऐप कहा जाता है, जिसे हम बाद में देखेंगे। तो मूल रूप से यह SymbianOS पर एक ऐप के लिए शास्त्रीय हेडर परिभाषा की तरह है। ठीक है, अगला। हम उस फ़ंक्शन को देखते हैं जिसमें हम रुचि रखते हैं, जो है CreateDocumentL।

तो....

और हम जिसे कॉल करते हैं वह है CreateDocumentL

तो हम एक document बनाते हैं... लेकिन क्यों...? सच में मैं भी उतना ही खोया हुआ हूँ जितना आप, लेकिन मेरा अनुमान है कि जब हम एक document बनाते हैं, तो हम मूल रूप से किसी तरह एक क्लास बनाते हैं जो हमें ऐप के UI के साथ बातचीत करने की सुविधा देता है, क्योंकि हम इसे मूल रूप से UI फ्रेमवर्क से प्राप्त करते हैं।

और चूंकि हम CreateDocumentL को कॉल करते हैं (मुझे लगता है कि इस उदाहरण में हम अपने कस्टम निष्पादन के साथ परिभाषा को ओवरराइट करते हैं), तो इसकी परिभाषा कहां है?? खैर, मुझे लगता है CaribeDocument.h में। तो यह किस बारे में है???

ठीक है, हम स्वाभाविक रूप से उस फ़ंक्शन को देखते हैं जिसमें हम रुचि रखते हैं, newL, तो चलिए CaribeDocument.cpp का निरीक्षण करते हैं

जैसा कि हम देख सकते हैं, हम अंततः new L को कॉल करते हैं जो newLC को कॉल करता है जो constructL को कॉल करता है और बस इतना ही। लेकिन CEikAppUi CreateAppUiL फ़ंक्शन के बारे में क्या? खैर

तो आइए इसमें से कुछ अर्थ निकालने की कोशिश करें। मूल रूप से जब हम CCaribeDocument के कंस्ट्रक्टर को कॉल करते हैं, तो हम CEikApplication को एक document के रूप में instantiate करते हैं। वह CEikApplication इस प्रकार परिभाषित है

तो मुझे लगता है कि यहां जो होता है वह यह है कि हम मूल रूप से UI तक पहुंचने की कोशिश करते हैं, और फिर हम एक क्लास परिभाषित करते हैं जो बाद में CreateAppUiL के साथ UI के साथ बातचीत को संभाल सकती है। ठीक है, तो चलिए CCaribeAppUi.h/CCaribeAppUi.cpp का निरीक्षण करते हैं

तो... हम इसका कोई अर्थ नहीं निकाल पाएंगे जब तक कि हम यह न देखें कि यह किससे विरासत में मिलता है, और वह है CAknAppUi।

तो हम देखते हैं कि

जिसे हम आगे निरीक्षण करते हैं कि CAknAppUi कैसा दिखता है

जिसका हम बाद में ConstructL का निरीक्षण करते हैं

जिससे मुझे लगता है कि यह एक सहायक फ़ंक्शन है जो केवल कंस्ट्रक्टर को पूरा करता है, क्योंकि कंस्ट्रक्टर खाली छोड़ दिया गया है। ठीक है, तो चलो इसे खोदते हैं

तो पहली पंक्ति में हम देखते हैं कि यह ErrMessage नामक एक फ़ंक्शन है, जिसे general.h में एक मैक्रो के रूप में परिभाषित किया गया है जो निर्दिष्ट पाठ पंक्तियों के साथ एक सूचना संवाद प्रदर्शित करता है। हम रिपोर्ट से जानते हैं कि cabir ने कैसा व्यवहार किया, मैलवेयर हमेशा नाम के साथ एक पॉपअप दिखाता था। जैसे

इसके बाद हम User::After का कॉल देखते हैं, यह क्या करता है? खैर, मैंने इसे बेहतर समझने के लिए इस पुस्तक का उपयोग किया (http://staff.ustc.edu.cn/~dingqing/teach/project/mobile/(2006%20Wiley)Developing%20Software%20for%20Symbian%20OS%A3%BAAn%20Introduction%20to%20Creating%20Smartphone%20Applications%20in%20C%20Plus%20Plus.pdf), और यदि हम इसे देखें तो यह कहता है कि यह मूल रूप से n सेकंड की प्रतीक्षा करता है, यहां 10 सेकंड*10 है जो लगभग 100 सेकंड है (त्वरित गणित =)) स्क्र्रा रा)

अगला, हम BaseConstructL को कॉल करते हैं जो मूल रूप से ENoAppResourceFile को मान के रूप में पारित करके UI को प्रारंभ करता है। यदि हम थोड़ी खोजबीन करें

और अगला, हम CaribeInstaller प्रकार का एक वेरिएबल घोषित करते हैं। ठीक है, तो देखते हैं कि यह किस बारे में है

तो हम CaribeInstaller.cpp का निरीक्षण करते हैं और देखते हैं कि यह काफी बड़ा है (that's what she said :)) ) खैर, मैं कई छवियां पोस्ट करूंगा क्योंकि स्रोत काफी बड़ा है

ठीक है, चूंकि यह इतना बड़ा है, तो चलिए उससे शुरू करते हैं जिसे जल्दी निपटाया जा सके, और वह है DOCRC16। जो केवल crc16 करता है, मुझे लगता है, नाम और इस तथ्य के आधार पर कि इसके पास एक subs table आदि है.... यह जांचने के लिए कि उसने जो लिखा है उसकी अखंडता सही है। ठीक है, आगे

हम पूर्वनिर्धारित पथों के साथ कई defines और _LIT मैक्रो के कई कॉल देखते हैं? यह मैक्रो क्या करता है? _LIT() मैक्रो C++ टेम्पलेट का उपयोग करता है, इसलिए यह प्रत्येक संभावित स्ट्रिंग लंबाई के लिए एक अलग प्रकार उत्पन्न करता है।

उद्धरण के लिए (https://docs.huihoo.com/symbian/s60-5th-edition-cpp-developers-library-v2.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/sdk/doc_source/faqSDK/faq_0529.html)

ओह, यह उल्लेख करना न भूलें कि अब तक हमारे पास IOC के रूप में यह है```cpp "C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.APP" "C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.RSC" "C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\" "C:\SYSTEM\RECOGS\FLO.MDL" "C:\SYSTEM\RECOGS\" "C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.SIS"

अच्छा, आगे हम CopyMeToAutostartableDir फ़ंक्शन का विश्लेषण करते हैं

इसलिए मैलवेयर स्रोत कोड से हम देखते हैं कि यह करता है&#x20;```cpp
	This function will copy the own dll of this application to
	"C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.APP".
	.mdl for autostart will start that application automaticly.

अच्छा, तो यह जो सबसे पहले काम करता है वह है ऐप का नाम प्राप्त करना, इस मामले में मुझे लगता है कि यह CARIBE होगा, फिर यह एक 16 बाइट बफ़र घोषित करता है जिसमें स्ट्रिंग शामिल होगी ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.APP

ऐप के नाम को अपरकेस अक्षरों में बदलता है और दोनों स्ट्रिंग की तुलना करता है। इसके बाद हम RFs प्रकार का एक वेरिएबल fs देखते हैं। वह प्रकार आखिर क्या है? खैर [https://journey.andreasjakl.com/paper/p04\_series60.php](https://journey.andreasjakl.com/paper/p04\_series60.php) यह कहता है कि सभी एप्लिकेशन RFs क्लास के ऑब्जेक्ट के लिए एक पॉइंटर परिभाषित करते हैं (जो फ़ाइल सर्वर तक पहुंचता है), फिर फ्रेमवर्क स्वचालित रूप से Connect() को कॉल करता है ताकि आप इस ऑब्जेक्ट का अपना इंस्टेंस बनाए बिना इसका उपयोग शुरू कर सकें। यह कॉल क्लाइंट-साइड API का हिस्सा है, जो एक शेयर्ड लाइब्रेरी के रूप में लागू किया गया है और सर्वर तक पहुंच प्रदान करता है।

(नोट: कृपया इसे देखें, जैसा कि मुझे बाद में इस लिंक के बारे में पता चला, यदि यह पर्याप्त संक्षिप्त नहीं है [https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source/reference/reference-cpp/F32\_EKA2/RFsClass.html#%3a%3aRFs](https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source/reference/reference-cpp/F32\_EKA2/RFsClass.html#%3a%3aRFs))

मूल रूप से यह हमें रिमोट कनेक्ट पर फ़ाइल सिस्टम फ़ाइल तक पहुंच प्राप्त करने की अनुमति देता है, जैसा कि आगे हम देखते हैं कि हम करते हैं&#x20;```cpp
User::LeaveIfError( .Connect());

यदि हम कनेक्ट नहीं कर पाते। अजीब बात यह है कि हमें socket प्रकार के चर के बिना connect API कॉल दिखाई देती है, लेकिन मुझे लगता है कि यह इस ब्लूटूथ प्रोटोकॉल मामले के लिए विशिष्ट है(हम बाद में देखेंगे कि कौन सा प्रोटोकॉल उपयोग में है)/ विशिष्ट है कि ऐप को कैसे डिज़ाइन किया गया था

फिर हम बनाते हैं```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\

रिमोट से जुड़े फोन पर, हम BaflUtils::CopyFile([https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source/reference/reference-cpp/BAFL/BaflUtilsClass.html#%3a%3aBaflUtils%3a%3aFileExists%28%29](https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source/reference/reference-cpp/BAFL/BaflUtilsClass.html#%3a%3aBaflUtils%3a%3aFileExists%28%29)) को कॉल करते हैं प्रोग्राम को स्वयं कॉपी करने के लिए&#x20;```cpp
C:\\SYSTEM\\SYMBIANSECUREDATA\\CARIBESECURITYMANAGER\\CARIBE.APP

फिर हम वही प्रक्रिया दोहराते हैं, इस बार केवल हम ऐप को कॉपी करते हैं ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.RSC

और फिर हम फ़ंक्शन से लौट आते हैं। अच्छा, लेकिन C:\\\ डायरेक्ट्री में क्यों और SYMBIANSECUREDATA में क्यों? और rsc फ़ाइल का क्या? खैर, जाहिर है अगर हम [https://www.virusbulletin.com/virusbulletin/2015/07/throwback-thursday-cabirn-fever-august-2004/](https://www.virusbulletin.com/virusbulletin/2015/07/throwback-thursday-cabirn-fever-august-2004/) की जाँच करें&#x20;

हमें उत्तर मिलता है कि ‘SYMBIANSECUREDATA’ डायरेक्ट्री के अंदर की फ़ाइलें डिफ़ॉल्ट रूप से उपयोगकर्ताओं को दिखाई नहीं देतीं जब तक कि File Manager इंस्टॉल न हो।

Kek लेकिन rsc फ़ाइल का क्या?

खैर, एक symbianOs किताब में यह आरेख हमें दिखाता है कि

<figure><img src="https://assets.kitploit.com/production/public/readmes/44345/9e576d96be08742edac009037f8eedf8b41767c116758c15068fecaef05b3c1b.png" alt=""><figcaption></figcaption></figure>

एक resource फ़ाइल जो एप्लिकेशन का कैप्शन, आइकनों की संख्या और अन्य जानकारी परिभाषित करती है। अगर हम .rsc फ़ाइल फ़ॉर्मेट के बारे में खोजें, तो हमें पता चलता है कि ये RSC फ़ाइलें आम तौर पर डेटा फ़ाइलों के रूप में वर्गीकृत होती हैं जिनमें RSS फ़ॉर्मेट से बाइनरी फ़ॉर्मेट में संकलित और मशीन-पठनीय संसाधन होते हैं। इनमें एक APP फ़ाइल और एक तैयार Symbian एप्लिकेशन होता है, जो एप्लिकेशन डेवलपर्स को APP के पुनःसंकलन के बिना प्रोग्राम संसाधनों में संशोधन की अनुमति देता है।&#x20;

इसलिए मैं यह निष्कर्ष निकालता हूँ कि यहाँ शायद आइकन या अलग-अलग संसाधन होंगे।

लेकिन C:\\\ ड्राइव क्यों? खैर, क्योंकि Symbian OS एक DOS-जैसी परंपरा अपनाता है जहाँ हर ड्राइव की पहचान एक अक्षर से होती है।&#x20;

अगला InstallMDL

&#x20;इसका लक्ष्य&#x20;```cpp
This function will install the mdl file to the recogs directory.

ठीक है, तो हम फिर से फ़ाइल सिस्टम तक पहुँचकर शुरू करते हैं, वर्तमान चल रहे ऐप का नाम प्राप्त करते हैं, एक वेरिएबल बनाते हैं जो स्ट्रिंग्स को रखता है ```cpp C:\SYSTEM\RECOGS\FLO.MDL

और फिर हम कुछ ऐसा देखते हैं जिससे हम परिचित नहीं हैं, जो TParse प्रकार का एक वेरिएबल है।

दस्तावेज़ों की जाँच करने पर हमें मिलता है&#x20;

<figure><img src="https://assets.kitploit.com/production/public/readmes/44345/56b89fb3a4e9c3381dcdb8d8aa2c047712196ba8112be9f9afc28ff363055acd.png" alt=""><figcaption></figcaption></figure>

आगे&#x20;```cpp
	TParse parser;
	parser.Set(OwnDllName,NULL,NULL);

	TBuf16 <KMaxPath> flodrivepath(parser.DriveAndPath());
	
	_LIT16(FLOMDL,"flo.mdl");

	flodrivepath.Append(FLOMDL);

यहाँ क्या होता है कि यह ऊपरी पथ को गतिशील रूप से बनाता है और मुझे लगा कि इसे समझाना बेकार होगा (यदि आप और जाँच करना चाहते हैं तो कृपया इस लिंक का उपयोग करें https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-E79A3B03-F8CB-37DB-A2A8-1C6C4E4D739A.html)

फिर हम यह निर्देशिका बनाते हैं ```cpp C:\SYSTEM\RECOGS\

और अंत में गतिशील रूप से बनाई गई स्ट्रिंग जो flo.mdl फ़ाइल की ओर इंगित कर रही है, उसे C:\\\SYSTEM\\\RECOGS\\\\&#x20; में कॉपी करें

अच्छा, तो mdl फ़ाइल के बारे में इतना दिलचस्प क्या है ? और recogs निर्देशिका ? खैर, fortinet से हमें यह मिलता है कि "recogs" फ़ोल्डर आमतौर पर "recognizers" के रूप में जाने जाने वाले प्रोग्राम संग्रहीत करता है

तो recognizer क्या है। सच कहूँ तो मुझे नहीं पता, मुझे जो कुछ भी मिला वह यह है MIME प्रकारों को Symbian OS में .mdl रिकग्नाइज़र द्वारा विभेदित किया जाता है (जो \System\Recogs फ़ोल्डर में संग्रहीत होते हैं) जो फ़ाइल के एक्सटेंशन और/या अंतर्विष्ट डेटा के प्रारूप/लेआउट का उपयोग करते हैं। ऐप्स किसी दिए गए mime प्रकार में अपनी रुचि को उस प्राथमिकता स्तर पर पंजीकृत करते हैं जो उनके लेखक द्वारा उनके .aif फ़ाइल में datatype\_list में निर्दिष्ट किया जाता है, जब वे स्थापित होते हैं (देखें C++ या OPL SDK दस्तावेज़ीकरण में "Aiftool resource file format")। उच्चतम प्राथमिकता व्यक्त करने वाला पंजीकृत ऐप सिस्टम द्वारा किसी भी दिए गए mime प्रकार के दस्तावेज़ को खोलने के प्रयास के लिए उपयोग किया जाता है।

और यह Symbian OS Recogniser सिस्टम द्वारा MIDlets को MIDlets के रूप में पहचाने जाने की अनुमति देता है।

तो कुछ खास नहीं.... लेकिन मुझे लगता है कि चूँकि इसका संबंध mime प्रकारों से है, मुझे लगता है कि यह आइकन और GUI सामग्री के बारे में है ([https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source//guide/Application-Framework-subsystem-guide/emime/recogs-framework.html#recogs%2dframework](https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source/guide/Application-Framework-subsystem-guide/emime/recogs-framework.html#recogs%2dframework)) 

और अब mdl फ़ाइलों के बारे में क्या ? खैर, उसी लिंक से हमें पता चलता है कि डेटा रिकग्नाइज़र `.mdl` एक्सटेंशन के साथ प्लग-इन DLL थे  जिसका मूल रूप से अर्थ है कि यह एक प्लगइन है जो एक मीडिया इमेज फ़ाइल लोड करता है . बढ़िया

\=============================================

sys फ़ाइल फ़ंक्शन बनाना tbd

\=============================================

अब जब हम समझ गए हैं कि प्रत्येक फ़ंक्शन क्या करता है, हम caribeappui.cpp पर लौटते हैं  और निष्पादन के प्रवाह का विश्लेषण करना जारी रखते हैं। हम देखते हैं कि ConstructL से अंतिम फ़ंक्शन है&#x20;```cpp
CaribeBluetooth::NewL();

और इस तरह हम Cariblebt.cpp में अपनी यात्रा शुरू करते हैं

तो newL, newLC को कॉल करता है जो constructorL को कॉल करता है जो RunL को कॉल करता है और iState को 3 पर सेट करता है। अब runL स्टेट की जाँच करता है और हमारे मामले में चूँकि हमने इसे डिफ़ॉल्ट रूप से 3 पर सेट किया है, हम FindDevices और ManageDevicesFound चलाते हैं।

FindDevices कुछ इस तरह दिखता है

ईमानदारी से कहूँ तो यह TCP के सामान्य स्कैन से अलग नहीं लगता, लेकिन चलिए गहराई में जाते हैं। पहले, क्योंकि मैं भूल गया, यह रहा Cariblebt.h

कूल, तो वापस अपने फ़ंक्शन पर आते हैं, हम KL2Cap को string या BTLinkManager प्रकार पर सेट करते हैं, फिर हम जाँचते हैं कि क्या हम सॉकेट सर्वर के साथ एक IPC संचार चैनल बना सकते हैं। ठीक है, रुको, तुम किस बारे में बात कर रहे हो? सच में मुझे नहीं पता, तो चलिए जाँच करते हैं। तो हमारे पास RsocketServ प्रकार का socketServ है। कूल और अब क्या ?>अब अगर हम उस क्लास के लिए सख्ती से खोजें(https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-EF29C1D7-B1E5-370F-AE37-66231A6BE449.html) तो हमें ठीक वही मिलता है जो मैंने कहा कि हम एक IPC चैनल बनाते हैं। लेकिन क्यों? अब नाम के आधार पर मैं अनुमान लगा सकता हूँ कि इसका संबंध सॉकेट से है। अब अगर हम Rsocke(https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0.html#GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0) का निरीक्षण करें तो हमें मिलता है कि यह एक प्रोटोकॉल के लिए क्लाइंट एंडपॉइंट प्रदान करता है। यह सॉकेट निर्माण, पढ़ने, लिखने के लिए फ़ंक्शन प्रदान करता है।

अब इस मामले पर और अधिक, अगर हम इस (https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-CED041C8-D68D-55D1-957E-1A48EEFFF851.html) का उपयोग करें, तो हम देखते हैं कि सिम्बियन पर रिमोट डिवाइस के बारे में पूछताछ इसी तरह काम करती है, यानी ब्लूटूथ कनेक्शन कैसे बनाया जाता है।

मजेदार बात यह है कि इसके ठीक बाद, अगली पंक्ति बिल्कुल वैसी ही है जैसा ऊपर प्रोटोकॉल में वर्णित है, जैसे कि RSocketServ::FindProtocol() का उपयोग करके उपयोग किए जाने वाले प्रोटोकॉल का चयन करना।

और बिल्कुल जैसा पहले बताया गया था, हम वही करते हैं जो ऊपर दस्तावेज़ में वर्णित है, यानी एक RHostResolver ऑब्जेक्ट बनाना और आरंभ करना।

फिर हम TInquirySockAddr को जनरल डिस्कवरी पर सेट करते हैं, ताकि हम डिवाइसों के लिए स्कैन कर सकें।

इसके बाद सॉकेट का पैरामीटर एड्रेस इन्क्वायरी के लिए सेट करते हैं, हम KHostResInquiry फ्लैग सेट करते हैं।

फिर हम GetByAddress का उपयोग करके क्वेरी शुरू करते हैं, और यदि हम कोई ब्लूटूथ डिवाइस ढूंढने में सफल हो जाते हैं, तो हमें एक 48-बिट अद्वितीय एड्रेस वापस मिलेगा। तो यहाँ मूल रूप से एक साधारण जाँच होती है कि क्या हमारे आसपास कोई ब्लूटूथ डिवाइस है।

आगे हम कॉल करते हैं ManageFoundDevices.

हम जाँचते हैं कि क्या हमें कोई एड्रेस मिला है और यदि मिला तो हम Cancle() को कॉल करते हैं। फिर हम ब्लूटूथ एड्रेस के लिए एक एंडपॉइंट/"कनेक्शन" बनाते हैं (लेकिन वास्तव में हम अभी वहाँ कनेक्ट नहीं करते), और आगे हम TObexBluetoothProtocolInfo प्रकार का एक वेरिएबल बनाते हैं, जिसका उपयोग ब्लूटूथ-विशिष्ट प्रोटोकॉल जानकारी का वर्णन करने के लिए किया जाता है(https://docs.huihoo.com/symbian/s60-5th-edition-cpp-developers-library-v2.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/sdk/doc_source/reference/reference-cpp/OBEX_Protocol/TObexBluetoothProtocolInfoClass.html#%3a%3aTObexBluetoothProtocolInfo)

अब Obex सर्वर आखिर क्या है ??? सिनोप्सिस ( https://www.synopsys.com/software-integrity/security-testing/fuzz-testing/defensics/protocols/bt-obexs.html) से, OBject EXchange (OBEX)(https://en.wikipedia.org/wiki/OBject_EXchange) एक संचार प्रोटोकॉल है जो ब्लूटूथ-सक्षम डिवाइसों के बीच बाइनरी ट्रांसफ़र को सुविधाजनक बनाता है। अच्छा, हमारे मामले में चूँकि TObexBluetoothProtocolInfo क्लास TObexProtocolInfo से इनहेरिट करती है, हमें ट्रांसपोर्ट का प्रकार निर्दिष्ट करना होता है ताकि सिम्बियन OS जान सके कि कौन सा प्रोटोकॉल उपयोग करना है, हमारे मामले में rfcomm। और इसलिए आगे हम मूल रूप से यह सेट करते हैं कि किससे बात करनी है और किस पोर्ट पर। चूँकि rfcomm पोर्ट डायनामिक है, यह 0x1-30 के बीच हो सकता है और इस मामले में यह 9 है। फिर हम क्लाइंट कनेक्शन बनाते हैं और उससे कनेक्ट करते हैं। ठीक है, तो आगे क्या होता है, इसका कोई संकेत नहीं है। तो मैं...... हाँ.... इसके बाद हम वापस लौटते हैं और चूँकि कोई while नहीं है, मुझे लगता है कि वही प्रक्रिया अब तक एक बार फिर दोहराई जाती है। केवल अब, चूँकि हम पहले ही उस डिवाइस से कनेक्ट हो चुके हैं, हमारा स्टेट 1 होगा और चूँकि हमने कनेक्शन स्थापित कर लिया है, हम put को कॉल करते हैं, जो विकिपीडिया देखें तो यह करता है

PUT: क्लाइंट सर्वर को एक फ़ाइल भेजता है; यदि वह एक पैकेट में फिट होने के लिए बहुत बड़ी है, तो सर्वर CONTINUE प्रतिक्रिया के साथ अगले भाग का अनुरोध करेगा।

अब हमें कैसे पता चलेगा कि कौन सी फ़ाइल iCurrFile है? खैर, मेरा सिद्धांत यह है कि फ़ाइल की शुरुआत में हमारे पास CActive फ़ंक्शन है, जो मुझे लगता है कि जब भी हम SetActive() को कॉल करते हैं, एक हुक की तरह कार्य करता है।

तो हाँ, यह विश्लेषण समाप्त होता है। इसे पढ़ने के लिए धन्यवाद! Happy hacking :)

cabir_analysis

सबसे लोकप्रिय