[Android General] HiddenRambler:
Edit: I've created a xposed module which works with the banking app version 1.7.1 see post below.

---------------------------------------------------

Edit: The changes needed to work with the latest version of the app (1.7.1) are listed in a post below below.

---------------------------------------------------

*There was a error in the diff file. I've uploaded the correct version. Also this patch will definitely not work with the latest version of the app.*

I managed to patch the Barclays mobile banking app version 1.4.2 to make it work with cyanagonmod 10.0 and cyanogenmod 11.

I realize that the current version on play store is 1.7.1 but I haven't updated to the latest version yet. If you do try the latest version please let me know if it differs greatly from the current version in it's root checks :)

I'm not going to attach the patched apk since using banking app from a stranger on the internet is really not a smart thing ;). Instead I will detail the work I did which hopefully someone else will find useful.

This guide is geared towards more technical people who already have some experience with android development. It will not give a detailed step by step how to, rather a general information about the process.

Obfuscation methods used in the app

The app obfuscates the names of some but not all of the namespaces/classes/methods which can stump some decompilers.

It seems to generously sprinkle useless switch statements and loops which does nothing but make the code appear way more complicated than it really is. I would guess quite a lot of the bulk in the code is coming through these dummy statements. smali2java-toolkit was of great help to figure this out.

All strings in the app have been encrypted by a simple xor algorithm which is then decrypted at run time just before they are used:

for example rather than

myfunction(“Hello world”)

the code writes something in the sort of:

myfunction(decrypt(“Juqqdxidqw”, 'x'))

The decryption function is a static method 'bЮЮЮЮЮЮ' in the class appears to be 'rrrrrr.srrrrr' (the method/class/namespace names are obfusecated)

I extracted the decompiled code from this method to write a console application which let me decrypt any string in the application:

static String decrypt(String crypStr, char keyChar) {
char[] arrayOfChar1 = crypStr.toCharArray();
char[] arrayOfChar2 = new char[arrayOfChar1.length];
for (int i = 0; i < arrayOfChar1.length; i++)
{
int j = keyChar ^ arrayOfChar1[i];
arrayOfChar2[i] = ((char)j);
}
return new String(arrayOfChar2);
}

Anti root methods used in the app

Checking for 'test-keys' string in the build tag. (/system/build.prop file)

Checking for superuser related package/apk files.

Checking for superuser hider package/apk files.

Checking for existance of 'su' binary

Attempting to execute 'su' binary
​

The above checks are done both in the java/dex code and in a native code library.

Defeating the anti-root methods in Java/dex code:

The Java code is fairly easy defeat since changing the strings of the apk/file names which are checked as root related will make it think that no 'bad' apps are on the phone.

A bulk of checks happen in the isRootedDevice method of the com.barclays.android.application.BMBApplication class. While it checks for quite a lot of apk's, for my particular purpose I only needed to patch 2 lines in the method:

Smali file line 306 – which starts the checks for “test-keys” string in the build tag.

Smali file line 407 – which start the check for the string “/system/app/Superuser.apk”.
​

The next method in the same class 'runRootCommand' attempts to execute 'su'

Smali line: 956 – which contains the string “su” which will be passed to java.lang.Runtime.exec

A (mostly?) duplicate of the isRootedDevice function exists in the com.barclays.android.container.DeviceData the relevant lines are :

smali file line 1237:	"test-keys" string check

smali file line 1271: "/system/app/Superuser.apk" file check
​

All of the above checks can easily be defeated by changing the the string so that it will check for a non existent package or file.

Keep in mind that all the strings listed above are in encrypted form. You can use the decrypt function listed above to decode them. I found the key char/byte needed to decrypt a given string is in the very next line to the one containing the encrypted string.

Defeating the anti-root methods in Native library

From what I can see the exact same tests which were done in the Java code is repeated in the native code library 'libtest_ndk.so'. As this check appears to form part of the authentication mechanism i don't believe it's possible to simply stop this check from being called from the Java code.

Also the com.barclays.android.container.sampler.SharedLibraryLoader which loads the native library appears to be doing some kind of checksum validation. While this probably could be easily worked around, disassembling an arm shared library was non trivial for me.

My approach was to write another native library which would hook into all the system calls such as 'system' 'stat' 'fopen', '__system_property_get' and redirect any operations to non existent targets, or change the return value. This achieves the same thing as what was done for the java code.

I put in some extra code into the smali classes to load my native library and to call it's initializer with the path to the actual native library.

Basic steps performed to patch the library:

Use apktool to decompile the original apk.

apktool d barclays.apk barclays

Use smali2java as helper to understand the code: This tool cannot decompile the critical check functions due to obfuscation. However it made it easier to understand the smali files generated by the apktool.

Patch the smali files to work around the checks as described above.

Build the hooking native library seperately

~/adt/adt-bundle-linux-x86_64-20131030/sdk/tools/android update project --path . --target android-19
ndk-build

Include the hooking shared library into the lib/armeabi of the decompiled package and change the smali files to load the new shared library.

Use apktool to rebuild the apk.

Apktool b barclays barclays.apk

Sign the apk from using your own key.

Create keystore:

keytool.exe -genkey -v -keystore my-release-key.keystore -alias release -keyalg RSA -keysize 2048 -validity 20000

Sign Keystore:

jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore barclays.apk release

Attached is the code for the hook library native project and the diff for the smali changes. Please note that this is for the smali files for generated by apktool (v1.5.2) for the version 1.4.2 of the Barclays mobile banking app.

For Users of other ROMs/SU applications and root hiders.

The app checks for a lot of common packages which I did not bother to patch since I don't use them, but if you do then you should put fixes for all those package/file names in both the smali and native code hook library.

A non exhustive list of files it check are:

/system/bin/amphoras
/system/bin/su
/system/xbin/su
/system/app/superuser.apk
/data/data/com.amphoras.hidemyroot
/data/data/eu.chainfire.supersu
/data/data/stericson.busybox
/data/data/stericson.busybox.donate
/data/data/com.jrummy.busybox.installer.pro
/data/data/com.jrummy.busybox.installer
/data/data/com.rootuninstaller.free
/data/data/com.rootuninstaller