Category Archives: Android

[ Technical Teardown: Malware Targetting Singapore Banks ]

[ Background ]
Originally i wanted to let one of the local student to write about it but he was busy with school, internship and solving challenges.
It’s also been a very long time since we written any “Technical Teardown” on malware/exploits here.

I got hold of this particular malware sample just days after these 2 reports.

The Association of Banks in Singapore (ABS) released an advisory to alert consumers on malware targeting mobile banking customers in Singapore.
We hope this technical teardown might be interesting to some of you.

[ Sample used in the analysis ]
MD5: 76745CE873B151CFD7260E182CBFD404
SHA1: 0F7C012466157891C1D12ADDDD4DFA0B8291DD75
Malware Sample: 76745ce873b151cfd7260e182cbfd404
Password is “infected29A”

Since it’s an Android malware, let’s check the permissions of this malware and further dissect it. Now, use apktool and run the following command:

Now let’s take a look at the AndroidManifest.xml file, you should see the following and the permissions requested by the APK file.

As we can see from the AndroidManifest.xml, it ask for quite a lot of permissions and it’s probably obfuscated.

Looking at the strings.xml and styles.xml, we can see that customised themes had been created for various banking applications.
This malware targets a number of banks by trying to mimic the authentic one and phishes for important banking information from the infected user as shown below.
Figure 1 – Customised Themes

[ Junk Codes as Anti-Analysis? ]
It took me 20-30mins to realise that this author uses lots of junk code. Possibly with the purpose of deterring people like me from reversing the malware.
Import metadata such as strings and function names are also obfuscated as shown in the image below.

Figure 2 – Junk Code with no useful functionality

Since the malware sample is heavily obfuscated, some of the things that i usually look out for is commands like Base64.decode or loadDataWithBaseURL or sendTextMessage

[ Revealing of Hidden Configuration Strings ]
So i did a quick grep and found out that it did use “Base64.decode” as shown below.
Figure 3 – Base64 encoded string

The following is the base64 string which i extracted from the malware.

After doing a base64 decoding on it, i got back the following strings.

As we can see, the decoded strings contained IP addresses and other interesting strings. We also can safely assume that the malware author uses “@” as a delimiter.
For better illustration, i replaced all the “@” with newline.

[ Assessment of Malware ]
We can see that the IP addresses are the C&C servers communicating on port 34580.

Within the malware sample, we also found out that it is targeting victims with the following bank accounts.

Dexia Kommunalkredit Bank
Bank Austria
Erste Bank und Sparkassen (Thanks to Alex Inführ for pointing my mistake.)
RGB (Raiffeisen Banking Group)
George (
DK (Deutsche Kreditbank AG)
Bawag (BAWAG P.S.K)


St George
National Australia Bank

New Zealand

Bank of New Zealand
ANZ Bank New Zealand



Hong Kong

Bank Of China
Hang Seng Bank

I’ll update this post later on how we can reverse such malware much more easily.
In the meantime, i do hope you enjoy reading it.

Happy Reversing,
Jacob Soo

[ Vulnerability Research Advisory : ALZip for Android ZIP Archive Extraction Directory Traversal & Local File Inclusion Vulnerability ]

This is just a simple vulnerability research advisory where i talk on ALZip for Android ZIP Archive Extraction Directory Traversal & Local File Inclusion Vulnerability.
Since vendor don’t want to reply me for 3 months and i personally don’t think it’s severe.
Here goes…

[ Summary: ]
An archive extraction directory traversal vulnerability has been found in ALZip for Android.
When exploited, this vulnerability allows an anonymous attacker to write files to arbitrary locations within the SD card of the user’s Android device.

[ Tested Versions: ]
ALZip Android Version 1.0.21 – 1.0.22

[ Tools Used: ]

[ Details: ]
This advisory discloses an archive extraction directory traversal vulnerability in ALZip for Android.
When exploited, this vulnerability allows an anonymous attacker to write files to arbitrary locations within the SD card of the user’s Android device.

When extacting compressed files from an archive, the extraction functionality does not properly sanitise compressed files that have directory traversal sequences in their filenames.
By tricking a user to extract a specially crafted archive containing files with directory traversal sequences in their filenames, an attacker can write files to arbitrary locations within the SD card of the user’s Android device, possibly overwriting the user’s existing files.

For example, a malicious archive can contain a compressed file with the following filename:

[ PoC: ]
1.) Copy the PoC.ZIP archive into the /storage/sdcard0/Download/ directory of your Android device.

IMPORTANT: Ensure that the /storage/sdcard0/Download/ directory exists on your Android device in order for the POC to work.
Extract the POC ZIP archive into the /storage/sdcard0/Download/ directory. i.e. tap and hold on to the POC ZIP file until the action selection pop-up appears, then select the “Extract” option.


Finally select “Extract here” option


When the extraction completes, navigate to the /storage/sdcard0/ directory. You’ll notice that pwnies.txt has been extracted into /storage/sdcard0/pwnies.txt instead of into /storage/sdcard0/Download/pwnies/pwniestxt.

Hence, by tricking a user to extract or download a specially-crafted archive, an attacker can potentially exploit this issue to write files into arbitrary locations within the SD card in the user’s Android device, or to overwrite files in known locations within the SD card.

For example, an attacker who is aware of the filenames of the user’s photo in the /storage/sdcard0/ directory can exploit this vulnerability to overwrite the user’s photo files.
But i doubt anyone knows the filenames.

Another bug was found manually via reversing the application and in the same time via Drozer due to exposed content provider.
But for simplicity sake, i will write about the method using Drozer
So what this means is that you can read the contents of any file in the victim(s)’ Android device if you got a specially crafted apk that abuses the exported content provider of ALZip.

The reason for this bug is that you expose the content provider.
A content provider can provide access to the underlying file system.
This allows apps to share files, where the Android Sandbox would otherwise prevent it.
Since we can reasonably assume that “files” is a file system backed content provider and that the path component represents the location of the file that we want to open.

So in drozer if you run the following command.

You will get back the contents of /etc/hosts

But this particular bug is not critical since /etc/hosts is world readable anyway.
It’s only serious if your app stores critical info about user or have a SQLite database.

[ POC/Test Code: ]
You can download the PoC here and follow the instructions as described in this blog post..

[ Disclosure Timeline : ]
01-04-2015 – Vulnerabilities Discovered.
01-04-2015 – Vulnerabilities Details Sent to Vendor.
01-04-2015 – No Reply From Vendor.
13-05-2015 – 2nd Email Sent to Vendor
13-05-2015 – No Reply From Vendor.
01-07-2015 – Public Release.

Thanks & Regards
Jacob Soo

[ Technical Analysis: Scoop.apk ]

[ How it starts ]
I started to write about this particular malware before Christmas in 2014 but it was left sitting in the draft for so long until i decided to take a break from #EquationAPT today. It all started when i got a sms as shown below.

Figure 1 – Initial SMS

I hardly take any photos and the Sarah i knew don’t even SMS me. So i found a bit weird. So what is special about this sample was that it uses a technique typical of computer worms to spread itself.

This particular piece of malware rely on social engineering to convince the user to click on the shortened link in the sms and install/run the malicious APK package.

[ Sample used in the analysis ]
MD5: 9187B180E741312AA0FF36EF6FE7DC51
SHA1: 322ABA633607F635F5581E8D7F53794566BCB80B
Malware Sample: Scoop
Password is “infected29A

[ Initial Analysis ]
Since it’s an Android malware, let’s check the permissions of this malware and further dissect it. Now, use apktool and run the following command:

Now let’s take a look at the AndroidManifest.xml file, you should see the following and the permissions requested by the APK file.

As you can see from the AndroidManifest.xml, it ask for quite a lot of permissions.

[ SMS Propagation ]
One of the more interesting functions that i’ve found is how it tried to spread itself.
As you can see from the image below.
Figure 2 – The worm’s SMS sending code

What is rather typical of this malware is that it is leaking SMS messages, call history & contact lists of the victim(s).
One of the characteristic of this malware is that it will fetch data from one of the hardcoded URLs in the APK with a HTTP POST.
The typical data that it will fetch will look like the code snippet below.

Other interesting stuff is that it will go to “[.]html” to fetch a new copy of Scoop.apk

The malicious url in the SMS, https://bit[.]ly/s_-c will redirect you to http://secret-message[.]net/

This malicious page will refresh and direct user to this malicious .APK file.

As i’ve already done quite a number of articles on reversing Android Malware.  Today we will be going through other stuff which might aid us in our investigation and see how this malware operate. The interesting thing here is we can see the statistics kindly provided to us by for all shortened URLs by appending a “+” sign without the double quotes like this:

You will see the stats as of then when i analyse this .apk. From the statistics given, we can see that most of the target(s) are from Singapore. 🙁

Figure 3 – Statistics of url

What is even more interesting sir, the same author of the malicious .APK file actually got several other domains spreading same .APK file.
You can check out the other shortened links by the same guy here.

Interestingly, one of the links leads to the Android app in PlayStore.

Figure 4 – Another app by Malware Author

Sadly, the app was removed before i downloaded it.  The URL in the PlayStore belongs to same domain as the other malicious links.

Could it be same guy? 😛

topemarketing[.]com points to
tombolaworld[.]com points to
secret-message[.]net points to

One other interesting thing is…2 of the domains are bought around 2009 and 2010 and expired in 2011 according to as shown here.

But did this guy bought them in 2014?
Or did she/he bought all those expired domains so that user(s) might think it’s still legit. Or it had been the malware author all along and she/he decides to use WhoisGuard later on.  Probably need the whois records to verify here. 🙁

The worm is targeted mostly against Singapore and French Android users according to the statistics from  Not sure why the domains are still alive.  Our advice to user(s) on how they can protect themselves effectively are:

  1. Restrict the installation of applications from unknown source
  2. Don’t click on suspicious links as Malware authors might use it as their social engineering tricks
  3. Always use an updated anti-virus solution on your Android device if you don’t know how to analyse the application

Happy Reversing,
Jacob Soo

[ Super Funday Mini Series : LINE Forensic Artifacts – Android Edition ]

This is the 2nd article in the “Super Funday Mini Series” about recovering forensics artifacts from mobile applications for your digital forensics investigations.

Today, i’ll be covering about LINE Forensic Artifacts – Android Edition.
However, as i was writing this. I think lots more information could be uncovered if i were to reverse the application.
LINE (version 4.7.1 is the version which i did my testing on) is a cross-platform application that allows users to do voice call, send messages and share images with their contacts using Windows, iOS, Android, Blackberry, Nokia Asha, MAC OSX and Windows Phone devices.

[ Tool Used ]

[ Why are LINE Artifacts Important to Your Mobile Forensics Investigations? ]
Much like other IM (Instant Messaging) applications, LINE contacts, messages, and attachments are valuable to forensics investigators who are looking to recover evidence for a variety of different investigation types. Whether you’re analyzing the mobile device of a suspect or a victim, these chat artifacts can contain valuable information to help solve a case.

In order to gain access to the more important LINE artifacts, forensics investigators must root or get a physical acquisition of the Android device.
Some of the more important LINE artifacts in Android can be found at:

The “naver_line” file is a relatively simple SQLite database with 25 tables:

Inside the “contacts” table, each contact are given a unique identifier, “m_id”.
This table will include the contact’s name in addressbook, message status, timestamps, and other details.
Chat history in Line are kept under “chat_history” table. This table contains the messages along with timestamps and other relevant data.
Included in this table is message content, timestamps for sent and received messages, status, state (whether the message has been delivered, read, etc.) and attachments (if applicable).

If you start a “Private Chat”, it will also be stored unencrypted in “chat_history” like the image shown below.

Image 0 : Screenshot of “Private Chat” entry in LINE’s “naver_line” DB

However, the “Private Chat” entry will reside in that table for 1 minute before it’s being removed after the receiver reads the message.
In my experiment, i notice that the timer to remove the message will end a few seconds earlier than the timer on the sender’s end.
So what this means is that after the receiver starts reading the message, it will sync back to LINE’s server. LINE’s server will inform the sender and the timer will begin.

What is interesting is that it is not deleted after 1 minute. The entry is removed but not permanently until some time later.
I extracted out the DB and still managed to recover the “Private Chat” message as shown below:

Image 1 : Screenshot of “deleted messages” which are not “deleted” immediately in LINE

The deletion of the “Private Chat” are controlled by the “Parameter” column in “chat_history” table.

If you were to view the “naver_line” DB, you will also notice that a typical private message is easily identified when you search for a user’s ID followed by “+private” as shown below
or in my case
followed by “1415376903” which is the timestamp of the message in Epoch timestamp

All messages appear together in the “chat_history” table, which can be challenging to sift through if multiple conversations occurred at the same time. To analyze these conversations properly, forensics investigators need to refer to both chat_id, which will identify who the conversation was with, and from_mid, which will indicate which party sent or received the message. Additionally, the “read_count” & “sent_count” column will indicate how many people were given message and how many had read the message.

The “naver_line_private_chat” SQLite database contains the following 3 tables:

A typical entry will look like this.

Image 2 : Screenshot of “naver_line_private_chat” in LINE

Another interesting DB is “line_general_key_value”, there is a “key_value_blob” table containing “PRIVATE_CHAT_PRIVATE_KEY” & “PRIVATE_CHAT_PUBLIC_KEY”
Probably need to fully reverse this application to see where this was used.

Even though there is an option to remove all the chat messages under
“Settings” -> “Privacy” -> “Clear Chat Messages”
It seems like it didn’t “Vacuum” the SQLite Database as required. Thus forensics investigators are still able to retrieve some valuable information from the Databases.

[ Timeline of LINE’s user ]
Another interesting artifact could be found under the following location:
Inside this folder, there are many files with random filenames.
These files contain the “messages” that a LINE user wrote under “Timeline”.
I have not reversed the application yet to fully understand what the struct will look like.

While this week’s blogpost seems not too comprehensive.
I do hope this “Super Funday Mini-Series” will be sufficient for others to pick up and further expand on the information that i’ve shared today.
Hopefully, i will find time to reverse this application and “find out the truth” on other parts which i didn’t cover today.

Happy Reversing,
Jacob Soo

[ Super Funday Mini Series : Viber Forensic Artifacts – Android Edition ]

This is the start of a series of blog posts about recovering forensics artifacts from mobile applications for your digital forensics investigations.
This series will be my tribute to LookOut Security for all the help they rendered, all the people there are very nice to me, especially Tim Strazzere, Marc Rogers, tamakikusu and Caleb Fenton. Thanks a lot.

Today, i’ll be talking about Viber Forensic Artifacts – Android Edition.
Viber (version is the version which i did my testing on) is a cross-platform application that allows users to do voice call, send messages and share images with their contacts using Windows, iOS, Android, Blackberry, Symbian and Windows Phone devices.

[ Tool Used ]

[ Why are Viber Artifacts Important to Your Mobile Forensics Investigations? ]
Currently, smartphones are used worldwide by billions of people to communicate and keep updated with the latest news.
Smartphone users spend the majority of their time on their devices sending emails, surfing the web, updating their social network status and/or chatting with others using various applications.

As such, it’s getting important for people working in the field of #DFIR to investigate mobile applications such as the likes of Viber as part of the source for evidence, and the ability to recover data from this application will potentially become important to their investigations since Viber is widely used as shown by the numbers of installs indicated in Google Play Store.

Image 0 : Screenshot of stats

For Android, most Viber artifacts relevant to forensic investigations are stored within SQLite databases, similar to other smartphone chat applications.
In order to gain access to the more important Viber artifacts, investigators must root or get a physical acquisition of the Android device.

Some of the more important Viber artifacts in Android can be found at:

These databases store details on the Viber user’s contacts, messages and attachments sent and received through the Viber application.

[ The Artifacts About The Viber User ]
Often in times during forensics investigation, we want to gather as much information about the user as possible. Information such as email used, phonenumber, contacts, activated SIM serial.
Viber stores information about:

We can cross verify some of the information with the .userdata file found in the location below.

[ The Key Artifacts That Need to Be Found When Investigating Viber ]
While doing mobile forensics, there are some key artifacts that we need to find in order to gain more insight about the Viber user.

1) Viber Contacts

Viber stores user contacts within the “viber_data“, SQLite database.

There are several tables in the SQLite database such as the following:

In a table called “phonebookcontact“, this list contains valuable information for all the Viber user’s contacts.
The table contains the following columns for each contact in the table.
_id, native_id, display_name, phonetic_name, phone_label, low_display_name, starred, viber, viber_out, contact_lookup_key, contact_hash_version, has_number, has_name, native_photo_id, recently_joined_date, joined_date, numbers_name, deleted, flags.

Image 1 : Screenshot of viber_data SQLite DB

Right now, i have not determine how “contact_lookup_key” and “contact_hash” are generated and what is the purpose of these columns.

Another interesting table, “calls“, is useful for investigators to know whether that Viber user made or receive any calls. The calls are not limited to Viber to Viber users. It also contain information on Viber Out.

The table consists of these columns:

Some of the findings i made are:

  • The values in “duration” is measured in seconds
  • The timestamp in all the tables are in Epoch timestamp.
  • The values in “viber_call_type” means the following:
    * 1 – viber user to viber user call type
    * 2 – viber out call type

2) Viber Messages

Given that Viber is a IM with call capability, it’s likely that the most valuable evidence will be found in the conversation(s).
Earlier on, we mentioned that there is another SQLite database, viber_messages.
This DB comprises of the following tables:
android_metadata, conversations, group_conversations_extras, kvdata, messages, messages_calls, participants, participants_info, public_messages_extras, purchase, sqlite_sequence, stickers, stickers_packages

The particular table(s) which we are more interested in are “conversations“, “messages“, “participants“, “participants_info

All messages appear together in the “messages” table, which can be a uphill and challenging task if we were to sift through several conversations that could have occurred simultaneously.
To analyze these conversations, we need to always refer to “conversation_id” and “group_id“, which will help us in identify who the conversation was with
Additionally, if want to know whether the Viber user has read a given message (a value of 0 means read while 1 means unread) in the “read” column.

In the “participants_info” table, we can gather information on who are the friends of this Viber user and possibly the Geo-location if they had enabled that.

3) Viber Attachments

Viber also supports the transfer of photos. Photos – sent from either the camera or gallery – are stored on the mobile device.
It is also worth noting an attachment can include a “description” entered by the sender of the attachment. The “description” might or might not contain important information.

We can find out the exact location of all these photos in the “extra_uri” column in the “messages” table.

Image 2 : Screenshot of attachments location in Viber

[ Recovering Clear Message History ]
There is a “Clear Message History” in Viber for users to delete all the messages.
While this may appear true if you use SQLite Browser to view the SQLite DB as shown here.

Image 3 : Screenshot of deleted messages in Viber

However, if you were to open the SQLite DB with Notepad++ or any other hex editor, you may see this instead.

Image 4 : Screenshot of “deleted messages” which are not “deleted” in Viber

As you can see, we managed to get back the supposedly “Deleted Messages”. 😀
While this might not be those super advanced articles. I do hope this “Super Funday Mini-Series” will be sufficient for others to pick up and learn more stuff about mobile forensics.

Happy Reversing,
Jacob Soo

[ Forensics Walk-through: DFIRCON EAST Smartphone Forensics Challenge ]

Today I was asked by a good friend of mine on whether there could be 2 answer(s) to the last question in DFIRCON EAST Smartphone Forensics Challenge.

Being the curious cat, i downloaded the Challenge and have a quick look and decided to write this out while i’m at it. It seems like we are given an iOS backup folder and an Android .apk file.

[ Tools Used ]
iPhone Backup Browser –
SQLite Database Browser –
pList Editor – or use the default viewer in Mac
Cerbero Profiler –

Let’s go through the question(s) and load the iOS backup folder using iPhone Backup Browser as shown here.

[ 1st Question ]
1. What third-party applications have been granted access to device camera photos?
Ok, if you have done iOS forensics before. It’s always good to do a quick check of the TCC SQLite3 database.
You might be asking “What is TCC SQLite3 database”?
Well, this SQLite3 database is used to control what permissions iOS apps have.
TCC.db is located at the following location on your phone.
Likewise this file also exists on a Mac.
~/Library/Application Support/

Incase, you have “accidentally” allowed more permissions than you wanted. You can use tccutil to reset the permissions instead of “tampering” the SQLite3 file.

So using SQLite DB Browser on TCC.db, we can immediately see the permissions granted to which applications.

So for this particular question, Facebookand Dropbox were both granted permissions to access the device camera photos.

[ 2nd Question ]
2. What third-party applications have been granted access to the device address book?
Actually if you had looked at TCC.db, you will notice that the answer to this question is “Waze” as shown here.

[ 3rd Question ]
3. Which websites were visited that requested the iPhone’s geolocation information for optimal browsing and were granted access?
Ok, now if you want to find out which website(s) requested this. The first thing to look for is GeolocationSites.plist
In this case, if you use iPhone Backup Browser to extract out the file. It should be located here:
iOS backup\Liz Lemon’s iPhone\System\Library\WebKit\GeolocationSites.plist
Using pList Editor or the default one on a Mac, you should see something like this.

Based on the returned results, we know that both “” and “” are the website(s) that request geolocation and were granted access.

[ 4th Question ]
4. What permissions does the application MysteryApp.apk NOT have on the device?
Naise, now we have moved on to the Android .apk file.
Let’s extract out the Android.manifest file and we should have something like this.
And if we do a quick check against the options that we were given:

  • Record audio
  • Read contacts
  • Send SMS
  • Record video
  • Mount & unmount files

We can quickly eliminate and know that that the permission that “MysteryApp.apk” don’t have is “Record video

[ 5th Question ]
5. What is the SHA1 digest value associated with the classes.dex file for the MysteryApp.apk application?
This is the question which my good friend asked about.
To me, if it’s SHA1 of classes.dex. The answer is definitely “0C3A720EB61D736E21561E9AA96066A4771F0F70
My friend was actually talking about the SHA-1 Signature found in the Dex header.
But the answer was saying “SHA1 (value within file)” so i’m not sure whether the original question implied the wrong thing or the answer was weird?

[ 6th Question ]
6. What foreign language word(s) are found within the MysteryApp.apk application?
We were given these options:

  • запись аудио – Record audio
  • mesajlaşma – Messaging
  • 未接来电 – Missed Calls
  • 連絡 – Contacts
  • None of the above

For this particular, you can use Cerbero Profiler and immediately you will know that the only foreign language found is “Chinese”.
Doing a quick check, we will see this.
Thus we know the correct answer to this is “未接来电 – Missed Calls“.

After doing a speed-run on this, I really regretted not taking part in DFIRCON EAST Smartphone Forensics Challenge in the first place. xDDD

I do hope this quick walk-through will be sufficient for others to pick up and learn more stuff about mobile forensics.

Happy Reversing,
Jacob Soo

[ Technical Tear Down: Fake Code4HK Mobile App ]

Today i’m going to talk about the Fake Code4HK Android application which the news reported here, The Code4HK guys had already long identified this Android mawlare this ( before the rest of the world did. However I probably should stop writing about Android malware but this one seems interesting for me to write though. 😛

As the thing happened almost 2weeks ago and the international activists only saw it yesterday. I was lucky to be able to grab a sample of this off Matthew Rudy Jacobs’s github. But i’ll be doing my own technical tear-down of this malware and hope to cover this comprehensively

[ Sample used in the analysis ]
MD5: 15e5143e1c843b4836d7b6d5424fb4a5
SHA1: c1e9ebd0b5ac7b6c50c69af219d163393d52df99

[ How it starts ]
It was first distributed via WhatsApp as shown in the image below.
As we can see, it’s asking participants of #OccupyCentral to download this url shortened link,
However, if you were to “Expand” this shortened URL, you will see the final url is,
That link is not valid anymore and furthermore, that suspicious url does not belong to code4hk.
The official url for code4hk is

Since it’s an Android malware, let’s check the permissions of this malware and further dissect it. Now, use apktool and run the following command:

Now let’s take a look at the AndroidManifest.xml file, you should see the following and the permissions requested by the APK file.

There are interesting meta-data available to us like the following found in the cert.rsa file.

The email could be useful but there are no hits on google using that.
Another interesting but not confirmed “findings” i have is maerts spelled backwards is “stream so could ITSC mean CSTI? Council of Science and Technology Institute? I’m not sure but i’ll let everyone’s imagination run. 😀

But let’s take a look at com.v1.MainActivity first, manually converting the initial Dalvik code back to pseudo Java code.
After disassembling the .apk file with apktool and checking the Android manifest file, the first thing that i check is the MainActivity class.
We will get back something like the one shown below. Looking through the codes, we can see that it’s starting another class, StreamService.

From my initial analysis, we can identify several things.
1.) It will open “qq.xml” from the Assets directory.
2.) It will create a new directory, “/sdcard/.qq/
3.) It read the contents of “qq.xml” and create a file, “/sdcard/.qq/temp.apk

If we had analysed the Android Manifest properly, “StreamService” will be started after reboot.
And if we were to analysed “StreamService” really carefully, it’s actually making use of AndroRat. 😛
If you had never seen AndroRat before, you can find a copy of it here.
So basically, it’s getting lots of other stuff from the victims as well. o.0″

[ PhoneReceiver ]
Now let’s take a look at “PhoneReceiver” class and we can see that it will start recording all outgoing calls made by the victim(s).
o.0″ Sounds malicious to me.

If we were to check the following Android documentations,
setOutputFormat –
setAudioSource –
setAudioEncoder –
We know that the Output format is 3GPP media file format.
The source for the recording is using Microphone audio.
The encoding used is AMR (Narrowband) audio codec.

There are other interesting findings such as the naming convention of the filenames are
out_” appended with the outgoing phone number followed by “_” and resides in “/data/data/com.v1/.record/
The file extension of the files are “.amr” as shown below.

[ StreamReceiver ]
One interesting thing is within the “StreamReceiver” class, it tried to read “getAll.dat” in a try..catch block and if it didn’t find it, it will activate the “features” of AndroRat”.
It will also try to read the contents of config.dat under “/assets/config.dat
This file actually contain an IP address, “” & a number “1430” which we can safely assume that it’s the port number.

It also tried to use Baidu to gather location data of the victim(s) as shown below.
The API could be found here:

Besides the IP address which we have highlighted earlier on, there are some other interesting IP address and domain name which are found within “StreamReceiver” class as shown below.

One thing which most people may not know is that mm usually stands for “木马” or “妹妹” in China context.
I highly doubt it meant the latter. xDDD
木马” means trojan horse. 😛

It also creates of other interesting files storing all the information that it “steals” from the victim(s).
But i won’t go through each and everyone of them.

From the whois information, we can gather more information on as shown below:

From the whois information, we can gather more information on as shown below:

[ FixTimeRecordReceiver ]
Now let’s take a look at “FixTimeRecordReceiver” class, we can see that the purpose of this is to record the audio using the MIC.
While it looks almost the same as “PhoneReceiver” but the recording starts in a fixed interval as it was set in “StreamService“.

There are other interesting findings such as the naming convention of the filenames are
FIX_TIME_” appended with “yyyyMMddHHmmss” (Date time of the system) and resides in “/data/data/com.v1/.record/
The file extension of the files are “.amr” as shown below.

[ Conclusion ]
While this is not one of the state of the art Android Trojan, but it’s probably one of the interesting one that makes use of a known coding group in Hong Kong and spread through WhatsApp.
But there will always be questions, why are they being targeted, why send through WhatsApp and i think the number used could be those easily available “pre-paid” data sim card in Hong Kong.

I hope that this is fairly simple to understand technical tear down that people can repeat the steps on their own and learn how to analyse Android Malware.

Happy Reversing,
Jacob Soo

[ Technical Tear Down: Fake WeChat Android App (Packed using Bangcle)]

[ Sample used in the analysis ]

MD5: 35C0A075CBC6135D957BD10769E3A620
SHA1: 554FD3D80B696F0677231A54F35B61B5774F2940

This is an Android malware found in the wild. You may be wondering what’s so special about this malware as there are thousands of Android malware out there. Well, this is one of the first few Android malware that has been packed. By being packed, it make reversing almost impossible for  static code analysis. As mentioned in my previous writeup, script from @timstrazz is available if bangcle is used to pack the apk.

As we at always encourages people to get their hands dirty, we have attached the malicious sample here.
The password is “infected29A

[ Tools Used ]
Cebero Profiler is used to disassemble the apk file to analyse the smali code.

Dex2Jar and Java Decompiler are used to decompile the apk file to a jar file and subsequently to get the java code for analysis.

Android Emulator is used for the dynamic analysis portion.

[ Before debangcling the app ]

As explained in my previous writeup, if Bangcle is used to pack an apk, when you try to reverse the file, you will notice a certain pattern like additional library files and new Java class files (ACall.class, ApplicationWrapper.class, FirstApplication.class). As shown in the picture below, this particular .apk when we decompile using dex2jar or disassembled using Profiler also contains similar files.


One thing my team and i found out is whenever we see this class (com.secapk.wrapper.ApplicationWrapper) and it’s be instantiated by default whenever the process is started.
We can safely deduce that it could have been packed using bangcle. So I tried using the script from @timstrazz found  here to unpack it.

Success!! It could be unpacked 🙂

[ Debangcled APK ]

The resultant of the debangcling process is a dex file which can now be reversed.


There are some obvious clues which flags out as a sorethumb to the analyst analysing the apk. Like the package name is called “com.example.banksteal“!! Who names their application banksteal anyway? And furthermore if your package name contains words like “example”, you can’t upload your apk into Google Playstore as it is deem as a generic name. So there are 2 things you can conclude even without analysing anything. 1st: This .apk is obviously from some third party market or circulated elsewhere other than the official Google Playstore. 2nd: This .apk is highly suspicious due to the naming conventions used. You can’t be 100% sure that this is a malware based on the above mentioned 2 pointers. So let’s delve in deeper.


The app requests for the following permissions:


Upon installing the app, you will get the following icon. This is the popular WeChat Android app, a Whatsapp like instant messaging app. The App is named as “Wēixìn” in Chinese which is the pinyin name for WeChat and means micro message.



When the app is invoked, it will first ask you for device admin permission for lock your phone, it can be seen from the code snippet below taken from the Launcher class.




and then for your credit card details as shown from the screenshot below when the app is executed on an emulator:


Next, more details will be asked like the type of bank from which the credit card was issued, card’s cvc number, expiry date, social security number, address etc



Let’s say, I chose the JCB card as my credit card and fill in all the details and click next:


I am running this in an emulator and it prompts that, “The email/message is not sent out!” I hope that my Chinese translation is accurate but then this raises another question of why a messaging app needs to send out an email. Let’s look into the source code for more evidence.

If you look at the BankData class, it summarises the data it harvests:



Under the Const class you will also get the email address of the receiver.



There are more clues in the MailUtil class where the host of the receiver is resolved.


In summary, this app requests for your credit card details and mail out these details.

Well ok, what’s wrong you may ask.

Just that in an actual WeChat app registration/installation no such details are required.

[Actual WeChat App]

Now let’s look at the actual WeChat app’s permissions when downloaded from the Google PlayStore.


You may think, this looks more malicious as it requests for much more permissions as compared to the previous app!!! But hold on.

Let’s take a look at the registration portion:



And that’s it. No credit card nor any bank details is required during installation nor registration of the official WeChat app.


The analysed application is an Android malware masquerading as the WeChat android application and request user for their credit card details. Supposedly to give the user a surprise at the end of the month!! On the other end the original app even though it requests for much more permissions, it does not cause financial loss for the user. This reiterates the point that users must not install app from unknown sources or third party markets. Most importantly, whichever app from third party or even the official Google Playstore requests for your credit card details, you are highly recommended to uninstall the app unless you feel generous 🙂

Another unique feature of this app is the usage of a packer. In this case, it is using Bangcle and we already have an unpacker available which helps in our analysis. What if a more complicated packer is used? It will further impede the analysis process. Then we have to only rely on dynamic analysis and if the apk is advanced enough to have anti-emulator techniques etc, how do we overcome this ? I will have another writeup on the possible dynamic analysis paradigm in the near future. If you have ideas, do share with us too.

David Billa (@billa316)

[ Android Packers: Bangcle ]

In this writeup, let’s take a look at Android packers in general before focusing on one of the more popular packer, Bangcle.

[An Introduction to Android Packers]

There are many useful reasons packers are used in software engineering, like for code obfuscation, compression, protecting your work against reverse engineers etc. The more sinister usage are for AV bypassing, masquerading malware and making the job of whitehat reverse engineers harder.

The common packers used for packaging EXEs are UPX Packer, RLPack, NSPack etc. As till recent times, the bulk of computer usage has been limited to PCs thus these were commonly used.

With the increase in usage of Android devices, different types of malicious Android applications were beginning to proliferate. In recent times, Android malware packaged using packers are beginning to surface in the wild.

A more detailed analysis on Android packers can be found here.  In the next section, I will be focusing on one of the increasingly popular Android packer which is being used for Android malware.

[Bangcle: Android Packer]


Bangcle is a mobile application security services provider company based in China. One of the services it offer is Android app protection as shown in the screenshot above.

A user just have to register and subsequently use the dashboard to upload your apk file and you will get the bangcled apk ready for use.


I tested with a simple Hello World application. Before bangcling this is how the app’s structure will look like.



After uploading the hello world apk to be bangcled the resultant apk will be as shown below:

hello-world-bangcledAfter the app has been bangcled you will have additional library files (, etc) and new Java class files (ACall.class, ApplicationWrapper.class, FirstApplication.class).

And the new bangcled application will also have additional permissions. Do take note that the actual hello world had no permissions initially.


The ACall.class file loads the additional libraries, FirstApplication.class file calls the super.onCreate function to initialize the activity and the ApplicationWrapper class subsequently loads the encrypted dex file which will be then be decrypted in the memory by the loaded libraries and finally executed. As it is being decrypted in memory, this makes static analysis of an Bangcled apk hard and tedious.

A more detailed writeup from Virus Bulletin can be found here.

[Reversing Bangcled APK]

In DEFCON 2014, TIM “DIFF” STRAZZERE (@timstrazz) presented and subsequently released the solution to debangcle a bangcled apk.

The full source can be found at his github acct here. Below is his shellscript portion.

To run his script (in a Linux environment), configure an Android enmulator (using AVD from the Android SDK) and install the bangcled apk in it using adb tools (adb install <bangcled-app.apk>).

Now execute his script after starting the app in the Android emulator. The dex will be decrypted in memory as discussed earlier. The script actually scans the memory in areas where an odex shouldn’t be to detect the magic bytes (“dey\n036”) for the optimized dex file and subsequently dumps out the specific memory portion as an dex file using baksmali. So the end product is an decrypted dex file which can now be analysed 🙂

[In Summary]

As the usage of Android increases, more variants and complex malwares are being now detected. As it was in PC malware ecosystem, packers are making inroads into Android now. Bangcle which is a China based Android packer created as a means to protect one’s apk is currently being misused for packing Android malwares making reversing hard.

However, bangcled apks can now be reversed for static analysis thanks to the great work by @timstrazz.

The next writeup will be on an technical teardown of a bangcled apk found in the wild recently.

David Billa (@billa316)


[ Technical Tear Down: UUPlay, ANDROID Malware ]

[ Sample used in the analysis ]
MD55: E7D6FEF2F1B23CF39A49771EB277E697
SHA1: F5735DC4D9502F99D3B62C49EF083B403D627124

We gotten this sample from Jacob’s old friend, “Amnesia”. UUPlay application portrays itself as an legitimate Google playstore application but it also doubles up as an malware in disguise, sending out victim(s)’ information from the device. You can check the VirusTotal detection rate here.

[ Tools Used ]
Cebero Profiler is used to disassemble the apk file to analyse the smali code.

Dex2Jar and Java Decompiler are used to decompile the apk file to a jar file and subsequently to get the java code for analysis.

Android Emulator and Burp Suite are used for the dynamic analysis portion.

[ Permissions ]

From the permissions list above, you can notice that it also haves the capability to download and install applications. Users may think that since it is a Google PlayStore app , it needs such permissions. But in this case, it also have the READ,WRITE and SEND SMS permissions. These permissions can be abused to send premium SMSes to premium numbers resulting in additional costs for the victim(s).

[ Source Code Analysis ]
The .apk is most probably obfuscated using ProGuard. From the screenshot below, one can notice that after reversing the .apk file, it seems bloated with multiple alphabetical java class files like any typical .apk file that is protected by ProGuard.


Thus it makes analyzing the source code harder. For more information on what ProGuard actually does, you can refer here.  In this analysis, dynamic analysis was primarily done to map out the behavior of the application.

[ Analysing Manifest File ]
From the manifest file, there are quite a lot of activities declared under the “” package.


For the list of Google Package names available for Android, you can refer to the list here. When checked against this list, it does not have any “” package. It is a clear sign that these might potentially be malicious activities running in the background masquerading as Google services.

Other than these activities, from the manifest file, it can also be deduced that a total of 3 services are running.


Two of the services are linked to the fake Google packages and the third service is supposedly a log service linked to the “com.uucun” package which is the main package name as noted from the manifest file.

Now let’s move on to the dynamic analysis portion.

[ Dynamic Analysis ]

Upon installing the uuplay.apk, the app’s icon does not appear under the device home or the application’s display. However, it can be found under the apps’ listings under Android system’s settings.

uuplay -appinfo

As you can notice, the icon is the same as the Google PlayStore’s icon.

The app can be started using Android Debug Bridge (adb) commands. From the manifest file, the main activity’s name can be deduced as RootActivity. The following command was used to invoke the main activity:

adb shell am start -n

After firing up the application, the UI is displayed as below.


Next, we used Burp Suite to monitor the network traffic. For instructions on configuring Android emulator to work with Burp Suite you can refer here.

Upon installing the app, information like imei number, sim card type, os version, date timestamp, app version and airpush version (mobile ads) were double url encoded and was posted to h–p:// as shown in the screenshot from Burp Suite below.

uuplay-burpsuite1Next it checks for updates for all the pre-installed apps from h–p://


If you search for any app, e.g Whatsapp, you can see that the searched information together with the phone information being posted out and subsequently the relevant apk file will be downloaded from h–p://

h–p:// is one of many un-official Android Marketplace from China.

While all these can be considered “fairly” normal behavior for an “Google PlayStore”, there are also other suspicious activities. Like at certain intervals (even when the app is not in use) encrypted data are being posted to urls like h–p://


The URL to which the data is posted is not hard-coded.  Meaning, sometimes the data are being posted to other URLs. But the key point is data (judging from the long list of permissions, it could be anything the app has access to) is being encrypted and were being ex-filtrated from the device.

[ Conclusion ]

In conclusion, uuplay is an application that masquerades as the official Google PlayStore application. It does similar activities like installing applications fetched mainly from the following urls:

– h–p://


At the same time, it also posts out personal information masked as log data to the following urls:




In short, install at your own risk!!

David Billa (@billa316)