Trojaning an Android app

Continuing my previous post about Android app reverse engineering and Smali editing, this time, I want to see if I can edit a snippet code in an activity of some app (which name I won't disclose here:) let's just say it's a popular bank's app in Israel), which is responsible for sending login credentials to some server for authentication, and then saving them somewhere for later use.

As before, we start with unpacking the apk with apktool.

After that's done, we need to find the Smali file, holding the values we want to save.

For this app, it's the user and password of the user, that'll be sent in the HTTP request in order to authenticate to the server.

In order to do that, I started the app and found the text for the login activity button, it was a simple 'login' string. Then, I've searched the app's 'strings.xml' file – just to verify I can find it there as well.

After that, you can search that string in the all the unpacked Smali files, you can use jd-gui for that or maybe write a small Python script that implements this search if you want.

Here's an example:

Among others, the file UserLoginActivity.smali was returned from my script.

In the file, I've found a method called 'loginToServer()', which checked some other values, and if they weren't met, an HTTP request to the server with the user's credentials was sent.

In order to save the user's credentials, I'm going to hook loginToServer(), call the android logging method (which will save them locally on the Android logcat file) and then continue execution to the rest of the original method. This obviously can be replaced with a HTTP request of our own, that will be sent to our remote server, with the user's credentials.

The first step is to add a local variable for our logging tag string. At the beginning of any Smali method name, a ' .locals' parameter can be found with a number after it, like so:

.locals 5

So, we'll change this value to 6 in order to add 1 more local for our log tag strings.

Next, we'll assign our tag string to the added local:

const-string v5, "The login for this user is: "

Then, call the Android Log() method with d (=debug) parameter:

invoke-static {v5, v4}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I

The whole code will like this:

And here's how it looks like on logcat file, after I ran the app and logged in:

That's all for now, until next time :)

A new way to start

I've been studying a lot lately about Windows persistency and evasion techniques used by malwares. Between other methods, I've read about using the windows registry in order to make the malware auto-start on reboot or shutdown. 

The obvious issue with this method, is that you have known registry paths, which windows will start their values on startup, and most of them are probably known by anti-viruses products and malware analysts.

But then I recalled that when I worked on an Android app, I've seen on other apps and even implemented myself, a BroadcastReceiver that received events for Android reboot/shut down/boot up and fired up a service upon receiving them.

I've also seen android malwares using the same techniques in order to start themselves up on startup. So I thought, maybe if I can implement the same thing on windows, I can register my app on one of the registry startup paths (e.g. – "Software\\Microsoft\\Windows\\CurrentVersion\\Run") but do it only right before the system is shutting down, so it'll be harder to track when the system is up and running. Then, when booting up again, remove this entry, so again, there is no trace of my malicious app till the next reboot/shut down.

The first thing I found, is that there are different events for console and windowed apps.

For the sake of this POC, I wrote a console app.

So I figured out I needed to register a HandlerRoutine callback function with SetConsoleCtrlHandler(), which windows will execute in a new thread on the process, when one of the signal types I specified, was received, and then my called function will run.

I registered CTRL_LOGOFF_EVENT and CTRL_SHUTDOWN_EVENT events.

The first thing I tried to run was a MessageBox before a reboot, but that didn't appear to work. Then I tried to create a .txt file on the Desktop instead and that did work!
I could see the text file being created just a moment before the system was going down for a reboot.

The next step was instead of creating a text file, calling some code that will register my program in the registry (I did it on "Software\\Microsoft\\Windows\\CurrentVersion\\Run", but I guess any other startup location will work too), then, after booting up from windows, removing this same entry from the registry, so no one can find it when the system is up.

There are examples online on how to add or remove a key from the windows registry so I won't add it here.

I tested this POC on windows 7-32 bit and windows 10-64 bit and both worked out for me – my console app started up on startup, but when I looked in the registry, my entry wasn't there 🙂

Probably one of the main issues with this method is that after a hard reset I won't be able to start up again, but I guess nothing is perfect 🙂