DexKit icon indicating copy to clipboard operation
DexKit copied to clipboard

Hidden method unfound

Open srdr0p opened this issue 1 year ago • 2 comments

In some obfuscation cases (such as YD), most of the dex code is retained, but some parts are stripped from dex. Example: XXX calls YYY and ZZZ, where YYY and ZZZ are hidden. Expected: It should be possible to locate the names of hidden methods by searching for methods in the dex code. Actual: Iteratoring over XXX.getInvokes() can discover YYY or ZZZ, but using XXX.getInvokes().findMethod() fails to find them.

Example code:

MethodData XXX = istenerClassRes.findMethod(FindMethod.create().matcher(MethodMatcher.create().name("XXX"))).single();
MethodDataList xxxcalls = XXX.getInvokes();
for (MethodData xxxcall: xxxcalls) {
    log(xxxcall.getReturnTypeName()); // one of  can output "boolean"
}
// following code throws exception
XXX.getInvokes().findMethod(FindMethod.create().matcher(MethodMatcher.create().returnType(boolean.class))).single();

srdr0p avatar Nov 13 '24 15:11 srdr0p

The FindMethod function in DexKit is designed to locate obfuscated methods within an APK. It filters out methods that cannot be resolved directly from the dex file (e.g., stub methods in framework.jar).

For instance, if you try to find a method in the framework like this:

bridge.findMethod {
    matcher {
        type = "java.util.Random"
        name = "nextInt"
    }
}

It will return an empty list.

In your case:

method.invokes.findMethod {
    matcher {
        ...
    }
}

This is equivalent to:

bridge.findMethod {
    searchInMethod(method.invokes)
    matcher {
        ...
    }
}

Therefore, stub methods cannot be returned.

teble avatar Nov 14 '24 05:11 teble

If your requirement can be fulfilled using the metadata provided by MethodData, it is better to utilize it directly. The findMethod function is more suitable for performing complex and relational queries.

teble avatar Nov 14 '24 05:11 teble