Category Archives: Android

Fitbit Android App and Password Security Issue

Android 3.0 047/365I’ve been a Fitbit user for a few months now, and really love the product.  Recently, I had been reading about Android apps that don’t do a great job of protecting user information on the device itself.  Many Android apps store sensitive information in plain text, and rely on the Linux sandbox model to protect that information.  The sandbox model works well, until the device is rooted, which allows access to all of the previously secured sandboxes.

I’ve been looking at the data stored by various apps on my rooted Galaxy S3 using Root Explorer looking for apps that fail to protect sensitive information.  During one of these exercises, I discovered that the Fitbit Android app falls into this category.

In the application sandbox’s files directory, is a file called login_credentials.json.  Inside this file are my Fitbit username and password in clear text:

{“password”=”<my password>”,”login”:”xxxx.yyyy@gmail.com”}

If a user chooses to use the same password for the Fitbit.com service as other services (such as a bank account), the disclosure of the Fitbit.com password could be very detrimental to them.  Of course, I’m able to see this information easily because my phone is rooted.  On a non-rooted device, the application sandbox security model prevents other apps from seeing this data.  However, there have been attacks on Android devices where malware first obtains root, and then uses root to enable other malicious behavior.  If someone was determined enough, they could craft a similar malware bot that could first obtain root access and then discover other passwords on the system stored as plain text.  If a thief steals an Android device, they could root the device and harvest passwords on the system.

I first disclosed this issue to Fitbit a few weeks ago, and after a few days they notified me that they were addressing the issue.  Another day or two goes by, and the new update was already available in the Google Play store.  After seeing the new update, I launched the app, and then Root Explorer to see if the this issue was fixed.  In the new version, the login_credentials.json file was gone, and instead replaced with a file called authinfo_credentials.json.  

Root Explorer viewing the Fitbit Android app sandbox.

Root Explorer viewing the Fitbit Android app sandbox.

This file contains what appears to be a base64-encoded encrypted blob,  which likely contains my username/password.  By encrypting my credentials, this fix prevents the scenario’s that I listed above.

Fitbit doesn’t list a security-related email address on their page for reporting these kind of issues.  I had to open a trouble-ticket with support, and quickly had it escalated, in order to disclose this vulnerability.  On the positive side, I was impressed that Fitbit took this issue seriously, and issued a fix within a week of my report.  I continue to be a fan of their products, and am glad to see that they care about user security.

photo by: Louish Pixel

Android at Google I/O 2013: Keynote Wrapup | Android Developers Blog

Google I/OI was really happy with the Android announcements yesterday from the Google I/O Keynote, as there are a number of things that I can immediately take advantage of as an app developer.

Android Studio

I have been a faithful user of Eclipse, and have avoid even trying some of the other IDEs for Android Development.  Just seeing a few of the features yesterday was enough to give the new Android Studio a try.  I love the embedded strings in the code editor, as managing strings in the resources is always a huge pain.

Beta and Limited Rollout

If you are fortunate to have a community of passionate users for your app, you have probably been asked by some of them to help test out early versions of new features.  I recently wrote about my experiences with this, and ended up creating my own beta channel app for these users.  Having this officially be part of the Android Developer Console will save a lot of time, and help other app developers who have not yet made the effort to offer a beta.

Limited Rollout is another great feature.  If your app is used by users for a critical part of their business, it can be risky to introduce new features.  Besides interrupting their business, it can also cause an avalanche of support emails and questions.  Being able to slowly roll out an application will go along way with major releases.

Google Games Cloud Save

While I’m not a game developer, I was happy to see a Cloud Save feature.  I’m puzzled as to why this is targeted only to game developers though.  Any app developer who has users on both a phone and tablet could benefit from this.  I’d love to see app preferences saved automatically across devices.  If an app has a complicated set of preferences, users are forced to enter (and re-enter) these preferences on every device.  While iCloud’s Core Data Sync isn’t perfect, I think the idea could be applied well to Android to help app developers of any sort synchronize app preferences.  I’m hoping that the Cloud Save feature on Android is generic enough that it can be used outside of games.

Android at Google I/O 2013: Keynote Wrapup | Android Developers Blog.

Use REST Web services to share data across iOS and Android apps.

REST Web Services can be a great way to share data between iOS and Android mobile apps.  I recently answered a question on Quora about this topic.  Here’s my answer:

There are several different options here.  When you want to support multiple mobile platforms, creating a simple REST api is a good way to go.  Soap-based protocols are going to be too complex, slow, and difficult to use from a mobile device.

It sounds like you already have the data being sent to a webserver.  From there you will need to store the data in a SQL database, such as MySQL or Postgresql.  When you want users to see the other scores, you can implement a simple GET request on your same web service which would query the database, and return back the scores of the other users.

When submitting the score, your app can use this GET operation to read the other scores before submitting it’s own score.

Alternatively, if you need real-time scoring updates, you can use push notifications.  Both Apple and Google have push notification capabilities in their architecture, but this will add some complexity and server requirements.  If you don’t need real-time updates, I’d suggest each app just read the other scores from the leaderboard as needed.

http://developer.apple.com/libra…

Google Cloud Messaging for Android

View Answer on Quora

Securing your app’s data on Android

Great article by SecureState’s Brandon Knight on Mobile App Security.

Securing your data is a common Android security problem.  During my development of Android apps, I’ve noticed lots of information being stored in unprotected areas of the filesystem, such as the /sdcard/Android/data folder.  For example, any file you view or cache offline from Dropbox is stored in /sdcard/Android/data/com.dropbox.android.  Given that Dropbox could be used for both personal and team-based uses, it’s easy to see that corporate data isn’t safe here either.

During the Android 2.2 days, many phones (such as my HTC EVO) had ~200MB available for apps (and storage), supplemented by micro SD.  There was no choice but to save information on the micro SD.  The newer Android phones ship with much more internal storage, meaning app developers can (and should) begin to more to saving data in the app sandbox instead of the public space.  It will take a long time before app developers change over to the new model.  In the meantime, users should be aware of what data is being stored on the micro SD and other public areas of the filesystem.

Android Developers Blog: New Google Maps Android API now part of Google Play services

I’m excited about the new Map Fragment in the latest Google Play services!  I’ve wanted to embed a Map View into one of my fragments for a while.  A lot of developers have requested this feature, and I’m glad to see it in the support library.

Android Developers Blog: New Google Maps Android API now part of Google Play services

Android-er: Preview build of ADT 21 and of the SDK Tools, r21 released

Looks like the preview build of ADT21 is out there.

Android-er: Preview build of ADT 21 and of the SDK Tools, r21 …: Preview 1 is mostly a bugfix release. It contains a number of bug fixes in various areas that were new in ADT 20, such as the new templa…

ADT20 was a nice jump in terms of functionality.  Since I work on both Android and iOS, while I enjoy the Eclipse environment more, there are some things that XCode does a better job at.  UI development and templates come to mind the most.  I’d love to see a Storyboard-esque feature in ADT, which would greatly improve the creation of UI’s.

The project templates are great to help get going faster, especially as the project structures get more complicated with things like Fragments.  Having previously built a fragment UI by hand, having the IDE create the initial template would have made it much easier.  I’m also hopeful that project templates will help encourage developers to follow more of the Android standards.

Asus Transformer Prime power adapter doesn’t like the heatwave

This heatwave (here in the US) sucks.  Not only do we (humans) hate it, but apparently some of our electronics don’t like it either, and occasionally need to go back to the cold.

I’ve been trying to figure out why my Asus Transformer Prime charger was no longer working.  I have a charger at work, and the tablet charges fine there, so I know that it’s not a problem with the tablet.  I first checked the USB cable for any kind of damage.  I didn’t find any, and in fact the cable has been working great as a debug cable for ADB to my Prime.  I then thought there was something wrong with the power outlet on the power strip.  Plugging in other things showed me that it was working completely fine.  

I continued on, investigating and experimenting, all in the hopes of getting my tablet to start charging.  At some point, I gave up and started browsing Amazon for a replacement.  While reading the reviews for this one, someone had posted a note in their review about needing to place the charger in the freezer to reset some kind of temperature sensor.  Being that my upstairs office is currently in the 90’s without the window unit AC, and that the power adapter heats up under use, I guessed that I was probably susceptible to this issue as well.  The ambient temperature in my office was not dropping down low enough to reset the sensor.

So I popped it in the freezer, and 30 minutes later, I had a working charger.  I couldn’t believe that worked.  If you’re having this problem, avoid paying $30 for a replacement, and throw yours in the freezer for a few minutes.  You may find it works just fine after a brief cool-down.

Gson and Android

Gson is a lightweight and open-source library from Google which takes care of serializing Plain Old Java Objects (POJO’s) to JSON, and JSON to POJO’s.  Since it is written in Java and has a JAR file available, I found it can also be a great choice for the Android platform as well.  The JAR file weighs in at 190KB, so it will add a little bit of bloat to your app.  However, I think the ease of use is worth the extra space that the code takes up.  With the use of ProGuard, most of the unneeded code will be removed from your APK file anyways.

In my Android app MoPhotos, I have a need to persist some user preferences that the built-in persistence mechanisms were either too simple (preferences) or too heavy-weight (SQLite).  This particular set of preferences is a set of directories that a user has selected for my app to scan and display photos for.

To persist each directory, I first created a model class that represents the data I want to persist for each user selection:

public class Filesystem
{
    private String uri;
    private boolean enabled;
    private transient List photoDirectories = null;
}

By default, any fields in the class will be included in the serialization/deserialization results.  To add additional fields that you do not want to be persisted, use the “transient” keyword to have Gson ignore that field.

The next step was to load the JSON file when the Activity was started.  The loadFilesystemConfiguration method is called during onCreate.  With Gson, this is pretty easy:

private void loadFilesystemConfiguration()
{
    Gson gson = new Gson(); //1
    FileInputStream fis = null; 
    try { 
        fis = this.application.openFileInput("Filesystems"); //2
        Type collectionType = new TypeToken<Collection<Filesystem>>(){}.getType(); //3 
        List filesystems = gson.fromJson(new InputStreamReader(fis), collectionType); //4
        if(filesystems != null) { 
            this.photoFileSystems.addAll(filesystems);
        }
    }
    catch(JsonIOException e) { ...  }
    catch(JsonSyntaxException e) { ...  }
    catch (FileNotFoundException e) { ...  }
    finally { 
        try { 
            if(fis != null)
                fis.close(); //5
        }
        catch (IOException e)  { ...  }
    }
}
Notes for the above snippit:
//1:  Create the Gson class instance which will deserialize the JSON into our POJO’s
//2:  Open the file storing the JSON string.  By default, I am using the app’s internal file storage space to store the JSON file in a file called “Filesystems”.  The name can be anything you want.
//3:  Because I’m persisting a list of POJO’s, I needed to create this Type object to reflect the collection type needed to give Gson the proper context.
//4:  Deserialize the JSON into a List object.
//5:  Make sure you close the file in the finally block.

Serializing the list of Filesystem objects is just as simple.  In the onDestroy method, the saveFilesystemConfiguration method is called:

public void saveFilesystemConfiguration()
{
    Gson gson = new Gson();
    String filesystemData = gson.toJson(this.photoFileSystems);  //1

    FileOutputStream fos = null;
    try {
        fos = this.application.openFileOutput("Filesystems", Context.MODE_PRIVATE);
        fos.write(filesystemData.getBytes());  //2
    }
    catch (FileNotFoundException e)  { ...  }
    catch (IOException e)  { ...  }
    finally {
        try {
            if(fos != null) fos.close();
        }
        catch (IOException e)  { ...  }
    }
}

Notes for the above snippit:

//1:  Serialize our List array to JSON into a string.
//2:  Write the JSON string to the filesystem, using the same file name as before, located in the app’s internal storage location.

Gson turned out to be a nice way to serialize this list of objects for my app.  In fact, I ended up using this same general design in 2 other places as well.  Eventually I realized that this mechanism, coupled with a ListActivity and ArrayAdapter, could be implemented as a more general mechanism for storing lists of user preferences.  Maybe next release.

This is probably a very simple use for Gson.  I could have used a simple flat text file and read the directories line-by-line.  However, Gson does make the code a bit easier, and I learned a new skill in the process that might prove helpful for a more complex future scenario.  Gson does add a little bit of weight to your APK, so you’ll have to weigh the cost/benefits against that.

Open File Dialog in Android

Android Open File BrowserThe Android SDK does not have a file browser dialog for use by app developers.  For my app MoPhotos, I needed to allow the user to select a file from their Android system that my app can use. I was surprised to learn there is no real built-in file chooser dialog. From my experience with .NET and the Win32 API, that’s a function that you can count on being there. I did not think it would be difficult to write one myself, but I’m always looking for quicker ways to get there.

Eventually, I found a blog post by Android-er, who shows a very simple version of the mechanics behind a file open dialog. After getting my version of his code up and running, I wanted to make a few modifications to meet my needs. These modifications are:

  • Alphabetize the list of files
  • Exclude hidden files, hidden directories, and directories without read access
  • Only show files with compatible file extensions

Fortunately, this was very easy to do using standard Java API’s. Instead of calling:

File[] files = f.listFiles();

I create a FileFilter to filter out the results:

File[] files = f.listFiles(new FileFilter() {
  @Override
  public boolean accept(File pathname)
  {
    //If a file or directory is hidden, or unreadable, don't show it in the list.</div>
    if(pathname.isHidden())
      return false;
    
    if(!pathname.canRead())
      return false;

    //Show all directories in the list.
    if(pathname.isDirectory())
      return true;

    //Check if there is a supported file type that we can read.
    String fileName = pathname.getName();
    String fileExtension;
    int mid= fileName.lastIndexOf(".");
    fileExtension = fileName.substring(mid+1,fileName.length());
    for(String s : supportedFileExtensions) {
      if(s.contentEquals(fileExtension)) 
        return true;
    }

    return false;
  }
});

The last change was to sort the files and directories alphabetically. I do the sorting operations after the list is constructed, but before the ArrayAdapter is initialized.
//Sort the files alphabetically.
Collections.sort(fileStringList);
Collections.sort(pathStringList);

fileListAdapter = new ArrayAdapter(this.getContext(), R.layout.open_file_entry, R.id.fileName, fileStringList);
ListView lv = (ListView) this.findViewById(R.id.pcap_files_list);
if(lv != null)
{
  lv.setAdapter(fileListAdapter);
}

So far, this code is working as intended. I don’t know if this is the most-optimal to do this, but that will be analyzed before I release this app to the market. For now, I’m still building out the basic infrastructure.