description: Bluetooth-Worm:SymbOS/Cabir 解析

Bluetooth-Worm:SymbOS/Cabir 解析

読み始める前に、一つお知らせしておかなければなりません：ここに書いてあることは全て話半分に読んでください。私はSymbianOSの開発者には程遠く、SymbianOS環境に詳しいわけでもありませんから。

でも、なぜこんな古いものを解析するのかって？それは、リモートハッキングに入門する最も簡単な方法だからだ。最近はこういうことは100万ドル級のnday/0dayでやるものだからな🤑🤑🤑。そして、私にはまだそのレベルの専門知識がないからだ。

よし、前置きはこの辺にして本題に入ろう。Cabirって何だよ？ Symbian携帯電話で動作するBluetoothワームだ。Symbian phoneって何だよ、って思った人向けに説明すると、基本的には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)をインストールする

そして出来上がり、環境が手に入った :)

追記: windows 7を使う方がいい。どうやらwindows 10では動作が壊れて正常に動かないらしい

実環境での感染

TBD

このパートでは、携帯電話を脱獄(そう、聞き間違いじゃない、脱獄だ)する必要があることを知っておいてほしい。どうやってやるのかって？

リバースエンジニアリング解析

よし、これを一体どうやってコンパイルするんだ？実に良い質問だ。私がやったのは、まず caribe\group フォルダから ABLT.BAT を実行することだった。こんな感じで

よし、次にやることは、SDKがインストールされている場所に行き、プラットフォームフォルダ(私の場合はS60_3rd_fp1)を特定し、epoc32フォルダを見つけてbuidフォルダに行き、userフォルダ、ユーザー名フォルダ、そしてさらに2、3個のディレクトリを選ぶと、こんな感じのフォルダに辿り着くはずだ

これが現在のパスだ。おそらく君が辿り着くはずの場所とほぼ同じものになるはずだ(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ファイルを生成して、携帯電話にインストールできるようにする。なぜcaribeソースコードからsisファイルを作るのかって？基本的には、makesisにcaribe.pkgを指定する必要があるからだ。じゃあ、なんでそんな手間をかけてbuildなんとかフォルダまで辿り着くのかって？ -dパラメータに指定する必要があるからだ。それによって.sisファイルが生成される

よし、この方法は、この記事で参照しているsdk v3でのみ動作する。どうやら私が実験しているときに、Symbian専用のDiscordサーバーの開発者の一人が、cabirはsdk v2用にコーディングされていると指摘してくれた。だから、ここで紹介した方法は役に立たないかもしれない.....これは彼に連絡が取れ次第、追記する予定だ...彼は最近Discordであまりオンラインにならないので...

よし、.sisファイルは一体どうやってリバースエンジニアリングするのか？

簡単に言うと、.sisファイルはアーカイブだ。だから... siscontentsアプリケーションを使って解凍し、.appファイルをidaに放り込む。

アセンブリの観点

プロセス全体はこんな感じだ

それで、そのフォルダに入って、次に2つ進むとapp.appファイルを取得する

よし、それをidaに放り込むと

よし、つまり基本的にはARMのexeだ。マジでクール！次、どうぞ！うむ、是非とも~~~

ファイルにシンボルがあるぞ！！！まあ、何か変な理由でデバッグシンボル付きでバイナリをコンパイルしたから、運が良かったわけだ！

そして、基本的にコードを手に入れているので、リバースエンジニアリングのプロセスは、ソースコード解析の章で説明したものとほぼ同じだ:)

スニッフィングの観点

残念ながらこれはできない。計画ではFts4btを使うつもりだった。結構良さそうに見えたからだ(https://www.diva-portal.org/smash/get/diva2:24278/FULLTEXT01.pdf)

だが、どうやらその製品はEOL(サポート終了)に達しているらしい。もし偶然このパートができる人がいたら、DMを送ってほしい。この章を完成させるためにプルリクエストも送ってほしい

デバッガの観点

で、このセクションはどうするんだ！>>~> まあ、これが私の意見だ：USB経由でデバッガを接続して、ノキアの携帯電話上で直接コードをデバッグする方法を学ぶのは、私にとっても読者である君にとっても経験として価値があるだろう。だが、今のところは時間と労力がかかりすぎる(もうかなり疲れているんだ... ごめん、また今度にしよう)。これが無駄だと言えるもう一つの理由は、ソースコードと専用設計のSymbian IDEを持っているからだ。だから、こうしよう。Carbide++のデバッガを使って、1つか2つの関数を手短にデバッグする。これは読者でもできるはずだ。コードの流れはSCAセクションで説明したし、コードの解析を難しくするような暗号化やアンチ何とかといった手法もないからだ。それでは... 行こう！

正直なところ

ソースコード解析

よし、ソースコードにアクセスできるという事実を利用して、最大限に活用しよう。

私たちのディレクトリ構造はこんな感じだ。かなりきれいに整理されている

ではsrcフォルダを調べてみよう

私たちの旅はsrcフォルダ、正確にはcaribe.cppから始まる。なぜかって？かなりきれいに整理されているけど、一つ目立つのはcaribe.cppというファイルがあることだ。何か特別なのかって？いや、でも経験に基づく推測だけど、このケースでは29A(このマルウェアを開発したグループ)がソフトウェア開発者の古典的なアプローチに従ったんだろう。つまり、アプリのメインロジックはname_of_project.extensionに入れるというやつだ。よし、で、それはどんな風に見えるのかって？こうだ、若人よ

クールだが、これは何だ？正直、知らない。でもいくつか推測してみよう。名前だけで判断すると、CApaApplication is the main of this application. If we search this on google we see that

よし、で、次はどうする？？もっと掘り下げていこうぜ。CCaribeApplicationを調べてみよう。でも待って、CCaribeApplicationはどこにある？ CaribeApplication.hの中だ。それはどこだって？ incフォルダの中だよ、ブラザー。こんな感じだ

よし、こんな感じだ

クールだな。別のクラスから継承するクラスが定義されているのが見える。そして、CreateDocumentLというprotectedメソッドが見える。クールだが、特に面白いものはない。ああ、ここは俺のミスだ、兄弟！！

何だよ、このミスは！よくもまあ自分をマルウェアアナリストって呼べるな =))) 落ち着けよ、ファム！いや、だから、このプロジェクトの作者はおそらく普通のソフトウェア開発者のように行動したはずだ。だから当然、srcフォルダの中のcaribeapplication.cppを調べるべきだ。よし、やろうぜ:)

よし、見慣れない言葉の羅列と、でたらめの塊だ。少し明らかにしていこう...

まず、あの定数(0x10005B91)について話そう。その目的は何だよ？まあ、その型はTUidだ。次のように定義されている

よし、つまりほぼIDだ。でもなぜ？？？正直、分からない。だが、アプリをビルドするとuuidが得られる。面白いのは、これについてインターネットで検索すると、ほとんど常に.sisアプリと呼ばれるものの一部として定義されているのが分かることだ。これについては後で掘り下げる。つまり、基本的にこれはSymbianOS上のアプリの古典的なヘッダ定義みたいなものだ。よし、次。私たちが関心を持つ関数、CreateDocumentLが見える。

それで....

そして、私たちが呼ぶのはCreateDocumentLだ

つまりドキュメントを作成する... だが、なぜ...？正直、私も君と同じくらい迷っている。だが、私の勘では、ドキュメントを作成するとき、基本的には何らかの形でクラスを作成している。それによって、アプリのUIと何らかの形でやり取りできるようになる。なぜなら、基本的にそれをUIフレームワークから派生させているからだ。

そして、CreateDocumentLを呼び出すので(この例では、定義をカスタム実行で上書きしているのだと思う)、その定義はどこにあるのか？？まあ、CaribeDocument.hにあると思う。それで、それは何なのか？？？

よし、当然ながら興味のある関数newLが見える。CaribeDocument.cppを調べてみよう

見ての通り、最終的にnewLを呼び、それがnewLCを呼び、さらにconstructLを呼んでいる。それだけだ。でも、CEikAppUiのCreateAppUiL関数はどうなんだ？まあ

では、これを何とか理解してみよう。基本的に、CCaribeDocumentのコンストラクタを呼び出すとき、CEikApplicationをドキュメントとしてインスタンス化している。そのCEikApplicationは次のように定義されている

ここで起こっているのは、基本的にUIにアクセスしようとしているのだと思う。そして、後でCreateAppUiLでUIとのやり取りを処理できるクラスを定義している。よし、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を呼び出す。これは基本的に、値としてENoAppResourceFileを渡してUIを初期化する。少し掘り下げてみると

そして次に、CaribeInstaller型の変数を宣言している。よし、それが何なのか見てみよう

CaribeInstaller.cppを調べてみると、かなり大きいことが分かる(彼女もそう言ってたな :)) ) とにかく、ソースがかなり大きいので、複数の画像を掲載する

よし、かなり大きいので、まず手っ取り早いやつから片付けよう。それがDOCRC16だ。名前と、サブステーブルなどを持っている事実から判断すると、crc16を実行するだけだろう。書き込んだものの整合性をチェックするためのものだ。よし、次

定義済みパスを持つdefinesの羅列と、_LITマクロへの呼び出しの山が見える。このマクロは何をするんだよ？ _LIT()マクロはC++テンプレートを使うので、文字列の長さごとに異なる型を生成する。

引用元はこちら(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)

おお、まだ言及していなかったが、これまでに得た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 関数を分析します

つまり、マルウェアのソースコードから、それが行うのがわかります&#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.

なるほど。このアプリが最初に行うことの一つは、アプリの名前を取得することです。この場合、CARIBE になると思います。次に、その文字列を格納する 16 バイトのバッファを宣言します。 ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.APP

アプリ名を大文字に変換して、2つの文字列を比較します。次に、RFs型のfsという変数があります。その型はいったい何でしょうか。さて、[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))

基本的にこれにより、リモート接続上のファイルシステムのファイルにアクセスできるようになります。次に、私たちが次のようにしているのがわかります。&#x20;```cpp
User::LeaveIfError( .Connect());

接続できない場合。奇妙なのは、型がsocketの変数なしでconnect API呼び出しが見られることだが、これはこの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)) を呼び出して、プログラム自体を&#x20;にコピーします。```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/)を確認すると&#x20;

「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を再コンパイルすることなくプログラムリソースを変更できるようにします。&#x20;

ですから、ここにはおそらくアイコンやさまざまなリソースが含まれているのだろうと結論づけます。

しかし、なぜC:\\\ドライブなのでしょうか？それは、Symbian OSがDOS風の規則を採用しており、各ドライブが1つの文字で識別されるからです。&#x20;

次はInstallMDLです。

&#x20;その目的&#x20;```cpp
This function will install the mdl file to the recogs directory.

では、まず再びファイルシステムにアクセスし、現在実行中のアプリの名前を取得し、文字列を保持する変数を作成します ```cpp C:\SYSTEM\RECOGS\FLO.MDL

そして、見慣れないもの、つまりTParse型の変数が見えます。

ドキュメントを調べると、次のようになります。&#x20;

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

次&#x20;```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\\\\&#x20;にコピーします。

なるほど、では mdl ファイルと recogs ディレクトリの何が面白いのか？ Fortinet によると、"recogs" フォルダには一般に "recognizers" として知られるプログラムが格納されるらしい。

では、レコグナイザとは何なのか。正直なところ、私が調べた限りでは次のようなものしか見つからなかった。Symbian OS では、MIME タイプは .mdl レコグナイザ（\System\Recogs フォルダに格納されている）によって識別される。これらのレコグナイザは、ファイルの拡張子や、含まれるデータのフォーマット／レイアウトを利用する。アプリは、インストール時に、自分の .aif ファイル内の datatype\_list で作者が指定した優先度レベルで、特定の MIME タイプへの関心を登録する（C++ または OPL SDK ドキュメントの "Aiftool resource file format" を参照）。システムは、最も高い優先度を表す登録アプリを使用して、任意の MIME タイプのドキュメントを開こうとする。

そして、これも見つけた。Symbian OS レコグナイザは、MIDlet がシステムによって MIDlet として認識されることを可能にする。

まあ、大した情報ではないけど……。ただ、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 ファイルはどうなのか？ 同じリンクから、データレコグナイザは `.mdl` 拡張子を持つプラグイン DLL であり、つまりメディア画像ファイルを読み込むプラグインであることがわかる。なるほど。

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

create sys file 関数（未定）

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

これで各関数が何をするのかを理解したので、caribeappui.cpp に戻り、実行フローの解析を続けます。すると、ConstructL の最後の関数は&#x20;```cpp
CaribeBluetooth::NewL();

そして、私たちはCariblebt.cppでの旅を始める。

そこで newL は newLC を呼び出し、newLC は constructorL を呼び出し、constructorL は RunL を呼び出して iState を 3 に設定する。次に RunL が状態をチェックする。今回の場合、デフォルトで 3 に設定しているため、FindDevices と ManageDevicesFound を実行することになる。

FindDevices は次のようになる。

正直なところ、通常のTCPスキャンと何ら変わりがないように見えるが、掘り下げてみよう。まず、忘れていたので、ここに Cariblebt.h を示す。

よし、関数に戻ると、KL2Cap を文字列または BTLinkManager 型に設定する。次に、ソケットサーバーとの IPC 通信チャネルを作成できるかどうかを確認する。ちょっと待って、何言ってんだ？正直分からないので調査しよう。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 アドレスへのエンドポイント/"接続"(しかし、実際にはまだ接続しない)を作成し、さらに Bluetooth 固有のプロトコル情報を記述するために使用される TObexBluetoothProtocolInfo 型の変数を作成する(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サーバーとは一体何なのか？？？ 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) は、Bluetooth 対応デバイス間のバイナリ転送を容易にする通信プロトコルである。我々の場合、TObexBluetoothProtocolInfo クラスが TObexProtocolInfo を継承しているため、Symbian OS が使用するプロトコルを認識できるように、トランスポートの種類を指定する必要がある。我々の場合は rfcomm だ。そして次にやることは、基本的に誰と話すか、どのポートに対してかを設定することだ。rfcomm ポートは動的であるため、0x1-30 の範囲を取り得るが、この場合は 9 である。次にクライアント接続を作成し、それに接続する。さて、ええと、次に何が起こるのか、その兆候がない。だから……うん……。その後、戻り、while がないので、同じ処理が今までと同様にもう一度繰り返される。唯一違うのは、すでにそのデバイスに接続しているため、状態が 1 になり、接続が確立されているので put を呼び出すことだ。put が何をするかウィキペディアで調べると、次のようになる。

PUT: クライアントはサーバーにファイルを送信する。ファイルが単一のパケットに収まらないほど大きい場合、サーバーは CONTINUE 応答で次の部分を要求する。

さて、どのファイルが iCurrFile なのかをどうやって知るのか？私の理論では、ファイルの先頭に CActive 関数があり、それが SetActive() を呼び出すたびにフックとして機能するのではないかと思う。

というわけで、これで解析は終了だ。読んでくれてありがとう！楽しいハッキングを :)

cabir_analysis

人気