Symbian OS - mysterious playground for new malware


Robert X Wang

Symantec, Ireland
Editor: Helen Martin


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?


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.

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 tools.html#SymbOSCppBt):

	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.


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.


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?



Latest articles:

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…

Dissecting the design and vulnerabilities in AZORult C&C panels

Aditya K Sood looks at the command-and-control (C&C) design of the AZORult malware, discussing his team's findings related to the C&C design and some security issues they identified during the research.

Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.