Shulou(Shulou.com)06/02 Report--

This article is to share with you about the Android Java layer of anti-hooking skills is how, the editor feels very practical, so share with you to learn, I hope you can learn something after reading this article, say no more, follow the editor to have a look.

Preface of 0x00

A recent approach to detecting native hook frameworks got me thinking about how an Android application can detect Cydia Substrate or Xposed frameworks at the Java layer.

Declaration:

All of the following anti-hooking techniques can be easily bypassed by experienced reverse personnel, and here are just a few detection methods. This type of anti-hooking detection is not available in tools such as DexGuard and GuardIT recently, but I'm sure it will be added soon.

Application of 0x01 detection installation

One of the most direct ideas is to check whether Substrate or Xposed framework is installed on the device, you can directly call PackageManager to show all the installed applications, and then see if Substrate or Xposed is installed.

#! java

PackageManager packageManager = context.getPackageManager ()

List applicationInfoList = packageManager.getInstalledApplications (PackageManager.GET_META_DATA)

For (ApplicationInfo applicationInfo: applicationInfoList) {

If (applicationInfo.packageName.equals ("de.robv.android.xposed.installer")) {

Log.wtf ("HookDetection", "Xposed found on the system.")

}

If (applicationInfo.packageName.equals ("com.saurik.substrate")) {

Log.wtf ("HookDetection", "Substrate found on the system.")

}

}

0x02 checks the call stack for suspicious methods

Another method that comes to mind is to check for suspicious methods in the Java call stack, actively throw an exception, and then print the method's call stack. The code is as follows:

#! java

Public class DoStuff {

Public static String getSecret () {

Try {

Throw new Exception ("blah")

}

Catch (Exception e) {

For (StackTraceElement stackTraceElement: e.getStackTrace ()) {

Log.wtf ("HookDetection", stackTraceElement.getClassName () + "- >" + stackTraceElement.getMethodName ())

}

}

Return "ChangeMePlskeeper!"

}

}

When the application is not hook, the normal call stack looks like this:

#! bash

Com.example.hookdetection.DoStuff- > getSecret

Com.example.hookdetection.MainActivity- > onCreate

Android.app.Activity- > performCreate

Android.app.Instrumentation- > callActivityOnCreate

Android.app.ActivityThread- > performLaunchActivity

Android.app.ActivityThread- > handleLaunchActivity

Android.app.ActivityThread- > access$800

Android.app.ActivityThread$H- > handleMessage

Android.os.Handler- > dispatchMessage

Android.os.Looper- > loop

Android.app.ActivityThread- > main

Java.lang.reflect.Method- > invokeNative

Java.lang.reflect.Method- > invoke

Com.android.internal.os.ZygoteInit$MethodAndArgsCaller- > run

Com.android.internal.os.ZygoteInit- > main

Dalvik.system.NativeStart- > main

But if there is a Xposed framework that hook the com.example.hookdetection.DoStuff.getSecret method, there are two changes to the call stack:

There is a de.robv.android.xposed.XposedBridge.main call after the dalvik.system.NativeStart.main method

If Xposed hook calls a method in the stack, there will also be de.robv.android.xposed.XposedBridge.handleHookedMethod and de.robv.android.xposed.XposedBridge.invokeOriginalMethodNative calls

So if you hook the getSecret method, the call stack will be as follows:

#! bash

Com.example.hookdetection.DoStuff- > getSecret

De.robv.android.xposed.XposedBridge- > invokeOriginalMethodNative

De.robv.android.xposed.XposedBridge- > handleHookedMethod

Com.example.hookdetection.DoStuff- > getSecret

Com.example.hookdetection.MainActivity- > onCreate

Android.app.Activity- > performCreate

Android.app.Instrumentation- > callActivityOnCreate

Android.app.ActivityThread- > performLaunchActivity

Android.app.ActivityThread- > handleLaunchActivity

Android.app.ActivityThread- > access$800

Android.app.ActivityThread$H- > handleMessage

Android.os.Handler- > dispatchMessage

Android.os.Looper- > loop

Android.app.ActivityThread- > main

Java.lang.reflect.Method- > invokeNative

Java.lang.reflect.Method- > invoke

Com.android.internal.os.ZygoteInit$MethodAndArgsCaller- > run

Com.android.internal.os.ZygoteInit- > main

De.robv.android.xposed.XposedBridge- > main

Dalvik.system.NativeStart- > main

Let's take a look at how the call stack changes after the Substrate hook com.example.hookdetection.DoStuff.getSecret method:

The com.android.internal.os.ZygoteInit.main appears twice after the dalvik.system.NativeStart.main call instead of once.

If Substrate hook calls a method in the stack, there will also be com.saurik.substrate.MS$2.invoked,com.saurik.substrate.MS$MethodPointer.invoke and methods related to the Substrate extension (com.cigital.freak.Freak$1 $1.invoked in this case).

So if you hook the getSecret method, the call stack will be as follows:

#! bash

Com.example.hookdetection.DoStuff- > getSecret

Com.saurik.substrate._MS$MethodPointer- > invoke

Com.saurik.substrate.MS$MethodPointer- > invoke

Com.cigital.freak.Freak$1 $1-> invoked

Com.saurik.substrate.MS$2- > invoked

Com.example.hookdetection.DoStuff- > getSecret

Com.example.hookdetection.MainActivity- > onCreate

Android.app.Activity- > performCreate

Android.app.Instrumentation- > callActivityOnCreate

Android.app.ActivityThread- > performLaunchActivity

Android.app.ActivityThread- > handleLaunchActivity

Android.app.ActivityThread- > access$800

Android.app.ActivityThread$H- > handleMessage

Android.os.Handler- > dispatchMessage

Android.os.Looper- > loop

Android.app.ActivityThread- > main

Java.lang.reflect.Method- > invokeNative

Java.lang.reflect.Method- > invoke

Com.android.internal.os.ZygoteInit$MethodAndArgsCaller- > run

Com.android.internal.os.ZygoteInit- > main

Com.android.internal.os.ZygoteInit- > main

Dalvik.system.NativeStart- > main

Once you know the changes in the call stack, you can write code at the Java layer to detect:

#! java

Try {

Throw new Exception ("blah")

}

Catch (Exception e) {

Int zygoteInitCallCount = 0

For (StackTraceElement stackTraceElement: e.getStackTrace ()) {

If (stackTraceElement.getClassName () .equals ("com.android.internal.os.ZygoteInit")) {

ZygoteInitCallCount++

If (zygoteInitCallCount = = 2) {

Log.wtf ("HookDetection", "Substrate is active on the device.")

}

}

If (stackTraceElement.getClassName (). Equals ("com.saurik.substrate.MS$2") &

StackTraceElement.getMethodName () .equals ("invoked")) {

Log.wtf ("HookDetection", "A method on the stack trace has been hooked using Substrate.")

}

If (stackTraceElement.getClassName (). Equals ("de.robv.android.xposed.XposedBridge") &

StackTraceElement.getMethodName () .equals ("main")) {

Log.wtf ("HookDetection", "Xposed is active on the device.")

}

If (stackTraceElement.getClassName (). Equals ("de.robv.android.xposed.XposedBridge") &

StackTraceElement.getMethodName () .equals ("handleHookedMethod")) {

Log.wtf ("HookDetection", "A method on the stack trace has been hooked using Xposed.")

}

}

}

0x03 detection should not be the native method of native

The Xposed framework changes the Java method type of hook to "native" and then replaces the original method with its own code (calling hookedMethodCallback). You can check out the implementation of XposedBridge_hookMethodNative, which is the method in the modified app_process.

Using this feature of Xposed to change the hook method (Substrate uses a similar principle), it can be used to detect whether it has been hook. Note that this cannot be used to detect the Xposed of the ART runtime because there is no need to change the type of the method to native.

Suppose there is the following method:

#! java

Public class DoStuff {

Public static String getSecret () {

Return "ChangeMePlskeeper!"

}

}

If the getSecret method is hook, it looks like the following definition at run time:

#! java

Public class DoStuff {

/ / calls hookedMethodCallback if hooked using Xposed

Public native static String getSecret ()

}

Based on the above principle, the detection steps are as follows:

Navigate to the DEX file of the application

Enumerate all class

A method to determine that the runtime should not be native through the reflection mechanism

The Java below demonstrates this technique. It is assumed that the application itself does not call native code through JNI, and most applications do not need to call local methods. However, if there is a JNI call, just add these native methods to a whitelist. In theory, this method can also be used to detect Java libraries or third-party libraries, but you need to add the native method of the third-party library to a whitelist. The detection code is as follows:

#! java

For (ApplicationInfo applicationInfo: applicationInfoList) {

If (applicationInfo.processName.equals ("com.example.hookdetection")) {

Set classes = new HashSet ()

DexFile dex

Try {

Dex = new DexFile (applicationInfo.sourceDir)

Enumeration entries = dex.entries ()

While (entries.hasMoreElements ()) {

String entry = entries.nextElement ()

Classes.add (entry)

}

Dex.close ()

}

Catch (IOException e) {

Log.e ("HookDetection", e.toString ())

}

For (String className: classes) {

If (className.startsWith ("com.example.hookdetection")) {

Try {

Class clazz = HookDetection.class.forName (className)

For (Method method: clazz.getDeclaredMethods ()) {

If (Modifier.isNative (method.getModifiers () {

Log.wtf ("HookDetection", "Native function found (could be hooked by Substrate or Xposed): + clazz.getCanonicalName () +"-> "+ method.getName ())

}

}

}

Catch (ClassNotFoundException e) {

Log.wtf ("HookDetection", e.toString ())

}

}

}

}

}

0x04 detects suspicious shared objects or JAR via / proc/ [pid] / maps

/ proc/ / maps records the area and access permissions of the memory map. First, check the image of the Android application. The * column is the start address and end address, and the sixth column is the path of the mapping file.

#! bash

# cat / proc/5584/maps

40027000-4002c000 r-xp 00000000 103 06 2114 / system/bin/app_process

4002c000-4002d000 Rmuri p 00004000 103 Vol 06 2114 / system/bin/app_process

4002d000-4002e000 rw-p 00005000 103 purl 06 2114 / system/bin/app_process

4002e000-4003d000 r-xp 00000000 103 system/bin/linker 06 246

4003d000-4003e000 rmurp 0000e000 103Vol 06 246 / system/bin/linker

4003e000-4003f000 rw-p 0000f000 103 purl 06 246 / system/bin/linker

4003f000-40042000 rw-p 00000000 00:00 0

40042000-40043000 rmurp 00000000 00:00 0

40043000-40044000 rw-p 00000000 00:00 0

40044000-40047000 r-xp 00000000 103 06 1176 / system/lib/libNimsWrap.so

40047000-40048000 rmurp 00002000 103 Vol 06 1176 / system/lib/libNimsWrap.so

40048000-40049000 rw-p 00003000 103 06 1176 / system/lib/libNimsWrap.so

40049000-40091000 r-xp 00000000 103 06 1237 / system/lib/libc.so

... Lots of other memory regions here...

So you can write code to detect suspicious files loaded into the current memory area:

#! java

Try {

Set libraries = new HashSet ()

String mapsFilename = "/ proc/" + android.os.Process.myPid () + "/ maps"

BufferedReader reader = new BufferedReader (new FileReader (mapsFilename))

String line

While ((line = reader.readLine ())! = null) {

If (line.endsWith (".so") | | line.endsWith (".jar")) {

Int n = line.lastIndexOf ("")

Libraries.add (line.substring (n + 1))

}

}

For (String library: libraries) {

If (library.contains ("com.saurik.substrate")) {

Log.wtf ("HookDetection", "Substrate shared object found:" + library)

}

If (library.contains ("XposedBridge.jar")) {

Log.wtf ("HookDetection", "Xposed JAR found:" + library)

}

}

Reader.close ()

}

Catch (Exception e) {

Log.wtf ("HookDetection", e.toString ())

}

Several so will be used by Substrate:

#! bash

Substrate shared object found: / data/app-lib/com.saurik.substrate-1/libAndroidBootstrap0.so

Substrate shared object found: / data/app-lib/com.saurik.substrate-1/libAndroidCydia.cy.so

Substrate shared object found: / data/app-lib/com.saurik.substrate-1/libDalvikLoader.cy.so

Substrate shared object found: / data/app-lib/com.saurik.substrate-1/libsubstrate.so

Substrate shared object found: / data/app-lib/com.saurik.substrate-1/libsubstrate-dvm.so

Substrate shared object found: / data/app-lib/com.saurik.substrate-1/libAndroidLoader.so

Xposed will use a Jar:

#! bash

Xposed JAR found: / data/data/de.robv.android.xposed.installer/bin/XposedBridge.jar

Methods of 0x05 Bypass Detection

Several anti-hooking methods have been discussed above, but it is believed that some people will propose bypass methods. Here, the corresponding detection methods are as follows:

GetInstalledApplications of hook PackageManager, remove the package name of Xposed or Substrate

Hook Exception's getStackTrace, get rid of your own method.

Hook getModifiers, change flag to look like native.

Operation of hook opened file, return / dev/null or modified map file

The above is what the anti-hooking skills of the Android Java layer are, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.