Symbian OS - mysterious playground for new malware

2005-09-01

Robert X Wang

Symantec, Ireland
Editor: Helen Martin

Abstract

In the last year or two, an increasing number of Symbian threats have been reported. While there are not yet many malware writers who are interested in the Symbian OS, this may soon change. Robert Wang asks: is the Symbian OS in danger of further attacks?


Introduction

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?

Milestone

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.

Symbian OS image format

There are three major executable formats:

  • Symbian E32 executable image: a format used by normal user applications and dynamically loading link libraries.

    Symbian E32 ROM image: a format used by ROM image files only. There are some similarities between E32 executable image and E32 ROM image. The major difference is that E32 ROM uses physical addresses instead of relative virtual addresses. The kernel loads ROM images directly into the specified address.

    Symbian Installation System (SIS): a format used by the installation system. This is much simpler than the above formats.

E32 executable image header (0x7C bytes)
Code section Text section (code and constant data)
Import table
Export table
Data section (initialised data)
Import section
Code relocation section
Data relocation section

Figure 1. E32 executable image format.

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:

  • iCheck is the checksum of the top three UIDs.
  • iCheckSumCode is the sum of all 32-bit words in the text section.
  • iCheckSumData is the sum of all 32-bit words in the data section.

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.

E32 ROM image header (0x64 bytes)s
Code section Text section (code and constant data)
Data section (initialised data)
Export table
DLL reference table

Figure 2. E32 ROM image format

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.

Bootstrap

The Symbian OS bootstrap process is as follows:

Symbian OS bootstrap process.

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.

Runtime environment

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 '.data' section (initialised data) is mapped to 0x00400000; the '.bss' section (uninitialised data) is mapped right after the '.data' section.
  • ROM code is mapped into the range 0x50000000 to 0x57FFFFFF.
  • ROM export table is mapped into the range 0x58000000 to 0x5FFFFFFF.
  • RAM device driver is mapped into the range 0x60000000 to 0x7FFFFFFF.
  • ROM '.data' and '.bss' sections are mapped into 0x8XXXXXXX.
  • RAM code is mapped into 0xFFXXXXXX.

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.

Conclusion

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?

twitter.png
fb.png
linkedin.png
googleplus.png
reddit.png

 

Latest articles:

VB99 paper: Giving the EICAR test file some teeth

There are situations that warrant the use of live viruses. There are also situations where the use of live viruses is unwarranted. Specifically, live viruses should not be used when safer and equally effective methods can be used to obtain the…

Powering the distribution of Tesla stealer with PowerShell and VBA macros

Since their return more than four years ago, Office macros have been one of the most common ways to spread malware. In this paper, Aditya K Sood and Rohit Bansal analyse a campaign in which VBA macros are used to execute PowerShell code, which in…

VB2017 paper: Android reverse engineering tools: not the usual suspects

In the Android security field, all reverse engineers will probably have used some of the most well-known analysis tools such as apktool, smali, baksmali, dex2jar, etc. These tools are indeed must‑haves for Android application analysis. However, there…

VB2017 paper: Exploring the virtual worlds of advergaming

As adverts in gaming (‘advergaming’) ecosystems continue to become more sophisticated, so the potential complications grow for parents, children and gamers, who just want to play without having to worry about where their data is going (and how it is…

Distinguishing between malicious app collusion and benign app collaboration: a machine-learning approach

Two or more mobile apps, viewed independently, may not appear to be malicious - but in combination, they could become harmful by exchanging information with one another and by performing malicious activities together. In this paper we look at how…


Bulletin Archive