spiralbl0ck/cabir_analysisanálisis parcial de cabin
Antes de que empieces a leer, tengo que hacer este anuncio: POR FAVOR, TÓMATE TODO LO QUE LEAS CON UN GRANITO DE SAL, YA QUE NO SOY EN ABSOLUTO UN DESARROLLADOR DE SymbianOS NI ESTOY FAMILIARIZADO CON EL ENTORNO SymbianOS
¿Pero por qué analizar algo tan antiguo? Bueno, porque es la forma más fácil de adentrarse en el hacking remoto, ya que hoy en día este tipo de mierda se hace con ndays/0days que valen 1 millón 🤑🤑🤑. Y porque todavía me falta experiencia para hacer ese tipo de cosas.
Bien, ahora que hemos dejado esta mierda de lado, vamos a ello. ¿Qué coño es Cabir? Es un gusano de Bluetooth que se ejecuta en teléfonos móviles Symbian. Para aquellos que se pregunten qué coño es un teléfono Symbian y toda esa mierda. Bueno, básicamente es un teléfono que usa ARM, así que nada nuevo bajo el sol :) Información más concisa (https://en.wikipedia.org/wiki/S60_(software_platform))
Ahora tuvimos la suerte de que el código fuente de esto estuviera en línea (cortesía de vxug) (SymbianOS.Cabir.7z). Ahora usaremos eso como referencia, pero sinceramente, a la mierda. Una de las otras razones por las que hago esto es porque quiero experimentar con ARM. Así que veremos esto desde una perspectiva de fuente/ensamblador/emulador/depuración/sniffing.
Bien, #1 ¿Cómo coño compilamos el código fuente?
Bueno, eso no es tan complicado...
Primero instala carbide ++(http://www.mediafire.com/file/6z54qrceef73x9s/Carbide_cpp_v2_7_en.exe/file)(desde https://gist.github.com/artem78/cb2b9650af186844f7b5654964676284)
luego instala cualquier motor de Perl
luego instala Nokia PC Suite(https://www.usitility.com/nokia-pc-suite/)
instala el SDK(http://www.mediafire.com/file/9uc7fjb2ynmxlud/s60v3.1_SDK.zip/file )
instala el plugin de c/c++ (https://ia800905.us.archive.org/7/items/nokia_sdks_n_dev_tools/s60_open_c_cpp_plug_in_v1_7_en.zip)
Y voilà, tenemos el entorno :)
PD: mejor usa Windows 7, ya que al parecer en Windows 10 las cosas se rompen y no funcionan correctamente
Infección en entorno real
TBD
Para esta parte, debes saber que necesitas jailbreak (sí, has oído bien, jailbreak) a tu teléfono. ¿Cómo sucede esto?
Análisis de ingeniería inversa
Bien, ¿cómo coño se compila esto? Muy buena pregunta. Lo que hice fue ejecutar primero ABLT.BAT desde la carpeta caribe\group así
Bien, a continuación lo que hacemos ahora es ir a donde está instalado nuestro SDK, identificar la carpeta de la plataforma (S60_3rd_fp1) en mi caso, encontrar la carpeta epoc32, ir a la carpeta build, elegir user, la carpeta de usuario y luego otras dos o tres carpetas más, y deberías terminar en una carpeta que se ve así
Esta es la ruta actual, que debería ser más o menos similar a lo que se supone que deberías tener (C:\Symbian\9.2\S60_3rd_FP1\Epoc32\BUILD\Users\pwn\Desktop\CabirSourceCodes\caribe\group)
Bien, a continuación tenemos que entrar en la carpeta caribe (o como hayas nombrado el código fuente) y encontrarás una carpeta con diferentes nombres, como se ve aquí
¿De qué va esto? Bueno, básicamente cuando ejecutamos por primera vez ablt.bat (a día de hoy sigo sin saber su propósito, pero da igual) obtenemos diferentes opciones de plataforma para compilar nuestro archivo pkg, a partir del cual generaremos nuestro archivo sis. En el caso que vemos aquí, vemos GCCE y WINSCW. Si ejecutas por defecto el comando ablt.bat build, lo compilará para WINSCW (que es el nombre en clave de la plataforma del emulador). A efectos de aprender a compilar el código fuente, usaremos GCCE por ahora, pero el proceso es el mismo si eliges hacerlo para, no sé, la plataforma arm, para que puedas subirlo a tu teléfono. Así que básicamente ablt build arm_whatever y luego haz exactamente los mismos pasos hasta aquí. Bien, ahora vamos a la carpeta GCCE
ve a la carpeta urel y debería haber un archivo llamado caribe.app. Desde ahí querrás abrir una línea de comandos y ejecutar
¿Y esto qué hace? Bueno, básicamente ejecutamos makesis, que genera un archivo sis para poder instalarlo en nuestro teléfono. ¿Y por qué estamos en un archivo sis del código fuente de caribe? Bueno, básicamente necesitábamos especificar caribe.pkg a makesis. Bien, ¿y entonces por qué todo ese lío para llegar a la carpeta build, blah, blah? Bueno, porque necesitas especificarlo en el parámetro -d para que pueda generar el archivo .sis
Bien, este método solo funciona con el SDK v3, al que se refiere este artículo. Al parecer, mientras experimentaba, un desarrollador de un servidor de Discord dedicado a Symbian me señaló que Cabir está codificado para SDK v2, por lo que lo que he presentado aquí será inútil... esto está pendiente hasta que pueda contactar con él... ya que últimamente está bastante desconectado de Discord...
Bien, ¿cómo se hace ingeniería inversa de un archivo .sis?
Simplemente, un archivo .sis es un archivo comprimido. Así que... usamos la aplicación siscontents para descomprimir y luego metemos el archivo .app en IDA.
Perspectiva del ensamblador
Así que todo el proceso se ve así
Ahora entramos en esa carpeta y luego 2 obtenemos el archivo app.app
Bien, si lo metes en IDA.
Bien, así que básicamente es un ejecutable ARM. ¡GENIAL, INCREÍBLE! ¡EL SIGUIENTE, POR FAVOR! HMM SÍ, POR FAVOR ~~~
¡¡¡HAY símbolos en el archivo, sí!!! Bueno, sí, ya que por alguna extraña razón compilamos el binario con símbolos de depuración, ¡tuvimos suerte!
Y así, como básicamente tenemos el código y todo eso, el proceso de ingeniería inversa es más o menos el mismo que se describe en el capítulo de análisis del código fuente :)
Perspectiva del sniffing
Desafortunadamente no puedo hacer esto, porque lo que planeaba hacer era usar Fts4bt, ya que vi que era bastante bueno(https://www.diva-portal.org/smash/get/diva2:24278/FULLTEXT01.pdf)
pero al parecer el producto llegó a su fin de vida. Si por casualidad puedes hacer esta parte, por favor escríbeme por privado y haz un pull request para terminar este capítulo
Perspectiva del depurador
¿¿¿Y QUÉ PASA CON ESTA SECCIÓN !>>~>? Bueno, esta es mi opinión al respecto: aunque valdría la pena para mí y para ti (el lector) como experiencia aprender a conectar un depurador a través de USB y depurar código directamente en un teléfono Nokia, me llevaría demasiado tiempo y esfuerzo hacerlo por ahora (ya estoy bastante cansado... lo siento, quizás en otro momento). Otro argumento de por qué esto sería inútil es porque tenemos el código fuente y un IDE de Symbian especialmente diseñado. Así que esto es lo que vamos a hacer: usaremos el depurador de Carbide++ para depurar brevemente una o dos funciones, y esto lo puede hacer el lector porque el flujo del código se explicó en la sección de análisis de código fuente y porque tampoco hay cifrado ni métodos anti-lo-que-sea que dificulten analizar el código. Así que... ¡vamos!
siendo sinceros
Análisis del código fuente
Bien, así que aprovechemos el hecho de que tenemos acceso al código fuente y usémoslo para obtener el máximo beneficio.
Nuestra estructura de directorios tiene este aspecto, que está bastante bien organizada
Así que vamos a inspeccionar la carpeta src
Nuestro viaje comienza en la carpeta src, precisamente en caribe.cpp. ¿Pero por qué? Porque aunque está bastante bien organizado, una cosa que destaca es que hay un archivo caribe.cpp. ¿Tiene algo de especial? Nah, pero supuse por corazonada educada que en este caso 29A (el grupo que desarrolló el malware) siguió un enfoque clásico de los desarrolladores de software, donde la lógica principal de una aplicación va en name_of_project.extension. Bien, ¿cómo coño se ve? Así, joven sangre
Genial, pero ¿qué es esto? Honestamente no sé, pero intentemos hacer algunas suposiciones. Basándome únicamente en el nombre, supongo que CApaApplication is the main of this application. If we search this on google we see that
Bien, ¿y ahora qué? Vamos a profundizar más, tío. Vamos a inspeccionar CCaribeApplication. Pero, ¿dónde diablos está CCaribeApplication? En CaribeApplication.h. ¿Dónde está eso? En la carpeta inc, hermano, que se ve así
Bien, se ve así
Genial, vemos una clase que se está desarrollando y que hereda de otra clase, y vemos un método protegido llamado CreateDocumentL. Bien, pero nada interesante. ¡Ye, culpa mía, tío!
¡¿Qué error es este, yo?! ¿Y te llamas analista de malware? =))) Tranqui, tío. Nah, entonces dijimos que el autor de este proyecto probablemente actuó como un desarrollador de software normal, así que naturalmente deberíamos inspeccionar caribeapplication.cpp en la carpeta src. Bien, vamos a ello :)
Bien, un montón de palabras desconocidas para nosotros y un montón de sinsentidos. Vamos a arrojar un poco de luz...
Primero, hablemos de esa constante (0x10005B91). ¿Cuál es su propósito? Bueno, su tipo es TUid, que se define como
Bien, así que básicamente es una id. ¿Pero por qué? Honestamente no sé, pero cuando compilas una aplicación obtienes un uuid. La parte interesante es que, si buscas en internet sobre ello, verás que siempre se define como parte de lo que se llama aplicación .sis, que exploraremos más tarde. Así que básicamente es como la definición clásica de cabecera para una aplicación en SymbianOS. Bien, siguiente. Vemos la función que nos interesa, que es CreateDocumentL.
Así que...
Y lo que llamamos es CreateDocumentL
así que creamos un documento... ¿pero por qué? Honestamente estoy tan perdido como tú, pero mi corazonada es que cuando creamos un documento, básicamente de alguna manera creamos una clase que nos permite interactuar con la interfaz de usuario de la aplicación, ya que básicamente la derivamos del framework de UI.
Y como llamamos a CreateDocumentL (supongo que en este ejemplo sobrescribimos la definición con nuestra ejecución personalizada), ¿dónde tenemos su definición? Bueno, supongo que en CaribeDocument.h. ¿Y eso qué?
Ok, bien, vemos naturalmente la función que nos interesa, newL, así que inspeccionemos CaribeDocument.cpp
como podemos ver, terminamos llamando a new L, que llama a newLC, que llama a constructL, y eso es todo. ¿Pero qué pasa con la función CEikAppUi CreateAppUiL? Bueno
Así que intentemos darle sentido a esto. Básicamente, cuando llamamos al constructor de CCaribeDocument, instanciamos un CEikApplication como documento. Ese CEikApplication se define como
Así que lo que creo que sucede aquí es que básicamente intentamos acceder a la UI y luego definimos una clase que más tarde puede manejar la interacción con la UI mediante CreateAppUiL. Bien, inspeccionemos CCaribeAppUi.h/CCaribeAppUi.cpp
Así que... no podremos darle sentido a esto a menos que inspeccionemos de qué hereda, y eso es CAknAppUi.
Así que vemos que
que inspeccionamos más a fondo para ver cómo es CAknAppUi
que luego inspeccionamos en ConstructL
lo que me hace pensar que esta es una función auxiliar que solo completa el constructor, ya que el constructor se deja vacío. Bien, vamos a cavar
así que en la primera línea vemos una función llamada ErrMessage, que se define en general.h como una macro que muestra un diálogo de información con las líneas de texto especificadas. Sabemos por los informes de cómo se comportaba Cabir que el malware siempre mostraba una ventana emergente con el nombre. Ej.:
A continuación vemos una llamada a User::After, ¿qué coño hace esto? Bueno, usé este libro de (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) para entenderlo mejor, y si buscamos eso, dice que básicamente espera un número n de segundos, aquí son 10 segundos*10, que son como 100 segundos (matemáticas rápidas =)) skrr ra)
A continuación llamamos a BaseConstructL, que básicamente inicializa la interfaz de usuario con ENoAppResourceFile pasado como valor. Si cavamos un poco
y a continuación declaramos una variable de tipo CaribeInstaller. Bien, veamos de qué va eso
Así que inspeccionamos CaribeInstaller.cpp y vemos que es bastante grande (eso dijo ella :)) ). De todos modos, publicaré múltiples imágenes ya que el código es bastante grande
.PNG)
.PNG)
.PNG)
.PNG)
.PNG)
.PNG)
.
.PNG)
Bien, ya que es tan grande, empecemos con la rápida para quitárnosla de encima, y esa es DOCRC16. Que solo hace un crc16, supongo, basándome en el nombre y en el hecho de que tenía una tabla de subs y demás... para comprobar la integridad de lo que ha escrito. Bien, a continuación
vemos un montón de defines con rutas predefinidas y un montón de llamadas a la macro _LIT? ¿Qué coño hace la macro? La macro _LIT() usa una plantilla de C++, por lo que produce un tipo diferente para cada posible longitud de cadena.
Ohh, no olvidemos mencionar esto como IOC que tenemos hasta ahora```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"
Bien, a continuación analizamos la función CopyMeToAutostartableDir
así que del código fuente del malware vemos que hace ```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.
Genial, así que entre las primeras cosas que hace está obtener el nombre de la aplicación; en este caso creo que será CARIBE. A continuación declara un búfer de 16 bytes que contendrá la cadena ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.APP
convierte el nombre de la aplicación a letras mayúsculas y compara las dos cadenas. A continuación vemos una variable llamada fs de tipo RFs. ¿Qué demonios es ese tipo? Bueno, [https://journey.andreasjakl.com/paper/p04\_series60.php](https://journey.andreasjakl.com/paper/p04\_series60.php) dice que todas las aplicaciones definen un puntero a un objeto de la clase RFs (que accede al servidor de archivos), y luego el framework llama automáticamente a Connect() para que puedas empezar a usarlo sin crear tu propia instancia de este objeto. Esta llamada forma parte de la API del lado del cliente, que se implementa como una biblioteca compartida y proporciona acceso al servidor
(NOTA: Por favor, considera esto, ya que más tarde descubrí este enlace por si esto no es lo suficientemente conciso [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))
básicamente esto nos permite tener acceso a los archivos del sistema de archivos en la conexión remota, ya que a continuación vemos que hacemos ```cpp
User::LeaveIfError( .Connect());
si no podemos conectarnos. Lo extraño es que vemos la llamada a la API de conexión sin una variable de tipo socket, pero creo que esto es específico de este caso de protocolo bluetooth (veremos más adelante qué protocolo se está usando) / específico de cómo se diseñó la aplicación.
luego creamos ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\
en el teléfono remoto conectado , llamamos a 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)) para copiar el propio programa a ```cpp
C:\\SYSTEM\\SYMBIANSECUREDATA\\CARIBESECURITYMANAGER\\CARIBE.APP
luego repetimos el mismo procedimiento, esta vez solo copiamos la aplicación a ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.RSC
y luego volvemos de la función. Interesante, pero ¿por qué al directorio C:\\\ y por qué a SYMBIANSECUREDATA? ¿Y qué pasa con el archivo rsc? Bueno, aparentemente si inspeccionamos [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/) 
obtenemos la respuesta: los archivos bajo el directorio ‘SYMBIANSECUREDATA’ no son visibles por defecto para los usuarios a menos que File Manager esté instalado
Kek pero ¿qué pasa con el archivo rsc?
Bueno, en un libro sobre symbianOs, este diagrama nos muestra que
<figure><img src="https://assets.kitploit.com/production/public/readmes/44345/9e576d96be08742edac009037f8eedf8b41767c116758c15068fecaef05b3c1b.png" alt=""><figcaption></figcaption></figure>
Un archivo de recursos que define el título de la aplicación, el número de iconos y otra información. Si buscamos sobre el formato de archivo .rsc, obtenemos que estos archivos RSC generalmente se clasifican como archivos de datos que contienen recursos compilados y legibles por máquina desde el formato RSS al formato binario. Consisten en un archivo APP y una aplicación Symbian terminada que permite a los desarrolladores de aplicaciones modificar los recursos del programa sin necesidad de recompilar el APP. 
Así que tiendo a concluir que aquí, supongo, habrá iconos o diferentes recursos.
¿Pero por qué la unidad C:\\\? Bueno, porque Symbian OS adopta una convención similar a DOS donde cada unidad se identifica con una sola letra 
A continuación, InstallMDL
 Su objetivo ```cpp
This function will install the mdl file to the recogs directory.
Genial, así que comenzamos nuevamente accediendo al sistema de archivos, obteniendo el nombre de la aplicación actualmente en ejecución, creando una variable que contiene las cadenas ```cpp C:\SYSTEM\RECOGS\FLO.MDL
Y luego vemos algo con lo que no estamos familiarizados, que es una variable de tipo TParse.
Inspeccionando la documentación obtenemos 
<figure><img src="https://assets.kitploit.com/production/public/readmes/44345/56b89fb3a4e9c3381dcdb8d8aa2c047712196ba8112be9f9afc28ff363055acd.png" alt=""><figcaption></figcaption></figure>
Siguiente ```cpp
TParse parser;
parser.Set(OwnDllName,NULL,NULL);
TBuf16 <KMaxPath> flodrivepath(parser.DriveAndPath());
_LIT16(FLOMDL,"flo.mdl");
flodrivepath.Append(FLOMDL);
Lo que sucede aquí es que crea dinámicamente la ruta superior y pensé que sería inútil explicarlo (si quieres investigar más, por favor usa este enlace https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-E79A3B03-F8CB-37DB-A2A8-1C6C4E4D739A.html)
Luego creamos este directorio ```cpp C:\SYSTEM\RECOGS\
y finalmente copia la cadena creada dinámicamente que apunta al archivo flo.mdl en C:\\\SYSTEM\\\RECOGS\\\\ 
Genial, entonces ¿qué tiene de interesante el archivo mdl ? ¿y el directorio recogs ? Bueno, de Fortinet obtenemos que la carpeta "recogs" almacena comúnmente programas conocidos como "recognizers"
entonces, ¿qué es un recognizer ? Honestamente, no sé, todo lo que pude encontrar fue esto: los tipos MIME se distinguen en Symbian OS mediante recognizers .mdl (almacenados en la carpeta \System\Recogs) que hacen uso de la extensión del archivo y/o del formato/disposición de los datos contenidos. Las aplicaciones registran su interés en un tipo MIME dado a un nivel de prioridad especificado por su autor en una datatype_list de su archivo .aif cuando se instalan (consulta "Aiftool resource file format" en la documentación de C++ u OPL SDK). La aplicación registrada que expresa la prioridad más alta es utilizada por el sistema para intentar abrir un documento de cualquier tipo MIME dado.
y esto: el Recogniser de Symbian OS permite que los MIDlets sean reconocidos como MIDlets por el sistema.
así que prácticamente nada.... Pero supongo que, como tiene que ver con los tipos MIME, supongo que se trata de los iconos y cosas de la 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)). Y ahora, ¿qué pasa con los archivos mdl ? Bueno, del mismo enlace obtenemos que los data recognizers eran DLLs plug-in con extensión `.mdl` lo que básicamente significa que esto es un plugin que carga un archivo de imagen multimedia. Genial.
\=============================================
crear función de archivo sys pendiente
\=============================================
Ahora que entendemos lo que hace cada función, volvemos a caribeappui.cpp y continuamos analizando el flujo de ejecución. Vemos que la última función de ConstructL es```cpp
CaribeBluetooth::NewL();
Y así comenzamos nuestro viaje en Cariblebt.cpp
así que newL llama a newLC, que llama a constructorL, que llama a RunL y establece iState a 3. Ahora runL comprueba el estado y, en nuestro caso, como lo establecimos a 3 por defecto, terminamos ejecutando FindDevices y ManageDevicesFound
FindDevices tiene este aspecto
Honestamente, no parece diferente de un escaneo tcp normal, pero profundicemos. Primero, porque lo olvidé, aquí está Cariblebt.h
Genial, volvamos a nuestra función. Establecemos KL2Cap como cadena o tipo BTLinkManager; luego comprobamos si podemos crear un canal de comunicación IPC con un servidor de sockets. Ok, espera, ¿qué demonios estás diciendo? Honestamente no lo sé, así que investiguemos. Tenemos un socketServ de tipo RsocketServ. Genial, ¿y ahora qué?>ahora si buscamos estrictamente esa clase(https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-EF29C1D7-B1E5-370F-AE37-66231A6BE449.html) obtenemos exactamente lo que dije: creamos un canal IPC. Pero ¿por qué? Bueno, por el nombre puedo suponer que tiene que ver con un socket. Ahora si inspeccionamos 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) obtenemos que proporciona un endpoint de cliente a un protocolo. Proporciona funciones para la creación, lectura y escritura de sockets
Ahora, con más detalle sobre este caso, si usamos esto (https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-CED041C8-D68D-55D1-957E-1A48EEFFF851.html) vemos que así es como funciona la consulta de dispositivos remotos en Symbian, o sea, cómo hacer una conexión Bluetooth.
Curiosamente, justo después de esto, la siguiente línea es exactamente como se describe en el protocolo anterior, p. ej., seleccionar el protocolo a usar mediante RSocketServ::FindProtocol()
Y exactamente como se dijo antes, hacemos justo lo que se describe en el documento anterior, que es crear e inicializar un objeto RHostResolver.
Luego establecemos TInquirySockAddr al descubrimiento general, para poder escanear dispositivos
A continuación, establecemos el parámetro del socket para consultas de direcciones; activamos el flag KHostResInquiry
Luego iniciamos la consulta usando GetByAddress y, si logramos encontrar algún dispositivo Bluetooth, se nos devuelve una dirección única de 48 bits. Entonces lo que ocurre aquí es básicamente una comprobación simple para ver si hay dispositivos Bluetooth a nuestro alrededor.
Next we call ManageFoundDevices.
Comprobamos si logramos obtener una dirección y, si lo hicimos, llamamos a Cancle(). Luego creamos un endpoint/"conexión" (pero en realidad todavía no conectamos ahí) hacia la dirección Bluetooth, y además creamos una variable de tipo TObexBluetoothProtocolInfo, que se usa para describir información de protocolo específica de 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)
Ahora, ¿qué demonios es un servidor OBEX? Según la sinopsis ( 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) es un protocolo de comunicaciones que facilita transferencias binarias entre dispositivos con Bluetooth. Genial, en nuestro caso, como la clase TObexBluetoothProtocolInfo hereda de TObexProtocolInfo, necesitamos especificar el tipo de transporte para que SymbianOS sepa qué protocolo usar; en nuestro caso, rfcomm. Y así, lo que hacemos a continuación es básicamente configurar a quién hablar y en qué puerto. Y como el puerto rfcomm es dinámico, puede estar entre 0x1-30 y en este caso es 9. Luego creamos una conexión de cliente y nos conectamos a él. Ok, entonces... emm, ¿qué pasa después? No hay señal de qué va a pasar. Así que... sí.... Después de eso retornamos y, como no hay while, supongo que el mismo proceso de hasta ahora se repite una vez más. Solo que ahora, como ya nos conectamos a ese dispositivo, nuestro estado será 1 y, como hemos establecido una conexión, llamamos a put, que si consultamos Wikipedia hace lo siguiente:
Ahora, ¿cómo sabemos qué archivo es iCurrFile? Bueno, mi teoría es que al principio del archivo tenemos la función CActive, que creo que actúa como un gancho para cuando llamamos a SetActive().
Así que, sí, esto concluye el análisis. ¡Gracias por leer esto! Feliz hacking :)