Trying to understand this
-
Decompiled a .class (translating to C++) using third party tools (namely Java Decompiler by Emmanuel Dupuy and DJ Java) and also from the bytecode output from javap; all result in the following:
StringBuffer stringbuffer = new StringBuffer();
for(int i = 0; i < stringbuffer.length(); i++)
{
byte byte0 = (byte)stringbuffer.charAt(i);
stringbuffer.append((char)byte0);
}I've been scratching my head for hours trying to figure it out. From what I can see it creates an empty buffer, tests the length (which would be 0) against 0 and skips the loop. Please, somebody, explain it to me. For completeness sake here is the javap output:
0: getstatic #5; //Field a:Z
3: ifeq 47
6: new #4; //class java/lang/StringBuffer
9: dup
10: invokespecial #9; //Method java/lang/StringBuffer."<init>":()V
13: astore_1
14: iconst_0
15: istore_2
16: goto 36
19: aload_1
20: iload_2
21: invokevirtual #13; //Method java/lang/StringBuffer.charAt:(I)C
24: i2b
25: istore_3
26: aload_1
27: iload_3
28: i2c
29: invokevirtual #11; //Method java/lang/StringBuffer.append:(C)Ljava/lang/StringBuffer;
32: pop
33: iinc 2, 1
36: iload_2
37: aload_1
38: invokevirtual #15; //Method java/lang/StringBuffer.length:()I
41: if_icmplt 19
44: invokestatic #12; //Method b:()V
47: getstatic #6; //Field b:Z
50: ifeq 57
53: iconst_0
54: putstatic #6; //Field b:Z
57: iconst_0
58: putstatic #5; //Field a:Z
61: returnWaldermort
-
Decompiled a .class (translating to C++) using third party tools (namely Java Decompiler by Emmanuel Dupuy and DJ Java) and also from the bytecode output from javap; all result in the following:
StringBuffer stringbuffer = new StringBuffer();
for(int i = 0; i < stringbuffer.length(); i++)
{
byte byte0 = (byte)stringbuffer.charAt(i);
stringbuffer.append((char)byte0);
}I've been scratching my head for hours trying to figure it out. From what I can see it creates an empty buffer, tests the length (which would be 0) against 0 and skips the loop. Please, somebody, explain it to me. For completeness sake here is the javap output:
0: getstatic #5; //Field a:Z
3: ifeq 47
6: new #4; //class java/lang/StringBuffer
9: dup
10: invokespecial #9; //Method java/lang/StringBuffer."<init>":()V
13: astore_1
14: iconst_0
15: istore_2
16: goto 36
19: aload_1
20: iload_2
21: invokevirtual #13; //Method java/lang/StringBuffer.charAt:(I)C
24: i2b
25: istore_3
26: aload_1
27: iload_3
28: i2c
29: invokevirtual #11; //Method java/lang/StringBuffer.append:(C)Ljava/lang/StringBuffer;
32: pop
33: iinc 2, 1
36: iload_2
37: aload_1
38: invokevirtual #15; //Method java/lang/StringBuffer.length:()I
41: if_icmplt 19
44: invokestatic #12; //Method b:()V
47: getstatic #6; //Field b:Z
50: ifeq 57
53: iconst_0
54: putstatic #6; //Field b:Z
57: iconst_0
58: putstatic #5; //Field a:Z
61: returnWaldermort
Your assessment looks correct: the loop will always be skipped. What were you trying to decompile, anyway?
-
Decompiled a .class (translating to C++) using third party tools (namely Java Decompiler by Emmanuel Dupuy and DJ Java) and also from the bytecode output from javap; all result in the following:
StringBuffer stringbuffer = new StringBuffer();
for(int i = 0; i < stringbuffer.length(); i++)
{
byte byte0 = (byte)stringbuffer.charAt(i);
stringbuffer.append((char)byte0);
}I've been scratching my head for hours trying to figure it out. From what I can see it creates an empty buffer, tests the length (which would be 0) against 0 and skips the loop. Please, somebody, explain it to me. For completeness sake here is the javap output:
0: getstatic #5; //Field a:Z
3: ifeq 47
6: new #4; //class java/lang/StringBuffer
9: dup
10: invokespecial #9; //Method java/lang/StringBuffer."<init>":()V
13: astore_1
14: iconst_0
15: istore_2
16: goto 36
19: aload_1
20: iload_2
21: invokevirtual #13; //Method java/lang/StringBuffer.charAt:(I)C
24: i2b
25: istore_3
26: aload_1
27: iload_3
28: i2c
29: invokevirtual #11; //Method java/lang/StringBuffer.append:(C)Ljava/lang/StringBuffer;
32: pop
33: iinc 2, 1
36: iload_2
37: aload_1
38: invokevirtual #15; //Method java/lang/StringBuffer.length:()I
41: if_icmplt 19
44: invokestatic #12; //Method b:()V
47: getstatic #6; //Field b:Z
50: ifeq 57
53: iconst_0
54: putstatic #6; //Field b:Z
57: iconst_0
58: putstatic #5; //Field a:Z
61: returnWaldermort
You are right. Loop skipped the condition all the times. I'm not sure the original code has an issue or the decompiler caused any.
I appreciate your help all the time... CodingLover :)
-
Your assessment looks correct: the loop will always be skipped. What were you trying to decompile, anyway?
Thanks for the confirmation, I thought I was missing something. After posting the message a came across a few other oddities like double xor'ing values and over complicated method calls that return the same data as passed in. Went from 4pm to 8am, manually reversing about 2000 lines of bytecode only to end up with a 9 line C++ method. I can only guess that the coder, an ex-coworker, coded it in such a way to make reverse engineering very difficult. By the way, it was initially a web app that was later converted to a standalone binary.
Waldermort
-
Thanks for the confirmation, I thought I was missing something. After posting the message a came across a few other oddities like double xor'ing values and over complicated method calls that return the same data as passed in. Went from 4pm to 8am, manually reversing about 2000 lines of bytecode only to end up with a 9 line C++ method. I can only guess that the coder, an ex-coworker, coded it in such a way to make reverse engineering very difficult. By the way, it was initially a web app that was later converted to a standalone binary.
Waldermort
I love that: wiki on Obfuscated_code[^] one can have hours of fun with this! did the decompiler figure out what really is supposed to happen here? the code in the loop also doesn't make sense. Please try to decompile it into a JAVA code - just to see what happens. regards Torsten
I never finish anyth...
-
I love that: wiki on Obfuscated_code[^] one can have hours of fun with this! did the decompiler figure out what really is supposed to happen here? the code in the loop also doesn't make sense. Please try to decompile it into a JAVA code - just to see what happens. regards Torsten
I never finish anyth...
I'm guessing that only about 1/5th of this code actual does anything. I would love to just plug it into a debugger and find out exactly what is going on but I gave up on that idea. The only thing I can do now is extract the base algorithms and rewrite the remaining code myself. At this point I'm thinking that even if I had the original code at hand (uncommented), I would probably still have a headache.
Waldermort