spiralbl0ck/cabir_analysiscabine analyse partielle
Avant de commencer à lire, je dois faire cette annonce : PRENEZ TOUT CE QUE VOUS LISEZ AVEC DES PINCETTES CAR JE NE SUIS NULLEMENT UN DÉVELOPPEUR SymbianOS NI QUELQU’UN DE FAMILIER AVEC L’ENVIRONNEMENT SymbianOS.
Mais pourquoi analyser un truc aussi vieux que ça ? Parce que c’est le moyen le plus simple de se lancer dans le hacking à distance, puisque de nos jours ce genre de conneries se fait avec des ndays/0days valant 1 million 🤑🤑🤑. Et parce que je n’ai pas encore l’expertise nécessaire pour faire ce genre de choses.
Cool, maintenant qu’on a évacué cette merde, c’est parti. C’est quoi, bordel, Cabir ? C’est un ver Bluetooth qui tourne sur les téléphones mobiles Symbian. Pour ceux qui se demandent ce qu’est un téléphone Symbian et tout ce bordel. Eh bien, c’est essentiellement un téléphone qui tourne sur ARM, donc du nouveau sous le soleil :) Des infos plus concises (https://en.wikipedia.org/wiki/S60_(software_platform))
Nous avons eu la chance que le code source de ce truc soit en ligne (merci à vxug) (SymbianOS.Cabir.7z). Nous allons l’utiliser comme référence mais, franchement, on s’en fout. Une des autres raisons pour lesquelles je fais ça, c’est que je veux toucher à ARM. Donc on va voir ça d’un point de vue source/assembly/émulateur/débogage/sniffing.
Cool, donc #1 Comment, bordel, on compile le code source ?
Eh bien, ce n’est pas si compliqué...
D’abord, installez carbide ++(http://www.mediafire.com/file/6z54qrceef73x9s/Carbide_cpp_v2_7_en.exe/file)(depuis https://gist.github.com/artem78/cb2b9650af186844f7b5654964676284)
ensuite, installez n’importe quel moteur Perl
ensuite, installez Nokia PC Suite(https://www.usitility.com/nokia-pc-suite/)
installez le SDK (http://www.mediafire.com/file/9uc7fjb2ynmxlud/s60v3.1_SDK.zip/file )
installez le plugin C/C++ (https://ia800905.us.archive.org/7/items/nokia_sdks_n_dev_tools/s60_open_c_cpp_plug_in_v1_7_en.zip)
Et voilà, on a l’environnement :)
PS : mieux vaut utiliser Windows 7 car apparemment sur Windows 10, des trucs cassent et ne fonctionnent pas correctement.
Infection en environnement réel
TBD
Pour cette partie, sachez que vous devez jailbreaker (oui, vous avez bien entendu, jailbreaker) votre téléphone. Comment ça se passe ?
Analyse de rétro-ingénierie
Cool, donc comment, bordel, on compile ce truc ? Très bonne question. Ce que j’ai fait, c’est d’abord exécuter ABLT.BAT depuis le dossier caribe\group, comme ceci
Cool, ensuite ce qu’on fait maintenant, c’est aller là où le SDK est installé, identifier le dossier de plateforme (S60_3rd_fp1) dans mon cas, trouver le dossier epoc32, aller dans le dossier build, choisir le dossier user, le dossier username, puis encore deux ou trois autres répertoires, et vous devriez arriver dans un dossier qui ressemble à ceci
C’est le chemin actuel, qui devrait être à peu près similaire à ce que vous devriez avoir (C:\Symbian\9.2\S60_3rd_FP1\Epoc32\BUILD\Users\pwn\Desktop\CabirSourceCodes\caribe\group)
Cool, ensuite il faut aller dans le dossier caribe (ou selon le nom que vous avez donné au code source) et vous trouverez un dossier avec différents noms, comme on le voit ici
C’est quoi, ça ? Eh bien, en gros, quand on lance ablt.bat (je ne sais toujours pas à ce jour à quoi ça sert, mais peu importe), on obtient différentes options de plateforme pour construire notre fichier pkg à partir duquel on générera notre fichier sis. Dans ce cas précis, on voit GCCE et WINSCW. Si vous exécutez par défaut la commande ablt.bat build, ça construira pour WINSCW (qui est le nom de code de la plateforme émulateur). Pour apprendre à compiler le code source, on va utiliser GCCE pour l’instant, mais le processus est le même si vous choisissez, je ne sais pas, la plateforme arm pour pouvoir l’envoyer sur votre téléphone. Donc en gros, ablt build arm_whatever, puis refaites exactement les mêmes étapes jusqu’ici. Cool, maintenant on va dans le dossier GCCE.
Allez dans le dossier urel et il devrait y avoir un fichier appelé caribe.app. À partir de là, ouvrez une ligne de commande et exécutez
Alors, qu’est-ce que ça fait ??? Eh bien, en gros, on a exécuté makesis, qui génère un fichier sis pour qu’on puisse l’installer sur notre téléphone. Et pourquoi on obtient un sis à partir du code source de caribe ? Eh bien, il fallait spécifier caribe.pkg à makesis. Cool, alors pourquoi toute cette galère pour arriver au dossier build et tout le tralala ? Parce qu’il faut le spécifier au paramètre -d pour que ça génère le fichier .sis.
Cool, donc cette méthode ne fonctionne qu’avec le SDK v3, celui mentionné dans ce write-up. Apparemment, pendant que j’expérimentais, un dev d’un serveur Discord dédié à Symbian a fait remarquer que Cabir est codé pour le SDK v2, et donc ce que je présente ici sera inutile..... c’est TBD quand je pourrai le joindre... car il est assez inactif sur Discord ces jours-ci...
Cool, alors comment fait-on de la rétro-ingénierie sur un fichier .sis ?
Simplement : un fichier .sis est une archive. Donc... on utilise l’application siscontents pour dézipper, puis on balance le fichier .app dans IDA.
Point de vue assembleur
Donc, tout le processus ressemble à ceci
Donc maintenant on va dans ce dossier et ensuite on obtient le fichier app.app.
Cool, si vous le balancez dans IDA.
Cool, donc en gros un exécutable ARM. COOL, DINGUE ! LA SUITE, S’IL VOUS PLAÎT ! HMM OUI S’IL VOUS PLAÎT ~~~
IL Y A des symboles dans le fichier, ouais !!! Eh bien oui, puisque pour une raison bizarre on a compilé le binaire avec des symboles de débogage, on a eu de la chance !
Et donc, comme on a en gros le code et tout, le processus de rétro-ingénierie est à peu près le même que celui décrit dans le chapitre sur l’analyse du code source :)
Point de vue sniffing
Malheureusement, je ne peux pas faire ça, car ce que je prévoyais de faire, c’était utiliser Fts4bt, que j’ai trouvé plutôt sympa (https://www.diva-portal.org/smash/get/diva2:24278/FULLTEXT01.pdf)
mais apparemment, le produit a atteint sa fin de vie. Si par hasard vous pouvez faire cette partie, envoyez-moi un message privé et faites une pull request pour terminer ce chapitre.
Point de vue débogueur
ALORS, ET CETTE SECTION ?!>>~> Eh bien, voici mon avis : même si ce serait intéressant pour moi et pour vous (le lecteur), en tant qu’expérience, d’apprendre à brancher un débogueur via USB et à déboguer le code directement sur un téléphone Nokia, cela me demanderait trop de temps et d’efforts pour le moment (je suis déjà assez fatigué... désolé, peut-être une autre fois). Un autre argument pour dire que ce serait inutile est que nous avons le code source et un IDE Symbian spécialement conçu. Voilà donc ce qu’on va faire. On va utiliser le débogueur de Carbide++ pour déboguer brièvement une ou deux fonctions, et cela peut être fait par le lecteur puisque le flux du code a été expliqué dans la section sca et parce qu’il n’y a pas non plus de méthodes de chiffrement/anti-truc pour rendre l’analyse du code plus difficile. Alors... C’est parti !
Pour être honnête
Analyse du code source
Cool, alors exploitons le fait que nous avons accès au code source et utilisons-le pour un profit maximal.
Notre structure de répertoires ressemble à ceci, c’est plutôt bien organisé
Alors, inspectons le dossier src
Notre voyage commence dans le dossier src, plus précisément dans caribe.cpp. Mais pourquoi ? Parce que, même si c’est plutôt bien organisé, une chose ressort : il y a un fichier caribe.cpp. Quelque chose de spécial ? Nan, mais j’ai supposé, par déduction éclairée, que dans ce cas, 29A (le groupe qui a développé le malware) a suivi l’approche classique des développeurs de logiciels où la logique principale d’une application va dans nom_du_projet.extension. Cool, et à quoi ça ressemble, du coup ? À ça, jeune sang
Cool, mais c’est quoi ça ? Franchement, je ne sais pas, mais essayons de faire quelques suppositions. En me basant uniquement sur le nom, je devinerais que CApaApplication est le cœur de cette application. Si on cherche ça sur Google, on voit que
Cool, et maintenant ? Creusons un peu plus, mec. Allons inspecter CCaribeApplication. Mais attends, où est CCaribeApplication ? Dans CaribeApplication.h. Où ça ? Dans le dossier inc, mon frère, qui ressemble à ceci
Cool, donc ça ressemble à ceci
Cool, on voit donc une classe en cours de développement qui hérite d’une autre classe, et on voit une méthode protégée appelée CreateDocumentL. Cool, mais rien d’intéressant. Ouais, c’est ma faute ici, mec !!
C’est quoi cette erreur, yo ! Et tu te prétends analyste de malwares =))) Calme-toi, mec ! Nan, donc on a dit que l’auteur de ce projet s’est probablement comporté comme un développeur de logiciels normal, donc on devrait naturellement inspecter caribeapplication.cpp dans le dossier src. Cool, c’est parti :)
Cool, donc un tas de mots inconnus et un tas de non-sens. Éclaircissons tout ça...
D’abord, parlons de cette constante (0x10005B91). C’est quoi son but ? Eh bien, son type est TUid, qui est défini comme
Cool, donc en gros un identifiant. Mais pourquoi ??? Franchement, je ne sais pas, mais quand on construit une application, on obtient un UUID. Ce qui est intéressant, c’est que si vous cherchez sur Internet, vous verrez que c’est toujours défini comme faisant partie de ce qu’on appelle une application .sis, ce qu’on explorera plus tard. Donc en gros, c’est comme la définition d’en-tête classique pour une application sur SymbianOS. Cool, passons à la suite. On voit la fonction qui nous intéresse, CreateDocumentL.
Donc....
Et ce qu’on appelle, c’est CreateDocumentL
donc on crée un document... mais pourquoi... ? Franchement, je suis aussi perdu que vous, mais mon intuition est que, quand on crée un document, on crée en quelque sorte une classe qui nous permet d’interagir avec l’interface de l’application, puisqu’on la dérive essentiellement du framework UI.
Et comme on appelle CreateDocumentL (je suppose qu’ici, dans cet exemple, on remplace la définition par notre exécution personnalisée), où se trouve sa définition >?? Eh bien, je suppose dans CaribeDocument.h. Alors, c’est quoi, ça ???
Ok, cool, on voit naturellement la fonction qui nous intéresse, newL, alors inspectons CaribeDocument.cpp.
Comme on peut le voir, on finit par appeler newL, qui appelle newLC, qui appelle constructL, et c’est à peu près tout. Mais qu’en est-il de la fonction CreateAppUiL de CEikAppUi ? Eh bien
Alors, essayons de donner un sens à tout ça. En gros, quand on appelle le constructeur de CCaribeDocument, on instancie un CEikApplication en tant que document. Ce CEikApplication est défini comme
Donc, ce que je pense qu’il se passe ici, c’est qu’on essaie fondamentalement d’accéder à l’interface, puis on définit une classe qui pourra ensuite gérer l’interaction avec l’interface via CreateAppUiL. Cool, alors inspectons CCaribeAppUi.h/CCaribeAppUi.cpp
Donc... on ne pourra rien comprendre à moins d’inspecter de quoi elle hérite, c’est-à-dire CAknAppUi.
On voit donc que
qu’on inspecte ensuite pour voir à quoi ressemble CAknAppUi
qu’on inspecte ensuite au niveau de ConstructL
ce qui me fait penser que c’est une fonction d’aide qui ne fait que terminer le constructeur, puisque le constructeur est laissé vide. Cool, creusons
donc, première ligne, on voit une fonction appelée ErrMessage, définie dans general.h comme une macro qui affiche une boîte de dialogue d’information avec les lignes de texte spécifiées. On sait, d’après les rapports sur le comportement de Cabir, que le malware affichait toujours une popup avec le nom. Par exemple
Ensuite, on voit un appel à User::After, c’est quoi ça ? Eh bien, j’ai utilisé ce livre (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) pour mieux comprendre, et si on cherche, il dit que c’est essentiellement attendre un certain nombre de secondes, ici 10 secondes*10, ce qui fait environ 100 secondes (calcul rapide =)) skrr ra)
Ensuite, on appelle BaseConstructL, qui initialise essentiellement l’interface avec ENoAppResourceFile passé comme valeur. Si on creuse un peu
et ensuite on déclare une variable de type CaribeInstaller. Cool, voyons ce que c’est
On inspecte donc CaribeInstaller.cpp et on voit qu’il est assez énorme (c’est ce qu’elle a dit :)) ). Bref, je vais poster plusieurs images car la source est assez grosse.
.PNG)
.PNG)
.PNG)
.PNG)
.PNG)
.PNG)
.
.PNG)
Cool, comme c’est si gros, commençons par le plus court pour s’en débarrasser, à savoir DOCRC16. Qui ne fait qu’un crc16, je suppose, d’après le nom et le fait qu’il a une table de substitution et tout le reste... pour vérifier l’intégrité de ce qui a été écrit. Cool, ensuite
on voit un tas de defines avec des chemins prédéfinis et un tas d’appels à la macro _LIT ? C’est quoi cette macro ? La macro _LIT() utilise un template C++, donc elle produit un type différent pour chaque longueur de chaîne possible.
Ohh, sans oublier de mentionner ceci comme IOC jusqu’à présent ```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, ensuite on analyse la fonction CopyMeToAutostartableDir
donc, à partir du code source du malware, on voit qu'il fait ```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 donc parmi les premières choses qu'il fait, c'est d'obtenir le nom de l'application, dans ce cas je pense que ce sera CARIBE, ensuite il déclare un buffer de 16 octets qui contiendra la chaîne ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.APP
Convertit le nom de l'application en lettres majuscules et compare les deux chaînes . Ensuite, nous voyons une variable appelée fs de type RFs. Que diable est ce type ? Eh bien [https://journey.andreasjakl.com/paper/p04\_series60.php](https://journey.andreasjakl.com/paper/p04\_series60.php) il dit que toutes les applications définissent un pointeur vers un objet de la classe RFs (qui accède au serveur de fichiers) , puis le framework appelle automatiquement Connect() afin que vous puissiez commencer à l'utiliser sans créer votre propre instance de cet objet. Cet appel fait partie de l'API côté client, qui est implémentée comme une bibliothèque partagée et fournit un accès au serveur
(NOTE: Veuillez consulter ceci car j'ai découvert plus tard ce lien en cas où ce n'est pas assez concis [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))
en gros cela nous permet d'avoir accès au fichier du système de fichiers sur la connexion à distance, ensuite nous voyons que nous faisons ```cpp
User::LeaveIfError( .Connect());
if we can't connect. Ce qui est étrange, c'est que nous voyons l'appel API connect sans variable de type socket, mais je pense que c'est spécifique à ce cas de protocole Bluetooth (nous verrons plus tard quel protocole est utilisé) / spécifique à la façon dont l'application a été conçue
we than create ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\
sur le téléphone distant connecté , nous appelons 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)) pour copier le programme lui-même vers ```cpp
C:\\SYSTEM\\SYMBIANSECUREDATA\\CARIBESECURITYMANAGER\\CARIBE.APP
nous répétons ensuite la même procédure, cette fois seulement nous copions l'application vers ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.RSC
et nous revenons ensuite de la fonction. Cool, mais pourquoi le répertoire C:\\\ et pourquoi SYMBIANSECUREDATA ? Et pour le fichier rsc ? Eh bien, apparemment si on inspecte [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/) 
on obtient la réponse : les fichiers du répertoire « SYMBIANSECUREDATA » ne sont pas visibles par défaut pour les utilisateurs, sauf si le gestionnaire de fichiers est installé
Kek mais qu'en est-il du fichier rsc ?
Eh bien, dans un livre sur Symbian OS, ce schéma nous montre que
<figure><img src="https://assets.kitploit.com/production/public/readmes/44345/9e576d96be08742edac009037f8eedf8b41767c116758c15068fecaef05b3c1b.png" alt=""><figcaption></figcaption></figure>
Un fichier de ressources qui définit la légende de l’application, le nombre d’icônes et d’autres informations. Si on recherche le format de fichier .rsc, on découvre que ces fichiers RSC sont généralement classés comme des fichiers de données contenant des ressources compilées et lisibles par machine, converties du format RSS au format binaire. Ils consistent en un fichier APP et une application Symbian finie qui permet aux développeurs d’applications de modifier les ressources du programme sans avoir à recompiler le fichier APP. 
Donc j’ai tendance à conclure qu’ici, je suppose, il y aura des icônes ou différentes ressources.
Mais pourquoi le lecteur C:\\\ ? Eh bien, parce que Symbian OS adopte une convention de type DOS où chaque lecteur est identifié par une seule lettre 
Ensuite InstallMDL
 Son objectif ```cpp
This function will install the mdl file to the recogs directory.
Cool donc on commence par accéder à nouveau au système de fichiers, obtenir le nom de l'application en cours d'exécution, créer une variable qui contient les chaînes ```cpp C:\SYSTEM\RECOGS\FLO.MDL
Et puis nous voyons quelque chose qui ne nous est pas familier : une variable de type TParse.
En inspectant la documentation, on obtient 
<figure><img src="https://assets.kitploit.com/production/public/readmes/44345/56b89fb3a4e9c3381dcdb8d8aa2c047712196ba8112be9f9afc28ff363055acd.png" alt=""><figcaption></figcaption></figure>
Suivant ```cpp
TParse parser;
parser.Set(OwnDllName,NULL,NULL);
TBuf16 <KMaxPath> flodrivepath(parser.DriveAndPath());
_LIT16(FLOMDL,"flo.mdl");
flodrivepath.Append(FLOMDL);
Ce qui se passe ici, c'est qu'il crée dynamiquement le chemin supérieur et j'ai pensé qu'il serait inutile de l'expliquer (si vous souhaitez approfondir, veuillez utiliser ce lien https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-E79A3B03-F8CB-37DB-A2A8-1C6C4E4D739A.html)
Nous créons ensuite ce répertoire ```cpp C:\SYSTEM\RECOGS\
et enfin copiez la chaîne créée dynamiquement qui pointe vers le fichier flo.mdl vers C:\\\SYSTEM\\\RECOGS\\\\ 
Cool alors qu'est-ce qu'il y a de si intéressant dans le fichier mdl ? et le répertoire recogs ? Eh bien de Fortinet, on apprend que le dossier "recogs" stocke généralement des programmes connus sous le nom de "recognizers"
Alors, qu'est-ce qu'un recognizer ? Honnêtement, je ne sais pas trop, tout ce que j'ai trouvé, c'est ceci : les types MIME sont distingués dans le système d'exploitation Symbian par des reconnaisseurs .mdl (stockés dans le dossier \System\Recogs) qui utilisent l'extension du fichier et/ou le format/disposition des données contenues. Les applications enregistrent leur intérêt pour un type MIME donné à un niveau de priorité spécifié par leur auteur dans une datatype\_list dans leur fichier .aif lors de leur installation (voir "Aiftool resource file format" dans la documentation du SDK C++ ou OPL). L'application enregistrée exprimant la plus haute priorité est utilisée par le système pour tenter d'ouvrir un document d'un type MIME quelconque.
et ceci : le Symbian OS Recogniser permet aux MIDlets d'être reconnues comme MIDlets par le système.
donc rien de bien passionnant.... Mais je suppose que puisque ça a à voir avec les types MIME, c'est probablement une histoire d'icônes et d'interface graphique ([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))
Et maintenant, qu'en est-il des fichiers mdl ? Eh bien, d'après le même lien, on apprend que les reconnaisseurs de données étaient des DLL plug-in avec une extension `.mdl` ce qui signifie essentiellement que c'est un plugin qui charge un fichier image média. Cool
\=============================================
créer une fonction de fichier sys (à faire)
\=============================================
Maintenant que nous comprenons ce que fait chaque fonction, nous revenons à caribeappui.cpp et nous continuons à analyser le flux d'exécution. Nous voyons que la dernière fonction de ConstructL est ```cpp
CaribeBluetooth::NewL();
Et c'est ainsi que nous commençons notre voyage dans Cariblebt.cpp
donc newL appelle newLC qui appelle constructorL qui appelle RunL et définit iState à 3. Maintenant, runL vérifie l'état et, dans notre cas, puisque nous l'avons défini à 3 par défaut, nous finissons par exécuter FindDevices et ManageDevicesFound
FindDevices ressemble à ceci
Honnêtement, cela ne semble pas différent d'un scan TCP habituel, mais creusons. D'abord, parce que j'ai oublié, voici Cariblebt.h
Cool, donc revenons à notre fonction. Nous définissons KL2Cap en chaîne ou en type BTLinkManager, ensuite nous vérifions si nous pouvons créer un canal de communication IPC avec un serveur de socket. Ok, attends, wtf, de quoi tu parles ? Franchement, je n'en sais rien, alors enquêtons. Donc nous avons socketServ de type RsocketServ. Cool, et maintenant quoi ?>Maintenant, si nous cherchons strictement cette classe (https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-EF29C1D7-B1E5-370F-AE37-66231A6BE449.html), nous obtenons exactement ce que j'ai dit : nous créons un canal IPC. Mais pourquoi ? Maintenant, d'après le nom, je peux deviner que cela a à voir avec une socket. Maintenant, si nous inspectons 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), nous obtenons qu'il fournit un endpoint client vers un protocole. Il fournit des fonctions pour la création de socket, la lecture et l'écriture.
Maintenant, pour aller plus loin avec ce cas, si nous utilisons ceci (https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-CED041C8-D68D-55D1-957E-1A48EEFFF851.html), nous voyons que c'est ainsi que fonctionne la recherche d'appareils distants sur Symbian, autrement dit comment établir une connexion Bluetooth.
Curieusement, juste après cela, la ligne suivante correspond exactement à ce qui est décrit dans le protocole ci-dessus, par exemple sélectionner le protocole à utiliser via RSocketServ::FindProtocol()
Et exactement comme indiqué précédemment, nous faisons comme décrit dans le document ci-dessus, à savoir créer et initialiser un objet RHostResolver.
Nous définissons ensuite TInquirySockAddr sur la découverte générale, afin de pouvoir scanner les appareils.
Ensuite, nous définissons le paramètre de la socket pour les requêtes d'adresse, nous positionnons le flag KHostResInquiry
Nous démarrons ensuite la requête à l'aide de GetByAddress, et si nous parvenons à trouver des appareils Bluetooth, on nous retourne une adresse unique de 48 bits. Donc ce qui se passe ici est essentiellement une simple vérification pour voir si des appareils Bluetooth sont autour de nous.
Ensuite, nous appelons ManageFoundDevices.
Nous vérifions si nous avons réussi à obtenir une adresse et, si c'est le cas, nous appelons Cancle(). Nous créons ensuite un endpoint/une « connexion » (mais en réalité nous ne nous connectons pas encore) vers l'adresse Bluetooth, et nous créons en outre une variable de type TObexBluetoothProtocolInfo, qui est utilisée pour décrire les informations de protocole spécifiques à Bluetooth (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)
Maintenant, wtf, c'est quoi un serveur Obex ??? D'après le 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) est un protocole de communication qui facilite les transferts binaires entre appareils compatibles Bluetooth. Cool, dans notre cas, puisque la classe TObexBluetoothProtocolInfo hérite de TObexProtocolInfo, nous devons spécifier le type de transport pour que SymbianOS sache quel protocole utiliser, dans notre cas rfcomm. Et donc, ce que nous faisons ensuite consiste essentiellement à définir à qui parler et sur quel port. Et comme le port rfcomm est dynamique, il peut être entre 0x1-30 et dans ce cas, c'est 9. Nous créons ensuite une connexion client et nous nous y connectons. Ok, donc euh, qu'est-ce qui se passe ensuite ? Il n'y a aucun signe de ce qui va se passer. Donc euh...... ouais.... Après cela, nous revenons de la fonction et, comme il n'y a pas de boucle while, je suppose que le même processus qu'avant se répète une fois de plus. Seulement, maintenant que nous nous sommes déjà connectés à cet appareil, notre état sera 1 et, comme nous avons établi une connexion, nous appelons put, qui, si l'on consulte Wikipédia, fait ceci :
Maintenant, comment savons-nous quel fichier est iCurrFile ? Eh bien, ma théorie est qu'au début du fichier, nous avons la fonction CActive qui, je pense, agit comme un hook pour chaque fois que nous appelons SetActive().
Donc voilà, cela conclut l'analyse. Merci d'avoir lu ceci ! Bon hacking :)