Find out the Bad guys on the Symbian

Find out the “Bad guys” on the Symbian Jie Zhang Fortinet Inc

Agenda 1 Symbian OS 2 Mobile Malware 3 Discover Virus 4 Identify Suspicious 5 Track Record 6 Conclusion 7 Thank You

What's Symbian? Symbian OS is a proprietary operating system, designed for mobile devices, with associated libraries, user interface frameworks and reference implementations of common tools, produced by Symbian Ltd.

Symbian OS History 1 EPOC 16 2 EPOC OS 1 -3 3 EPOC 4 4 EPOC 5 5 ER 5 U Symbian OS 5. 1 6 Symbian 6. 0 and 6. 1 7 Symbian 7. 0 and 7. 0 s 8 Symbian 8. x (EKA 1, EKA 2) 9 Symbian 9. 0 10 Symbian 9. 1 11 Symbian 9. 2 and 9. 3 12 Symbian 9. 5 1991 -1998 1997 1998 1999 2000 2001 2003 2004 2005 2006 2007

S 60 and UIQ The S 60 Platform UIQ by UIQ Technology

Mobile Malware 1 Symbian OS 2 Mobile Malware 3 Discover Virus 4 Identify Suspicious 5 Track Record 6 Conclusion 7 Thank You

About Mobile Malware • Concept: Mobile malware is an electronic virus that targets mobile phone and PDA. In fact, it is often of the few similar pieces of code or programs. • About: Today, there are more than 400 families of mobile malware. And we expect to see more and more of them in the near future. There are much more variants for some of the families, such as: Cabir, Comm. Warrior, Fontal, Skull, Cardtrap, and so on. Most of them are very similar.

Mobile Malware Category • Worm: Cabir, Mabir, Comm. Warrior, Card. Trap • Trojan / Backdoor / RAT: Flexispy, X-wodi, Pb. Stealer • Doom: Fontal, Drever, Skull • Misc: Infected virus, Exploit worm, WAP attacker or worm

Threat from Mobile Malware • Critical - Now, mobile becomes more and more important from individuals to business. Once mobile function was failed, our loss may be immeasurable. • Cost - Cell communications almost cause cost, such as: call, SMS/MMS, GPRS and so on. For widely spreading itself, malware will send them through one or more ways. That mean, each spread for the malware will bring the cell owner a terrible cost. • Sensitive - Today, people become to pay more attention to their own personal privacy. They often store many things on phone. Of course, there may be some private data. Once virus obtained the data, it will suffer to serious consequences.

Discover Virus 1 Symbian OS 2 Mobile Malware 3 Discover Virus 4 Identify Suspicious 5 Track Record 6 Conclusion 7 Thank You

Discover "Bad guys" • Abnormal behaviors • High cost • Suspicious process and file

Identify Suspicious 1 Symbian OS 2 Mobile Malware 3 Discover Virus 4 Identify Suspicious 5 Track Record 6 Conclusion 7 Thank You

Choose your weapon • Fix API name and dance with IDA • Extract SIS archive • Break into compressed application

Fix API name and dance with IDA - 1 As we know, the hardware platform of the mobile is less powerful than PC. And the memory for mobile is limited. In order to reduce the program file size, the API names will not be saved in the Import Address Table by the programs on Symbian platform, but just be imported with API order. As the result, we couldn’t obtain the invoked API names from the analyzing program. Therefore, we must improve the API examine system so that the IDA could correctly identify the API names used in the program.

Fix API name and dance with IDA - 2 For the acquisition of the API names, first of all, we must install Symbian SDK. In this paper, as we mainly search on the S 60 2 nd Symbian 7. 0 s, we need to download the S 60 2 nd SDK from the Nokia official website. Enter %S 60_SDK%Epoc 32releasearmiurel, and look up the current directory in the command mode. After inputing the command line, we will get the result.

Fix API name and dance with IDA - 3

Fix API name and dance with IDA - 4 For example: Get the API name for the "WAPP_1" functio in IDA. What does WAPP_1 mean? WAPP_1 = WAPP + 1 WAPP => Library Name 1 => Export Order

Fix API name and dance with IDA - 5 objdump –syms wapp. lib

Fix API name and dance with IDA - 6 Let's compile our received data: ID NAME VALUE 1 Module WAPP 2 Order 1 3 API New. L__22 CMsv. BIOWap. Access. Parser. R 20 CRegistered. Parser. Dll. R 15 CMsv. Server. Entry. R 3 RFs 4 Alias CMsv. BIOWap. Access. Parser: : New. L(CRegistered. Parser. Dll &, CMsv. Server. Entry &, RFs &)

Fix API name and dance with IDA - 7 Alternative method: ar 2 idt Library IDT efd zipids IDS

Extract SIS archive • • • You could get the Unsis tool from symbian official home page to extract the . SIS file on the PC And also, you could choose Un. Make. SIS to do the same thing, but it's a shareware and you should purchase it. For receiving more info, I wrote a tool sisdump to help us.

Break into compressed application - 1 • Sometimes, we will find that few applications could not be analyzed by IDA correctly.

Break into compressed application - 2 • Attempt to dump the application information with “petran” utility, you maybe get the similar following message: How to decompress it?

Break into compressed application - 3 • The correct answer is: Petran –nocompress <target file>

Reverse mobile malware - 1 • Except the basic ARM and Symbian OS knowledge, we must know how the function passes parameters: 1. System will use R 0 -R 3 to pass the parameters, generally speaking; 2. If there are more than 4 parameters, the other parameters will be passed by stack; 3. Class method (not static) will use R 0 to pass the class this pointer; 4. Return value uses R 0 register;

Reverse mobile malware - 2 • Dump IAT to know your enemy: Before analyzing the target sample, we’d better scan the IAT in the sample. We would know if the sample will execute on the file, bluetooth, infrared, network, SMS/MMS, and so on. I am not intending to describe this information further. For E 32 Image format, you could read related documents in reference. Use petran tool to get IAT information much more easily. I also create a utility that is called epocdep to do the same thing.

Reverse mobile malware - Comm. Warrior • We will start to analyze the sample in SIS file. • Receive SIS file information: We could get the file related information with sisdump. [!] ------------------------[!] File record type: Simple File [!] File type: [!] File to be run during installation and/or removal [!] Details: [!] Run during installation only Src name: commwarrior. exe Dst name: !: systemappsComm. Warriorcommwarrior. exe [!] ------------------------[!] File record type: Simple File [!] File type: [!] Standard File Src name: commrec. mdl Dst name: !: systemappsComm. Warriorcommrec. mdl

Reverse mobile malware - Comm. Warrior • There are some important things we should know: 1. The SIS archive includes two files: "commwarrior. exe" and “commrec. mdl"; 2. These two files will be installed to: !: systemappsComm. Warriorcommwarrior. exe !: systemappsComm. Warriorcommrec. mdl Note: "!" - mean user selected installation driver; 3. During installation, commwarrior. exe will be loaded and run;

Reverse mobile malware - Comm. Warrior • Reverse MDL 1. What’s MDL? MDL is a MIME recognizer Dynamic Library. 2. MDL Purpose: MDL is a plug-in code that can examine data in a file, or sample data supplied in a buffer, and return, if recognized, its data type. A data type is also commonly known as a MIME type. 3. Why most of malware include this file: Malware always intends to load itself with system boot time. That's the reason. 4. MDL Loads flow: Symbian OS MDL loader invokes order: <1> E 32 Dll(TDll. Reason) <2> Create. Recognizer() // Exported as entry point // Exported by MDL, order = 1

Reverse mobile malware - Comm. Warrior • Although the commwarrior. exe file will be running first, but I still intend to analyze MDL file in advance. Because the file is very easy to be understood and it will be launched when OS boots. • We have know that MDL has two exported functions, they are: E 32 Dll(TDll. Reason) Create. Recognizer() So, we will choose them to start our journel.

Reverse mobile malware - Comm. Warrior • E 32 Dll: Original assemble codes: . text: 10000000 start. text: 10000000. text: 100002 F 8 loc_100002 F 8. text: 100002 FC EXPORT start B 0 x 100002 F 8 ; CODE XREF: startj MOV BX R 0, #0 LR C++ codes: GLDEF_C TInt E 32 Dll(TDll. Reason /* a. Reason*/) { return KErr. None; }

Reverse mobile malware - Comm. Warrior • Create. Recognizer (order 1): . text: 100002 C 8 commrec_1. text: 100002 C 8. text: 100002 CC. text: 100002 D 0. text: 100002 D 4. text: 100002 D 8. text: 100002 DC. text: 100002 E 0. text: 100002 E 4. text: 100002 E 8 loc_100002 E 8. text: 100002 EC. text: 100002 F 0. text: 100002 F 4 EXPORT commrec_1 STMFD MOV BL SUBS BEQ MOV BL MOV new function, for CBase and its inherited class SP!, {R 4, LR} R 0, #0 x 128 CBase: : __nw(uint) R 4, R 0, #0 loc_100002 E 8 R 0, R 4 loc_10000004 R 4, R 0 class constructor call ; CODE XREF: start+2 D 8 j BL MOV LDMFD BX loc_10000068 R 0, R 4 SP!, {R 4, LR} LR virus core invoke

Reverse mobile malware - Comm. Warrior • After converting, we wil get the C++ source codes: EXPORT_C CApa. Data. Recognizer. Type * Create. Recognizer() { CApa. Data. Recognizer. Type * rg = new CMy. Recognizer(); // loc_10000004 do_exe_virus_body(); // loc_10000068 return rg; } // Or other format, if you like! EXPORT_C CApa. Data. Recognizer. Type * Create. Recognizer() { CApa. Data. Recognizer. Type * rg = new CMy. Recognizer(); // loc_10000004 CMy. Recognizer: : do_exe_virus_body(); // loc_10000068 There is no difference to return rg; analyst, right? }

Reverse mobile malware - Comm. Warrior • We will talk about class CMy. Recognizer later, for there is no harmful codes in the class. • Let’s see the do_exe_virus_body () function () first:

. text: 10000068 STMFD SP!, {R 4, R 5, LR}. text: 1000006 C SUB SP, #0 x 18. text: 10000070 MOV R 0, #4. text: 10000074 BL __builtin_new. text: 10000078 SUBS R 5, R 0, #0. text: 1000007 C LDRNE R 3, =0 x. FFFF 8001. text: 10000080 STRNE R 3, [R 5]. text: 10000084 ADD R 0, SP, #0 x 10. text: 10000088 LDR R 1, =a. Commrec. text: 1000008 C BL TPtr. C 16: : TPtr. C 16(ushort const *). text: 10000090 MOV R 3, #0 x 100. text: 10000094 STR R 3, [SP, #arg_0]. text: 10000098 STR R 3, [SP, #arg_4]. text: 1000009 C MOV R 4, #0. text: 100000 A 0 STR R 4, [SP, #arg_8]. text: 100000 A 4 MOV R 3, #1. text: 100000 A 8 STR R 3, [SP, #arg_C]. text: 100000 AC MOV R 0, R 5. text: 100000 B 0 ADD R 1, SP, #0 x 10. text: 100000 B 4 LDR R 2, =loc_100000 FC. text: 100000 B 8 MOV R 3, #0 x 2000. text: 100000 BC BL RThread: : Create(TDes. C 16 const &, int (*)(void *), int, void *, TOwner. Type). text: 100000 C 0 BL User: : Leave. If. Error(int). text: 100000 C 4 MOV R 0, R 5. text: 100000 C 8 MOV R 1, R 4. text: 100000 CC BL RThread: : Set. Priority(TThread. Priority). text: 100000 D 0 MOV R 0, R 5. text: 100000 D 4 BL RThread: : Resume(void). text: 100000 D 8 MOV R 0, R 5. text: 100000 DC BL RHandle. Base: : Close(void). text: 100000 E 0 B loc_100000 F 0. text: 100000 F 0 ADD SP, #0 x 18. text: 100000 F 4 LDMFD SP!, {R 4, R 5, LR}. text: 100000 F 8 BX LR void do_exe_virus_body() { RThread* boot. Thread = new RThread(); TPtr. C ptr(KTxt. Virus. Name); // and Start it User: : Leave. If. Error( boot. Thread->Create( ptr, Thread. Proc, 0 x 2000, 0 x 100, NULL, EOwner. Thread) ); boot. Thread->Set. Priority(EPriority. Normal); boot. Thread->Resume(); boot. Thread->Close(); }

TInt Thread. Proc(TAny * /* arg */) CActive. Scheduler: : Install(scheduler); { cleanup = CTrap. Cleanup: : New(); TRequest. Status r; // 4 if (!cleanup) { TTime tm; // 8 ret = 0 x. FFFFFFFC; RTimer timer; // 10 goto quit_proc; TInt ret; } timer. Create. Local(); TRAP(ret, exe_virus_body. L()); tm. Home. Time(); delete cleanup; tm += (TTime. Interval. Seconds)5; quit_proc: timer. At(r, tm); return ret; User: : Wait. For. Request(r); CActive. Scheduler * scheduler = new CActive. Scheduler; CTrap. Cleanup * cleanup; if (!scheduler) { ret = 0 x. FFFFFFFC; goto quit_proc; }

void exe_virus_body. L () { RFs a. Fs; User: : Leave. If. Error(a. Fs. Connect()); Cleanup. Close. Push. L(a. Fs); TFind. File a. Find. File(a. Fs); User: : Leave. If. Error( a. Find. File. Find. By. Dir( KTxt. Virus. App, KTxt. Null) ); CApa. Command. Line * a. Cmd. Line = CApa. Command. Line: : New. LC(); a. Cmd. Line->Set. Library. Name. L(a. Find. File()); a. Cmd. Line->Set. Command. L(EApa. Command. Open); RApa. Ls. Session a. Session; User: : Leave. If. Error(a. Session. Connect()); Cleanup. Close. Push. L(a. Session); User: : Leave. If. Error(a. Session. Start. App(*a. Cmd. Line)); Cleanup. Stack: : Pop. And. Destroy(3); }

Reverse mobile malware - Comm. Warrior • Although the class CMy. Recognizer is no useful here, but we still need to analyze it. Because there is a much more important concept we should know. That is vtable and vptr. • We will talk about more information based on the codes. • But first of all, let’s see some definitions.

class CBase { public: IMPORT_C virtual ~CBase(); inline TAny* operator new(TUint a. Size, TAny *a. Base); IMPORT_C TAny* operator new(TUint a. Size); inline TAny* operator new(TUint a. Size, TLeave); IMPORT_C TAny* operator new(TUint a. Size, TUint an. Extra. Size); protected: IMPORT_C CBase(); private: CBase(const CBase&); CBase& operator=(const CBase&); IMPORT_C static TAny* new. L(TUint a. Size); }; We found that all classes that is inherited from CBase contained at least one vptr and the first virtual function must be destructor.

class CApa. Data. Recognizer. Type : public CBase { // Notice: I have removed static and non-virtual methods for simplify public: IMPORT_C ~CApa. Data. Recognizer. Type(); IMPORT_C virtual TUint Preferred. Buf. Size(); IMPORT_C virtual TData. Type Supported. Data. Type. L (TInt a. Index) const = 0; private: IMPORT_C virtual void Do. Recognize. L(const TDes. C& a. Name, const TDes. C 8& a. Buffer); IMPORT_C virtual void Reserved_1(); protected: const TUid i. Type. Uid; const TInt i. Priority; TInt i. Count. Data. Types; TInt i. Confidence; TData. Type i. Data. Type; private: TInt i. Lock; TInt i. Spare; }; CApa. Data. Recognizer. Type variant: id name 1 vptr 2 i. Type. Uid 3 i. Priority 4 i. Count. Data. Types 5 i. Confidence … offset 00 04 08 0 C 10

The vptr is pointing to the vtable. The vtable structure is as following on the Symbian: struct vtable { DCD offset; DCD unknow; // unknow, but almost 0 DCD vfunc[]; // virtual function array }; The field of vtable. offset is used by compiler to calculate the object pointer from vptr, the fomula is: object pointer = vptr + vtable. offset

CMy. Recognizer class constructor. text: 10000004 STMFD SP!, {R 4, LR}. text: 10000008 MOV R 4, R 0. text: 1000000 C LDR R 3, = dword_10000564. text: 10000010 LDR R 1, [R 3]. text: 10000014 MOV R 2, #0. text: 10000018 BL CApa. Data. Recognizer. Type : : CApa. Data. Recognizer. Type(TUid, int). text: 1000001 C LDR R 3, = dword_100005 AC. text: 10000020 STR R 3, [R 4]. text: 10000024 MOV R 3, #1. text: 10000028 STR R 3, [R 4, #0 x. C]. text: 1000002 C MOV R 0, R 4. text: 10000030 B loc_1000003 C. text: 1000003 C loc_1000003 C ; CODE XREF: start+30 j. text: 1000003 C LDMFD SP!, {R 4, LR}. text: 10000040 BX LR . text: 100005 AC dword_100005 AC DCD 0, 0 ; DATA XREF: start: off_10000038�o. text: 100005 B 4 DCD loc_10000538 CMy. Recognizer: : ~CMy. Recognizer. text: 100005 B 8 DCD loc_10000044 CMy. Recognizer: : Preferred. Buf. Size. text: 100005 BC DCD loc_1000004 C CMy. Recognizer: : Supported. Data. Type. L. text: 100005 C 0 DCD locret_10000064 CMy. Recognizer: : Do. Recognize. L. text: 100005 C 4 DCD CApa. Data. Recognizer. Type: : Reserved_1(void)

• At last we got the C++ syntax source codes for constructor: const TUid My. Uid = {0 x 10001941}; CMy. Recognizer: : CMy. Recognizer(): CApa. Data. Recognizer. Type(My. Uid, 0) { i. Count. Data. Types=1; } • And also, we know the each virtual function entry point: . text: 100005 AC dword_100005 AC DCD 0, 0 ; DATA XREF: start: off_10000038�o. text: 100005 B 4 DCD loc_10000538 CMy. Recognizer: : ~CMy. Recognizer. text: 100005 B 8 DCD loc_10000044 CMy. Recognizer: : Preferred. Buf. Size. text: 100005 BC DCD loc_1000004 C CMy. Recognizer: : Supported. Data. Type. L. text: 100005 C 0 DCD locret_10000064 CMy. Recognizer: : Do. Recognize. L. text: 100005 C 4 DCD CApa. Data. Recognizer. Type: : Reserved_1(void)

Reverse mobile malware - Comm. Warrior • Okay! We have analyze the whole MDL file in Comm. Warrior sample. • How does exe file work? I think you could easily analyze it in this way. But you should notice that the exe file has a CRT stub. • For more information, please reference my paper • Let’s go on, guys!

Track Record 1 Symbian OS 2 Mobile Malware 3 Discover Virus 4 Identify Suspicious 5 Track Record 6 Conclusion 7 Thank You

Track "bad guys" record - 1 • • For static analysis, we can scan the IAT of target sample to find out which functions the malware used. And then we will do a full analysis with our favorite reversing tool. The advantage of this is that it identifies infections with high accuracy, but it requires analyst with good experience and knowledge. Of course, it also means more work and time. To speed up steps, we borrow the "sandbox" idea from the PC platform. That will help analyst to track the suspicious samples' action records in automatic way. It will enable us to get more details for the target.

Track "bad guys" record - 2 • Depend on large number of Symbian malware analysis, we found that some of the following actions needed us to focus on: 1. File operation 2. SMS/MMS/Bluetooth/Infrared 3. Process Changing 4. Telephone 5. Network Communication 6. Sensitive data 7. More

Conclusion • • • Powerful function is a double-edged sword. It gives you a tremendous benefit, and meanwhile, it also maybe harm to you. The war always exists, perhaps only the war would keep progress. Symbian Company also has found this point. They are strengthening their system security and making a big effort. Symbian v 9. x bring us dawn. This version is introducing a signed mechanism. All unsigned application will be limited to a security ring. But that does not mean the war is over. In fact, it's the beginning of a new war. In this no smoke battlefield, there is no always winner. We will keep up and ready for the next war coming.

Thank you! And any questions?