Issuu on Google+

SMARTLINK A Tethering Solution by Smartcom


T-Mobile Tethering Software Project

 2

For ANDROID phones (Later for RIM/Blackberry, WIN MOBILE and others...)

REQUIREMENTS: • Tethering SW pre-installed on a device (mobile phone) • Application is launched from the device • Connects to the PC primarily via a regular USB cable (Wi-Fi and BT) • The proposed tethering SW will not allow any other Tethering SW to operate

CONFIDENTIAL 07/02/10 Confidential

Project Background, Goal & Solutions

 3


Smartcom has already developed several Tethering solutions for different mobile phones and OS’s. Smartcom analyzed multiple solutions and scenarios based on the requested specific T-Mobile Tethering solution.


The goal of this application is to check and kill 3 rd party tethering applications and not allow users to tether if they’re not subscribed to the TMobile Tethering plan.


Solutions we studied were focused on trying to monitor 3rd party applications based on the permission to access USB or Wi-Fi interfaces and to kill them if we detected them to be a tethering solution. This approach is complicated to control and ensure that we don’t kill any other application that is not doing tethering but still requires using these resources.

CONFIDENTIAL 07/02/10 Confidential

Conclusion and Proposition

 4

OUR CONCLUSION The best and safest approach to prevent tethering for users not subscribed to the service would be: To develop a specific application that has a blacklist of 3 rd party tethering applications to be killed if detected to be active, or trying to share the internet. Prior to killing the application, we will detect and determine if the application is indeed in the process of tethering, only then we will kill and not allow such applications to tether. HOW DOES IT WORK: We will develop an application that will monitor active processes in the phone. If the user is not subscribed to T-Mobile Tethering plan, we then search and if detect a blacklisted software, we monitor and kill the connection if the phone enters in a tethering mode. All blacklisted applications will reside also in our (Smartcom or T-Mobile) server. We will provide a specific “Live Update Mechanism” which will update the application with the latest blacklisted 3 rd party applications on a regular basis. The application should also be able to detect either via contacting operator’s server or reading the SIM card, whether user is subscribed to the tethering option; If the user is subscribed, then the application will not activate the blacklist killing process. We will need to define with T-Mobile and device manufacturers if this application should be embedded in the ROM of the device or as an Android App. If in ROM, difficult for user to delete/remove, but updates will be more complicated. If it is an Android app, then easier to update, but user can more easily remove it from the phone. CONFIDENTIAL 07/02/10


SMARTCOM proposition

Technical review

CONFIDENTIAL 07/02/10 Confidential

 5

Tethering Software Structure

 6




CORE TETHERING CONTROLLER is a background service which will manipulate tethering status of the phone to prevent or allow this feature for a given device. It will run in a root mode that brings us possibility to check states of all interfaces such as Bluetooth, WiFi and USB in order to check tethering status. This module will be based on Android NDK (C-based) which provides us possibility to use all low level features of Android OS. DATA ACCESS MODULE is responsible for communication with T-Mobile (or Smartcom) server for reading and writing all necessary data (tethering status, blacklist, configuration, etc.). It will run on user level and it will be implemented using Android SDK (Java-based). PRESENTATION MODULE will provide mobile phone user interface to show tethering status, configure application and blacklist, etc. It is an optional feature and it will not influence the core functionality. CONFIDENTIAL 07/02/10 Confidential

Requirements and Call Flow Charts

 7

To perform the main service installation task we have to rebuild Android OS in order to integrate our low level service to run it with root privileges on startup. Thus we may need to contact phone manufacturers to be able to create a special T-Mobile version of Android OS phones.

CALL FLOW: CORE TETHERING CONTROLLER will start right after the system startup and will perform such actions as reading the configuration, turning on/off the tethering feature on the device. After this work is done the controller will listen to all TCP messages to find another tethering application in the system. DATA ACCESS MODULE will start after “CORE TETHERING CONTROLLER” and will read the configuration from the server each 5 or…. minutes. After this module gets a new configuration from server, configuration will be stored on the device and the “CORE TETHERING CONTROLLER” will be notified through the pipe about the configuration changes. “CORE TETHERING CONTROLLER” behavior in this situation will be the same as in startup. PRESENTATION MODULE will run manually by the user. Using this module user can change some properties of tethering. After user makes some changes, it will be written to the configuration file and will notify “CORE TETHERING CONTROLLER” like the previous module. CONFIDENTIAL 07/02/10 Confidential


CONFIDENTIAL 07/02/10 Confidential

 8


CONFIDENTIAL 07/02/10 Confidential

 9


CONFIDENTIAL 07/02/10 Confidential

 10


CONFIDENTIAL 07/02/10 Confidential

 11

Detecting Tethering Application

 12

There are two ways to get tethering through Android OS phones: 1. Tethering using hardware configuration (need root permissions). We will use this way for our tethering program, it is cheapest and fastest, but users will not be able to use this option because they will not have root permissions. 2. Tethering using Proxy application installed on the phone. Detecting tethering application on the phone is detecting Proxy applications. We will implement a system which will find and block all types of proxies such as Socks4, Socks5 and HTTP proxy on the device. Finding HTTP proxy is simple: we have to look through http headers and find “Proxy header”. From this header we can find an application port and application PID, so we will know the application we have to kill. Socks5 and Socks4 proxy finding is more complicated than the HTTP proxy. We have to check all incoming TCP messages and see if they contain Socks5 or Socks4 messages. We propose to check from 5 to 10 messages in a row for a given port to be sure that this application works as proxy. To see if it is a Socks message, then we will compare a given message to messages that are described in Socks4 and Socks5 RFCS. Links: CONFIDENTIAL 07/02/10 Confidential

 13

SMARTCOM proposition

Q&A and next steps



Tethering solution by Smartcom