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:
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:
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:
uses the sms module
calls the built-in sleep function
calls the sms send function
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:
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
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.