[Soot-list] Add Expression works strange.

[Roman Petriev]

Thanks you, Elena. I think, that I can use different disassemblers for
checking, e.g. Eclipse Bytecode Viewer.
I make obfuscations, therefore I can add instructions after
return sometimes.


2015-02-06 21:51 GMT+03:00 Elena Sherman <elenasherman at boisestate.edu>:

> Eric, yes, it works correctly. I've added the print statement in Roman's
> code and it does prints out 500. So, I don't know if it should be reported
> or not.
> When I was looking for the format of iinc_w I found the following
> iinc_w index byte1 byte2
> where the value to be incremented is calculated as byte1 << 8 | byte2
> When I've changed the value to increment from 500 to  512 and  javap
> changed the bytecode from "iinc_w        #0,  1" to "iinc_w        #0,
>  2", so apparently javap shows only byte1 part since 1<<8 = 256 and 2<<8 is
> 512 but fails to show byte 2, which should be 244 for 500 and 0 for 512.
>
> Roman, when you instrument the code make sure to add your instrumentation
> before return statement, for example by using units.insertBefore(....) or
> units.insertAfter(...) methods.
>
>
> On Fri, Feb 6, 2015 at 5:37 AM, Eric Bodden <eric.bodden at sit.fraunhofer.de
> > wrote:
>
>> Thanks a lot for the input Elena!
>>
>> Wow, that's odd! I have never seen javap give such apparently
>> false/misleading information. Is this something we should report to Oracle?
>>
>> Anyway, I would assume that the bytecode is actually correct?
>>
>> Cheers,
>> Eric
>>
>>
>> > On 06.02.2015, at 01:22, Elena Sherman <elenasherman at boisestate.edu>
>> wrote:
>> >
>> > Roman,
>> >
>> > I've run your code with the initialization of the local variable part
>> added to it. It looks like that depending on the bytecode viewer I get
>> different bytecode. When I use javap -c Decomp.class I get the following
>> (what you get):
>> >
>> > Compiled from "Decomp.java"
>> > public class decomp.Decomp {
>> >   public decomp.Decomp();
>> >     Code:
>> >        0: aload_0
>> >        1: invokespecial #1                  // Method
>> java/lang/Object."<init>":()V
>> >        4: return
>> >        5: iconst_0
>> >        6: istore_0
>> >        7: iinc_w        #0,  1              // #0
>> >
>> >   public static void main(java.lang.String[]);
>> >     Code:
>> >        0: return
>> >        1: iconst_0
>> >        2: istore_0
>> >        3: iinc_w        #0,  1              // #0
>> > }
>> >
>> > However, when I use Eclipse's bytecode viewer I get the following:
>> >
>> > // Compiled from Decomp.java (version 1.2 : 46.0, super bit)
>> > public class decomp.Decomp {
>> >   // Method descriptor #12 ()V
>> >   // Stack: 1, Locals: 1
>> >   public Decomp();
>> >      0  aload_0 [this]
>> >      1  invokespecial java.lang.Object() [1]
>> >      4  return
>> >      5  wide
>> >      6  iinc 0 500 [this]
>> >       Line numbers:
>> >         [pc: 0, line: 0]
>> >         [pc: 1, line: 1]
>> >         [pc: 4, line: 2]
>> >         [pc: 5, line: 3]
>> >       Attribute: LineNumberTable Length: 18
>> >       Attribute: LineNumberTable Length: 18
>> >
>> >   // Method descriptor #11 ([Ljava/lang/String;)V
>> >   // Stack: 0, Locals: 1
>> >   public static void main(java.lang.String[] arg0);
>> >     0  return
>> >     1  wide
>> >     2  iinc 0 500 [arg0]
>> >       Line numbers:
>> >         [pc: 0, line: 0]
>> >         [pc: 1, line: 1]
>> >       Attribute: LineNumberTable Length: 10
>> >       Attribute: LineNumberTable Length: 10
>> > }
>> >
>> > Which is correct. So, apparently the wide incremental instruction,
>> i.e., iinc_w should be interpreted a bit different than its regular version
>> iinc. I'm not a bytecode specialist, so I cannot tell exactly how to
>> interpret iinc_w's arguments in terms of iinc.
>> >
>> > In general bytecode can be quite confusing, so in order to check
>> whether your instrumentation works as expected try to print something out
>> like the value of the local variable you're trying to increment. Thus when
>> you execute the instrumented code you will know for sure if this is what
>> you want or not, or there are any errors in the instrumentation.
>> >
>> > Hope it helps.
>> >
>> > Elena
>> >
>> > On Thu, Feb 5, 2015 at 11:38 AM, Roman Petriev <vvpiroman at gmail.com>
>> wrote:
>> > Test cases here.
>> > Is it good? Do you need anything else?
>> >
>> > 2015-02-05 12:58 GMT+03:00 Bodden, Eric <eric.bodden at sit.fraunhofer.de
>> >:
>> > Hi Roman.
>> >
>> > > I hope that is (exactly) what you want to see.
>> >
>> > Ideal would be a minimal but runnable example, including your driver
>> class for Soot and the command-line options you are using. We should be
>> able to reproduce this with as little effort as possible.
>> >
>> > Thanks,
>> > Eric
>> >
>> >
>>
>> --
>> Prof. Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
>> Head of Secure Software Engineering at Fraunhofer SIT, TU Darmstadt and
>> EC SPRIDE
>> Tel: +49 6151 16-75422    Fax: +49 6151 869-127
>> Room B5.11, Fraunhofer SIT, Rheinstraße 75, 64295 Darmstadt
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.CS.McGill.CA/pipermail/soot-list/attachments/20150208/0346ef73/attachment-0001.html