Saturday, 20 September 2014

Being a security enthusiast, I had a good opportunity to talk on one of my interesting subject in mobile security: Android Malware Analysis at the null Open Security Community September 2014 Meetup held at SICSR (Symbiosis Institute of Computer Studies and Research), Pune.

Meetup Agenda:

10:00 am to 10:10 am
10:10 am to 10:45 am
News Bytes by Sneha Rajguru
10:45 am to 11:15 am
Android Malware Analysis by Shubham Aher
11:15 am to 12:00 pm
Secure coding in PHP  by Sneha Rajguru
12:00 pm to 12:15 pm
Feedback & Topic Discussion for Next Month meet
This was my first talk at null Meetup and I really enjoyed interacting with all the other inquisitive and like-minded security enthusiasts and professionals.

Alongwith the presentation, my talk required analyzing a couple of real-world Android malwares and demoing a few code snippets from these. So here are the download links for all the material:

Malware Samples Analyzed:

null is India's largest open security community. Registered as a non-profit society in 2010, we have been active since even before that. null is about spreading information security awareness. All our activites such as null Monthly Meets, null Humla, null Bachaav, null Puliya, null Job Portal are for the cause of that.

null is Open, is professional, is inclusive, responsible and most importantly completely vounteer driven.

Any questions/comments/suggestions/criticisms, feel free to post.

Wednesday, 1 May 2013

Many smartphone users ( including me ), don't like the new ring lockscreen that we get after some software updates on older HTC Sense 2.1 devices ( like my phone, which is HTC Salsa C510e ).

So here is a trick to change the ring lockscreen to a slide-to-side lockscreen as shown below:

Ring lockscreen changed to Slide-to-side lockscreen



1. Check HTC Sense version.
By navigating to "Settings" ==> "About phone" ==> "Software information", check if it says "2.1" under "HTC Sense version". This is how it should look:

2. Using any of your favourite file explorer app, navigate to /system/app/ . There will be a file named "HtcLockScreen.apk" (see the red box) :

3. Rename it to "HtcLockScreen.apk.bak". We dont delete it because if the trick doesn't work or if we want the ring lockscreen back, we can rename it to original name.

4. After renaming:

5. Reboot the phone. You will have the slide-to-side lockscreen after the phone starts.

Saturday, 27 April 2013


To learn to:
  1. Decompile the Native Android App File (.apk) into Java code (.java)
  2. Disassemble the Shared Object File (.so) into ARM Assembler Opcodes.
  3. Use of tools like IDA (Interactive Disassembler)dex2jarjd-gui, etc.
This tutorial introduces you to the basics of reverse engineering a Native Android app on Ubuntu.


    Tools Needed:

    • Android SDK (for adb and Emulators )
    • Dex2jar
    • AXMLPrinter2.jar (for converting a binary XML into textual XML)
    • jd-gui
    • signapk.jar (for re-signing the modified APK)


    • The general overview of steps required to carry for reversing a Native Android app are:

    I have put together all the tools and the target crackme APK file in one directory called "mycracklab", zipped and uploaded it. Download the and extract it anywhere you like. I have the "mycracklab" directory at /home/shubhuntu/mycracklab/


    $ pwd
    $ ls
    crackme.native-1.apk  tools

    Viewing files in the APK. An APK is a ZIP file with a .apk extension. So we use the "zipinfo" command.
    $ zipinfo crackme.native-1.apk
    Archive:  crackme.native-1.apk
    Zip file size: 153346 bytes, number of entries: 8
    -rw----     2.0 fat     1436 bX defN 13-Apr-08 16:45 AndroidManifest.xml
    -rw----     1.0 fat      576 b- stor 13-Apr-08 16:45 resources.arsc
    -rw----     2.0 fat     2924 bl defN 13-Apr-08 16:45 classes.dex
    -rw----     2.0 fat   268812 bl defN 13-Mar-13 22:29 lib/armeabi/gdbserver
    -rw----     2.0 fat    13432 bl defN 13-Apr-08 16:26 lib/armeabi/
    -rw----     2.0 fat      409 bl defN 13-Apr-08 16:45 META-INF/MANIFEST.MF
    -rw----     2.0 fat      462 bl defN 13-Apr-08 16:45 META-INF/CERT.SF
    -rw----     2.0 fat     1203 bl defN 13-Apr-08 16:45 META-INF/CERT.RSA
    8 files, 289254 bytes uncompressed, 152306 bytes compressed:  47.3%

    Starting the emulator.
    Using the Android's AVD Manager I have started an emulator running Android 4.2 that is API Level 17:

    Installing the APK in the emulator using adb.

    To install, I will use the Android Debug Bridge i.e. adb which is present in the "platform-tools" directory of the Android SDK.
    $ cd /opt/android/adt-bundle-linux-x86/sdk/platform-tools/
    shubhuntu@elf:/opt/android/adt-bundle-linux-x86/sdk/platform-tools$ ls
    aapt  adb  aidl  api  dexdump  dx  fastboot  lib  llvm-rs-cc  NOTICE.txt  renderscript
    $ ./adb install /home/shubhuntu/mycracklab/crackme.native-1.apk
    987 KB/s (153346 bytes in 0.151s)
     pkg: /data/local/tmp/crackme.native-1.apk

    If the command succeeds, that means it is installed and an icon for the app appears in the menu of emulator:

    Click on the app to start the crackme:
    As seen the crackme displays the message "Hello from JNI !". Our aim is to modify this message string.
    Let us begin our hunt for the message.
    Remember NOT to close the emulator !

                                                       DECOMPILATION (.dex to .jar to *.java files)
    Extraction of all the files from the crackme APK(which is actually a ZIP file).
    $ cd /home/shubhuntu/mycracklab/
    $ unzip -d extracted crackme.native-1.apk 
    Archive:  crackme.native-1.apk
      inflating: extracted/AndroidManifest.xml  
     extracting: extracted/resources.arsc  
      inflating: extracted/classes.dex   
      inflating: extracted/lib/armeabi/gdbserver  
      inflating: extracted/lib/armeabi/  
      inflating: extracted/META-INF/MANIFEST.MF  
      inflating: extracted/META-INF/CERT.SF  
      inflating: extracted/META-INF/CERT.RSA  
    $ cd extracted/
    $ ls
    AndroidManifest.xml  classes.dex  lib  META-INF  resources.arsc

    Conversion of the "classes.dex" file to "classes-dex2jar.jar" file.
    $ sh ../tools/dex2jar- classes.dex
    dex2jar classes.dex -> classes-dex2jar.jar


    Conversion of the .jar file to *.java files using jd-gui Java decompiler.


    Start the jd-gui tool.
    $ jd-gui classes-dex2jar.jar &
    [1] 4371

    Navigate to "File" ==> "Save All Sources" inside the jd-gui.
    Keep the default filename as it is: ""
    Click on "Save" button.

    Extraction of the *.java files into a directory called "javacode"
    $ ls
    AndroidManifest.xml  classes.dex  classes-dex2jar.jar  jd-gui.cfg  lib  META-INF  resources.arsc
    $ unzip -d javacode
       creating: javacode/android/
       creating: javacode/android/annotation/
      inflating: javacode/android/annotation/  
      inflating: javacode/android/annotation/  
       creating: javacode/com/
       creating: javacode/com/example/
       creating: javacode/com/example/hellojni/
      inflating: javacode/com/example/hellojni/  
      inflating: javacode/com/example/hellojni/  
      inflating: javacode/com/example/hellojni/  


    Converting the Binary XML into a Textual XML using AXMLPrinter2.jar
    $ java -jar ../tools/AXMLPrinter2.jar AndroidManifest.xml > AndroidManifest.xml.text
    $ ls
    AndroidManifest.xml  AndroidManifest.xml.text  classes.dex  classes-dex2jar.jar  javacode  jd-gui.cfg  lib  META-INF  resources.arsc
    $ vim AndroidManifest.xml.text

    This is how the textual XML will look:

    We come to know that the initial activity is ".HelloJni" which corresponds to "" source file and is in "com.example.hellojni" package.
    Open "" in any of your favourite Java editor.
    Following is the code of "":
    package com.example.hellojni;
    import android.os.Bundle;
    import android.widget.TextView;
    public class HelloJni extends Activity
      public void onCreate(Bundle paramBundle)
        TextView localTextView = new TextView(this);
      public native String stringFromJNI();
      public native String unimplementedStringFromJNI();
    /* Location:           classes-dex2jar.jar
     * Qualified Name:     com.example.hellojni.HelloJni
     * JD-Core Version:    0.6.2
    Its quite evident that the static code block which gets executed first is loading a native library named "hello-jni".
    So its full name will be ""

    Verifying the shared object file ""
    $ file ./lib/armeabi/
    ./lib/armeabi/ ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, stripped
    Also you can observe from the "" file, that the "setText()" method sets the text using the native method declared as:
    public native String stringFromJNI();

    We will now look for this "stringFromJNI()" method in the disassembled view of IDA inside the native file "".
    I am running the Windows version of IDA on Ubuntu using Wine but you can build and use the Linux version if you want.

    Select the file to disassemble in IDA:

    It will detect it automatically as an ELF Shared Object File. Click OK :

    ARM and THUMB SWITCH INSTRUCTIONS warning. Just click OK:

    This is the disassembled view of the "" file. Click on the "Exports" tab for viewing all functions exported by this library:

    Here is the list of all exports. The Java methods that are made native and implemented using this library are by default named in "Java_complete_package_name_ClassName_methodName" format.
    For e.g.:
    In our case, package name is "com.example.hellojni", class name is "HelloJni" and method name is "stringFromJNI" so the function name in exports will be "Java_com_example_hellojni_HelloJni_stringFromJNI".

    Click on this function, and IDA will show you the ARM opcodes for this function:

    This is the disassembled view of the function. IDA is so powerful that it comments the code where strings are used. Thus as you can see that IDA has commentend our string (I have highlighted it with a red box below). Also we come to know that the string "Hello from JNI !" is declared as a variable named "aHelloFromJni".

    Double-click on "aHelloFromJni" and it will show you the declaration of string.

    As you can see, "aHelloFromJni" is defined as "Hello from JNI !" with the DCB assembler directive.

    DCB is an ARM Assembler Directive that stands for Define Constant Byte.

     Now click on the "Hex View" tab, and you will see the Hex Dump for the defined string.
    Click on the first character of the string i.e. 'H', and at the status bar at the bottom you will get the file offset of the beginning of the string literal.

    In this case it is 0x2030.


    Using any of your favourite Hex Editor (I have used Bless Hex Editor), open the file "" and go to file offset 0x2030.

    Replace the original string bytes with new bytes and save the file.
    I have replaced the original string "Hello from JNI !" with "Bye.. from JNI !"
    Warning#1: As it is a binary ELF shared object file, take care that you replace only the original bytes in the string "Hello from JNI !" starting from the offset 0x2030 till 0x203F.
    Warning#2: Also see that you "REPLACE" and not "INSERT".

    Now as we have modified the "" file we need to update the modified file in the "crackme.native-1.apk" file and also resign the "crackme.native-1.apk" !

    Updating the modified library file inside the .apk file.
    $ zip ../crackme.native-1.apk -u lib/armeabi/ 
    updating: lib/armeabi/
     zip warning: Local Entry CRC does not match CD: lib/armeabi/
     (deflated 61%)
    Step#22: Re-signing the updated .apk file.
    $ cd ..
    $ java -jar ./tools/signapk.jar ./tools/testkey.x509.pem ./tools/testkey.pk8 crackme.native-1.apk crackme.native-1-SIGNED.apk


    Merely installing the new crackme will give error as the fully qualified name of both the original and modified crackme will conflict because of being same (com.example.hellojni).
    So before installing our modified apk, we need to uninstall the previous one.

    Uninstall the previous crackme manually by navigating to "Settings" ==> "Manage Applications".

    In order to test our new modified apk, we need to go to "platform-tools" directory of the SDK:
    $ cd /opt/android/adt-bundle-linux-x86/sdk/platform-tools/
    P.S.: The emulator is still running.

    Install modified APK (crackme.native-1-SIGNED.apk) in Emulator using adb.
    $ ./adb install /home/shubhuntu/mycracklab/crackme.native-1-SIGNED.apk 
    970 KB/s (153453 bytes in 0.154s)
     pkg: /data/local/tmp/crackme.native-1-SIGNED.apk

    Click the icon to run the crackme.

    Monday, 21 January 2013


    To learn to:
    1. Decompile the Android App File (.apk) into Java code (.java)
    2. Disassemble the Dex File (.dex) into Dalvik Opcodes (.smali)
    3. Use of tools like adb(Android Debug Bridge), dex2jar, jd-gui, etc.
    Besides above things, this tutorial introduces you to the basics of reverse engineering on Android platform.

    Tools Needed:

    • Android SDK (for adb and Emulators )
    • EasyAPKDisassembler ( Its batch utility created by some XDA member that supports disassembling, converting binary XML to textual XML, APKtool assembly/disassembly, Signing/Designing Certificates, etc)
    • Dex2jar
    • WinRAR or any archive tool (with .zip file support)
    • jd-gui or any other Java decompiler.

      Steps for DISASSEMBLING (.dex to .smali) :

      1. Copy the target APK file ( TestHelloWorld.apk ) to "platform-tools" folder inside the main "android-sdk" folder. For e.g. On my machine Android SDK is in "D:\Program Files(x86)\Android\android-sdk\platform-tools"

      2. Copy the Command Prompt(cmd.exe) from your system files into "platform-tools" folder and double click it to type following commands:
      D:\Program Files (x86)\Android\android-sdk\platform-tools>adb devices
      List of devices attached
      emulator-5554   device
      D:\Program Files (x86)\Android\android-sdk\platform-tools>adb install TestHelloW
      24 KB/s (5546 bytes in 0.220s)
              pkg: /data/local/tmp/TestHelloWorld.apk

      3. "adb devices" tells us the list of running emulators.

      4. We install the APK package with "adb install TestHelloWorld.apk" command.

      5. Lets check and see the app in emulator:

      6. Download and extract "" in a folder anywhere you like. Also copy the "TestHelloWorld.apk" in the same folder.

      7. Open "TestHelloWorld.apk" with WinRAR or any other archive tool that supports the ZIP format as .APK is nothing but a .ZIP file with a different extension. From this file extract the "classes.dex" into the same dir where you extracted the "" files :

      8. Start "EasyApkDisassembler.EN.bat" , press option 2 and give the name of the file as "TestHelloWorld.apk" :

      9. Now the "classes.dex" file is disassembled into the same folder with a name as "out_TestHelloWorld.apk". This folder contains all the disassembled source code in Dalvik Opcodes format (.smali) files :

      10. Navigate to "\out_TestHelloWorld.apk\com\example\android\helloactivity\" :

      11. You will see many .smali files. Open the "HelloActivity.smali" file in Notepad or any other text editor you like :

      .class public Lcom/example/android/helloactivity/HelloActivity;
      .super Landroid/app/Activity;
      .source ""
      # direct methods
      .method public constructor ()V
          .registers 1
          .line 27
          invoke-direct {p0}, Landroid/app/Activity;->()V
          .line 28
      .end method
      # virtual methods
      .method public onCreate(Landroid/os/Bundle;)V
          .registers 3
          .parameter "savedInstanceState"
          .line 35
          invoke-super {p0, p1}, Landroid/app/Activity;->onCreate(Landroid/os/Bundle;)V
          .line 39
          const/high16 v0, 0x7f02
          invoke-virtual {p0, v0}, Lcom/example/android/helloactivity/HelloActivity;->setContentView(I)V
          .line 40
      .end method
      12. You have successfully disassembled the .dex file into .smali file. In order to understand the .smali code you will need to go through the Dalvik Opcodes List.

      13. The disassembled file in .smali format is very easy to patch. In my upcoming Android reversing tutorials I will be covering patching the Dalvik Bytecodes.

      Steps for DECOMPILING (.dex to .java) :

      1. Download latest copy of "dex2jar" tool and extract its content in the same folder where you extracted the "" files as in above part. Also copy the same "classes.dex" into "dex2jar-" folder :

      2. Within the "dex2jar-" folder, open the command prompt and type following command :
      dex2jar classes.dex

      3. After the command completes you will see the "classes_dex2jar.jar" file in the same folder. You can extract this .jar file into a folder you like and you will see many .class files. Open the "HelloActivity.class" file in "jd-gui" or any other java decompiler you like :

      4. You have successfully decompiled the .dex file into .java file.

      Download Links:

      1. EasyAPKDisassembler: or

      2. Dex2jar:

      3. WinRAR:

      4. jd-gui: 

      Friday, 10 August 2012



      In this tutorial we will learn how to "fish" i.e. find a hardcoded password from a Win32 crackme using OllyDbg Debugger.


      You are given a simple crackme (32-bit .exe file)


      1. This is a Flash Video tutorial.
      2. Download OllyDbg from here.
      3. Unzip anywhere you want and run the ollydbg.exe file as per the tutorial.
      4. Download the simple Win32 Crackme File.
      5. For the flash video tutorial there are two options:



      1. Download the actual flash video tutorial from here.
      2. Unzip Win32 RCE anywhere you want and open the Win32 RCE Tut1.htm file in your favourite browser. Note: Your browser should support flash(.swf) files. If it doesn't then download the flash video plugin for your browser.
      3. In case you are not able to play the file in browser, you can play the Win32 RCE Tut1.swf file directly in K-Lite Codec Pack's Media Player Classic.

      Monday, 23 July 2012


      In this tutorial we will learn how to patch the bytecode present in the class file of the simple crackme which we used in the previous tutorial.


      You are given a simple crackme (Java .class file)


      • JavaBite - My favourite Java bytecode viewer/editor


      1. Lets first run the given crackme file (SimplePasswordCheck.class) and see what happens:

      2. If we type "john" as password, it results in "ACESS DENIED" that means the password "john" is wrong.

      3. Now open the class file in JavaBite by navigating to 'Classes | Add Java Class' in the menu. We will not use any java decompiler(like we did in previous tutorial) as we are going to study the class file at a more granular i.e. assembly(java opcode) level.

      4. After opening the file you will see something like this:

      5. In the left-hand side column, expand the tree by navigating from the class file to 'Methods | main'. After selecting 'main', the bytecodes of 'main()' method will be loaded in the right-hand side column. This is the opcode/assembly representation of the body of the 'main()' method. After loading, it should like this:

      6. In the loaded bytecode, there are 3 columns:
      1. '#' - The bytecode index (in hex).
      2. 'ByteCode' - The actual hex representation of the bytcode.
      3. 'Disassembled' - The disassembled representation of the java opcodes.
      7. All the words like 'new', 'dup', 'getstatic', 'invokespecial', 'astore_1', 'ldc', 'invokevirtual', 'ifeq', 'goto', 'return' are infact the java opcodes. In order to understand them properly you should go through the 'Java Virtual Machine Instruction Set'.

      8. As we have know from the previous tutorial that this crackme has 'shubham' as the password, we see the same string as being the argument to 'ldc' instruction at bytecode index '000B' in the loaded bytecode.(See below):

      ldc #0005<shubham>

      See the specification for the 'ldc' instruction at

      Short Explanation: The argument (number) '0005' is a reference to the string literal "shubham" in the constant pool of the loaded class file.

      9. Traversing down in the loaded opcodes, we see a line of our interest the 'ifeq' check ! This is the appropriate line to patch as it is a validation check for the password.

      ifeq 0000002E
      See the specification for the 'if<cond>' instruction at

      Short Explanation: The eq succeeds if and only if value = 0. That means if the comparison with 0(false) succeeds then it branches to the address given in the argument. So in above e.g., if the condition is false then it jumps to bytecode index '0000002E' that is at line:

      002E          B20006          getstatic #0006< java.lang.System.out>'

      10. Next we see that the string "ACCESS DENIED :-(" is loaded. This confirms that the current line(bytecode index '0031') is the line inside the 'else' block of the 'if-else' statement.

      11. So we now, actually patch the 'ifeq' line at bytecode index '0020' as shown below:

       Select the line. Righclick and choose 'Edit instruction'.

      12. Now the 'Edit Instruction' box will pop up. Select 'ifne' from the 'Instruction' dropdown list.

      13. Also double click the 'BRANCH_OFFSET' item in the 'Parameters' tab and a 'Edit Branch Offset' box will pop up. Select '002E - getstatic' from the 'Branch to line' dropdown list of the 'Branch Offset' tab.(see below)

      14. Thats it! 


      We have changed the 'ifeq' conditional instruction to the 'ifne' conditional instruction i.e. we have inverted the conditional check. But why ? What we have done is that we have patched the crackme such that for every password input other than the original("shubham") the crackme will result in displaying the message "ACCESS GRANTED :-)" that means for any password(except original) the true case of if-else check is executed.


      If you have not understood this tutorial then you must be lacking the knowledge of Java opcodes. Please go thoroughly from the 'Java Virtual Machine Instruction Set'.



      To learn how to use the decompiler in reverse engineering.


      You are given a simple crackme (Java .class file)



      1. Lets first run the given crackme file (SimplePasswordCheck.class) and see what happens:

      2. If we type "john" as password, it results in "ACESS DENIED" that means the password "john" is wrong.

      3. Open the class file ( SimplePasswordCheck.class) in jd-gui decompiler. You will see the following decompiled code:

      class SimplePasswordCheck
        public static void main(String[] paramArrayOfString)
          throws Exception
          DataInputStream localDataInputStream = new DataInputStream(;
          String str1 = "shubham";
          System.out.println("\nPlease enter your password: ");
          String str2 = localDataInputStream.readLine();
          if (str2.equals(str1))
            System.out.println("\nACCESS GRANTED :-) ");
            System.out.println("\nACCESS DENIED :-( ");

      4. The string "shubham" is assigned to String variable 'str1' and the input password is taken in String variable 'str2'.

       5. There is a simple if-else check to compare if 'str1' and 'str2' are equal that means the string "shubham" is a hardcoded password !!

      6. So we have fished out the hardcoded password from the decompiled code of the class file. Lets try this fished password to check if it works:


      This tutorial covered how to fish out the password from a class file by using a decompiler. However such technique of using only decompilation is not feasible in complex(obfuscated) programs. In such a case you may need to use other techniques like patching the actual and appropriate bytecode in the class file by studying the check/validation process at a more granular level.

      The purpose of this tutorial was to make you understand the use of decompiler in reverse engineering, understand the scope of finding hardcoded password.

      However, in the 'Java Reverse Engineering Tutorial#3' , we will reverse engineer this very same crackme with a different approach - Java bytecode patching. This will clear the significance of using both the techniques.


      In case you are unable to run the given .class file crackme, you can compile for yourself the sourcefile( for this tutorial.



      Whats the size of Boolean Datatype in Java ? 1bit, 8bit, etc ?
      In this tutorial we will study the size of the most speculated datatype in Java: Boolean. The reason for this is that many people think that Boolean's size is 1 bit but thats not possible, so may be its the minimum possible 8bits. No. Its not either. Well, we will use reverse engineering to see actually what is the size actually assigned in the class file.

      Tools Needed:


      1. Copy paste the following code in your favourite java sourcecode editor:
      class BooleanSize
       public static void main(String args[])
        boolean myboolean;

      2. Save and Compile the Java Sourcecode file to generate class file.
      C:\Program Files (x86)\Java\jdk1.6.0\bin>javac
      3. A file named as "BooleanSize.class" is generated.

      4. Open this file in jd-gui java decompiler. You will see the following output:
      class BooleanSize
        public static void main(String[] paramArrayOfString)
          int i = 1;


      So after decompiling the class file we observe that, the boolean variable that we declared is actually an 'int'. Why ? Because, the actual size of a boolean type is not defined correctly by the Java Specification itself.
      In the boolean section, it says: 
      The boolean data type has only two possible values: true and false. Use this data type for simple flags that track true/false conditions. This data type represents one bit of information, but its "size" isn't something that's precisely defined.
      So why 'int' ? Actually, it is VM-dependent. I used a 32bit Java Compiler to compile and it assigns size of an  'int' to a 'boolean'.


      Hence, the size of boolean datatype in Java is VM-dependent and not a fixed size like 1bit or 1 byte.