Symbian OS - mysterious playground for new malware

In the last year or two, an increasing number of Symbian threats have been reported. Some of these threats have exploited various services such as Bluetooth, MMS (Multimedia Messaging Service), etc. On the other hand, there are still not many professional malware writers who are interested in the Symbian OS. However, this might change in the near future. Even worse, adware/spyware companies may also involve themselves with the Symbian OS. Imagine if people have a hidden dialer on their handset, a keylogger that traces PINs or other sensitive information. Is the Symbian OS in danger of further attacks?

In June 2004, SymbOS/Cabir, the first Symbian worm to propagate via Bluetooth, was discovered (see VB, August 2004, p.4). This threat was a proof-of-concept worm without a payload.

In November 2004, another unpleasant name, became well known: SymbOS/Skulls. This overwrites many system files on the device. Although this threat contained nothing new from a technical point of view, it demonstrated that Symbian Installation System (SIS) files are a handy medium for attacks.

In January 2005, the first SIS file infector, SymbOS/Lasco.A, was discovered. This threat searches for SIS files on the device and appends itself to them.

In March 2005, SymbOS/Commwarrior.A, the first Symbian worm to propagate via MMS, was discovered (see VB, April 2005, p.4). Furthermore, this threat also attempted to disguise itself as a system kernel process, preventing other processes from changing its priority or terminating it.

Fortunately, these threats are not too complicated. Due to platform dependency and interactive requirements, they are also unlikely to become widespread in the real world. However, that doesn't mean we will be lucky forever. The question is what and when will the next Symbian threat appear.

There are many approaches that a threat might use to propagate itself, such as Bluetooth, MMS, email, SMS with malicious link, web browser, file infection, and vulnerable exploits. This article will focus on potential file infection and rootkit functionality. The Symbian OS is a fully object-oriented system. This might be one of the reasons why we have been lucky enough not to have seen any live virus so far. Unfortunately, it is still vulnerable to potential file infection that may cause more troubles.

There are three major executable formats:

Symbian E32 is unlike the Windows PE file format. There is no official specification available. Fortunately, Symbian has released the source code of PETRAN that translates PE-COFF format into E32 format. The following code is copied from PETRAN source code (see http://www.symbian.com/developer/downloads/ tools.html#SymbOSCppBt):

E32ImageHeader
{
public:
	TUint32 iUid1; 				// system UID
	TUint32 iUid2; 				// interface UID
	TUint32 iUid3; 				// program UID
	TUint32 iCheck; 			// checksum of the above UIDs
	TUint iSignature; 			// signature bytes: 'EPOC'
	TCpu iCpu; 					// type of CPU
	TUint iCheckSumCode; 			// sum of all 32 bit words
									// in text section
	TUint iCheckSumData; 			// sum of all 32 bit words
									// in data section
	TVersion iVersion; 			// version of PETRAN
	TInt64 iTime; 				// time and date the file was
								// created
	TUint iFlags; 				// 0 = exe, 1 = dll, +2 = no
								// call entry points
	TInt iCodeSize; 			// size of code, including
								// import address table,
								// constant data and export
								// address table
	TInt iDataSize; 			// size of initialised data
	TInt iHeapSizeMin; 			// min size of heap
	TInt iHeapSizeMax; 			// max size of heap
	TInt iStackSize; 			// size of stack
	TInt iBssSize; 				// size of un-initialised data
	TUint iEntryPoint; 			// offset into code of entry
								// point
	TUint iCodeBase; 			// where the code is linked for
	TUint iDataBase; 			// where the data is linked for
	TInt iDllRefTableCount; 		// number of imported DLLs
	TUint iExportDirOffset; 		// offset of the export
									// address table
	TInt iExportDirCount; 			// number of exported
									// functions
	TInt iTextSize; 			// size of the text section
	TUint iCodeOffset; 			// file offset to code section
	TUint iDataOffset; 			// file offset to data section
	TUint iImportOffset; 			// file offset to import
									// section
	TUint iCodeRelocOffset; 		// relocations for code and
									// const
	TUint iDataRelocOffset; 		// relocations for data
	TProcessPriority iPriority; 		// priority of this
										// process
};

E32 format has three checksum fields:

This check is simple; malicious programmers could easily patch the code and generate a new checksum.

The Symbian OS is based on the ARM architecture. It supports two types of instruction set: ARM (32-bit) and THUMB (16-bit). Each of them includes instructions to switch the processor state. All ARM instructions have a fixed length. If bit 0 of iEntryPoint is set, the program will be started in THUMB state, otherwise, it will be started in ARM state. All these features are extremely beneficial to polymorphism.

By default, the value of iEntryPoint is 0, which means that the code always starts from the beginning of the text section. However, it can also be redirected to other locations within the text section. When a program is launched, the kernel checks UIDs, signature bytes, type of CPU and the checksums, but it does not check the range of the sections. Obscured entry point, patched import table and many other traditional tricks may be used in the Symbian world.

Compared to the E32 executable image format, the E32 ROM image format is more compact. It uses physical addresses instead of relative virtual addresses. The code section, the export table and the data section will be mapped to specified addresses. The ROM image uses a DLL reference table instead of traditional import table, all API calls are invoked directly to the physical address. All these features make the ROM image more powerful.

Almost all existing Symbian threats use SIS files to propagate. Other than Trojans, Commwarrior and Lasco have already demonstrated that SIS files can easily be generated or patched on the fly. Furthermore, there is no check against the first DWORD (system UID) of a SIS file, which makes it more dangerous and may cause potential cross-platform infection.

The Symbian OS bootstrap process is as follows:

Figure 3. Symbian OS bootstrap process.

Unfortunately, processes after EFile.exe are unprotected. This may leave an opening for malicious code to increase its priority. Furthermore, there are many undocumented kernel APIs. By default, kernel calls are typically made through euser.dll. Euser.dll is responsible for handling direct user API requests and uses software interrupts to enter privileged mode. Kernel calls can also be made directly or indirectly. These hidden exports may also help malicious code to gain unauthorized control.

On the Windows platform, all running programs are locked by the system to prevent files from being modified by other processes. When a program is launched in Symbian, the kernel maps the file to memory and then releases it. This means that a virus can infect almost any executable file, regardless of whether it is running or not.

The kernel provides a virtual machine environment for user processes. The data of each process is mapped into the same virtual address range, 0x00400000 to 0x3FFFFFFF.

The Memory Management Unit translates only the virtual address of user data. User processes share the same map of ROM code. This may leave another opening for viruses or rootkits to hook into the system.

From version 6.0 of the operating system, several functions have been withdrawn. By default, the kernel no longer allows user programs to create remote threads. User programs must not use the E32 ROM image format, otherwise they will not be loaded and executed.

Does that mean we are safe? No. A file in E32 ROM image format can also be loaded from RAM. The SymbOS/Doomboot.A Trojan has demonstrated that. The kernel may load libraries from RAM instead of ROM. Malicious code may use a combination of exploits to hook into the system and infect or encrypt files.

Symbian OS is a very successful and powerful operating system for mobile devices. As the number of mobile devices in use continues to increase significantly, attempts to attack the Symbian OS may impact millions of users.

In theory, almost every type of attack might be found in the mobile world: stealing sensitive information, displaying fraudulent information, performing DDoS attacks, opening backdoor shells, starting hidden dialers, lowering security settings, firing dirty payloads, and so on.

Are we, as security professionals, ready to handle more complicated threats and various attacks?