Showing posts with label Android Market. Show all posts
Showing posts with label Android Market. Show all posts

Tuesday, October 11, 2011

Accelerometer Values App Demo

The accelerometer sensor is meant to simulate the acceleration forces like the speed changes that you see while playing games on phones. The values returned by the accelerometer for each axis range between (+/-)0–10. Let's see how to design this app. With three axes in our co-ordinate system, we will need 6 text fields to display 6 different values for (+/-) X, Y and Z axes.


<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
       android:orientation="vertical" android:layout_width="fill_parent"
       android:layout_height="fill_parent" android:layout_gravity="center"
       android:background="@android:color/white">
       <TextView android:layout_width="match_parent" android:text="@string/x_axis"
              android:layout_height="wrap_content" android:gravity="center"
              android:textSize="25sp" android:padding="10dip" android:textColor="@android:color/black" />
       <LinearLayout android:id="@+id/x_axis"
              android:layout_width="match_parent" android:layout_height="wrap_content"
              android:background="@android:color/black">
              <TextView android:text="X-AXIS (+)ve:" android:layout_width="wrap_content"
                     android:id="@+id/txtSensorValueLeft" android:textSize="30dip"
                     android:layout_weight="1" android:layout_height="wrap_content"
                     android:gravity="left">TextView>
              <TextView android:layout_width="wrap_content" android:text="X-AXIS (-)ve:"
                     android:textSize="30dip" android:layout_weight="1"
                     android:id="@+id/txtSensorValueRight" android:layout_height="wrap_content"
                     android:gravity="right" />
LinearLayout>

Here, we have laid out a single TextView to display the axis name, followed by two text views to display the positive and negative values of the axis, repeated for Y and Z axes.

<TextView android:layout_width="match_parent" android:text="@string/y_axis"
              android:layout_height="wrap_content" android:gravity="center"
              android:textSize="25sp" android:padding="10dip" android:textColor="@android:color/black" />
       <LinearLayout android:id="@+id/y_axis"
              android:layout_width="fill_parent" android:layout_height="wrap_content"
              android:orientation="vertical" android:gravity="center"
              android:background="@android:color/black">
              <TextView android:layout_width="fill_parent" android:text="Y-AXIS (+)ve:"
                     android:layout_height="wrap_content" android:textSize="30dip"
                     android:layout_weight="1" android:id="@+id/txtSensorValueUp"
                     android:gravity="center" />
              <TextView android:layout_width="fill_parent" android:text="Y-AXIS (-)ve:"
                     android:layout_height="wrap_content" android:textSize="30dip"
                     android:layout_weight="1" android:id="@+id/txtSensorValueDown"
                     android:gravity="center" />
       LinearLayout>
       <LinearLayout android:layout_width="match_parent"
              android:layout_height="wrap_content" android:background="@android:color/black"
              android:padding="5dip">
       LinearLayout>
       <TextView android:layout_width="match_parent" android:text="@string/z_axis"
              android:layout_height="wrap_content" android:gravity="center"
              android:textSize="25sp" android:padding="10dip" android:textColor="@android:color/black"/>
       <LinearLayout android:id="@+id/z_axis"
              android:layout_width="fill_parent" android:layout_height="wrap_content"
              android:orientation="vertical" android:background="@android:color/black">
              <TextView android:layout_width="wrap_content" android:text="Z-AXIS (+)ve"
                     android:layout_height="wrap_content" android:textSize="30dip"
                     android:layout_weight="1" android:id="@+id/txtSensorZValueUp" />
              <TextView android:layout_width="wrap_content" android:text="Z-AXIS (-)ve"
                     android:layout_height="wrap_content" android:textSize="30dip"
                     android:layout_weight="1" android:id="@+id/txtSensorZValueDown" />
LinearLayout>

After laying out the UI, we have to actually get access to the sensor and display the values it returns. First, we need to reference the UI widgets in our Java class, so we declare variables for each:

private SensorManager mSensorManager;
       private Sensor mAccelerometer;
       private TextView mSensorValuesLeft;
       private TextView mSensorValuesRight;
       private TextView mSensorValuesUp;
       private TextView mSensorValuesDown;
       private TextView mSensorValuesZUp;
       private TextView mSensorValuesZDown;

Next, we need to reference them in our Java class; this can be done with the following code.

       /** Called when the activity is first created. */
       @Override
       public void onCreate(Bundle savedInstanceState) {
              super.onCreate(savedInstanceState);
              setContentView(R.layout.main);

              mSensorValuesLeft = (TextView) findViewById(R.id.txtSensorValueLeft);
              mSensorValuesRight = (TextView) findViewById(R.id.txtSensorValueRight);
              mSensorValuesUp = (TextView) findViewById(R.id.txtSensorValueUp);
              mSensorValuesDown = (TextView) findViewById(R.id.txtSensorValueDown);
              mSensorValuesZUp = (TextView) findViewById(R.id.txtSensorZValueUp);
              mSensorValuesZDown = (TextView) findViewById(R.id.txtSensorZValueDown);

The basic classes that we use to access sensors are: SensorManager, Sensor, SensorListener and SensorEvent. The SensorManager class provides an app the ability to access sensors and interact with them. The Sensor class is the model class for sensors, and provides the basic API to get values from the underlying sensor. The SensorListener class is a listener class (like a button onClick listener). It allows the app to register itself with the listener, to receive notifications of changes on the sensors, with the new values. The SensorEvent class interacts with the sensors, and has some basic methods that access sensors and retrieve data in case of any event or change.

Sensors are provided by the system service, so first we have to claim the sensor service from the system service with the following code:

              mSensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);

Now let's go ahead and use the above to implement our app:

mAccelerometer = mSensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER);
mSensorManager.registerListener(this, mAccelerometer,
                           SensorManager.SENSOR_DELAY_UI);

We start by getting hold of the sensor the using getDefaultSensor() method, which returns the default sensor for the type passed as a parameter. We requested Sensor.TYPE_ACCELEROMETER. After getting the sensor, we register our app with the sensor listener, to be able to listen to changes detected by the sensor, with RegisterListener(). SensorManager.SENSOR_DELAY_UI represents the delay in listening to sensor events. This constant specifies listening at speeds normal for a User Interface, because continuous listening to sensors drains battery very quickly. Other constants are SensorManager.SENSOR_DELAY_FASTEST, SensorManager.SENSOR_DELAY_NORMAL, and SensorManager.SENSOR_DELAY_GAME, whose purposes are obvious.

@Override
       public void onAccuracyChanged(Sensor sensor, int accuracy) {
              /*
               * You could have values defined for x, y and z axes and add these
               * values to the original values while using it in your app
               */
       }

       @Override
       public void onSensorChanged(SensorEvent event) {

       }

There are two methods that need to be overridden: onAccuracyChanged() and onSensorChanged(). The first is used to calibrate the sensor if wanted (you implement it if you want a custom calibration, not the default). OnSensorChanged() is invoked every time a change is detected by the sensor. The SensorEvent parameter will hold the values for all three axes.

@Override
       public void onSensorChanged(SensorEvent event) {
              if (event.sensor.getType() != Sensor.TYPE_ACCELEROMETER)
                     return;
              // X-axis
              if (event.values[0] > 0) {
                     mSensorValuesLeft.setText("X-axis (+)ve: "
                                   + Integer.toString((int) event.values[0]));
              } else if (event.values[0] < 0) {
                     mSensorValuesRight.setText("X-axis (-)ve:: "
                                  + Integer.toString(((int) event.values[0]) * -1));
              }

              float y = event.values[1];
              if (y > 0) {
                     mSensorValuesUp.setText("Y-axis (+)ve: "
                                  + Integer.toString((int) y));
              } else {
                     mSensorValuesDown.setText("Y-axis (-)ve: "
                                  + Integer.toString((int) y * -1));
              }

              float z = event.values[2];
              if (z > 0) {
                     mSensorValuesZUp.setText("Z-axis (+)ve: "
                                  + Integer.toString((int) z));
              } else {
                     mSensorValuesZDown.setText("Z-axis (-)ve: "
                                  + Integer.toString((int) z * -1));
              }
       }

The logic is very simple: the SensorEvent variable is an array holding 3 values corresponding to the X axis (element 0) to Z axis (element 2) respectively. We use simple if-else logic to set the values to their corresponding TextViews, If the value is positive then assign it to the positive value of axis otherwise set the negative value of axis. The negative value is multiplied by (-1) so that it will be displayed as a (+)ve value for (-)ve axis.

@Override
       protected void onPause() {
              // TODO Auto-generated method stub
              super.onPause();
              mSensorManager.unregisterListener(this);
       }

       @Override
       protected void onResume() {
              // TODO Auto-generated method stub
              super.onResume();
              mSensorManager.registerListener(this, mAccelerometer,
                           SensorManager.SENSOR_DELAY_UI);
       }

       @Override
       protected void onStop() {
              // TODO Auto-generated method stub
              super.onStop();
              mSensorManager.unregisterListener(this);
       }

As discussed earlier, we should not be listening to sensors all the time, because it could lead to serious battery drain—so we register in onResume() and un-register in onPause() and onStop(). Now, we can extend this app by showing a list of sensors that when a user clicks one, the respective sensor demo app is opened. To accomplish the above task, I will create another activity, and show a list of sensors supported by the device. 

mSensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);
              mSensorList = mSensorManager.getSensorList(Sensor.TYPE_ALL);
              ArrayList mSensorNames = new ArrayList();

              for (Sensor sensor : mSensorList) {
                     mSensorNames.add(sensor.getName());
              }

              adapter = new ArrayAdapter(MainListActivity.this,
                           android.R.layout.simple_list_item_1, mSensorNames);
              setListAdapter(adapter);

Here, we get the instance of the Sensor service, and then get a list of available sensors using the SensorManager method getSensorList(). We then set up an adapter for the list, and display it to the user.
Enhanced by Zemanta

Monday, August 8, 2011

Vulnerability Found In Android That Allows For Phishing Scams and Pop-up Ads


You hated them on your PC and now those annoying pop-up ads and phishing attempts could find their way into an Android device near you. This year at Defcon 19 (a hacking conference held every year in Las Vegas) a couple of researchers managed to find a vulnerability in Android that could allow for apps in the Android Market to steal a users data via phishing or by be used by advertisers to bring the most annoying idea of the 21st century, pop-up ads.
Apparently, it’s possible for someone to create an app that will display a fake bank app log-in page while the user is using a legitimate banking app. Currently, apps that want to communicate with a user while a different apps is being used can only push an alert to the notification bar. But in the Android Software Development Kit (SDK) there is an application programming interface that allows for an app to be pushed into the foreground while another is being used.
The guys over at Trustwave have named this issue as Focus Stealing Vulnerability. Sean Schulte, an SSL developer at Trustwave explained how, “Android allows you to override the standard for (hitting) the back buttons.” Nicholas Percoco, senior vice president and head of SpiderLabs at Trustwave further explained that, “Because of that, the app is able to steal the focus and you’re not able to hit the back button to exit out.”
To further expose this issue, the researchers even created a proof-of-concept tool that is a game but also triggers fake displays for Facebook, Amazon, Google Voice and Gmail. They demoed the tool by showing a user opening up a legitimate app and then almost instantaneously, a “fake” login screen for Facebook appears. Percoco further explains, “With this design flaw, game or app developers can create targeted pop-up ads. The ads could be merely annoying, like most pop-ups are, but they could also be targeted to pop up an ad when a competitor’s app is being used.”
If you think you could avoid these apps by simply reading over the permissions page for a particular app, you would be mistaken. This kind of pop-up functionality is found in many legitimate apps and is known as an Activity Service.
Google has addressed this issue by stating the following,
“Switching between applications is a desired capability used by many applications to encourage rich interaction between applications. We haven’t seen any apps maliciously using this technique on Android Market and we will remove any apps that do.”
Nicholos Percoco responded by saying,
“Application switching is not the issue. The real issue is ability for other apps to identify which app is in the foreground and then decide to jump in front of that running app without the user giving it permission to do so. We also don’t see how they could determine the difference between a malicious app or a legitimate one since they would both look almost identical until a user reports it to them as malicious. The ‘wait until an app is reported bad before removing’ stance is dangerous and will likely prove out to be a fruitless effort as attackers could post apps much faster than Google could identify and remove them from the Market.”
I will now turn this to our readers. How does the potential of pop-up ads and phishing scams coming out of the Android Market sound to you? I’m not so sure Google’s statement is enough peace for me. Do you feel like Google needs to do more to address and further prevent this exposed Android “design flaw?”

Enhanced by Zemanta

Android App Turns Smartphones Into Mobile Hacking Machines


Dangerous hacks come in small packages.
Or they will, perhaps, when an app called Anti, or Android Network Toolkit, hits the Android market next week. The program, which Israeli security firm Zimperium revealed at the Defcon hacker conference in Las Vegas Friday and plans to make available to Android users in coming days, is designed for penetration testing–in theory, searching out and demonstrating vulnerabilities in computer systems so that they can be patched. Anti aims to bring all the hacking tools available to penetration testers on PCs to smartphones, with an automated interface intended to make sniffing local networks and owning remote servers as simple as pushing a few buttons.
“We wanted to create a penetration testing tool for the masses, says Itzhak “Zuk” Avraham, founder of Tel-Aviv-based Zimperium. “It’s about being able to do what advanced hackers do with a really good implementation. In your pocket.”
Anti, a free app with a $10 corporate upgrade, will offer a wi-fi-scanning tool for finding open networks and showing all potential target devices on those networks, as well as traceroute software that can reveal the IP addresses of faraway servers. When a target is identified, the app offers up a simple menu with commands like “Man-In-The-Middle” to eavesdrop on local devices, or even “Attack”; The app is designed to run exploits collected in platforms like Metasploit or ExploitDB, using vulnerabilities in out-of-date software to compromise targets.

A screenshot from Anti displaying target machines on the local network. (Click to enlarge.)
For now, the demonstration app Avraham showed me was equipped with only a few exploits: One aimed at a bug in Windows–the same flaw exploited by the Conficker worm in 2009–another targeting default SSH passwords in jailbroken iPhones, and a third exploiting a vulnerable, older version of Android. Zimperium has also built a Windows trojan that allows Anti to perform automated commands on hijacked machines like taking a screenshot, ejecting a CD, or opening the calculator, a common penetration-testing demonstration.
Even in its current form, the app raises the possibility of dangerous, stealthy attacks. A hacker could, for instance, walk into a coffee shop or a corporate office with his phone and start sussing out machines for data theft or malware infection. But Avraham says Zimperium will ask users in its terms of service to limit their hacking to “white hat” penetration testing.

Another screenshot showing command options on a target machine, including "man-in-the-middle" and "attack." (Click to enlarge.)
“Hacking is not for the chosen few,” reads one description in the app’s documentation, formatted in Star Wars-style scrolling text. “Anti is your perfect mobile companion, doing it all for you. Please remember, with great power comes great responsibility. Use it wisely.”
Penetration testers who saw the app at Defcon were impressed. “It’s just sick,” says Don Bailey, a researcher with security firm iSec Partners. “The way it populates the screen with vulnerable targets…it’s really elegant.”
Another professional penetration tester for a defense contractor firm who asked that his name not be used called the app a “quick and dirty Swiss army knife for mobile pen testing.” “It’s so polished it’s almost like playing a video game,” he says, comparing it to penetration testing suites that cost thousands of dollars.
With its sheer simplicity, Anti’s impact could be comparable to that of Firesheep, a proof-of-concept tool released in October of last year that allowed anyone to easily snoop on devices on unsecured wi-fi networks that connected to unencrypted web pages. That tool was downloaded more than 1.7 million times, and no doubt used in some instances to spy on web users unawares. But it also helped inspire both Twitter and Facebook to encrypt traffic to their site and prevent such eavesdropping.
“People might use it in dangerous ways,” Avraham says with a shrug. “I really hope not. But I know this might be the risk to help people increase their security, and that’s our goal.”


Enhanced by Zemanta