description: Análise do Bluetooth-Worm:SymbOS/Cabir

Análise do Bluetooth-Worm:SymbOS/Cabir

Antes de começar a ler, tenho que fazer este anúncio: POR FAVOR, LEVE TUDO O QUE VOCÊ LER COM UMA PITADA DE SAL, POIS NÃO SOU UM desenvolvedor SymbianOS nem nada familiarizado com o ambiente SymbianOS

Mas por que analisar algo tão antigo assim? Bem, porque é a forma mais fácil de entrar no hacking remoto, já que hoje em dia esse tipo de merda é feito com ndays/0days que valem 1 milhão 🤑🤑🤑. E porque ainda não tenho a experiência necessária para fazer esse tipo de coisa.

Beleza, agora que tiramos essa merda do caminho, vamos nessa. Que diabos é Cabir? É um Bluetooth-worm que roda em celulares Symbian. Para aqueles que se perguntam que diabos é um celular Symbian e essa porra toda. Bem, basicamente é um telefone que roda ARM, nadinha de novo debaixo do sol :) Informações mais concisas (https://en.wikipedia.org/wiki/S60_(software_platform))

Agora, tivemos a sorte de o código-fonte disso estar online (cortesia do vxug) (SymbianOS.Cabir.7z). Vamos usar isso como referência, mas, sinceramente, foda-se isso. Uma das outras razões pelas quais faço isso é porque quero mexer com ARM. Então vamos ver isso sob uma perspectiva de source/assembly/emulator/debugging/sniffing.

Beleza, então #1 Como diabos compilamos o código-fonte?

Bem, isso não é tão complicado...

Primeiro instale o carbide ++(http://www.mediafire.com/file/6z54qrceef73x9s/Carbide_cpp_v2_7_en.exe/file)(de https://gist.github.com/artem78/cb2b9650af186844f7b5654964676284)

em seguida, instale qualquer engine perl

em seguida, instale o nokia pc suite(https://www.usitility.com/nokia-pc-suite/)

instale o SDK(http://www.mediafire.com/file/9uc7fjb2ynmxlud/s60v3.1_SDK.zip/file )

instale o 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)

E voilà, temos o ambiente :)

Ps: é melhor usar Windows 7, pois aparentemente no Windows 10 as coisas quebram e não funcionam corretamente

Infecção em ambiente real

A definir

Para esta parte, saiba que você precisa fazer jailbreak (sim, você ouviu certo, jailbreak) no seu celular. Como isso acontece?

Análise de engenharia reversa

Beleza, então como diabos se compila essa porra? Ótima pergunta. O que eu fiz foi rodar primeiro o ABLT.BAT na pasta caribe\group, assim

Beleza, o próximo passo é ir até onde o SDK está instalado, identificar a pasta da plataforma (S60_3rd_fp1) no meu caso, encontrar a pasta epoc32, ir para a pasta build, escolher a pasta user, a pasta do nome de usuário e depois mais duas ou três outras pastas, e você deve acabar em uma pasta que se parece com isso

Este é o caminho atual, que deve ser aproximadamente semelhante ao que você deveria estar (C:\Symbian\9.2\S60_3rd_FP1\Epoc32\BUILD\Users\pwn\Desktop\CabirSourceCodes\caribe\group)

Beleza, em seguida precisamos entrar na pasta caribe (ou como você nomeou o código-fonte) e você encontrará uma pasta com nomes diferentes, como visto aqui

Sobre o que é isso? Bem, basicamente quando rodamos o ablt.bat pela primeira vez (até hoje não sei a finalidade, mas tudo bem), obtemos diferentes opções de plataforma para construir nosso arquivo pkg, a partir do qual geraremos nosso arquivo sis. No caso aqui, vemos GCCE e WINSCW. Se você rodar por padrão o comando ablt.bat build, ele criará para WINSCW (que é o nome de codinome dado à plataforma do emulador). Para o propósito de aprender a compilar o código-fonte, usaremos GCCE por enquanto, mas o processo é o mesmo se você escolher fazer para, sei lá, plataforma ARM, para poder enviar para o seu celular. Então, basicamente, ablt build arm_whatever e depois faça exatamente os mesmos passos até aqui. Beleza, agora vamos para a pasta GCCE

vá para a pasta urel e deve haver um arquivo chamado caribe.app. A partir daí, você quer abrir uma linha de comando e executar

Então, o que isso faz??? Bem, basicamente rodamos o makesis, que gera um arquivo sis para que possamos instalá-lo no nosso celular. E por que um arquivo sis a partir do código-fonte do caribe? Bem, basicamente precisávamos especificar o caribe.pkg para o makesis. Beleza, então por que todo esse trabalho para chegar à pasta build blá blá blá? Bem, porque você precisa especificá-la no parâmetro -d para que ele possa gerar o arquivo .sis

Beleza, então esse método só funciona no SDK v3, ao qual este write-up se refere. Aparentemente, enquanto eu estava experimentando, um dev de um servidor Discord dedicado a Symbian apontou que o Cabir é codificado para o SDK v2, e sendo assim, o que apresentei aqui será inútil..... isso está a definir até eu conseguir falar com ele... porque ele está bem offline no Discord ultimamente...

Beleza, então como se faz engenharia reversa de um arquivo .sis?

sIMPLESMENTE, um arquivo .sis é um arquivo compactado. Então... usamos o aplicativo siscontents para descompactar e depois jogamos o arquivo .app no ida.

Perspectiva de assembly

Então, o processo inteiro se parece com isto

Então, agora vamos para essa pasta e logo em seguida temos o arquivo app.app

Beleza, se você jogar no ida.

Beleza, então basicamente um exe ARM. QUE LOUCURA! PRÓXIMO, POR FAVOR! HMM SIM, POR FAVOR ~~~

tEM símbolos no arquivo, sim!!! bem, sim, porque por algum motivo estranho compilamos o binário com símbolos de depuração, demos sorte!

E como basicamente temos o código e tal, o processo de engenharia reversa é quase o mesmo descrito no capítulo de análise de código-fonte :)

Ponto de vista do sniffing

Infelizmente não posso fazer isso, pois o que eu planejava fazer era usar o Fts4bt, já que vi que era bem legal(https://www.diva-portal.org/smash/get/diva2:24278/FULLTEXT01.pdf)

mas aparentemente o produto chegou ao fim da vida (EOL). Se por acaso você puder fazer essa parte, por favor me chame no DM e faça um pull request para terminar este capítulo

Ponto de vista do debugger

eNTÃO, QUE TAL ESTA SEÇÃO !>>~> Bem, aqui está minha opinião sobre isso: embora valha a pena para mim e para você (o leitor) como experiência aprender a conectar um debugger via USB e depurar código diretamente em um Nokia, isso me custaria muito tempo e esforço para fazer agora (já estou bem cansado... desculpe, talvez outra hora). Outro argumento para isso ser inútil é que temos o código-fonte e uma IDE Symbian especialmente projetada. Então aqui está o que vamos fazer. Vamos usar o debugger do Carbide++ para depurar brevemente uma ou duas funções, e isso pode ser feito pelo leitor, pois o fluxo do código foi explicado na seção sca e porque também não há métodos de criptografia/anti-qualquer-coisa para dificultar a análise do código. Então... vamos lá!

sinceramente

Análise do código-fonte

Beleza, então vamos explorar o fato de termos acesso ao código-fonte e usá-lo para obter o máximo proveito.

Então, nossa estrutura de diretórios se parece com isto, que é muito bem organizada

Então, vamos inspecionar a pasta src

Nossa jornada começa na pasta src, precisamente em caribe.cpp. Mas por quê? Porque, embora seja muito bem organizada, uma coisa que se destaca é que há um arquivo caribe.cpp. Algo especial sobre ele? Não, mas presumi por palpite fundamentado que, neste caso, o 29A (o grupo que desenvolveu o malware) seguiu a abordagem clássica dos desenvolvedores de software, onde a lógica principal de um app vai para name_of_project.extension. Beleza, então como diabos isso se parece? Assim, jovem sangue

lEGAL, mas o que é isso? sinceramente, não sei, mas vamos tentar fazer alguns palpites. Baseado apenas no nome, vou chutar que CApaApplication is the main of this application. If we search this on google we see that

Beleza, e agora?? Vamos cavar mais fundo, cara. Vamos inspecionar o CCaribeApplication. Mas espera, onde está o CCaribeApplication? Em CaribeApplication.h. Onde isso? Na pasta inc, mano, que se parece com isto

Beleza, então se parece com isto

lEGAL, então vemos uma classe sendo definida que herda de outra classe e vemos um método protegido chamado CreateDocumentL. Legal, mas nada interessante. Sim, culpa minha aqui, mano!!

Que erro é esse, ei! E você se diz analista de malware =))) relaxa, mano! Não, então dissemos que o autor deste projeto provavelmente agiu como um desenvolvedor de software normal, então naturalmente devemos inspecionar o caribeapplication.cpp na pasta src. Beleza, vamos nessa :)

Beleza, então um monte de palavras desconhecidas para nós e um monte de nonsense. Vamos esclarecer as coisas então...

Primeiro, vamos discutir essa constante(0x10005B91). Qual é a porra do propósito dela? Bem, o tipo dela é TUid, que é definido como

Beleza, então basicamente um id. Mas por quê??? Sinceramente, não sei, mas quando você compila um app, você recebe um uuid. A parte interessante é que, se você pesquisar na internet sobre isso, verá que está sempre definido como parte do que é chamado de app .sis, que exploraremos mais tarde. Então, basicamente, isso é tipo a definição clássica de cabeçalho para um app no SymbianOS. Beleza, próximo. Vemos a função que nos interessa, que é CreateDocumentL.

Então....

E o que chamamos é CreateDocumentL

então criamos um documento... mas por quê...? Sinceramente, estou tão perdido quanto você, mas meu palpite é que, quando criamos um documento, basicamente criamos de alguma forma uma classe que nos permite interagir com a UI do app, já que derivamos dela o framework de UI.

E já que chamamos CreateDocumentL (acho que aqui neste exemplo sobrescrevemos a definição com nossa execução personalizada), onde temos a definição dela >?? Bem, acho que em CaribeDocument.h. Então, o que isso quer dizer???

Ok, legal, vemos naturalmente a função que nos interessa, newL, então vamos inspecionar o CaribeDocument.cpp

como podemos ver, acabamos chamando new L, que chama newLC, que chama constructL, e é só isso. Mas e a função CreateAppUiL de CEikAppUi? Bem

Então, vamos tentar entender isso. Basicamente, quando chamamos o construtor de CCaribeDocument, instanciamos um CEikApplication como documento. Esse CEikApplication é definido como

Então, o que eu acho que acontece aqui é que basicamente tentamos acessar a UI e então definimos uma classe que depois pode lidar com a interação com a UI usando CreateAppUiL. Beleza, então vamos inspecionar CCaribeAppUi.h/CCaribeAppUi.cpp

Então... não conseguiremos entender nada disso a menos que inspecionemos de quem ela herda, e isso é CAknAppUi.

Então vemos que

que inspecionamos mais a fundo para ver como é o CAknAppUi

que depois inspecionamos para ver ConstructL

o que me faz pensar que esta é uma função auxiliar que apenas finaliza o construtor, já que o construtor é deixado vazio. Beleza, então vamos cavar nisso

então, na primeira linha, vemos uma função chamada ErrMessage, definida em general.h como uma macro que exibe um diálogo de informações com as linhas de texto especificadas. Sabemos pelos relatos de como o Cabir se comportava que o malware sempre mostrava um popup com o nome. Ex:

Em seguida, vemos uma chamada a User::After, que porra isso faz? Bem, usei este livro 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 entender melhor e, se procurarmos, ele diz que é basicamente esperar um certo número de segundos; aqui são 10 seconds*10, o que dá uns 100 segundos (matemática rápida =)) skrr ra)

Em seguida, chamamos BaseConstructL, que basicamente inicializa a UI com ENoAppResourceFile passado como valor. Se cavarmos um pouco mais

e em seguida declaramos uma variável do tipo CaribeInstaller. Beleza, então vamos ver o que é isso

Então, inspecionamos o CaribeInstaller.cpp e vemos que é bem grande (foi o que ela disse :)) ). De qualquer forma, vou postar várias imagens, pois o código é bem extenso

Beleza, como é tão grande, vamos começar com a mais rápida para nos livrarmos dela, e essa é DOCRC16. Que só faz um crc16, imagino, com base no nome e no fato de ter uma tabela de substituição e tal.... para verificar a integridade do que foi escrito. Beleza, próximo

vemos um monte de defines com caminhos predefinidos e um monte de chamadas à macro _LIT? que porra a macro faz? A macro _LIT() usa um template de C++, então ela produz um tipo diferente para cada comprimento possível de string.

para citar (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)

Ahh, não posso esquecer de mencionar isso como IOC que temos até agora ```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"

Legal, a seguir analisamos a função CopyMeToAutostartableDir

então, a partir do código-fonte do malware, vemos que ele faz&#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.

Legal, então entre as primeiras coisas que ele faz está obter o nome do aplicativo, neste caso acho que será CARIBE, em seguida ele declara um buffer de 16 bytes que conterá a string ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.APP

converte o nome do aplicativo para letras maiúsculas e compara as duas strings. Em seguida, vemos uma variável chamada `fs` do tipo `RFs`. O que diabos é esse tipo? Bem, [https://journey.andreasjakl.com/paper/p04\_series60.php](https://journey.andreasjakl.com/paper/p04\_series60.php) diz que todas as aplicações definem um ponteiro para um objeto da classe `RFs` (que acessa o servidor de arquivos), então o framework chama automaticamente `Connect()` para que você possa começar a usá-lo sem criar sua própria instância deste objeto. Essa chamada faz parte da API do lado do cliente, que é implementada como uma biblioteca compartilhada e fornece acesso ao servidor

(NOTA: Por favor, veja isto, pois descobri mais tarde sobre este link, caso isto não seja 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))

basicamente isso nos permite ter acesso ao sistema de arquivos na conexão remota, pois em seguida vemos que fazemos &#x20;```cpp
User::LeaveIfError( .Connect());

se não conseguirmos conectar. O estranho é que vemos a chamada de API connect sem uma variável do tipo socket, mas acho que isso é específico deste caso do protocolo bluetooth(veremos depois qual protocolo está em uso)/ específico de como o app foi projetado

então criamos ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\

no telefone remoto conectado , chamamos 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 o próprio programa para&#x20;```cpp
C:\\SYSTEM\\SYMBIANSECUREDATA\\CARIBESECURITYMANAGER\\CARIBE.APP

então repetimos o mesmo procedimento, desta vez apenas copiamos o aplicativo para ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.RSC

and we then return from the function . Cool but why to C:\\\ directory and why to SYMBIANSECUREDATA? And what about the rsc file ? Well apprently if we inspect [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;

we get the answear files under the ‘SYMBIANSECUREDATA’ directory are not visible by default to users unless File Manager is installed

Kek but what about rsc file ?

Well on a symbianOs book this diagram shows us that

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

Um arquivo de recursos que define o título do aplicativo, o número de ícones e outras informações. Se pesquisarmos sobre o formato de arquivo .rsc, descobrimos que esses arquivos RSC são geralmente classificados como arquivos de dados que contêm recursos compilados e legíveis por máquina, convertidos do formato RSS para o formato binário. Eles consistem em um arquivo APP e um aplicativo Symbian concluído, o que permite aos desenvolvedores modificar os recursos do programa sem recompilar o APP.&#x20;

Então, eu tendo a concluir que aqui, acho eu, haverá ícones ou recursos diferentes.

Mas por que a unidade C:\\\? Bem, porque o Symbian OS adota uma convenção semelhante à do DOS, em que cada unidade é identificada por uma única letra&#x20;

A seguir, InstallMDL

&#x20;Seu objetivo&#x20;```cpp
This function will install the mdl file to the recogs directory.

Legal, então começamos novamente acessando o sistema de arquivos,obtendo o nome do aplicativo atualmente em execução, criando uma variável que contém as strings ```cpp C:\SYSTEM\RECOGS\FLO.MDL

E então vemos algo com o qual não estamos familiarizados, que é uma variável do tipo TParse.

Inspecionando a documentação, obtemos&#x20;

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

Próximo&#x20;```cpp
	TParse parser;
	parser.Set(OwnDllName,NULL,NULL);

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

	flodrivepath.Append(FLOMDL);

O que acontece aqui é que ele cria dinamicamente o caminho superior e achei que seria inútil explicá-lo (se você quiser investigar mais, use este link https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-E79A3B03-F8CB-37DB-A2A8-1C6C4E4D739A.html)

Em seguida, criamos este diretório ```cpp C:\SYSTEM\RECOGS\

e finalmente copie a string criada dinamicamente que aponta para o arquivo flo.mdl para C:\\\SYSTEM\\\RECOGS\\\\&#x20;

Legal, então o que há de tão interessante no arquivo mdl? E no diretório recogs? Bem, da Fortinet temos que a pasta "recogs" normalmente armazena programas conhecidos como "reconhecedores"

então, o que é um reconhecedor. Honestamente, não sei; tudo o que consegui encontrar foi isto: os tipos MIME são distinguidos no Symbian OS por reconhecedores .mdl (armazenados na pasta \System\Recogs) que fazem uso da extensão do arquivo e/ou do formato/estrutura dos dados contidos. Os aplicativos registram seu interesse em um determinado tipo MIME com um nível de prioridade especificado pelo seu autor em uma datatype\_list no arquivo .aif quando são instalados (consulte "Aiftool resource file format" na documentação do SDK C++ ou OPL). O aplicativo registrado que expressa a prioridade mais alta é usado pelo sistema para tentar abrir um documento de qualquer tipo MIME.

e isto: O Symbian OS Recogniser permite que MIDlets sejam reconhecidos como MIDlets pelo sistema.

então, basicamente nada.... Mas eu acho que, como tem a ver com tipos MIME, é sobre os ícones e coisas de 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)). E agora, e os arquivos mdl? Bem, do mesmo link obtemos que os reconhecedores de dados eram DLLs de plug-in com extensão `.mdl`, o que basicamente significa que é um plug-in que carrega um arquivo de imagem de mídia. Legal.

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

função de criação do arquivo sys tbd

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

Agora que entendemos o que cada função faz, voltamos para caribeappui.cpp e continuamos a analisar o fluxo de execução. Vemos que a última função de ConstructL é&#x20;```cpp
CaribeBluetooth::NewL();

E assim começamos nossa jornada em Cariblebt.cpp

então newL chama newLC, que chama constructorL, que chama RunL e define iState como 3. Agora o runL verifica o estado e, no nosso caso, como o definimos como 3 por padrão, acabamos executando FindDevices e ManageDevicesFound

FindDevices se parece com isto

Honestamente, não parece diferente de um scan usual de tcp, mas vamos nos aprofundar. Primeiro, porque esqueci, aqui está Cariblebt.h

Legal, então voltando à nossa função: definimos KL2Cap como string ou tipo BTLinkManager. Em seguida, verificamos se podemos criar um canal de comunicação IPC com um servidor de socket. Ok, espera aí, que diabos você está falando, cara? Honestamente, não sei, então vamos investigar. Temos então socketServ do tipo RsocketServ. Legal, e agora? >agora se pesquisarmos estritamente por essa classe(https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-EF29C1D7-B1E5-370F-AE37-66231A6BE449.html) obtemos exatamente o que eu disse: criamos um canal IPC. Mas por quê? Bom, com base no nome, posso imaginar que tem a ver com um socket. Agora, se inspecionarmos 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) descobrimos que ela fornece um endpoint de cliente para um protocolo. Ela fornece funções para criação, leitura e escrita de sockets

Agora, mais sobre este caso: se usarmos este link (https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-CED041C8-D68D-55D1-957E-1A48EEFFF851.html) vemos que é assim que funciona a consulta sobre dispositivos remotos no Symbian, ou seja, como fazer uma conexão bluetooth.

Engraçado que logo depois disso, a linha seguinte é exatamente como descrito no protocolo acima, ou seja, selecionar o protocolo a ser usado usando RSocketServ::FindProtocol()

E exatamente como dito antes, fazemos o que está descrito no documento acima: criar e inicializar um objeto RHostResolver.

Em seguida, definimos o TInquirySockAddr para descoberta geral, para podermos escanear por dispositivos

Em seguida, definimos o parâmetro do socket para consultas de endereço; configuramos o sinalizador KHostResInquiry

Então iniciamos a consulta usando GetByAddress e, se conseguirmos encontrar algum dispositivo bluetooth, receberemos um endereço único de 48 bits. O que acontece aqui é basicamente uma verificação simples para ver se há algum dispositivo bluetooth ao nosso redor.

Next we call ManageFoundDevices.

Verificamos se conseguimos obter um endereço e, se sim, chamamos Cancle(). Então criamos um endpoint/"conexão"(mas na verdade ainda não nos conectamos) para o endereço bluetooth, e ainda criamos uma variável do tipo TObexBluetoothProtocolInfo, que é usada para descrever informações de protocolo específicas do 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)

Agora, que diabos é um servidor Obex??? Pela sinopse ( 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) é um protocolo de comunicação que facilita transferências binárias entre dispositivos habilitados para Bluetooth. Legal, no nosso caso, como a classe TObexBluetoothProtocolInfo herda de TObexProtocolInfo, precisamos especificar o tipo de transporte para que o SymbianOS saiba qual protocolo usar, e no nosso caso é rfcomm. Então o que fazemos a seguir é basicamente definir com quem falar e em qual porta. E como a porta rfcomm é dinâmica, pode estar entre 0x1-30 e, neste caso, é 9. Então criamos uma conexão de cliente e nos conectamos a ela. Ok, então, hmm... o que acontece a seguir, já que não há sinal do que deve acontecer? Então... é.... Depois disso, retornamos e, como não há um while, acho que o mesmo processo de até agora se repete novamente. Só que agora, como já nos conectamos àquele dispositivo, nosso estado será 1 e, como estabelecemos uma conexão, chamamos put, que, se olharmos na Wikipedia, faz

PUT: o cliente envia um arquivo ao servidor; se for grande demais para caber em um único pacote, o servidor solicitará a próxima parte com uma resposta CONTINUE

Agora, como sabemos qual arquivo é o iCurrFile? Bem, minha teoria é que no início do arquivo temos a função CActive, que eu acho que atua como um gancho sempre que chamamos SetActive().

Então é isso, isto conclui a análise, obrigado por ler! Bom hacking :)

cabir_analysis

Mais Populares