Skip to content
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

StringIndexOutOfBoundsException #350

Closed
nsonaniya2010 opened this issue Aug 28, 2021 · 9 comments · Fixed by #352
Closed

StringIndexOutOfBoundsException #350

nsonaniya2010 opened this issue Aug 28, 2021 · 9 comments · Fixed by #352

Comments

@nsonaniya2010
Copy link

nsonaniya2010 commented Aug 28, 2021

Please send this error log to https://github.com/Konloch/bytecode-viewer/issues or Konloch at https://the.bytecode.club or konloch@gmail.com
If you hold appropriate legal rights to the relevant class/jar/apk file please include that as well.
Bytecode Viewer Version: 2.10.16 [Fat Jar], OS: Mac OS X, Java: 1.8.0_302

java.lang.StringIndexOutOfBoundsException: String index out of range: -3
	at java.lang.String.substring(String.java:1967)
	at org.objectweb.asm.signature.SignatureReader.parseType(SignatureReader.java:178)
	at org.objectweb.asm.signature.SignatureReader.accept(SignatureReader.java:111)
	at org.objectweb.asm.commons.Remapper.mapSignature(Remapper.java:209)
	at org.objectweb.asm.commons.ClassRemapper.visitMethod(ClassRemapper.java:193)
	at org.objectweb.asm.ClassVisitor.visitMethod(ClassVisitor.java:366)
	at com.googlecode.d2j.dex.Dex2Asm.collectBasicMethodInfo(Dex2Asm.java:330)
	at com.googlecode.d2j.dex.Dex2Asm.convertMethod(Dex2Asm.java:639)
	at com.googlecode.d2j.dex.Dex2Asm.convertClass(Dex2Asm.java:526)
	at com.googlecode.d2j.dex.Dex2Asm.convertClass(Dex2Asm.java:428)
	at com.googlecode.d2j.dex.Dex2Asm.convertDex(Dex2Asm.java:542)
	at com.googlecode.d2j.dex.Dex2jar.doTranslate(Dex2jar.java:135)
	at com.googlecode.d2j.dex.Dex2jar.to(Dex2jar.java:235)
	at the.bytecode.club.bytecodeviewer.util.Dex2Jar.dex2Jar(Dex2Jar.java:42)
	at the.bytecode.club.bytecodeviewer.resources.importing.impl.APKResourceImporter.open(APKResourceImporter.java:66)
	at the.bytecode.club.bytecodeviewer.resources.importing.ImportResource.importKnownFile(ImportResource.java:88)
	at the.bytecode.club.bytecodeviewer.resources.importing.ImportResource.run(ImportResource.java:60)
	at java.lang.Thread.run(Thread.java:748)
@ThexXTURBOXx
Copy link
Contributor

I've seen this error for some users already.
Are you able to share the DEX file, so I can debug the problem?

Please only share the DEX file if you have the appropriate legal rights to do so. If not, please share the link to the Google Play Entry or some other uploader.

@nsonaniya2010
Copy link
Author

@ThexXTURBOXx
Copy link
Contributor

Thanks for sharing! It is not easy to fix that, but I will try my best. Actually, JADX, for example, also faces this exact problem.

@nsonaniya2010
Copy link
Author

Thanks.

@ThexXTURBOXx
Copy link
Contributor

This error should be "fixed" in this release. Can you confirm that this is the case? :)

There will be lots of warnings in the command line since I added a fix that works around this issue by responding to specific exceptions from ASM. Please, also note that methods and/or fields that can't be decompiled successfully now are abstract and their types are java.lang.Object. This is about the same workaround that jadx added (skylot/jadx@009939f), but it is much uglier in dex2jar :)

@nsonaniya2010
Copy link
Author

Thanks a lot. I will check it.

@nsonaniya2010
Copy link
Author

I checked it. The above issue got fixed.
However when I see the class files they're not properly categorized in the folders for example the main app.
I checked the same with JADX and found out to be working pretty well in categorizing the classes in proper folders.
Can you look into it as well?

@ThexXTURBOXx
Copy link
Contributor

Thanks for reporting back! It's very nice to see that the issue is kinda "fixed" :)
About the categorization: I am unsure if I understand correctly.
With the newest build of BCV, your decompiled APK looks like this (a small snippet):
grafik

In JADX, it looks like this:
grafik

As you can see, dex2jar is organizing all classes as-is, i.e. if a class is relocated/obfuscated into the default package (e.g. class a had another name in some package before, but was obfuscated into the default package as class a), then it will be in the default package as well after dex2jar consumed it.
JADX, on the other hand, introduces a package called defpackage, which now contains all the classes that were obfuscated into the DEFault PACKAGE before (hence the name defpackage).
I don't know which approach is the best, but I actually prefer the way dex2jar is handling it. Maybe I will add some switch at some point, which you can use to relocate classes from the default package into some defpackage, but this will be purely optional, since I don't want to break existing procedures that rely on that :)

That all being said, I will let this issue open until I further looked into this.

@nsonaniya2010
Copy link
Author

Thats Cool. Thanks a lot & Thanks for promptly replying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants