spiralbl0ck/cabir_analysiscabin частичный анализ
Прежде чем вы начнёте читать, я должен сделать объявление: ПОЖАЛУЙСТА, ВОСПРИНИМАЙТЕ ВСЁ, ЧТО ВЫ ЧИТАЕТЕ, СО ЗДОРОВЫМ СКЕПСИСОМ, ПОТОМУ ЧТО Я ВООБЩЕ НЕ РАЗРАБОТЧИК SymbianOS И НИКАК НЕ СВЯЗАН С ОКРУЖЕНИЕМ SymbianOS
Но зачем вообще анализировать что-то настолько старое? Ну потому что это самый простой способ войти в удалённый взлом, поскольку сейчас такое дерьмо делается с помощью ndays/0days стоимостью 1 млн 🤑🤑🤑. И потому что мне пока не хватает опыта для такого.
Окей, раз уж мы разобрались с этим дерьмом, поехали. Что такое Cabir? Это Bluetooth-червь, который работает на Symbian-телефонах. Для тех, кто понятия не имеет, что такое Symbian-телефон и всё такое. Ну, по сути, это телефон на ARM, так что ничего нового под солнцем :) Более краткая информация (https://en.wikipedia.org/wiki/S60_(software_platform))
Нам повезло, что исходный код этого был в открытом доступе (спасибо vxug) (SymbianOS.Cabir.7z). Теперь мы будем использовать это как справочник, но, честно, нафиг это. Одна из других причин, почему я это делаю, — я хочу поразбираться с ARM. Так что мы рассмотрим это с точки зрения исходников/ассемблера/эмулятора/отладки/сниффинга.
Окей, #1 Как, чёрт возьми, скомпилировать исходный код?
Ну, это не так уж сложно...
Сначала установите carbide ++(http://www.mediafire.com/file/6z54qrceef73x9s/Carbide_cpp_v2_7_en.exe/file)(из https://gist.github.com/artem78/cb2b9650af186844f7b5654964676284)
затем установите любой Perl-движок
затем установите nokia pc suite(https://www.usitility.com/nokia-pc-suite/)
установите SDK(http://www.mediafire.com/file/9uc7fjb2ynmxlud/s60v3.1_SDK.zip/file )
установите плагин c/c++ (https://ia800905.us.archive.org/7/items/nokia_sdks_n_dev_tools/s60_open_c_cpp_plug_in_v1_7_en.zip)
И вуаля, у нас есть окружение :)
P.S. лучше используйте Windows 7, так как на Windows 10, судя по всему, всё ломается и работает неправильно
Заражение реальной среды
TBD
Для этой части знайте, что вам нужно взломать (да, вы правильно услышали — джейлбрейк) ваш телефон. Как это происходит?
Реверс-инжиниринг
Окей, и как, чёрт возьми, это компилируется? Отличный вопрос. Итак, сначала я запустил ABLT.BAT из папки caribe\group вот так
Окей, дальше мы идём туда, где установлен SDK, находим папку платформы (S60_3rd_fp1) в моём случае, находим папку epoc32, заходим в папку build, выбираем папку user, папку с именем пользователя, а затем ещё два-три каталога, и вы должны оказаться в папке, которая выглядит так
Это текущий путь, который должен быть примерно похож на тот, где вы должны оказаться (C:\Symbian\9.2\S60_3rd_FP1\Epoc32\BUILD\Users\pwn\Desktop\CabirSourceCodes\caribe\group)
Окей, дальше нам нужно зайти в папку caribe (или как вы назвали исходный код), и вы найдёте папку с разными именами, как показано здесь
Что это значит? Ну, по сути, когда мы сначала запускаем ablt.bat (я до сих пор не знаю, зачем он нужен, но ладно), мы получаем разные варианты платформы для сборки нашего pkg-файла, из которого мы сгенерируем наш sis-файл. В данном случае мы видим GCCE и WINSCW. Если вы запустите команду ablt.bat build по умолчанию, она соберёт для WINSCW (это кодовое название платформы эмулятора). Для целей изучения компиляции исходников мы пока используем GCCE, но процесс тот же, если вы решите сделать, скажем, для ARM-платформы, чтобы загрузить его на телефон. То есть, в основном, ablt build arm_whatever, а затем выполняете те же шаги до этого места. Окей, теперь заходим в папку GCCE
Заходим в папку urel, и там должен быть файл caribe.app. Оттуда нужно открыть командную строку и запустить
И что это делает??? Ну, по сути, мы запускаем makesis, который генерирует sis-файл, чтобы мы могли установить его на телефон. А почему мы в sis-файле из исходников caribe? Ну, нам нужно было указать caribe.pkg для makesis. Окей, а зачем тогда все эти мучения, чтобы добраться до папки build, бла-бла-бла? Потому что нужно указать её в параметре -d, чтобы сгенерировать .sis файл.
Окей, этот метод работает только на SDK v3, о котором идёт речь в этом посте. Похоже, когда я экспериментировал, один разработчик из специального Discord-сервера по Symbian указал, что Cabir написан для SDK v2, и поэтому то, что я здесь показал, будет бесполезно..... это TBD, когда я смогу до него добраться... так как он сейчас редко бывает в Discord...
Окей, как реверс-инженерят .sis файл?
ПРОСТО. .sis файл — это архив. Итак... мы используем приложение siscontents, чтобы распаковать, а затем закидываем .app файл в ida.
С точки зрения ассемблера
Итак, весь процесс выглядит так
Итак, теперь мы заходим в эту папку, и далее получаем файл app.app
Окей, закидываем его в ida.
Окей, так что это, по сути, ARM exe. КРУТО, ЧЁРТ! ДАЛЬШЕ, ПОЖАЛУЙСТА! ХМ, ДА, ПОЖАЛУЙСТА ~~~
В файле есть символы, да!!! Ну да, поскольку по какой-то странной причине мы скомпилировали бинарник с отладочными символами, нам повезло!
И так, поскольку у нас по сути есть код и всё такое, процесс реверс-инжиниринга примерно такой же, как описанный в главе анализа исходного кода :)
Сниффинг
К сожалению, я не могу этого сделать, так как планировал использовать Fts4bt, поскольку видел, что он довольно неплох (https://www.diva-portal.org/smash/get/diva2:24278/FULLTEXT01.pdf)
но, судя по всему, продукт достиг конца жизненного цикла (EOL). Если вам случайно удастся сделать эту часть, пожалуйста, напишите мне в личку и сделайте pull request, чтобы завершить эту главу
Отладчик
Итак, ЧТО НАСЧЁТ ЭТОГО РАЗДЕЛА !>>~> Ну, вот моё мнение: хотя для меня и для вас (читателя) было бы полезно научиться подключать отладчик через USB и отлаживать код прямо на телефоне Nokia, сейчас это потребовало бы слишком много времени и усилий (я уже довольно устал... извините, может быть, в другой раз). Ещё один аргумент, почему это бесполезно, — у нас есть исходный код и специально разработанная Symbian IDE. Итак, вот что мы сделаем. Мы воспользуемся отладчиком из Carbide++, чтобы кратко отладить одну-две функции, и читатель сможет сделать это самостоятельно, так как поток кода был объяснён в разделе SCA, а также потому, что здесь нет шифрования или анти-всего, что могло бы затруднить анализ кода. Итак... Поехали!
если честно
Анализ исходного кода
Окей, давайте воспользуемся тем, что у нас есть доступ к исходному коду, и используем это по максимуму.
Итак, наша структура каталогов выглядит так, она довольно хорошо организована
Давайте заглянем в папку src
Наш путь начинается в папке src, а именно с caribe.cpp. Но почему? Потому что, хотя всё довольно хорошо организовано, бросается в глаза файл caribe.cpp. В нём есть что-то особенное? Нет, но я предположил по наводке, что в этом случае 29A (группа, разработавшая вредонос) следовала классическому подходу разработчиков ПО, когда основная логика приложения лежит в файле имя_проекта.расширение. Окей, и как это выглядит, чёрт возьми? Вот так, молодёжь
Клёво, но что это? Честно, не знаю, но давайте попробуем угадать. Основываясь только на имени, я предположу, что CApaApplication is the main of this application. If we search this on google we see that
Окей, и что дальше?? Давай копать глубже, чувак. Пойдём посмотрим на CCaribeApplication. Но где, блин, CCaribeApplication? В CaribeApplication.h. А это где? В папке inc, братан, которая выглядит так
Окей, выглядит это так
Клёво, мы видим класс, который наследуется от другого класса, и защищённый метод CreateDocumentL. Круто, но ничего интересного. Да, это моя ошибка, чувак!!
Какая ошибка, йо! И ты называешь себя аналитиком вредоносов =))) Спокойно, братан! Ну так вот, мы сказали, что автор проекта, вероятно, действовал как обычный разработчик, поэтому нам, естественно, следует посмотреть caribeapplication.cpp в папке src. Окей, погнали :)
Окей, куча неизвестных нам слов и бессмыслицы. Давайте немного проясним...
Сначала обсудим эту константу (0x10005B91). Каково её назначение? Ну, её тип — TUid, который определён как
Окей, то есть по сути это ID. Но зачем??? Честно, не знаю, но когда вы собираете приложение, вы получаете UUID. Интересная часть в том, что если поискать об этом в интернете, вы увидите, что он всегда определён как часть так называемого .sis приложения, которое мы рассмотрим позже. Так что это вроде классического определения заголовка для приложения на SymbianOS. Окей, дальше. Мы видим функцию, которая нас интересует, — CreateDocumentL.
Итак....
И мы вызываем CreateDocumentL
итак, мы создаём документ... но зачем...? Честно, я потерян не меньше вашего, но моё чутьё подсказывает, что когда мы создаём документ, мы каким-то образом создаём класс, который позволяет нам взаимодействовать с UI приложения, поскольку мы по сути наследуем его из UI-фреймворка.
И поскольку мы вызываем CreateDocumentL (думаю, в этом примере мы переопределяем определение своей собственной реализацией), где находится её определение?? Ну, я предполагаю, в CaribeDocument.h. Так что это такое???
Окей, мы видим функцию newL, которая нас интересует, так что давайте посмотрим CaribeDocument.cpp
как мы видим, мы в итоге вызываем new L, который вызывает newLC, который вызывает constructL, и на этом всё. Но что насчёт функции CEikAppUi CreateAppUiL? Ну
Давайте попробуем в этом разобраться. По сути, когда мы вызываем конструктор CCaribeDocument, мы создаём экземпляр CEikApplication как документ. Этот CEikApplication определён как
Я думаю, здесь происходит следующее: мы пытаемся получить доступ к UI, а затем определяем класс, который позже может обрабатывать взаимодействие с UI через CreateAppUiL. Окей, давайте посмотрим CCaribeAppUi.h/CCaribeAppUi.cpp
Итак... мы не сможем понять это, пока не посмотрим, от чего он наследуется, а это CAknAppUi.
Итак, мы видим, что
который мы далее изучаем, чтобы увидеть, как выглядит CAknAppUi
который мы затем изучаем через ConstructL
что заставляет меня думать, что это вспомогательная функция, которая просто завершает конструктор, поскольку сам конструктор пуст. Окей, давайте копнём
итак, первая строка — это функция ErrMessage, определённая в general.h как макрос, который показывает информационный диалог с указанными строками текста. Из отчетов о поведении Cabir мы знаем, что вредонос всегда показывал всплывающее окно с названием. Например
Дальше мы видим вызов User::After. Что это, чёрт возьми, делает? Ну, я использовал эту книгу из (http://staff.ustc.edu.cn/~dingqing/teach/project/mobile/(2006%20Wiley)Developing%20Software%20for%20Symbian%20OS%A3%BAAn%20Introduction%20to%20Creating%20Smartphone%20Applications%20in%20C%20Plus%20Plus.pdf), чтобы лучше понять, и если поискать, в ней говорится, что это по сути ожидание в течение n секунд. Здесь это 10 секунд*10, то есть примерно 100 секунд (быстрая математика =)) скрр ра)
Далее мы вызываем BaseConstructL, который по сути инициализирует UI с переданным значением ENoAppResourceFile. Если немного покопаться
и далее мы объявляем переменную типа CaribeInstaller. Окей, давайте посмотрим, что это такое
Итак, мы смотрим CaribeInstaller.cpp и видим, что он довольно большой (так и сказала она :)) ) В любом случае, я выложу несколько изображений, так как исходник довольно большой
.PNG)
.PNG)
.PNG)
.PNG)
.PNG)
.PNG)
.
.PNG)
Окей, раз он такой большой, начнём с быстрого, чтобы разобраться, — это DOCRC16. Судя по названию и тому, что там есть таблица subs и всё такое, он просто считает CRC16... чтобы проверить целостность того, что было записано. Окей, дальше
мы видим кучу define с предопределёнными путями и кучу вызовов макроса _LIT? Что за чёрт, что делает этот макрос? Макрос _LIT() использует шаблон C++, поэтому он создаёт разный тип для каждой возможной длины строки.
О, и не забыть упомянуть это как IOC, который у нас есть на данный момент ```cpp "C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.APP" "C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.RSC" "C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\" "C:\SYSTEM\RECOGS\FLO.MDL" "C:\SYSTEM\RECOGS\" "C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.SIS"
Итак, дальше мы проанализируем функцию CopyMeToAutostartableDir
итак, из исходного кода вредоносного ПО мы видим, что оно делает ```cpp
This function will copy the own dll of this application to
"C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.APP".
.mdl for autostart will start that application automaticly.
Круто, так что среди первых вещей, которые он делает, — получить имя приложения; в этом случае я думаю, это будет CARIBE. Далее он объявляет 16-байтовый буфер, который будет содержать строку```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.APP
приводит имя приложения к верхнему регистру и сравнивает две строки. Далее мы видим переменную с именем `fs` типа `RFs`. Что это вообще за тип? Итак, [https://journey.andreasjakl.com/paper/p04\_series60.php](https://journey.andreasjakl.com/paper/p04\_series60.php) там говорится: все приложения определяют указатель на объект класса `RFs` (который обеспечивает доступ к файловому серверу), затем каркас автоматически вызывает `Connect()`, так что вы можете начать использовать его без создания собственного экземпляра этого объекта. Этот вызов является частью клиентского API, который реализован как разделяемая библиотека и обеспечивает доступ к серверу.
(ПРИМЕЧАНИЕ: пожалуйста, учтите это, так как я позже обнаружил эту ссылку, если приведённое выше недостаточно сжато [https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source/reference/reference-cpp/F32\_EKA2/RFsClass.html#%3a%3aRFs](https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source/reference/reference-cpp/F32\_EKA2/RFsClass.html#%3a%3aRFs))
по сути, это позволяет нам получить доступ к файлам файловой системы при удалённом соединении; далее мы видим, что мы делаем ```cpp
User::LeaveIfError( .Connect());
если мы не можем подключиться. Странно то, что мы видим вызов API connect без переменной типа socket, но я думаю, это специфично для данного случая bluetooth-протокола(мы увидим позже, какой протокол используется)/ специфично для того, как было спроектировано приложение
мы затем создаем ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\
на удалённом подключённом телефоне, мы вызываем BaflUtils::CopyFile([https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source/reference/reference-cpp/BAFL/BaflUtilsClass.html#%3a%3aBaflUtils%3a%3aFileExists%28%29](https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source/reference/reference-cpp/BAFL/BaflUtilsClass.html#%3a%3aBaflUtils%3a%3aFileExists%28%29)) для копирования самой программы в ```cpp
C:\\SYSTEM\\SYMBIANSECUREDATA\\CARIBESECURITYMANAGER\\CARIBE.APP
затем мы повторяем ту же процедуру, только в этот раз мы копируем приложение в ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.RSC
и затем мы возвращаемся из функции. Круто, но зачем диск C:\\\ и зачем SYMBIANSECUREDATA? А что насчёт rsc-файла? Ну, судя по всему, если заглянуть в [https://www.virusbulletin.com/virusbulletin/2015/07/throwback-thursday-cabirn-fever-august-2004/](https://www.virusbulletin.com/virusbulletin/2015/07/throwback-thursday-cabirn-fever-august-2004/) 
мы получим ответ: файлы в каталоге «SYMBIANSECUREDATA» по умолчанию не видны пользователям, если не установлен File Manager
Кек, а что насчёт rsc-файла?
Ну, в книге по Symbian OS эта диаграмма показывает нам, что
<figure><img src="https://assets.kitploit.com/production/public/readmes/44345/9e576d96be08742edac009037f8eedf8b41767c116758c15068fecaef05b3c1b.png" alt=""><figcaption></figcaption></figure>
Ресурсный файл, который определяет заголовок приложения, количество значков и другую информацию. Если поискать о формате файла .rsc, мы узнаем, что эти RSC-файлы обычно классифицируются как файлы данных, содержащие скомпилированные и машиночитаемые ресурсы из формата RSS в двоичный формат. Они состоят из APP-файла и готового приложения Symbian, что позволяет разработчикам приложений изменять ресурсы программы без перекомпиляции APP. 
Так что я склонен заключить, что здесь, как я полагаю, будут значки или другие ресурсы.
Но почему диск C:\\\? Дело в том, что Symbian OS использует похожее на DOS соглашение, где каждый диск обозначается одной буквой 
Далее InstallMDL
 Его цель ```cpp
This function will install the mdl file to the recogs directory.
Круто, итак мы снова начинаем с доступа к файловой системе,получения имени текущего запущенного приложения, создания переменной, которая содержит строки ```cpp C:\SYSTEM\RECOGS\FLO.MDL
И затем мы видим то, с чем не знакомы — переменную типа `TParse`.
Изучая документацию, мы получаем
<figure><img src="https://assets.kitploit.com/production/public/readmes/44345/56b89fb3a4e9c3381dcdb8d8aa2c047712196ba8112be9f9afc28ff363055acd.png" alt=""><figcaption></figcaption></figure>
Далее```cpp
TParse parser;
parser.Set(OwnDllName,NULL,NULL);
TBuf16 <KMaxPath> flodrivepath(parser.DriveAndPath());
_LIT16(FLOMDL,"flo.mdl");
flodrivepath.Append(FLOMDL);
Что здесь происходит: динамически создается верхний путь, и я решил, что объяснять это бесполезно (если хотите изучить подробнее, воспользуйтесь этой ссылкой https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-E79A3B03-F8CB-37DB-A2A8-1C6C4E4D739A.html)
Затем мы создаем этот каталог ```cpp C:\SYSTEM\RECOGS\
и, наконец, скопируйте динамически созданную строку, которая указывает на файл flo.mdl, в C:\\\SYSTEM\\\RECOGS\\\\ 
Круто, и что же такого интересного в файле mdl и каталоге recogs? Ну, из Fortinet мы узнаём, что в папке «recogs» обычно хранятся программы, известные как «recognizers».
Итак, что такое recognizer? Честно говоря, не знаю; всё, что мне удалось найти, это: типы MIME в Symbian OS различаются с помощью .mdl recognizers (хранящихся в папке \System\Recogs), которые используют расширение файла и/или формат/расположение содержащихся данных. Приложения регистрируют свой интерес к определённому типу MIME с уровнем приоритета, указанным их автором в datatype\_list в их .aif-файле при установке (см. «Aiftool resource file format» в документации C++ или OPL SDK). Приложение, зарегистрированное с наивысшим приоритетом, используется системой для попытки открыть документ любого заданного типа MIME.
и вот это: The Symbian OS Recogniser позволяет системе распознавать MIDlets как MIDlets.
так что, по сути, ничего особенного.... Но, думаю, раз это связано с типами MIME, наверное, речь об иконках и GUI ([https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source//guide/Application-Framework-subsystem-guide/emime/recogs-framework.html#recogs%2dframework](https://docs.huihoo.com/symbian/s60-3rd-edition-cpp-developers-library-v1.1/GUID-35228542-8C95-4849-A73F-2B4F082F0C44/html/SDL\_93/doc\_source/guide/Application-Framework-subsystem-guide/emime/recogs-framework.html#recogs%2dframework)). А что насчёт файлов mdl? Ну, из той же ссылки мы узнаём, что распознаватели данных были подключаемыми DLL-библиотеками с расширением `.mdl` что по сути означает, что это плагин, который загружает файл медиаизображения. Круто
\=============================================
создать функцию sys file (TBD)
\=============================================
Теперь, когда мы понимаем, что делает каждая функция, мы возвращаемся к caribeappui.cpp и продолжаем анализировать поток выполнения. Мы видим, что последняя функция из ConstructL — это ```cpp
CaribeBluetooth::NewL();
Итак, мы начинаем наше путешествие в Cariblebt.cpp
Итак, newL вызывает newLC, который вызывает constructorL, который вызывает RunL и устанавливает iState в 3. Затем runL проверяет состояние, и в нашем случае, поскольку по умолчанию мы установили его в 3, в итоге выполняются FindDevices и ManageDevicesFound
FindDevices выглядит так
Честно говоря, это не выглядит иначе, чем обычное сканирование TCP, но давайте копнём глубже. Сначала, поскольку я забыл, вот Cariblebt.h
Круто, вернёмся к нашей функции: мы устанавливаем KL2Cap в строку или тип BTLinkManager, затем проверяем, можем ли мы создать IPC-канал связи с socket-сервером. Окей, погоди, о чём это я вообще? Честно, не знаю, так что давайте разбираться. Итак, у нас есть socketServ типа RsocketServ. Круто, и что дальше? > теперь, если поискать строго этот класс(https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-EF29C1D7-B1E5-370F-AE37-66231A6BE449.html), мы получим ровно то, о чём я говорил, — мы создаём IPC-канал. Но зачем? Теперь, судя по названию, могу предположить, что дело связано с сокетом. Теперь, если мы посмотрим на Rsocke(https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0.html#GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0), мы увидим, что он предоставляет клиентскую конечную точку для протокола. Он предоставляет функции для создания сокета, чтения, записи
Теперь подробнее по этой теме: если мы воспользуемся этим (https://docs.huihoo.com/symbian/nokia-symbian3-developers-library-v0.8/GUID-CED041C8-D68D-55D1-957E-1A48EEFFF851.html), мы увидим, что именно так работает запрос об удалённых устройствах в Symbian, то есть как установить Bluetooth-соединение.
Забавно, что сразу после этого следующая строка — это ровно то, что описано в приведённом выше протоколе, например, выбор используемого протокола с помощью RSocketServ::FindProtocol()
И, как уже говорилось ранее, мы делаем ровно то, что описано в приведённом выше документе, а именно создаём и инициализируем объект RHostResolver.
Затем мы устанавливаем TInquirySockAddr для общего обнаружения, чтобы можно было сканировать устройства.
Далее устанавливаем параметр сокета для запросов адресов: мы устанавливаем флаг KHostResInquiry
Затем мы запускаем запрос с помощью GetByAddress, и если нам удалось найти какие-либо Bluetooth-устройства, мы получим в ответ уникальный 48-битный адрес. Так что здесь, по сути, происходит простая проверка того, есть ли вокруг нас Bluetooth-устройства.
Далее мы вызываем ManageFoundDevices.
Мы проверяем, удалось ли получить адрес, и если да, вызываем Cancle(). Затем мы создаём конечную точку/«соединение» (но на самом деле мы там ещё не подключаемся) к Bluetooth-адресу и далее создаём переменную типа TObexBluetoothProtocolInfo, который используется для описания информации о 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)
Теперь что такое Obex-сервер??? Из обзора ( https://www.synopsys.com/software-integrity/security-testing/fuzz-testing/defensics/protocols/bt-obexs.html) OBject EXchange (OBEX)(https://en.wikipedia.org/wiki/OBject_EXchange) — это коммуникационный протокол, который обеспечивает двоичную передачу данных между устройствами с поддержкой Bluetooth. Круто. В нашем случае, поскольку класс TObexBluetoothProtocolInfo наследуется от TObexProtocolInfo, нам нужно указать тип транспорта, чтобы symbianos могла узнать, какой протокол использовать, в нашем случае rfcomm. Итак, дальше мы по сути задаём, с кем говорить и на каком порту. А поскольку порт rfcomm динамический, он может быть в диапазоне от 0x1 до 30, и в данном случае это 9. Затем мы создаём клиентское соединение и подключаемся к нему. Окей, эм... а что происходит дальше? Никаких признаков того, что должно произойти. Так что я...... да.... После этого мы возвращаемся, и, поскольку нет цикла, думаю, тот же процесс, что и до сих пор, повторяется снова. Единственное отличие: теперь, поскольку мы уже подключились к этому устройству, наше состояние будет 1, и, поскольку мы установили соединение, мы вызываем put, который, если заглянуть в Википедию, делает следующее:
Теперь как мы узнаем, какой файл является iCurrFile? Моя теория такова: в начале файла у нас есть функция CActive, которая, как я думаю, действует как перехватчик при каждом вызове SetActive().
Так что да, на этом анализ завершён, спасибо за чтение! Счастливого хакинга :)