Downloading Files Quickly with aria2

At University, I have been blessed with a 1gb Ethernet connection, which is great for downloading large datasets and ISOs etc. However, I often find that the bandwidth of the server from which I am downloading a file is the limiting factor, meaning I cannot always max out the connection.

After some searching, I came across the tool aria2c, which has quickly become my wget replacement. Aria2 is a cross-platform tool that allows you to download files using multiple connections, allowing you to take full advantage of CDNs and load balancing.

Where you might normally run the command:

wget http://releases.ubuntu.com/16.04/ubuntu-16.04-desktop-amd64.iso

the aria2 equivalent is:

aria2c -x4 http://releases.ubuntu.com/16.04/ubuntu-16.04-desktop-amd64.iso

This tells aria2 to use 4 concurrent connections to download the ISO.

Aria2 supports more than just the http/https protocols — it comes with support for SFTP, BitTorrent and Metalink. Aria2 automatically detects the correct connection type based on the URL scheme. Additionally, aria2 can be controlled using remotely over an API.

As per the documentation, aria2 can be used to download batches of files. By placing a list of URLs in a text file, separated by newline, and then calling aria2c -i urls_filename.txt, aria2 will chomp through and download each entry.

All major platforms are supported, including most flavours of Linux, OS X, Windows and Android.

Under Ubuntu/Debian, aria2 can be installed with:

sudo apt-get install aria2

under CentOS/Fedora/Scientific Linux with:

sudo yum install aria2

or under OS X (using brew) with:

brew install aria2

For other platforms, see the guide listed on the aria2 website.

Bypassing Root Detection in Three InTouch

Three recently released “InTouch”, an application for Android and iOS that allows you to use a WiFi network to send/receive phone calls and text messages, meaning that you can continue to use your phone as a phone without having a cellular network connection.

Unfortunately for me, Three decided not to allow rooted devices to use the application – launching the app on a rooted device resulted in a “It seems that the device is rooted. This application can not run on rooted device” error.

Screenshot_2014-10-16-14-48-57

 

Not wanting to miss out on being able to use their application (my house is a signal deadzone), and being unwilling to un-root my phone, I decided to explore other avenues.

Firstly, I downloaded the APK file from my phone using adb:

adb pull /data/app/com.hutchison3g.threeintouch-1.apk

I then decompiled the application into Smali using apktool, by running the following command:

apktool d com.hutchison3g.threeintouch-1.apk

This created a new folder with the same name as the APK file. Inside that folder was another folder called “smali’, which contains the smali disassembly of the APK.

A simple grep for the string “root” was all that was needed to find the sections of the disassembly responsible for root detection:

The relevant lines were those containing “device is rooted” – in this case, “v.smali” and “FgVoIP.smali”. Opening up FgVoIP.smali and searching for the line containing the word “root” gave me some context:

Screen Shot 2014-10-16 at 15.21.09

Line 4193 is an if statement, checking if the register v0 is equal to zero. The value of v0 is return value of the method invoked on line 4189. In the case that v0 is equal to zero, execution jumps to whatever is at the label :cond_2 – if v0 is anything other than 0, then a string mentioning “device is rooted” is defined, and passed to another method. With that in mind, it’s fair to say that a() in the FgVoIP class is probably their “root checking” method.

An easy way to patch this root detection out is to modify the if statement on 4193 to make it unconditional. I did this by replacing “if-eqz v0, :cond_2” with “goto :cond_2”:

Screen Shot 2014-10-16 at 15.27.21

I then repeated a similar process on “v.smali”.

Once I had modified the two smali files to skip the root detection, I needed to re-compile the apk file so that I could install it on my device. I accomplished this by running:

apktool b com.hutchison3g.threeintouch-1 -o com.hutchison3g.threeintouch-1-patched.apk

However, the resultant APK was un-signed. In order to install the APK onto my device, I needed to generate a key and sign the APK. I did this by following the instructions for “Signing Your App Manually” on the Android SDK documentation.

Once I had signed my app, I was able to install it by running “adb install com.hutchison3g.threeintouch-1-patched.apk”. I was then able to launch and use the Three InTouch app without any problems.

Screenshot_2014-10-16-15-40-16

 

It’s worth noting that I did this as a learning exercise, and don’t recommend that you necessarily go out there and do this yourself. Similar techniques can be used to bypass root detection in many Android Applications.

 

Fixing “java.awt.HeadlessException” when launching an AVD

I’ve just bought a new laptop (Lenovo x230), and decided to go with a Debian Testing install. One of the problems I ran into was that I was unable to start an AVD (Android Virtual Device) using the GUI – the AVD manager would just crash, and I’d end up with a “java.awt.HeadlessException” exception printed to my console.

Google suggested that this was due to some incompatability between the AVD Manager and `openjdk-7-jre`, and that the fix was to remove `openjdk-7-jre` and replace it with `openjdk-6-jre`. I didn’t really want to have to do that, so came up with an alternative solution.

By downloading openjdk-6-jre, and modifying the ‘android’ bash script (located in android-sdk-linux/tools/android) by changing the line:

java_cmd="java"

to

java_cmd="/usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java"

it becomes possible to use Java 7 by default, but run the AVD Manager under Java 6.

Introduction to virtualenv

Keeping track of  Python package dependencies can be a tricky task, especially when you’ve already got multiple packages installed and you’re not sure what your project is/isn’t using. Thankfully, a tool called virtualenv exists which helps keep track of your packages and lets you isolate installations.

Installing virtualenv is easy – it’s a Python script, and can be obtained by running pip install virtualenv.

Once virtualenv is installed, you can create your virtual environment by running virtualenv my_env_name. This will copy your system’s Python binary (you can specify a custom version by passing the --python=/path/to/your/desired/python flag), and install both pip and setuptools to the my_env_name folder. It also creates an activation script, which you can call by running source my_env_name/bin/activate. Activating your virtual environment will update your PATH to use the newly copied Python, as well as the new packages folder and pip install.

Now that your newly create virtual environment has been activated, any calls to Python, easy_install or pip will be passed to your newly created Python install. This means that pip will install packages to your virtual environment rather than to your system install, and that any system packages that you had previously installed are no longer accessible. A useful side-effect of running under a virtual environment is that both pip and easy_install no longer require special write privileges – you’ll no longer need sudo/root privileges to install packages.

Another handy use of virtualenv is to generate a list of requirements for your project – running pip freeze > requirements.txt will create a pip install -r compatible requirements.txt file for you, allowing you to easily distribute and keep track of project dependencies.

virtualenv can be de-activated by running deactivate from your shell, which restores your environment to its former self.

GNUPanel on Debian Squeeze

I was recently playing around with the “GNUPanel” Hosting control panel software. While trying to install the dependencies (with the install-dep.sh file), I encountered the error:

Debian version not supported

Even though the GNUPanel site seemed to say that Debian Squeeze was supported.

A quick look at the install-dep.sh file showed that it relied on the mawk unix utility.

By running apt-get install mawk, we can solve this problem and continue with the installation.


UPDATE:

I’ve now had a chance to play around with GNUPanel a bit more, and unfortunately, I don’t think it’s fully up to scratch. The installation process was pretty clunky – the automated installed script forced me to manually confirm the installation of at least 10 groups of packages. Once the software was installed, I had to guess at the username – and the web interface was also pretty…. “ropey”. These are mainly minor issues, and I’m sure that with some TLC, the project can progress, and become much more useable.