You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As per smali specification, this is fine, as when you call a method (via invoke- instructions), you specify the full signature, including the return type of the method that you're trying to invoke.
Meanwhile, the java decompiled counterpart does not contain these methods, as they violate the language specification, where you cannot have multiple methods with same calling signature, as a result, the decompiled methods would result in invalid java code:
Is there an option to automatically rename methods (much like the deobfuscation feature) when their equivalent signature in java would clash with another method's signature?
The content of these methods is not really important, as it's an overly obfuscated call to another decoding method.
The following is extracted smali file from the application scratch_6.txt
The text was updated successfully, but these errors were encountered:
@Dragas look like it was a bug in check for removing synthetic bridge method, so both methods were removed.
I commit a fix, so now one of these methods got renamed. Please check latest unstable build.
Sadly, this issue does not fall under regular decompilation error template, as it does not produce an exception or an error.
In the APK that I'm analyzing, I found that xshield sometimes likes to generate methods with following signature:
As per smali specification, this is fine, as when you call a method (via invoke- instructions), you specify the full signature, including the return type of the method that you're trying to invoke.
Meanwhile, the java decompiled counterpart does not contain these methods, as they violate the language specification, where you cannot have multiple methods with same calling signature, as a result, the decompiled methods would result in invalid java code:
Is there an option to automatically rename methods (much like the deobfuscation feature) when their equivalent signature in java would clash with another method's signature?
The content of these methods is not really important, as it's an overly obfuscated call to another decoding method.
The following is extracted smali file from the application scratch_6.txt
The text was updated successfully, but these errors were encountered: