-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[core] Newer Jadx versions generate random alphanumeric entries breaking the original code reconstruction #1672
Comments
Have you tried to disable deobfuscation? The package name |
@jpstotz I haven't tried. I will try but similar things are generated also with packages with longer names and simple code sections, not only with |
UPDATE Example
Latest Jadx version (line 52) Old Jadx version (line 52)
Latest Jadx version (line 254) Old Jadx version (line 254) |
The In detail method The two conflicting methods are:
The interesting part is that the second method is marked as @skylot I first debugged a different part of Jadx when searching for the cause. I started with For example using the sample APK file |
@jpstotz I see, jadx renames these methods due to collision with bridge method, but next remove/merge that bridge method, so this renames not needed anymore. I will try to fix this. @JohnFarl as workaround for now, you can disable all checkboxes in
yes, this allowed in bytecode, so unique method signature contains return type |
@jpstotz @skylot Disabling the rename options I get more consistent code. A code with colliding methods cannot be compiled in first place, so if Jadx produces colliding code that needs to refactor to avoid collisions, this certainly happens because it merges code from different packages that isn't supposed to be in same place. |
Not in this case. The colliding code is generated by the Android dex compiler may be to apply some optimization or whatever. So the original Java code was free of method collisions and also the generated class files. But when the APK files was created and everything was compiled/translated to DEX code the synthetic methods were added and thus the method collisions were introduced. |
@jpstotz How a colliding code is supposed to be executed without crashing at runtime due to ambigous method signatures? Because they are in different bytecode blocks that reside in different sections and are called by different methods, so it doesn't make difference for the executor if there are methods with same signatures, because these are called separately, this is a problem only in compilation time, but if these blocks are decompiled in order to not have visibility outside the respective invokers a refactor isn't needed. |
Dex is more powerful than Java class files. On dex level methods are referenced by a signature that includes the return type. Therefore for Android there are no ambigous methods. |
Fixed. |
The code decompiled with the newer version seems worse than the code decompiled with an old Jadx version.
There are a lot of lines broken with random codes everywhere e.g.
Latest Jadx (line 22)
import android.support.p001v4.content.ContextCompat;
Old Jadx (line 22)
import android.support.v4.content.ContextCompat;
Latest Jadx (line 84)
TypedArray a = context.obtainStyledAttributes(attrs, C0016R.styleable.CollapsingToolbarLayout, defStyleAttr, C0016R.style.Widget_Design_CollapsingToolbar);
Old Jadx (line 84)
TypedArray a = context.obtainStyledAttributes(attrs, R.styleable.CollapsingToolbarLayout, defStyleAttr, R.style.Widget_Design_CollapsingToolbar);
Latest Jadx (line 61)
Older Jadx (line 61)
There are countless similar cases, and changing the decompilation mode from AUTO to RESTRUCTURE leads to analogous result.
The apk I have tried link.
Unfortunately, I cannot say what is the old version I'm talking about, because I have updated it many time without paying attention to this detail.
The text was updated successfully, but these errors were encountered: