April 13, 2010 at 9:17 am
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
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.
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
http://blog.fortinet.com/reversing-the-symbian-enoriv-malware/
