UTF-8 characters are unsupported ...

[GoogleCodeExporter]

What seems to be the problem?
I tried analyzing PowerAMP. When I'm baksmaling, an exception is occurred. By 
using IDA, I found that some class and method names are UTF-8 chars ...

What is the exact smali/baksmali command that you ran?
java -jar baksmali.jar classes.dex -o smali

What version of smali/baksmali are you using? What rom are you working
from?
baksmali-1.4.2, any ROM

Please provide any additional information below: error messages, symptoms,
etc.
Here is the output:
--------------------------------------------------------------------------------
--------------------
unknown opcode encountered - 3f. Treating as nop.

UNEXPECTED TOP-LEVEL EXCEPTION:
org.jf.dexlib.Util.ExceptionWithContext: Index: 16001, Size: 6425
        at org.jf.dexlib.Util.ExceptionWithContext.withContext(ExceptionWithContext.java:54)
        at org.jf.dexlib.IndexedSection.getItemByIndex(IndexedSection.java:77)
        at org.jf.dexlib.Code.InstructionWithReference.lookupReferencedItem(InstructionWithReference.java:88)
        at org.jf.dexlib.Code.InstructionWithReference.<init>(InstructionWithReference.java:57)
        at org.jf.dexlib.Code.Format.Instruction21c.<init>(Instruction21c.java:63)
        at org.jf.dexlib.Code.Format.Instruction21c.<init>(Instruction21c.java:40)
        at org.jf.dexlib.Code.Format.Instruction21c$Factory.makeInstruction(Instruction21c.java:112)
        at org.jf.dexlib.Code.InstructionIterator.IterateInstructions(InstructionIterator.java:82)
        at org.jf.dexlib.CodeItem.readItem(CodeItem.java:154)
        at org.jf.dexlib.Item.readFrom(Item.java:77)
        at org.jf.dexlib.OffsettedSection.readItems(OffsettedSection.java:48)
        at org.jf.dexlib.Section.readFrom(Section.java:143)
        at org.jf.dexlib.DexFile.<init>(DexFile.java:431)
        at org.jf.baksmali.main.main(main.java:280)
Caused by: java.lang.IndexOutOfBoundsException: Index: 16001, Size: 6425
        at java.util.ArrayList.rangeCheck(Unknown Source)
        at java.util.ArrayList.get(Unknown Source)
        at org.jf.dexlib.IndexedSection.getItemByIndex(IndexedSection.java:75)
        ... 12 more
Error occured while retrieving the string_id_item item at index 16001
Error occured at code address 0
code_item @0x41cb4
--------------------------------------------------------------------------------
--------------------

Is there a classes and methods renamer, etc.?

Original issue reported on code.google.com by chen.92...@gmail.com on 2 Oct 2013 at 1:59

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Please try smali/baksmali 2.0 :)

Original comment by jesusfreke@jesusfreke.com on 2 Oct 2013 at 5:42

• Changed state: Pending

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Fixed

[GoogleCodeExporter]

Thank you very much!
BTW, why is ".locals" discontinued?

Original comment by chen.92...@gmail.com on 26 Oct 2013 at 9:12

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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