spiralbl0ck/cabir_analysis캐빈 부분 분석
description: Bluetooth-Worm:SymbOS/Cabir 분석
읽기 시작하기 전에, 공지 하나 할게 있음 : 여기 적힌 모든 내용은 그냥 걸러들어. 나는 SymbianOS 개발자도, SymbianOS 환경에 익숙한 사람도 전혀 아니니까.
그런데 왜 이렇게 오래된 걸 분석하는 거지? 음, 왜냐하면 이게 리모트 해킹에 입문하기 가장 쉬운 방법이기 때문이야. 요즘 이런 유형의 짓은 1백만 달러 가치의 ndays/0days로 이루어지거든 🤑🤑🤑. 그리고 나는 아직 그런 유형을 할 만한 전문성이 부족하고.
좋아, 이제 이 개꼴을 치웠으니 본론으로 들어가자. Cabir이 대체 뭐냐? 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)
그리고 짠, 환경이 준비됐어 :)
참고로 windows 7을 쓰는 게 좋아. windows 10에서는 뭔가가 깨지고 제대로 작동하지 않더라고.
실제 환경 감염
TBD
이 부분에서는 여러분의 휴대폰을 탈옥(그래, 네가 제대로 들었어, 탈옥)해야 한다는 걸 알아둬. 어떻게 하는 거지?
리버스 엔지니어링 분석
좋아, 그럼 대체 이걸 어떻게 컴파일하는 거야? 꽤 좋은 질문이야. 그래서 내가 한 건 caribe\group 폴더에서 먼저 ABLT.BAT를 실행한 거야, 이렇게.
좋아, 다음으로 우리가 할 일은 SDK가 설치된 곳으로 가서 플랫폼 폴더(내 경우 S60_3rd_fp1)를 식별하고, epoc32 폴더를 찾아 buid 폴더로 가서 user 폴더, username 폴더를 선택하고, 그다음 디렉토리를 두세 개 더 들어가면 이런 모양의 폴더에 도달하게 돼.
이게 현재 경로야. 대략적으로 너희가 있어야 할 위치와 비슷할 거야 (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이라는 파일이 있을 거야. 거기서 명령줄을 열고 실행하고 싶을 거야.
그래서 이게 뭘 하는 거냐고??? 음, 기본적으로 우리는 sis 파일을 생성하는 makesis를 실행한 거야. 그래야 폰에 설치할 수 있지. 그리고 왜 caribe 소스 코드에서 sis 파일로 하냐고? 음, 기본적으로 makesis에 caribe.pkg를 지정해야 하기 때문이야. 좋아, 그럼 왜 build 어쩌구 폴더까지 찾아가는 그런 수고를 하는 거지? 음, -d 파라미터에 그걸 지정해야 .sis 파일을 생성할 수 있기 때문이야.
좋아, 이 방법은 이 글에서 참조하는 sdk v3에서만 작동해. 분명히 내가 실험하는 동안 symbian 전용 discord 서버의 한 개발자를 만났는데, 그가 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)에 도달한 것 같아. 혹시 이 부분을 할 수 있다면 나에게 dm을 보내고 이 챕터를 완성하기 위해 pull request를 보내줘.
디버거 관점
그럼 이 섹션은 뭐냐!>>~> 음, 이에 대한 내 의견은 이래: usb를 통해 디버거를 연결하고 노키아 폰에서 직접 코드를 디버깅하는 방법을 배우는 것이 나와 너(독자)에게 경험이 될 만한 가치가 있긴 하지만, 지금 당장은 시간과 노력이 너무 많이 들어. (이미 꽤 지쳤거든... 미안, 다음 기회에.) 이게 쓸모없는 이유에 대한 또 다른 논거는 우리가 소스 코드와 특별히 설계된 symbian IDE를 갖고 있다는 거야. 그래서 우리가 할 일은 이거야. 우리는 Carbide++의 디버거를 사용해서 한두 개의 함수를 간단히 디버깅할 거야. 코드의 흐름은 sca 섹션에서 설명했고, 코드 분석을 어렵게 만드는 암호화나 안티-어쩌구 방법도 없기 때문에 독자가 직접 할 수 있어. 자... 가자!
솔직히
소스 코드 분석
좋아, 소스 코드에 접근할 수 있다는 사실을 활용해서 최대한 이득을 보자.
우리 디렉토리 구조는 이렇게 생겼는데 꽤 잘 정리되어 있어
자, src 폴더를 살펴보자
우리의 여정은 src 폴더, 정확히는 caribe.cpp에서 시작해. 왜냐고? 꽤 잘 정리되어 있긴 한데, 한 가지 눈에 띄는 게 caribe.cpp라는 파일이 있다는 거야. 뭔가 특별한 점이 있냐고? 아니, 그런데 나는 교육받은 추측으로 이 경우 29A(악성코드를 개발한 그룹)가 소프트웨어 개발자의 고전적인 접근 방식을 따랐다고 짐작했어. 앱의 주요 로직이 name_of_project.extension에 들어간다는 그 방식 말이야. 좋아, 그럼 이게 대체 어떻게 생겼냐고? 이렇게 생겼어, 젊은 피여
좋은데 이게 뭐냐? 솔직히 모르겠어. 하지만 추측을 좀 해 보자. 이름만으로 보면 CApaApplication은 이 애플리케이션의 메인이라고 추측할 거야. 이걸 구글에서 검색하면 이걸 보게 돼
좋아, 이제 뭐 어쩌라고?? 좀 더 파보자. CCaribeApplication을 살펴보자. 그런데 CCaribeApplication이 대체 어디 있지? CaribeApplication.h에 있어. 그게 어디냐고? inc 폴더에 있지, 브라더. 이렇게 생겼어
좋아, 이렇게 생겼어
좋아, 그래서 우리는 다른 클래스에서 상속되는 클래스가 정의되고 있고, CreateDocumentL이라는 protected 메서드가 보여. 좋아, 하지만 흥미로운 건 없어. 그래, 내 잘못이야, 이 녀석아!!
이게 무슨 실수야, yo! 그러면서 자신을 악성코드 분석가라고 부르는 거야? =))) 진정해, 팸! 아니, 그래서 우리는 이 프로젝트 작성자가 평범한 소프트웨어 개발자처럼 행동했을 거라고 했잖아. 그러니 자연스럽게 src 폴더에 있는 caribeapplication.cpp를 살펴봐야 해. 좋아, 가보자 :)
좋아, 우리에게 익숙하지 않은 단어들이 잔뜩 있고 말도 안 되는 것도 잔뜩 있네. 좀 알아보자...
먼저 그 상수(0x10005B91)에 대해 이야기해 보자. 그게 대체 무슨 용도지? 음, 그 타입은 TUid인데, 이렇게 정의되어 있어
좋아, 그냥 id 정도 되는 거지. 그런데 왜??? 솔직히 모르겠어. 하지만 앱을 빌드하면 uuid를 얻게 돼. 흥미로운 점은 인터넷에서 이걸 검색해 보면 거의 항상 .sis 앱이라고 불리는 것의 일부로 정의되어 있다는 거야. 나중에 살펴볼 거고. 기본적으로 이건 SymbianOS 앱의 전형적인 헤더 정의 같은 거야. 좋아, 다음. 우리가 관심 있는 함수인 CreateDocumentL이 보여.
그래서....
그리고 우리가 호출하는 건 CreateDocumentL이야.
그래서 우리는 문서를 생성해... 그런데 왜...? 솔직히 나도 너만큼 혼란스러워. 하지만 내 직감으로는 문서를 생성할 때 기본적으로 UI 프레임워크에서 파생했기 때문에 앱의 UI와 상호작용할 수 있게 해주는 클래스를 어떻게든 생성하는 것 같아.
그리고 우리가 CreateDocumentL을 호출하니까(이 예제에서는 사용자 지정 실행으로 정의를 덮어쓴 것 같아) 그 정의는 어디에 있을까>?? 음, CaribeDocument.h에 있을 거야. 그래서 그게 뭐냐고 ???
좋아, 당연히 우리가 관심 있는 함수 newL이 보이네. CaribeDocument.cpp를 살펴보자.
보시다시피 결국 newL을 호출하고, newL은 newLC를 호출하고, 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를 살펴보면 꽤 방대하다는 걸 알 수 있어(그녀가 그렇게 말했지 :)) ) 어쨌든 소스가 꽤 크니 이미지를 여러 개 올릴게.
.PNG)
.PNG)
.PNG)
.PNG)
.PNG)
.PNG)
.PNG)
좋아, 너무 크니까 빨리 처리할 수 있는 것부터 시작하자. 바로 DOCRC16이야. 이름과 subs 테이블 등을 가지고 있는 걸 보면 아마 crc16만 수행해서 자기가 쓴 내용의 무결성을 확인하는 것 같아. 좋아, 다음.
미리 정의된 경로를 가진 defines가 잔뜩 보이고 _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.
Cool 그래서 그가 가장 먼저 하는 것 중 하나는 앱의 이름을 가져오는 것입니다. 이 경우에는 CARIBE라고 생각합니다. 다음으로 16바이트 버퍼를 선언하는데, 그 버퍼에는 문자열이 포함될 것입니다 ```cpp C:\SYSTEM\SYMBIANSECUREDATA\CARIBESECURITYMANAGER\CARIBE.APP
앱 이름을 대문자로 변환하여 두 문자열을 비교합니다. 다음으로 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))
기본적으로 이를 통해 원격 연결에서 파일 시스템 파일에 액세스할 수 있습니다. 다음으로 우리가 수행하는 것을 볼 수 있습니다 ```cpp
User::LeaveIfError( .Connect());
연결할 수 없다면. 이상한 점은 socket 유형의 변수 없이 connect API 호출이 표시된다는 것이지만, 이는 이 블루투스 프로토콜 사례(나중에 어떤 프로토콜이 사용되는지 보게 될 것입니다)/ 앱이 설계된 방식에 특정한 것이라고 생각합니다.
그런 다음 우리는 생성합니다 ```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 파일은 어떨까?
음, symbianOs 책에서 이 다이어그램은 우리에게 다음을 보여줍니다.
<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" 폴더에는 일반적으로 "recognizer"로 알려진 프로그램들이 저장된다.
그렇다면 recognizer가 무엇일까? 솔직히 잘 모르겠다. 내가 찾을 수 있었던 것은 이뿐이다. Symbian OS에서 MIME 유형은 .mdl recognizer(\System\Recogs 폴더에 저장됨)에 의해 구분되며, 이 recognizer는 파일 확장자 및/또는 포함된 데이터의 형식/레이아웃을 사용한다. 앱은 설치될 때 .aif 파일의 datatype\_list에서 작성자가 지정한 우선순위 수준으로 특정 MIME 유형에 대한 관심을 등록한다(C++ 또는 OPL SDK 문서의 "Aiftool resource file format" 참조). 가장 높은 우선순위를 나타내는 등록된 앱은 시스템이 주어진 MIME 유형의 문서를 열려고 할 때 사용된다.
그리고 Symbian OS Recogniser는 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 파일은 어떨까? 같은 링크에서 데이터 recognizer는 `.mdl` 확장자를 가진 플러그인 DLL이었다는 것을 알 수 있다. 기본적으로 이것은 미디어 이미지 파일을 로드하는 플러그인이라는 뜻이다. 좋아.
\=============================================
create sys file 함수는 추후 결정
\=============================================
이제 각 함수가 무엇을 수행하는지 이해했으므로 caribeappui.cpp로 돌아가 실행 흐름을 계속 분석한다. ConstructL의 마지막 함수는 ```cpp
CaribeBluetooth::NewL();
그래서 우리는 Cariblebt.cpp에서 여정을 시작한다.
그래서 newL은 newLC를 호출하고, newLC는 constructorL을 호출하며, constructorL은 RunL을 호출하고 iState를 3으로 설정한다. 이제 runL은 상태를 확인하는데, 우리 경우에는 기본적으로 3을 설정했기 때문에 결국 FindDevices와 ManageDevicesFound를 실행하게 된다.
FindDevices는 이렇게 생겼다.
솔직히 일반적인 TCP 스캔과 크게 다르지 않아 보이지만, 좀 더 파고들어 보자. 먼저, 깜빡했는데 여기 Cariblebt.h가 있다.
좋아, 다시 우리 함수로 돌아와서, 우리는 KL2Cap을 string 또는 BTLinkManager 타입으로 설정한다. 다음으로 소켓 서버와 IPC 통신 채널을 만들 수 있는지 확인한다. 잠깐, 지금 뭐라는 거야? 솔직히 나도 모르겠으니 조사해 보자. 그래서 우리는 RsocketServ 타입의 socketServ를 얻는다. 좋아, 그런데 이제 뭐지? >이제 그 클래스를 정확히 검색해 보면(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에서 원격 장치를 조회하는 방법, 즉 블루투스 연결을 만드는 방법임을 알 수 있다.
재미있게도, 바로 다음 줄은 위의 프로토콜 문서에 설명된 것과 정확히 일치한다. 예를 들어 RSocketServ::FindProtocol()을 사용하여 사용할 프로토콜을 선택한다.
그리고 앞서 말한 대로, 위 문서에 설명된 것처럼 RHostResolver 객체를 생성하고 초기화한다.
그런 다음 TInquirySockAddr을 일반 검색(discovery)으로 설정한다. 그래야 장치를 스캔할 수 있다.
다음으로 주소 조회를 위해 소켓의 매개변수를 설정하는데, KHostResInquiry 플래그를 설정한다.
그런 다음 GetByAddress를 사용하여 쿼리를 시작한다. 블루투스 장치를 찾았다면 48비트 고유 주소를 반환받게 된다. 즉, 여기서 일어나는 일은 기본적으로 주변에 블루투스 장치가 있는지 확인하는 간단한 검사다.
다음으로 우리는 ManageFoundDevices를 호출한다.
주소를 얻었는지 확인하고, 얻었다면 Cancle()을 호출한다. 그런 다음 블루투스 주소에 대한 엔드포인트/"연결"을 생성한다(하지만 아직 실제로 연결하지는 않는다). 그리고 추가로 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 서버는 도대체 뭐지??? 시놉시스(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)는 블루투스 지원 장치 간 바이너리 전송을 용이하게 하는 통신 프로토콜이다. 좋아, 우리 경우에는 TObexBluetoothProtocolInfo 클래스가 TObexProtocolInfo를 상속하므로 symbianos가 어떤 프로토콜을 사용할지 알 수 있도록 전송 유형을 지정해야 한다. 우리 경우에는 rfcomm이다. 그래서 우리가 다음에 하는 일은 기본적으로 누구에게 말하고 어떤 포트로 말할지를 설정하는 것이다. rfcomm 포트는 동적이므로 0x1-30 사이일 수 있으며, 이 경우에는 9다. 그런 다음 클라이언트 연결을 생성하고 연결한다. 좋아, 그럼 다음에는 뭐가 일어날까? 일어날 일에 대한 표시가 전혀 없다. 그래서 음...... 그래.... 그 후 우리는 반환되고, while 루프가 없으므로 지금까지와 같은 과정이 다시 한 번 반복될 것이라고 추측한다. 다만 이제는 이미 그 장치에 연결했기 때문에 상태(state)는 1이 되고, 연결이 수립되었으므로 put을 호출한다. Wikipedia에서 확인해 보면 put은 다음과 같이 동작한다.
그럼 iCurrFile이 어떤 파일인지 어떻게 알 수 있을까? 내 이론은 이렇다. 파일 시작 부분에 CActive 함수가 있는데, 이 함수가 SetActive()를 호출할 때마다 훅(hook) 역할을 한다고 생각한다.
그래, 이걸로 분석을 마친다. 읽어줘서 고마워! 즐거운 해킹 되길! :)