Closed GoogleCodeExporter closed 9 years ago
I found the real problem: PowerAMP's author made an unused method with an
undefined opcode 0x3F in its code. The method's body is "3F FF 00 00 0F 00".
We mustn't let this unexpected opcode stop our work.
Original comment by chen.92...@gmail.com
on 2 Oct 2013 at 3:11
Please try smali/baksmali 2.0 :)
Original comment by jesusfreke@jesusfreke.com
on 2 Oct 2013 at 5:42
Thanks! The new version works well.
But there are still problems when re-smaling. But because of the class name
contains Unicode characters, it shows as "?" in the output, so I can't
determine what smali file contains errors. Is there a classes renamer?
Original comment by chen.92...@gmail.com
on 3 Oct 2013 at 1:18
I found where the error happens. An unused method contains a non-exist string:
"string@16001". The line of code is:
const-string v0, string@16001
Is it possible to skip unused methods?
Original comment by chen.92...@gmail.com
on 3 Oct 2013 at 1:28
I was stuck on deleting the smali folder. Some classes' names are too long (>
256 chars), and Windows can't delete them (I couldn't ever know how they are
created)!
Original comment by chen.92...@gmail.com
on 12 Oct 2013 at 11:34
The smali 2.0 final (and maybe 2.0b6, I don't recall) has better support for
long class names. It truncates them and ensures they are unique.
You can use any utility you want to rename the smali files. The filename isn't
used for anything, and so can be anything.
For now, you'll have to manually remove/comment out the "bogus" methods. I do
want to do something better for this in the future though.
Original comment by jesusfreke@jesusfreke.com
on 12 Oct 2013 at 5:40
Thank you very much!
BTW, why is ".locals" discontinued?
Original comment by chen.92...@gmail.com
on 26 Oct 2013 at 9:12
It isn't. The -l flag controls whether baksmali produces a .locals or
.registers directive. smali can consume either.
Also, a quick update on the "bogus" methods. I actually found a bug here. For
example, the "const-string v0, string@16001" instruction actually should have
been commented out, which would then make the method able to be reassembled.
Original comment by jesusfreke@jesusfreke.com
on 26 Oct 2013 at 5:12
I think it's better to print the unknown opcodes and non-exist strings found
while disassembling, because the classes with unknown opcodes or non-exist
strings can't pass the Dalvik's verifier, so they're not used at all!
BTW, ".locals" should be the default, because it's more convenient to count the
registers.
Original comment by chen.92...@gmail.com
on 9 Nov 2013 at 2:04
Here's something unrelative (sorry)
I got an exception when smaling:
UNEXPECTED TOP-LEVEL EXCEPTION:
java.lang.IllegalStateException: Cannot get the location of a label that hasn't
been placed yet.
at org.jf.dexlib2.builder.Label.getLocation(Label.java:54)
at ...
I know it's my fault, but there isn't any detailed information in the output,
even the error file name ... I hope a fix.
Original comment by chen.92...@gmail.com
on 5 Feb 2014 at 3:41
Sure, that's a reasonable issue/request. Can you please file another issue and
give more information.
Original comment by jesusfreke@jesusfreke.com
on 5 Feb 2014 at 5:54
Oh, OK, I will. But it's just a small issue so I think it's better be solved
here.
Original comment by chen.92...@gmail.com
on 6 Feb 2014 at 2:56
Original issue reported on code.google.com by
chen.92...@gmail.com
on 2 Oct 2013 at 1:59