Android Tutorials

Tutorials on how to get thins done on Android devices, most of the time , HTC devices in general.

Android systems , secure or not ?

By the end of this current year, 1.4 billion smartphones will be in use: 798 million of them will run Android, 294 million will run Apple’s iOS, and 45 million will run Windows Phone, according to a new study by ABI Research.

Source: BusinessInsider

This is an incredible number of smartphone users which are connected to the big wide web. But how secure are they ? Is it possible for a mobile operating system to be secure ? Or is it insecure from the roots up ?

As you already might guess I will only be covering the Android part, not surprisingly they have the bigger marketshare. So, how do you ‘test’ a secure mobile system ?

A system can be locked down extremely but this can have an impact on the user friendliness, where do you draw the line ? How do we test if a given Android system is secure. Do we forget the user friendliness or are we considering the bigger picture : a secure , user friendly, Android system. I think considering the bigger picture is a more realistic impact as it includes the user’s behavior, which makes up a great part of the system’s security.

Let’s take a look at the security mechanisms Android has implemented for save distribution of applications. Android applications are shared through the Google Play Store. Android has two important security mechanisms which involve distribution and installation of apps in order to protect the installing user from malicious actions.

  • applications need to be signed
  • applications need permissions to access phone functions

Applications need to be signed with a special unique key that a developer can obtain. The signing of an application can be thought of as providing the application of a digital certificate. With this certificate Android aims on establishing trust relationships between applications. For example consider an app which we call “AppX”. If “AppX” is first installed, it is signed with a specific private key. If the developer upgrades “AppX” to “AppX2”, he needs to use the same key which he used to sign “AppX”. This creates a trusted relationship between “AppX” and “AppX2”, because only the developer that holds the key for “AppX” can develop an upgrade for the app. But is this waterproof ?

Probably u know the answer already because else I wouldn’t have hinted it. Well, no this is not waterproof. A rather invasive bug was found in the signing process.

The core issue is that Android package (APK) files are parsed and verified by a different implementation of “unzip a file” than the code that eventually loads content from the package: the files are verified in Java, using Harmony’s ZipFile implementation from libcore, while the data is loaded from a C re-implementation.

The way that these two implementations handle multiple files with the same name occurring in the zip file differs. The way the Java implementation reads the file is that it goes through the “central directory” and adds each entry to a LinkedHashMap. The key the entry is stored using is the name of the file.

Later, the PackageParser goes through each entry in the zip file, verifying that the file was signed with a consistent signature. This code iterates over the LinkedHashMap. The result is that only the last entry with a given name is considered for signature verification: all previous duplicates are discarded.

Source : Saurik

This is a rather technical explanation of the bug, so a more noob explanation follows. As .APK files are nothing more than JAR files, this is where the problem lies. Where a JAR stands for Java ARchive, a sort of folder with all your Java code. If you want to ensure the integrity of a JAR as a self-contained entity such as an Application then the ability to sign individual files is not a requirement. In fact it is difficult to see in what circumstances the ability to sign individual files and only individual files could be a requirement.

Because it is only possible to sign individual files, a signed JAR is really nothing more than a collection of files which may or may not be signed and the verification of a signed JAR is a very convoluted way of determining into which category each file belongs. All of which leads us to question of what signed JARs are actually for ?

The ability to package files in this way was presumably considered useful when the specification was produced but it is clear that it is a decidedly sub-optimal way of attempting to ensure the integrity of an Application made up of a number of files which have been packaged as a ZIP file.

While signed JARs undoubtedly constitute a flexible mechanism for doing something, its just not clear what, they do so at a cost.

As we have seen the cost is the complexity of the verification process and the inconclusiveness of the result.

The process of verification is ridiculously complicated and consequently dangerously error-prone which is not what you want from something which is a key part of ensuring the security of your platform. (Source : Simon Lewis)

Now, what can a user do about this ? Nothing much actually. The bug is known for some time now, the only actions Google has taken so far was to change something in the .APK submission in the play store. A fix to the devices is coming with Android 4.3 . Older devices need to install the CyanogenMod custom ROM. They have included the 4 LINE BUGFIX, which google failed to deliver OTA.

Next up on the list was “Permissions”. Every app needs specific permissions to access phone functions. As an example I will include permissions my currently developing app needs :

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.WRITE_INTERNAL_STORAGE" />
<uses-permission android:name="android.permission.READ_LOGS"/>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.WAKE_LOCK" />
<uses-permission android:name="" />

These permissions look like they’re asking a lot, but the only access they give to the phone are :

  • The use of internet
  • Ability to write to SD card(= caching images) and internal memory (= for settings)
  • Read error log on crash to send back a detailed error log to me
  • Google Cloud Messaging service
  • Accessing the network state , to check if there’s an internet connection
  • And wake lock, my app uses a service that needs to run with or without the app running , so the services needs a wake lock

These permissions will be shown to the user upon install. So this is the part where the user’s common sense plays a big part. If you want to play a game and the game asks for a whole list of permissions, the game is usual spyware. It will collect as much info as it can and will send it back to a server. The maintainers of this server will use the information to sell to advertising companies. So reading through the permissions is not time lost, as they can be pretty invasive on the privacy of the phone user.

So I did not reach a conclusion, as it as a whole research on its own (maybe a master thesis ? 😉 ). But I hope I gave some pointers that there’s a huge gap between user friendliness and optimal security of a mobile system. Any comments or questions, shoot !

Setting up Android development environment

Maybe some of you want to know how to set up your computer to start developing for Android. I will cover to set up Eclipse and downloading the Android SDK.

Installing Android SDK

In order to start developing for Android you need the Software Development Kit. You can download it for Windows, Linux or for Mac OS X.

Once downloaded you have to install it, on Windows just start the executable file.

Installing Java JDK and Eclipse

The Java Development Kit is needed to develop Android applications since Android is based on Java and XML. Writing Android code is being done using an editor, the best supported ,and in my opinion, the best one around is Eclipse. Eclipse is an opensource freeware editor that is capable of supporting a wide range of programming languages.

Installing the ADT Plugin

Once Eclipse is installed we need to connect the Android SDK with Eclipse, this is being done by the ADT Plugin. Installing this plugin is easily done using eclipse.

  1. Start Eclipse. Navigate in the menu to Help > Install new software..
  2. Press ‘ Add..’,  in the new window that pops up you can fill in Name with an arbitrary name. A good suggestion could be “Android Plugin” and in the location you have to paste :
  3. Click ‘Ok’. Make sure the checkbox for Developer Tools is selected and click “Next”.
  4. Click ‘Next’. Accept al the license agreements, click ‘Finish’ and restart Eclipse.
  5. To configure the plugin : choose Window > Preferences
  6. Select ‘Android’ on the left panel and browse for the Android SDK you downloaded in the first step. (On windows : C:\Program Files (x86)\Android\android-sdk)
  7. Click apply and you’re ready and ok !

Adding platforms and components

On windows, start the SDKManager.exe . Located in C:\Program Files (x86)\Android\android-sdk and install all platforms and components.

You’re ready to start coding now ! Any problems , comment below !

Happy coding, h4

Rooting your HTC device using unrevoked

Why rooting your HTC device?

– ability to flash a custom ROM (ie. Cyanogenmod, Openfire, Wildpuzzle ,..)

– super user permission

– ability to flash overclockable kernels (caution with this !)

– and a lot more tweaks..


– People who installed the Froyo update on the Wildfire can’t use unrevoked at this time, they’re still working on this. So it only works with Eclair at the moment. Unrevoked3 can also be used to flash another custom recovery than Clockworkmod Recovery.

– First download unrevoked3 here : It’s available for Linux, Windows and Mac OS X.

– Before we begin : Windows users have to uninstall HTC Sync and download the Hboot drivers. A more specific tutorial here.

– I’ll explain this now further for Linux Ubuntu , download the package : reflasg.tar.gz and copy the script ‘reflash’ to your home folder.

– Next , open a terminal and type : chmod 755 ./reflash

– Now we can execute the script , type : sudo ./reflash (the script requires root acces , type your password , don’t worry the terminal doesn’t show anything for security purposes)

– Follow the instructions on screen . DON’T forget to enable USB Debugging on your phone!

– Congratz, you have now a rooted HTC device!

What changed ?

Well, you now have super User permission and unrevoked installed clockwork recovery , with this clockwork you can flash a custom rom. I’ll write a tutorial for this soon.

NEVER PULL YOUR BATTERY , it just takes some time. Pulling your battery can result in a brick (so you’ll have a useless phone)

I am not responsible for bricking or messing up your phone, you do this at your own risk. But it’s nearly impossible to brick a HTC device, if you have questions don’t hesitate to comment below. If you do mess up your phone and point your finger at me, I may and probably will laugh at you.

Grtz H4oxer

PS : Stay tuned for a tutorial on how to flash a custom ROM. I am also developping my own sense and froyo based ROM , called ImPrOS , it will be available soon.