KR20120126920A - Method for Anti-Encoding Android by Using Java Native Interface - Google Patents

Abstract

PURPOSE: An Android obfuscation method with a JNI(Java Native Interface) is provided to prevent the exposure of text string data by converting a text string into the JNI and implementing a class and method call part with a callback method of the JNI. CONSTITUTION: All of variables, methods, and classes are changed into a specific text format by changing classes and functions defined in an AndroidManfest.xml(S100). A declared text string of a byte code is changed into a JNI which is a binary code(S300). A part calling a class method in an object oriented program is removed from a Java source code and changed into a part calling the JNI(S400). [Reference numerals] (AA) Start; (BB) End; (S100) Changing all variables, methods, and classes in a java file into a, b, and c formats; (S200) Changing a text row in the java file into an SO library; (S300) Changing a byte code into a JNI, binary code; (S400) Removing a class method call part from a java source code and changing into a JNI call part; (S500) Calling a java function by the JNI

Description

Method for Anti-Encoding Android by Using Java Native Interface}

The present invention relates to an Android obfuscation method using JNI, and more specifically, to protect against decompilation of Android using the Dalvik language, a string is converted into a Java Native Interface (“JNI”). It's about Android obfuscation using JNI to make changes and cause called functions to be called via JNI.

Among the popularization of smartphones, Android is the most popular terminal platform.

However, Android uses Dalvik, a language similar to Java (JAVA), so it is easy to be exposed to reverse compilation.

With these shortcomings, in recent years, tools such as dex have been introduced for decompiling, and obfuscation techniques for defending decompilation have been urgently needed.

On the other hand, when Java is compiled, it is created as a class file and the executable file becomes a class file. However, Android uses an executable file with the extension of apk.

The apk file is implemented in the form of a general zip compressed file, and the structure of the file is shown in Table 1 below.

Filename Explanation AndroidManifest.xml apk executable file
Permission to use, class to use, and structure Classes.dex Actually java source file is compiled META-INF Folder where authenticated key values are stored res Images and layouts related to graphics lib so library

When programming the java file is classes.dex. It is changed to a file that contains the values of all java classes tied together for easy recognition by the Dalvik virtual machine.

1 is a diagram illustrating a conventional reverse compilation method, FIG. 2 is a view showing an example of a class file changed through a conventional reverse compilation, and FIG. 3 is a view showing a file list changed to a class file through a conventional reverse compilation. 4 is a view showing a source view state through a conventional JD reverse compiler.

As shown in Figs. 1 to 4, the classes.dex. File first undergoes a process of dex file generation into a class and then back-compiled into a java file.

As such, it can be changed into a class file as shown in FIG. 2 through a reverse compiler.

The classes.dex. File is decompiled and represented as a class file having the name c $ 1.class in FIG.

If the class file is decompiled through JD, which is a general Java decompiler, the source can be viewed as shown in FIG.

An object of the present invention for solving the above problems is to extend the level of obfuscation using JNI to change the class and method names to Android, and to extend the level of obfuscation using JNI, which is an extension of the existing Java obfuscation technology. The present invention provides a method for obfuscation.

Another object of the present invention is to provide an Android obfuscation method using JNI, which makes it impossible to know what the actual code does even through code through decompilation.

Still another object of the present invention is to provide an Android obfuscation method using JNI, which makes it impossible to extract a source by reverse engineering when a function is called through JNI.

An object of the present invention as described above, the obfuscation method for preventing the reverse compilation of the Android source, the first step of changing all variables, methods and classes in the Java file to a specific character format; And a second step of changing a string into a so library in the Java file, wherein the second step comprises: a second step of changing a declared string of bytecode into JNI, which is a binary code; And step 2-2 of removing the part of the class method call from the object-oriented program from the Java source code and changing the part of the JNI call to the part of calling the JNI.

In addition, according to the present invention, characterized in that it further comprises the step of changing the classes and functions defined in the AndroidManfest.xml.

In addition, according to the present invention, the first step is characterized in that it further comprises the step of declaring the package path in the package of the mainfest tag in AndroidManfest.xml.

According to the present invention, the first step may further include finding and changing the location of the class in the source file with reference to the package name and the class name.

Further, according to the present invention, the first step, the specific character is a 'a', 'b,' c 'format, limiting the number of characters used so that reverse engineering is not convenient to only the first head of the string, Characters are characterized by increasing the number in the format 'a1', 'b1', 'c1'.

In addition, according to the present invention, the second step, characterized in that it further comprises a second to third step is called via a JNI when the function is called.

In addition, according to the present invention, the step 2-3 may include: checking original Java code called by another class when a function is called; Finding a string of the changed Java file corresponding to the called function; And calling a function corresponding to the string with JNI.

Also, according to the present invention, the second step may further include the step of declaring a method private when calling a Java method through a callback function in a JNI class.

According to the Android obfuscation method using the JNI of the present invention, there is an effect that can not know what the actual code behaves even through the code through the reverse compilation.

According to the Android obfuscation method using the JNI of the present invention, the flow is interrupted by changing the string to JNI to prevent the exposure of the string data, and implementing the class and method call parts for using the function as JNI callback methods. It is effective to make.

According to the Android obfuscation method using the JNI of the present invention, when the function is called through the JNI, the source extraction is impossible by reverse engineering.

1 is a diagram illustrating a conventional inverse compilation method.
2 is a view showing an example changed to a class file through the conventional inverse compilation.
3 is a view showing a file list changed to a class file through a conventional reverse compilation.
4 illustrates a source view state through a conventional JD reverse compiler.
5 is a flowchart of an Android obfuscation method using JNI according to an embodiment of the present invention.
6 is a diagram showing an example of a package path declaration in AndroidManifest.xml according to an embodiment of the present invention.
7 is a diagram illustrating a process of calling a call function through JNI according to an embodiment of the present invention.

The terms and words used in the present specification and claims should not be construed as limited to ordinary or dictionary terms and the inventor may appropriately define the concept of the term in order to best describe its invention It should be construed as meaning and concept consistent with the technical idea of the present invention.

Therefore, the embodiments described in the specification and the drawings shown in the drawings are only the most preferred embodiment of the present invention and do not represent all of the technical idea of the present invention, various modifications that can be replaced at the time of the present application It should be understood that there may be equivalents and variations.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

In general, Dex file and class file are interpreted by writing byte code. Unlike binary, it is possible to decompile and see the actual source.

Java does not use JNI widely to maintain platform-independent benefits by default, but Android code does not need to be platform-independent because it only works on Android. Therefore, if you use JNI obfuscation, you can expect excellent performance to prevent reverse engineering.

Android has a Linux operating system and library files have a so file extension to communicate with the JVM. JNI is more difficult to reverse engineer than a normal library because of this communication code with Dalvik.

Recently, Android provides JNI by default and build tool called Android NDK. JNI basically puts the library declaration function as a static variable within the class.

First, let's explain the basic source form of JIN.

static {System.loadLibrary ("android_security");}

As above, the module name is basically compiled with lib in front of it. If the module name is libandroid_security.so, android_security should be called in the actual module.

public native void <method name>;

Also, if you declare as above with native function, the relevant method is called and used.

Return data type Java_ <package name> _ <class name> _ <method name>

When writing JNI, C code creates a method with the same rules as above to communicate with the corresponding Java file.

jbyte

Java_kr_co_soongsil_VirusCheck_charJNI1 (JNIEnv * env,

                                                  jobject thiz)

{

return 'e';

}

JNIEnv * env, jobject thiz is a part that must be entered, and the argument value received after the corresponding argument value is included.

The format below is a part of calling method charJNI1 of VirusCheck class of kr.co.soongsil package that returns byte type.

5 is a flowchart of an Android obfuscation method using JNI according to an embodiment of the present invention, FIG. 6 is a diagram illustrating an example of a package path declaration statement in AndroidManifest.xml according to an embodiment of the present invention, and FIG. 7 is an embodiment of the present invention. 2 is a diagram illustrating a process of calling a call function through JNI.

Referring to FIG. 5, in the Android obfuscation method using JNI, all variables, methods, and classes in a Java file are changed to a, b, and c (S100).

At this time, change the class defined in AndroidManfest.xml as well.

Since Android has a class defined in AndroidManifest.xml, it is difficult to change the defined class by the existing Java Obfuscation method. For Android obfuscation, modify the defined class of AndroidManifest.xml and The name of the class being replaced must also be modified at the same time.

Also, the class used in Android is defined in AndroidManifest.xml. Therefore, the existing class name cannot be changed only by the existing Java obfuscation technique.

As of Android 2.3, the Proguard obfuscation tool has not been able to change the xml. However, for complete obfuscation, the function defined in AndroidManifest.xml must be changed so that its contents are difficult to understand by class name.

More specifically, as shown in Figure 6, in AndroidManifest.xml, the package path is declared in the package of the manifest tag.

The tags defined by class are shown in Table 2 below.

event Explanation Activity Activity that launches the screen Receiver Receiver receiving an event Service Service running in the background

Refer to the package name and the class name to find the location of the class in the source file, change it, and change the names of all other classes.

Only five letters from a to c are used. This is because looking at a to z makes reverse engineering easier with just the beginning of the string.

When A, b, and c are crossed, it proceeds in the order of a1, b1, b1, a2, b2, b3.

After changing the class, you need to change the method. Similarly, change the method in the form a1, b1. Select the method inside the class and refer to the method to change it.

Next, change the string in the Java file to the so library to communicate (S200), and in the case of the byte code String, since the string exposure, which is a chronic weakness, exists, change to the binary code JNI to avoid this. (S300).

When using private-key cryptography, if a particular encryption-related key is put into a string, reverse engineering simply extracts the key. In the case of strings that leak or reluctant information, such as specific URLs, changing the data to JNI makes it difficult to find the information even during reverse engineering.

You can implement this by writing code that takes a string between quotes and returns it as a result in JNI. In the meantime, the native method name is randomly generated, making it more difficult to recognize.

An example of this method is shown below.

String st = “test_string”;

The string test_string is declared as a String, and the quotes are changed to getString JNI as shown below.

String st = getString (test_string);

An example C code for JNI communication is shown below.

jstring

Java_kr_co_testsungsil_TestJni_getString (JNIEnv * env,

                                                  jobject this, jobject test_obj)

{

    return (* env)-> NewStringUTF (env, test_obj);

}

As shown in Figure 7, the object-oriented program calls the class method in the JAVA source code and removes the part to call the JNI (S400), JNI calls a function of the Java, so that the user can It cannot be determined whether the method is called (S500).

In essence, all of the Android base class's methods can be changed with JNI callbacks. Therefore, it is extremely difficult to infer what the class does with only the decompiled JAVA source.

Table 3 below shows functions and classes for JNI.

GetObjectClass jclass class_Employee = (* env)-> GetObjectClass (env, obj_this); FindClass jclass class_String
= (* env)-> FindClass (env, ”java / lang / String”) GetFieldID jfieldID id_salary
= (* env)-> GetFieldID (env, class_Employee, ”salary”, ”D”);

As shown in Table 4 below, when calling a Java method through a callback function in a JNI class, the method must be declared private.

JNI to call class methods jint
Java_kr_co_testsungsil_TestJni_callMethod (JNIEnv * env, jobject obj)
{
jclass cls = (* env)-> GetObjectClass (env, obj); // Get the current class.
jmethodID aMethodID = (* env)-> GetMethodID (env, cls, "callbackmethod", "(I) V");
int myvar = 7;
(* env)-> CallVoidMethod (env, obj, aMethodID, myvar);
}

Also, when calling a Java function with JNI, the function used in Java can be passed as an argument value as shown in Table 5 below.

Pass OBJECT argument Java_kr_co_testsungsil_TestJni_callMethod2 (JNIEnv * env, jobject obj, jobject test_obj)
{
jclass cls = (* env)-> GetObjectClass (env, obj); // get the object class
jmethodID aMethodID = (* env)-> GetMethodID (env, cls, "callbackmethod2", "(Ljava / util / ArrayList;) V"); // return value void argument value int
(* env)-> CallVoidMethod (env, obj, aMethodID, test_obj);
}

And, when calling other classes other than Java calling JNI as shown in Table 6 below, find class information by using FindClass function. CallObjectMethod can be used to call the method, get the return value from the called method, and pass it back to JAVA through JNI.

Passing Information of Other Classes jobject
Java_kr_co_testsungsil_TestJni_callClassMethodReturn (JNIEnv * env, jobject obj, jobject test_obj)
{
jobject rtnobj;
jclass cls = (* env)-> FindClass (env, "kr / co / testsungsil / TestClass"); // get the object class
jmethodID aMethodID = (* env)-> GetMethodID (env, cls, "testMethodReturn", "(Ljava / util / ArrayList;) Ljava / util / ArrayList;"); // return value ArrayList argument value ArrayList

if (aMethodID == 0) {
} else {
rtnobj = (* env)-> CallObjectMethod (env, obj, aMethodID, test_obj);
}
return rtnobj;
}

As shown in Table 6, if you change the method, you won't even know how to call the method or the class invocation.

You can also change the default functions used by Android. If you change the default function through JNI, even if you actually decompile, it is almost impossible to look at the code and find out what it is actually doing.

For example, the ANDROID codes are shown in Table 7 below.

ANDROID CODE static {System.loadLibrary ("test_security");}

public native void contentView (int m);

public void onCreate (Bundle savedInstanceState) {
super.onCreate (savedInstanceState);
// setContentView (R.layout.main); // actual code
contentView (R.layout.main); // call JNI code
}

In Table 7, the setContentView function applies the XML LAYOUT provided by Android to the screen.

However, as shown in Table 8 below, the function can be called through JNI.

JNI to call Android native functions Java_kr_co_testsungsil_TestJni_contentView (JNIEnv * env, jobject obj, jint test_main)
{
jclass cls = (* env)-> FindClass (env, "android / app / Activity");
jmethodID aMethodID = (* env)-> GetMethodID (env, cls, "setContentView", "(I) V");
(* env)-> CallObjectMethod (env, obj, aMethodID, test_main);
}

In this way, if you change the entire class and method of the Android program to characters that are difficult to understand and change to JNI, reverse engineering is almost impossible.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is clearly understood that the same is by way of illustration and example only and is not to be taken by way of limitation, It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present invention as defined by the appended claims and their equivalents.

Claims (8)

In the obfuscation method to defend against decompilation of Android source,
A first step of changing all variables, methods, and classes in the Java file to a specific character format; And
Including the second step of changing the string into the so library in the Java file,
The second step,
Step 2-1 of changing the declared string of the byte code to JNI, which is a binary code; And
The method of Android obfuscation using JNI, comprising the step 2-2 of removing the part of calling the class method in the object-oriented program from the Java source code and the part of calling the JNI.
The method of claim 1,
The first step is,
Android obfuscation method using JNI, characterized in that it further comprises the step of changing the classes and functions defined in AndroidManfest.xml.
The method of claim 1,
The first step is,
The Android obfuscation method using JNI further comprising the step of declaring the package path in the package of the mainfest tag in AndroidManfest.xml.
The method of claim 1,
The first step is,
The Android obfuscation method using JNI further comprising the step of finding and changing the location of the class in the source file with reference to the package name and the class name.
The method of claim 1,
The first step is,
The specific characters are in the form of 'a', 'b,' c ', limiting the number of characters used so that reverse engineering is not convenient with the first head of the string, and the additional characters are' a1 ',' b1 ',' Android obfuscation method using JNI, characterized by increasing the number in c1 'format. The method of claim 1,
The second step,
Android obfuscation method using JNI, characterized in that it further comprises the second to third steps that are called via JNI when the function is called.
The method according to claim 6,
The second step is,
Checking the original Java code that is called by another class when the function is called;
Finding a string of the changed Java file corresponding to the called function; And
Android obfuscation method using JNI comprising the step of calling a function corresponding to the string with JNI.
The method of claim 1,
The second step,
In the case of calling a Java method through a callback function in a JNI class, the method further includes declaring the method as private.

Images