CODEWITHSUNDEEP
androidobfuscation
Mehran Torki
Mehran Torki

Reputation: 987

Obfuscating android API

I was reading some article about different ways of obfuscating android apps in terms of protecting them from reverse engineering. One thing that came to my mind was that, is it possible to obfuscate android API? Suppose i have an android code like this:

import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.util.Base64;
import android.util.Log;

public class MainActivity extends AppCompatActivity {
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Log.d("Hello", "World");
    }
}

Is there any way to obfuscate the code to get something like this:

import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import x.y.z;

public class MainActivity extends AppCompatActivity {
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        z.w("Hello", "World");
    }
}

I came up with two ways:

  1. Creating a package x, having a sub-package y, having a class z. Class z must have a method named w that calls Log.d. Actually a layer of indirection is used here and reverse engineering is got just a little harder.
  2. Creating a package x, having a sub-package y, having a class z. Getting source code of android.util.Log from here and pasting the whole code inside class z (remember to rename method d to w). This will definitely increase code size but makes reverse engineering a lot harder.

Are these ways correct? Any easier way?

UPDATE:

An article mentioning android API can be obfuscated:

ViewDroid: Towards Obfuscation-Resilient Mobile Application Repackaging Detection, Section 5.2.1

Upvotes: 0

Views: 442

Answers (1)

CommonsWare
CommonsWare

Reputation: 1006704

Creating a package x, having a sub-package y, having a class z. Class z must have a method named w that calls Log.d. Actually a layer of indirection is used here and reverse engineering is got just a little harder.

Creating a tool to undo that indirection would not be especially difficult to create.

Creating a package x, having a sub-package y, having a class z. Getting source code of android.util.Log from here and pasting the whole code inside class z (remember to rename method d to w). This will definitely increase code size but makes reverse engineering a lot harder.

It also will not compile, as your app does not have access to com.android.internal.* symbols, the various native methods, etc.

Are these ways correct?

If by "correct" you mean "will compile and run", the first one will.

Upvotes: 1

Related Questions