invalid signature for packed-switch-payload

[GoogleCodeExporter]

What seems to be the problem?
It seems there's a bug in smali that messes up the packed-switch-payload opcode 
identifier (should be 0x0100). It might be an alignment problem. 

What is the exact smali/baksmali command that you ran?
java -jar baksmali-2.0b4.jar test.dex

What version of smali/baksmali are you using? What rom are you working from?
smali/baksmali version: 2.0b4. 
Android rom: the SDK 4.1 emulator

What is the airspeed velocity of an unladen swallow?
What do you mean, an African or European Swallow?

Please provide any additional information below: error messages, symptoms, etc.

smali produces no errors. The following are the error messages thrown by the 
dalvik verifier: 

09:44:53.094: W/dalvikvm(618): VFY: wrong signature for switch table (0x0003, 
wanted 0x0100)
09:44:53.105: W/dalvikvm(618): VFY:  rejecting opcode 0x2b at 0x007b

Original issue reported on code.google.com by moh.elsa...@gmail.com on 21 Jun 2013 at 2:10

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ops, I posted the wrong command. Here's the smali command I used: java -jar 
smali-2.0b4.jar -o classes.dex redacted/smali/

Original comment by moh.elsa...@gmail.com on 21 Jun 2013 at 2:17

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Here's the dexdump of the offset that the dalvikvm is complaining about: 

0fde82: 0001 0300 5000 077f 7f00 0000 9f00 ... |00af: packed-switch-data (10 
units)

It seems the signature is correct 0100.. but there's a misalignment by 2 bytes 
somewhere. Shouldn't the 0fde82 be aligned to 4 bytes?

Original comment by moh.elsa...@gmail.com on 21 Jun 2013 at 3:19

[GoogleCodeExporter]

I believe this was fixed in 2.0b5, please give that a try and let me know if it 
works or not.

Original comment by bgruv@google.com on 21 Jun 2013 at 5:42

• Changed state: Pending

[GoogleCodeExporter]

Oh, I didn't notice there was a new release! Anyway, I just tried it and the 
dalvikvm gave a slightly different error: 

14:07:55.024: W/dalvikvm(849): VFY: unaligned switch table: at 123, switch 
offset 54
14:07:55.024: W/dalvikvm(849): VFY:  rejecting opcode 0x2b at 0x007b

Here's the dex dump: 

1070ba: 2b00 3600 0000                         |007b: packed-switch v0, 
000000b1 // +00000036
....
....
107124: 0001 0300 5000 077f 7f00 0000 9f00 ... |00b0: packed-switch-data (10 
units)

Original comment by moh.elsa...@gmail.com on 21 Jun 2013 at 6:14

[GoogleCodeExporter]

Seems the switch offset is incorrect, right? since the switch payload must be 
4-byte aligned, the offset cannot be 0x36 as that would give: 007b + 0x36 = 
0xb1.

Original comment by moh.elsa...@gmail.com on 21 Jun 2013 at 6:32

[GoogleCodeExporter]

The problem is in that "nop" (see snippet below) baksmali inserts when decoding 
the dex. Is there a reason for having a nop there? I mean, there are no 
absolute references or alignment issues at the decoded smali level, right? If 
"nop" is commented out, the smali-ed code runs fine with no problem at all. 
What do you think, Ben?

    :pswitch_f

    # some code goes here

     goto :goto_e

    .line 16
    nop

    :pswitch_data_11
    .packed-switch 0x7f0b0195
        :pswitch_f
    .end packed-switch

Original comment by moh.elsa...@gmail.com on 28 Jun 2013 at 2:25

[GoogleCodeExporter]

Oh, sorry. I forgot to reply to the bug after you mentioned the issue with b5. 
I did see it and started working on a fix though :)

In any case, yes - there is an alignment requirement for payload instructions, 
and a nop can be inserted before the payload instruction to align it if needed. 
However, you shouldn't have to worry about this - smali should take care of it 
for you. And as I mentioned, I'm working on a fix.

Original comment by bgruv@google.com on 28 Jun 2013 at 8:08

• Changed state: Accepted

[GoogleCodeExporter]

Have the same issue. Do you have an idea when you might be done with the fix?

Original comment by Miller....@googlemail.com on 2 Jul 2013 at 11:54

[GoogleCodeExporter]

Try using attached smali. It forces alignment on all switch payloads. See if it 
resolves the issue and let me know. I will push the fix if it does.

Original comment by twosh...@two-sheds.com on 14 Aug 2013 at 4:08

Attachments:

• smali-2.0b5-dev.jar

[GoogleCodeExporter]

Sorry, but you don't seem to be a project member..

Original comment by moh.elsa...@gmail.com on 22 Aug 2013 at 6:23

[GoogleCodeExporter]

TwoSheds is legit :). He's the one who wrote the original code for dexlib2 that 
dealt with the switch payload alignment

Original comment by bgruv@google.com on 22 Aug 2013 at 8:17

[GoogleCodeExporter]

Oh, okay. Thanks TwoSheds. I tested it and the same exact issue persists.

Original comment by moh.elsa...@gmail.com on 22 Aug 2013 at 8:23

[GoogleCodeExporter]

Thanks for validating my legitimacy, JesusFreke. I was going to post a link to 
my MethodWriteUtil commit, but your word has more weight. :)

moh.elsa, are you modifying smali source at all? Would it be possible to get a 
copy of dex files you are working with? (optional, but would help with 
debugging quite a bit)

I am surprised that patched version of smali didn't work. I should probably 
force alignment on packed switch payloads for all cases anyway... 

Original comment by twosh...@two-sheds.com on 23 Aug 2013 at 3:04

[GoogleCodeExporter]

Hi TwoSheds. Yes, I modify the smali. I can manually insert/remove NOPs to 
align the payload statements, but it is very cumbersome and unfeasible for the 
code size I am working on.

Original comment by moh.elsa...@gmail.com on 23 Aug 2013 at 3:10

[GoogleCodeExporter]

This should be fixed now. The fix is in the dexlib_redesign branch, and will be 
in the next 2.0 beta - v2.0b6.

Original comment by jesusfreke@jesusfreke.com on 14 Sep 2013 at 9:03

• Changed state: Fixed