spiralbl0ck/cabir_analysiscabin Teilanalyse
Bevor du mit dem Lesen beginnst, muss ich diese Ankündigung machen: BITTE NIMM ALLES, WAS DU LIEST, MIT VORSICHT, DA ICH KEINESWEGS EIN SymbianOS-ENTWICKLER ODER IRGENDWIE MIT DER SymbianOS-UMGEBUNG VERTRAUT BIN
Aber warum überhaupt etwas analysieren, das so alt ist? Nun, weil es der einfachste Weg ist, in Remote-Hacking einzusteigen, da diese Art von Scheiß heutzutage mit ndays/0days im Wert von 1 Mio. 🤑🤑🤑 gemacht wird. Und weil mir noch das Fachwissen dafür fehlt.
Cool, jetzt wo wir diesen Scheiß hinter uns haben, legen wir los. WTF ist Cabir? Es ist ein Bluetooth-Wurm, der auf Symbian-Handys läuft. Für diejenigen, die sich fragen, was zum Teufel ein Symbian-Handy ist und so. Nun, im Grunde ist es ein Telefon, das auf ARM läuft, also nichts Neues unter der Sonne :) Präzisere Infos (https://en.wikipedia.org/wiki/S60_(software_platform))
Nun, wir hatten das Glück, dass der Quellcode dafür online war (Dank an vxug) (SymbianOS.Cabir.7z). Jetzt werden wir das als Referenz nutzen, aber ehrlich gesagt scheiß drauf. Einer der anderen Gründe, warum ich das mache, ist, dass ich mich mit ARM beschäftigen möchte. Wir werden das also aus einer Source-/Assembly-/Emulator-/Debugging-/Sniffing-Perspektive betrachten.
Cool, also #1 Wie zur Hölle kompilieren wir den Quellcode?
Nun, das ist nicht so kompliziert...
Zuerst installiere Carbide++(http://www.mediafire.com/file/6z54qrceef73x9s/Carbide_cpp_v2_7_en.exe/file)(von https://gist.github.com/artem78/cb2b9650af186844f7b5654964676284)
Als Nächstes installiere eine beliebige Perl-Engine.
Dann installiere Nokia PC Suite(https://www.usitility.com/nokia-pc-suite/)
SDK installieren(http://www.mediafire.com/file/9uc7fjb2ynmxlud/s60v3.1_SDK.zip/file )
C/C++-Plugin installieren (https://ia800905.us.archive.org/7/items/nokia_sdks_n_dev_tools/s60_open_c_cpp_plug_in_v1_7_en.zip)
Und voilà, wir haben die Umgebung :)
P.S. Benutze besser Windows 7, da anscheinend unter Windows 10 Dinge kaputtgehen und nicht richtig funktionieren
Live-Infektion der Umgebung
TBD
Für diesen Teil solltest du wissen, dass du dein Telefon jailbreaken musst (ja, du hast richtig gehört: jailbreaken). Wie passiert das?
Reverse-Engineering-Analyse
Cool, also wie zur Hölle kompiliert man dieses Zeug? Wirklich gute Frage. Was ich also tat, war, zuerst ABLT.BAT aus dem Ordner caribe\group auszuführen, und zwar so:
Cool, als Nächstes gehen wir dorthin, wo unser SDK installiert ist, identifizieren den Plattform-Ordner (in meinem Fall S60_3rd_fp1), finden den Ordner epoc32, gehen zum Ordner buid, wählen den Ordner user, dann den Benutzernamen-Ordner und dann noch zwei oder drei weitere Verzeichnisse, und du solltest in einem Ordner landen, der so aussieht:
Dies ist der aktuelle Pfad, der ungefähr dem entsprechen sollte, wo du sein solltest (C:\Symbian\9.2\S60_3rd_FP1\Epoc32\BUILD\Users\pwn\Desktop\CabirSourceCodes\caribe\group)
Cool, als Nächstes müssen wir in den Ordner caribe gehen (oder wie auch immer du den Quellcode genannt hast), und du findest einen Ordner mit verschiedenen Namen, wie hier zu sehen:
Worum geht es dabei? Nun, im Grunde bekommen wir, wenn wir zuerst ablt.bat ausführen (bis heute weiß ich nicht, was der Zweck ist, aber egal), verschiedene Plattformoptionen zum Erstellen unserer PKG-Datei, aus der wir unsere SIS-Datei generieren. Im gegebenen Fall sehen wir GCCE und WINSCW. Wenn du standardmäßig den Befehl ablt.bat build ausführst, wird er für WINSCW gebaut (das ist der Codename für die Emulator-Plattform). Zum Zweck des Lernens, wie man den Quellcode kompiliert, verwenden wir vorerst GCCE, aber der Prozess ist derselbe, wenn du es zum Beispiel für die ARM-Plattform machen willst, damit du es auf dein Telefon hochladen kannst. Also im Grunde ablt build arm_whatever und dann die gleichen Schritte bis hierher. Cool, jetzt gehen wir in den GCCE-Ordner
Gehe in den Ordner urel, und dort sollte eine Datei namens caribe.app sein. Von dort öffnest du eine Befehlszeile und führst Folgendes aus:
Also, was macht das??? Nun, im Grunde haben wir makesis ausgeführt, das eine SIS-Datei erzeugt, damit wir sie auf unserem Telefon installieren können. Und warum die SIS-Datei aus dem caribe-Quellcode? Nun, im Grunde mussten wir makesis die Datei caribe.pkg angeben. Cool, und warum dann der ganze Aufwand, um zu dem build bla bla Ordner zu gelangen? Nun, weil du es dem Parameter -d angeben musst, damit er eine .sis-Datei erzeugen kann.
Cool, diese Methode funktioniert also nur mit SDK v3, worauf sich dieser Artikel bezieht. Offenbar – als ich experimentierte – hat mich ein Entwickler aus einem Symbian-Discord-Server darauf hingewiesen, dass Cabir für SDK v2 codiert ist, und daher das, was ich hier präsentiere, nutzlos sein wird..... das ist TBD, sobald ich ihn erreichen kann... da er in letzter Zeit ziemlich offline auf Discord ist...
Cool, wie reverse-engineert man eine .sis-Datei?
Ganz einfach: Eine .sis-Datei ist ein Archiv. Also... verwenden wir die Anwendung siscontents, um sie zu entpacken, und werfen dann die .app-Datei in IDA.
Assembly-Perspektive
Der gesamte Prozess sieht also so aus
Also gehen wir jetzt in diesen Ordner, und als Nächstes bekommen wir die Datei app.app
Cool, wenn du sie in IDA wirfst.
Cool, also im Grunde eine ARM-EXE. COOL, GEIL! WEITER, BITTE! HMM, JA, BITTE ~~~
In der Datei sind Symbole, ja!!! Nun ja, da wir das Binärprogramm aus irgendeinem seltsamen Grund mit Debug-Symbolen kompiliert haben, hatten wir Glück!
Und da wir im Grunde den Code und so haben, ist der Prozess des Reverse Engineering ungefähr derselbe wie im Kapitel zur Quellcode-Analyse beschrieben :)
Sniffing-Sicht
Leider kann ich das nicht tun, denn was ich vorhatte, war Fts4bt zu verwenden, da ich sah, dass das ziemlich gut war (https://www.diva-portal.org/smash/get/diva2:24278/FULLTEXT01.pdf)
aber anscheinend hat das Produkt das EOL erreicht. Falls du diesen Teil zufällig machen kannst, schreib mir bitte eine DM und erstelle einen Pull-Request, um dieses Kapitel abzuschließen.
Debugger-Sicht
Also, was ist mit diesem Abschnitt !>>~> Nun, hier ist meine Meinung dazu: Auch wenn es für mich und dich (den Leser) eine Erfahrung wäre zu lernen, wie man einen Debugger über USB anschließt und Code direkt auf einem Nokia-Telefon debuggt, würde es für mich im Moment zu viel Zeit und Mühe erfordern (da ich schon ziemlich müde bin... sorry, vielleicht ein anderes Mal). Ein weiteres Argument, warum das nutzlos wäre, ist, dass wir den Quellcode und eine speziell entworfene Symbian-IDE haben. Also, das werden wir tun: Wir verwenden den Debugger von Carbide++, um kurz ein oder zwei Funktionen zu debuggen, und das kann der Leser tun, da der Codefluss im SCA-Abschnitt erklärt wurde und weil es auch keine Verschlüsselungs-/Anti-Irgendwas-Methoden gibt, die die Analyse des Codes erschweren. Also... Los geht's!
Ehrlich gesagt
Quellcode-Analyse
Cool, also nutzen wir die Tatsache aus, dass wir Zugriff auf den Quellcode haben, und verwenden ihn für maximalen Profit.
Unsere Verzeichnisstruktur sieht also so aus, was ziemlich gut organisiert ist
Also schauen wir uns den Ordner src an
Unsere Reise beginnt im Ordner src, genauer gesagt in caribe.cpp. Aber warum? Weil, obwohl es ziemlich gut organisiert ist, eines hervorsticht: Es gibt eine Datei caribe.cpp. Ist daran etwas Besonderes? Nein, aber ich habe durch eine fundierte Vermutung angenommen, dass 29A (die Gruppe, die die Malware entwickelte) einen klassischen Ansatz von Softwareentwicklern verfolgt hat, bei dem die Hauptlogik einer App in name_of_project.extension liegt. Cool, und wie zum Teufel sieht das aus? So, junges Blut
KEWL, aber was ist das? Ehrlich, ich weiß es nicht, aber lass uns ein paar Vermutungen anstellen. Allein aufgrund des Namens würde ich raten, dass CApaApplication is the main of this application. If we search this on google we see that
Cool, und jetzt? Lass uns tiefer graben, Alter. Gehen wir und untersuchen CCaribeApplication. Aber wo zur Hölle ist CCaribeApplication? In CaribeApplication.h. Wo ist das? Im inc-Ordner, Bruder, der so aussieht
Cool, es sieht also so aus
Kewl, wir sehen eine Klasse, die entwickelt wird und von einer anderen Klasse erbt, und wir sehen eine geschützte Methode namens CreateDocumentL. Cool, aber nichts Interessantes. Ja, mein Fehler, Digga!!
Was ist das für ein Fehler, yo! Und du nennst dich einen Malware-Analysten =))) chill mal, Alter! Nein, also wir sagten, der Projektautor hat sich wahrscheinlich wie ein normaler Softwareentwickler verhalten, also sollten wir natürlich caribeapplication.cpp im src-Ordner untersuchen. Cool, nichts wie los :)
Cool, also ein Haufen uns unbekannter Wörter und ein Haufen Unsinn. Bringen wir etwas Licht ins Dunkel...
Zuerst besprechen wir diese Konstante(0x10005B91). WTF ist ihr Zweck? Nun, ihr Typ ist TUid, der wie folgt definiert ist:
Cool, also im Grunde eine ID. Aber warum??? Ehrlich, ich weiß es nicht, aber wenn du eine App baust, bekommst du eine UUID. Interessanter Teil ist, dass du, wenn du im Internet danach suchst, ziemlich sicher sehen wirst, dass es immer als Teil einer sogenannten .sis-App definiert ist, die wir später erkunden werden. Also im Grunde ist das die klassische Header-Definition für eine App auf SymbianOS. Cool, weiter. Wir sehen die Funktion, die uns interessiert, nämlich CreateDocumentL.
Also....
Und was wir aufrufen, ist CreateDocumentL
Also erstellen wir ein Dokument... aber warum ...? Ehrlich, ich bin genauso verloren wie du, aber meine Vermutung ist, dass wir, wenn wir ein Dokument erstellen, im Grunde irgendwie eine Klasse erzeugen, die es uns ermöglicht, irgendwie mit der UI der App zu interagieren, da wir sie im Grunde aus dem UI-Framework ableiten.
Und da wir CreateDocumentL aufrufen (ich vermute, wir überschreiben hier in diesem Beispiel die Definition mit unserer eigenen Ausführung), wo ist dann die Definition >?? Nun, ich vermute in CaribeDocument.h. Und worum geht es dabei???
Ok, cool, wir sehen natürlich die Funktion, die uns interessiert, newL, also schauen wir uns CaribeDocument.cpp an
Wie wir sehen können, rufen wir am Ende new L auf, das newLC aufruft, das constructL aufruft, und das war's. Aber was ist mit der Funktion CEikAppUi CreateAppUiL? Nun,
Also versuchen wir, daraus schlau zu werden. Im Grunde instanziieren wir, wenn wir den Konstruktor von CCaribeDocument aufrufen, eine CEikApplication als Dokument. Diese CEikApplication ist definiert als
Ich denke, was hier passiert, ist, dass wir im Grunde versuchen, auf die UI zuzugreifen, und dann definieren wir eine Klasse, die später die Interaktion mit der UI über CreateAppUiL übernehmen kann. Cool, also schauen wir uns CCaribeAppUi.h/CCaribeAppUi.cpp an
Also... wir können daraus keinen Sinn erkennen, es sei denn, wir untersuchen, wovon es erbt, und das ist CAknAppUi.
Wir sehen also, dass
das wir weiter untersuchen, um zu sehen, wie CAknAppUi aussieht
das wir später bei ConstructL untersuchen
was mich zu der Annahme bringt, dass dies eine Hilfsfunktion ist, die nur den Konstruktor abschließt, da der Konstruktor leer gelassen wird. Cool, also graben wir tiefer
In der ersten Zeile sehen wir eine Funktion namens ErrMessage, die in general.h als Makro definiert ist, das einen Informationsdialog mit den angegebenen Textzeilen anzeigt. Aus den Berichten darüber, wie sich Cabir verhielt, wissen wir, dass die Malware immer ein Popup mit dem Namen einblendete. Z.B.
Als Nächstes sehen wir einen Aufruf von User::After – was zum Teufel macht das? Nun, ich habe dieses Buch von (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) verwendet, um es besser zu verstehen, und wenn wir danach suchen, steht dort, dass es im Grunde eine gewisse Anzahl von Sekunden wartet, hier 10 Sekunden*10, also etwa 100 Sekunden (schnelle Mathe =)) skrr ra)
Als Nächstes rufen wir BaseConstructL auf, das im Grunde die UI initialisiert, wobei ENoAppResourceFile als Wert übergeben wird. Wenn wir ein wenig graben
und als Nächstes deklarieren wir eine Variable vom Typ CaribeInstaller. Cool, also schauen wir uns an, worum es dabei geht
Also untersuchen wir CaribeInstaller.cpp und sehen, dass es ziemlich groß ist (das hat sie auch gesagt :)) ). Wie auch immer, ich werde mehrere Bilder posten, da die Quelle ziemlich groß ist
.PNG)
.PNG)
.PNG)
.PNG)
.PNG)
.PNG)
.
.PNG)
Cool, da es so groß ist, beginnen wir mit der schnellen Sache, um sie loszuwerden, und das ist DOCRC16. Das macht nur ein CRC16, vermute ich, basierend auf dem Namen und der Tatsache, dass es eine Substabelle und so weiter hat.... um die Integrität dessen zu überprüfen, was es geschrieben hat. Cool, weiter
wir sehen einen Haufen Defines mit vordefinierten Pfaden und einen Haufen Aufrufe des _LIT-Makros? Was zum Teufel macht das Makro? Das _LIT()-Makro verwendet eine C++-Vorlage, sodass es für jede mögliche Zeichenfolgenlänge einen anderen Typ erzeugt.
um zu zitieren aus (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)
Oh, und nicht zu vergessen, dies als IOC zu erwähnen, das wir bisher haben```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"
Cool, als Nächstes analysieren wir die Funktion CopyMeToAutostartableDir
also sehen wir aus dem Quellcode der Malware, dass es tut ```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.
Cool, zu den ersten Dingen, die es tut, gehört, den Namen der App zu ermitteln. In diesem Fall denke ich, dass es CARIBE sein wird. Als Nächstes deklariert es einen 16-Byte-Buffer, der den String enthalten wird```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.APP
wandelt den Namen der App in Großbuchstaben um und vergleicht die beiden Zeichenketten. Als Nächstes sehen wir eine Variable namens fs vom Typ RFs. Was in aller Welt ist das für ein Typ? Nun, [https://journey.andreasjakl.com/paper/p04\_series60.php](https://journey.andreasjakl.com/paper/p04\_series60.php) heißt es: Alle Anwendungen definieren einen Zeiger auf ein Objekt der Klasse RFs (das auf den Dateiserver zugreift); dann ruft das Framework automatisch Connect() auf, sodass du es verwenden kannst, ohne eine eigene Instanz dieses Objekts zu erstellen. Dieser Aufruf ist Teil der clientseitigen API, die als gemeinsam genutzte Bibliothek implementiert ist und Zugriff auf den Server bietet.
(HINWEIS: Bitte sieh dies als einen später entdeckten Link an, falls dies nicht präzise genug ist [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))
Im Grunde ermöglicht uns dies den Zugriff auf Dateien des Dateisystems auf der Remote-Verbindung. Als Nächstes sehen wir, dass wir ```cpp
User::LeaveIfError( .Connect());
wenn wir uns nicht verbinden können. Seltsam ist, dass wir den Connect-API-Aufruf ohne eine Variable vom Typ Socket sehen, aber ich denke, das ist spezifisch für diesen Bluetooth-Protokoll-Fall (wir werden später sehen, welches Protokoll verwendet wird)/ spezifisch dafür, wie die App entworfen wurde
wir erstellen dann ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\
auf dem entfernt verbundenen Telefon , rufen wir 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)) auf, um das Programm selbst zu kopieren nach ```cpp
C:\\SYSTEM\\SYMBIANSECUREDATA\\CARIBESECURITYMANAGER\\CARIBE.APP
wir wiederholen dann dasselbe Verfahren, diesmal kopieren wir nur die App nach ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.RSC
und wir dann aus der Funktion zurückkehren. Cool, aber warum in das Verzeichnis C:\\\ und warum in SYMBIANSECUREDATA? Und was ist mit der RSC-Datei? Nun, anscheinend erhalten wir, wenn wir [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/) untersuchen, 
erhalten wir die Antwort, dass Dateien im Verzeichnis ‘SYMBIANSECUREDATA’ für Benutzer standardmäßig nicht sichtbar sind, es sei denn, der Dateimanager ist installiert.
Okay, aber was ist mit der RSC-Datei?
Nun, in einem symbianOs-Buch zeigt uns dieses Diagramm Folgendes:
<figure><img src="https://assets.kitploit.com/production/public/readmes/44345/9e576d96be08742edac009037f8eedf8b41767c116758c15068fecaef05b3c1b.png" alt=""><figcaption></figcaption></figure>
Eine Ressourcendatei, die die Beschriftung der Anwendung, die Anzahl der Symbole und weitere Informationen definiert. Wenn wir nach dem .rsc-Dateiformat suchen, erhalten wir die Information, dass diese RSC-Dateien allgemein als Datendateien klassifiziert werden, die kompilierte und maschinenlesbare Ressourcen vom RSS-Format in ein Binärformat enthalten. Sie bestehen aus einer APP-Datei und einer fertigen Symbian-Anwendung, die es Anwendungsentwicklern ermöglicht, Programmressourcen zu ändern, ohne die APP neu zu kompilieren. 
Ich neige also zu dem Schluss, dass es hier wohl Symbole oder andere Ressourcen geben wird.
Aber warum das Laufwerk C:\\\ ? Nun, weil Symbian OS eine DOS-ähnliche Konvention übernimmt, bei der jedes Laufwerk durch einen einzelnen Buchstaben identifiziert wird. 
Als Nächstes InstallMDL
 Sein Ziel ```cpp
This function will install the mdl file to the recogs directory.
Cool, also beginnen wir damit, erneut auf das Dateisystem zuzugreifen, den Namen der aktuell laufenden App abzurufen und eine Variable zu erstellen, die die Strings enthält ```cpp C:\SYSTEM\RECOGS\FLO.MDL
Und dann sehen wir etwas, mit dem wir nicht vertraut sind: eine Variable vom Typ TParse.
Ein Blick in die Dokumentation zeigt uns 
<figure><img src="https://assets.kitploit.com/production/public/readmes/44345/56b89fb3a4e9c3381dcdb8d8aa2c047712196ba8112be9f9afc28ff363055acd.png" alt=""><figcaption></figcaption></figure>
Weiter ```cpp
TParse parser;
parser.Set(OwnDllName,NULL,NULL);
TBuf16 <KMaxPath> flodrivepath(parser.DriveAndPath());
_LIT16(FLOMDL,"flo.mdl");
flodrivepath.Append(FLOMDL);
Was hier passiert, ist, dass es den oberen Pfad dynamisch erstellt, und ich dachte, es wäre sinnlos, es zu erklären (wenn Sie weiter untersuchen möchten, verwenden Sie bitte diesen Link https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-E79A3B03-F8CB-37DB-A2A8-1C6C4E4D739A.html)
Danach erstellen wir dieses Verzeichnis ```cpp C:\SYSTEM\RECOGS\
und kopiere schließlich den dynamisch erstellten String, der auf die Datei flo.mdl zeigt, nach C:\\\SYSTEM\\\RECOGS\\\\ 
Cool, was ist also so interessant an der mdl-Datei und dem Recogs-Verzeichnis? Nun, von Fortinet erfahren wir: Der Ordner "recogs" speichert üblicherweise Programme, die als "recognizers" bekannt sind.
Also, was ist ein Recognizer? Ehrlich gesagt, ich weiß es nicht genau. Alles, was ich finden konnte, war dies: MIME-Typen werden im Symbian OS durch .mdl-Recognizer unterschieden (gespeichert im Ordner \System\Recogs), die die Dateierweiterung und/oder das Format/Layout der enthaltenen Daten nutzen. Apps registrieren ihr Interesse an einem bestimmten MIME-Typ mit einer Prioritätsstufe, die von ihrem Autor in einer datatype\_list in ihrer .aif-Datei festgelegt wird, wenn sie installiert werden (siehe "Aiftool resource file format" in der C++- oder OPL-SDK-Dokumentation). Die registrierte App mit der höchsten Priorität wird vom System verwendet, um zu versuchen, ein Dokument eines beliebigen MIME-Typs zu öffnen.
und dies: Der Symbian OS Recogniser erlaubt es, dass MIDlets vom System als MIDlets erkannt werden.
also so ziemlich nichts.... Aber ich schätze, da es mit MIME-Typen zu tun hat, geht es wohl um die Symbole und GUI-Sachen ([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)). Und was ist nun mit mdl-Dateien? Nun, von demselben Link erfahren wir, dass Daten-Recognizer Plug-in-DLLs mit einer `.mdl`-Erweiterung waren, was im Grunde bedeutet, dass dies ein Plugin ist, das eine Medienbilddatei lädt. Cool
\=============================================
Sys-Datei-Funktion erstellen tbd
\=============================================
Nachdem wir nun verstanden haben, was jede Funktion tut, kehren wir zu caribeappui.cpp zurück und setzen die Analyse des Ausführungsflusses fort. Wir sehen, dass die letzte Funktion von ConstructL ist ```cpp
CaribeBluetooth::NewL();
Und so beginnen wir unsere Reise in Cariblebt.cpp
So ruft newL newLC auf, was constructorL aufruft, was RunL aufruft und iState auf 3 setzt. Nun prüft runL den Zustand, und in unserem Fall, da wir ihn standardmäßig auf 3 gesetzt haben, landen wir bei der Ausführung von FindDevices und ManageDevicesFound.
FindDevices sieht folgendermaßen aus
Ehrlich gesagt scheint es sich nicht von einem üblichen TCP-Scan zu unterscheiden, aber lass uns tiefer eintauchen. Zuerst, weil ich es vergessen habe, hier ist Cariblebt.h
Cool, also zurück zu unserer Funktion: Wir setzen KL2Cap auf einen String bzw. Typ BTLinkManager. Als Nächstes prüfen wir, ob wir einen IPC-Kommunikationskanal mit einem Socket-Server erstellen können. Ok, Moment, wovon zum Teufel redest du? Ehrlich, ich weiß es nicht, also lass uns nachforschen. Wir haben also socketServ vom Typ RsocketServ. Cool, und was jetzt?>Jetzt, wenn wir streng nach dieser Klasse suchen (https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-EF29C1D7-B1E5-370F-AE37-66231A6BE449.html) erhalten wir genau das, was ich sagte: Wir erstellen einen IPC-Kanal. Aber warum? Nun, basierend auf dem Namen kann ich vermuten, dass es mit einem Socket zu tun hat. Wenn wir nun 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) untersuchen, erhalten wir, dass es einen Client-Endpunkt zu einem Protokoll bereitstellt. Es stellt Funktionen für Socket-Erstellung, Lesen und Schreiben bereit.
Nun, mehr zu diesem Fall: Wenn wir dies verwenden (https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-CED041C8-D68D-55D1-957E-1A48EEFFF851.html), sehen wir, dass dies die Funktionsweise von „Inquiring about Remote Devices“ unter Symbian ist, also wie man eine Bluetooth-Verbindung herstellt.
Lustigerweise ist die direkt darauf folgende Zeile genau das, was im obigen Protokoll beschrieben wird, z. B. das Auswählen des zu verwendenden Protokolls mittels RSocketServ::FindProtocol()
Und genau wie zuvor erwähnt, machen wir genau das, was im obigen Dokument beschrieben ist, nämlich ein RHostResolver-Objekt erstellen und initialisieren.
Dann setzen wir TInquirySockAddr auf die allgemeine Entdeckung (general discovery), damit wir nach Geräten scannen können.
Als Nächstes setzen wir den Parameter des Sockets für Adressabfragen, wir setzen das KHostResInquiry-Flag.
Dann starten wir die Abfrage mit GetByAddress, und wenn wir Bluetooth-Geräte finden, erhalten wir eine 48-Bit-eindeutige Adresse zurück. Was hier also passiert, ist im Grunde eine einfache Prüfung, ob sich Bluetooth-Geräte in unserer Umgebung befinden.
Als Nächstes rufen wir ManageFoundDevices.
Wir prüfen, ob wir eine Adresse erhalten haben, und wenn ja, rufen wir Cancle() auf. Danach erstellen wir einen Endpunkt/„Verbindung“ (aber wirklich verbinden wir uns dort noch nicht) zur Bluetooth-Adresse, und wir erstellen außerdem eine Variable vom Typ TObexBluetoothProtocolInfo, die zur Beschreibung Bluetooth-spezifischer Protokollinformationen verwendet wird (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).
Was zur Hölle ist ein OBEX-Server? ??? Aus der Synopsis (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) ist ein Kommunikationsprotokoll, das binäre Übertragungen zwischen Bluetooth-fähigen Geräten ermöglicht. Cool. In unserem Fall, da die Klasse TObexBluetoothProtocolInfo von TObexProtocolInfo erbt, müssen wir den Transporttyp angeben, damit Symbian OS weiß, welches Protokoll verwendet werden soll – in unserem Fall rfcomm. Und so legen wir als Nächstes im Grunde fest, mit wem wir sprechen und auf welchem Port. Da der rfcomm-Port dynamisch ist, kann er zwischen 0x1-30 liegen, und in diesem Fall ist es 9. Wir erstellen dann eine Client-Verbindung und verbinden uns mit ihr. Ok, also ähm, was passiert als Nächstes? Es gibt keinen Hinweis darauf, was passieren soll. Also ähm...... ja.... Danach kehren wir zurück, und da es kein while gibt, denke ich, wiederholt sich derselbe Prozess wie bisher noch einmal. Nur dass unser Zustand jetzt, da wir uns bereits mit diesem Gerät verbunden haben, 1 sein wird, und da wir eine Verbindung hergestellt haben, rufen wir put auf, was – wenn wir Wikipedia zu Rate ziehen – Folgendes tut:
Woher wissen wir nun, welche Datei iCurrFile ist? Nun, meine Theorie ist, dass wir am Anfang der Datei eine CActive-Funktion haben, die meiner Meinung nach als Hook fungiert, wann immer wir SetActive() aufrufen.
Also ja, das schließt die Analyse ab. Danke fürs Lesen! Happy hacking :)