java virtual machine is big endin processor

[kernelerror]

After my lecture give a introduction to the java GUI application I
goes
home and write a program , and I just disassemble it ,

The program source code is shown in here ... anyway , the java
language compiler
pushes the line numbers as the debugging symbols into the binary
executable .But
I redundant my some comments and line spacings , so this program may
be vary
when you considering the lines . Please don't try to compare the
lines .
Shuch as .line21 , is a line number debugging symbol information .


----------------------------------------------------------------------
package guifirstlesson ;


import java.awt.* ;


public class GUIFirst extends Frame {
// the constructor of this class
public GUIFirst (){
super ("This was an basic GUI example ");


}


// This is our faviourate main method that everyone knows how
to
write
public static void main ( String args[] ){


// creates an object of the GUIFirst class
GUIFirst guiFirst = new GUIFirst ();


// then make it's size
guiFirst.setSize ( 300, 500 );


// then display that on the screen
guiFirst.setVisible (true );
}


}


----------------------------------------------------------------------

what are you think about this , this is the dissembly listing that I
was get a screenshot of the currently working IDA pro .



<img src="http://img90.imageshack.us/img90/6826/
firstprogramdisassemblyrm4.gif"/>


http://img90.imageshack.us/img90/6826/firstprogramdisassemblyrm4.gif


The best thing of this is that the , I learn that java virtual
machine
is a completely
a big edin processor . Just see that these instructions ,


sipush 300
sipush 500
invokevirtual guifirstlesson/GUIFirst.setSize(II)V


These java assembly langauge instructions are relevant to the hex
machine code


11 01 2C 11 01 F4 B6 00 05


anyway I don't know the java assembly language , But I was guessed
the
op code
relevant to the sipush is 11 , guess that !


Yes the java language is using the stack for the parameater passing
for the line
of code that I above written .


guiFirst.setSize ( 300, 500 );


The 300 is pushed first it's hex value is 0x12C and when comes to the
500 it's
hex value is 0x1F4 , likewise the instruction 11H is the opcode for
the instruction
for the java virtual machine .


So it makes me to think that the JVM is an big endin virtual
processor .


and I learn many things form this ,
1. Java used the big ending type to strore the variables in
it's
memory .
2. Java byte code can sometime have the debugging line number
information
as the form of symbols .
3. Looking at the dissassembly you can easily reverseenginner
into
your
orginal java program .
4. java is imports vm libraries by using the dynamic linking ,
it was
similar to
a win32 dll program that imports the functions and
datastructures
using the
import table . Runtime class loading I don't know the
mechanism
anyway .
5. Java language is heavily vulnnualble to the reverse
engneering .


what are you think about this , friends . Please let me know your
ideas . Please .


java byte code is fun than java source code , I like java byte code
than java
source codez ! .


anyway this is java byte code . what about Native win32 or win64 or
the linux byte codes
.. You will be feel funny with it . Get Addicted !


If you need more information about debuggers and disassemblers ,
please ask here .


-- sanzilla jackcat -

 

[Mark Space]

anyway I don't know the java assembly language , But I was guessed
the
op code
relevant to the sipush is 11 , guess that !

Correct. However there is no need to guess. Here's a fairly complete list:

<http://en.wikipedia.org/wiki/Java_bytecode>

There are lots of other online sources too.

 

[Andreas Leitgeb]

Correct. However there is no need to guess. Here's a fairly complete list:
<http://en.wikipedia.org/wiki/Java_bytecode>
There are lots of other online sources too.

True, but I agree to kernelerror, that reverseengineering some not
too trivial format can be an entertaining hobby. Looking at the openly
available docu is like looking at the solution when filling out a
crossword puzzle

Having reverse-engineered a public format surely doesn't earn
one the honour that reverse-engineering a proprietary format
would bring, or even more so an encrypted format (leaving aside
the legal hassles with the latter two)

There also was some fallacy in the original posting: just because
the class-file-format is big-endian, does *not* imply that the jvm
was also big-endian. It may be, or it may be not - even a little-
endian machine can run a program that reads in a number in big-endian
encoding.
To find out the actual endianness of a jvm, you'd probably
have to use a real-machine assembler level debugger, and
run the jvm inside that, and then watch how values are
really written to memory. This of course will only tell
you the endianess of that particular jvm that you are using
on your particular machine - not more.

 

[Andreas Leitgeb]

The JVM itself is a big-endian machine by definition.
To be precise, since that statement is ambiguous and therefore debatable, the
JVM presents a view to its clients of a big-endian virtual machine.

Can you actually provide a Java-code-snippet, that would make
obvious even the "presented" big-endian view?

e.g. something like C's:
short s=0x0100;if (*((char*)&s)==1) {puts("big");} else {puts("little");}
(I tested that on pc(little) and sun(big); checking for other obscure but
existing byte-orderings is left as an exercise to the interested reader

I could think of one way, that would involve "hacking" the bytecode of
a class (like removing some "s2b" bytecode) and hoping that the byte-code-
verifier doesn't notice. I'm not sure, if this wouldn't then (if
it actually worked) be seen as a bug in the verifier.

But then again, I might just miss the obvious.

So is a JVM big-endian? I say yes in the narrow sense that any code running
on the JVM thinks it's running on a big-endian platform.

Huh? How can there be a narrow sense? Does that mean, there can be more
than one exactly defined sense to anything in or around Java at all?

 

[Mike Schilling]

Can you actually provide a Java-code-snippet, that would make
obvious even the "presented" big-endian view?

There's no sense asking about whether Java is big- or little-endian
internally. It doesn't expose anything that would let you see that: no
pointers that can be converted from int* to byte*, no variant records, no
EQUIVALENCE statement, etc. Java's natural representation for external
data is big-endian: see DataInput (or any of the other ways of converting
between a byte stream and an integral type) for that.

 

[Roedy Green]

The best thing of this is that the , I learn that java virtual
machine
is a completely
a big edin processor . Just see that these instructions ,


sipush 300
sipush 500
invokevirtual guifirstlesson/GUIFirst.setSize(II)V

However, if you watch that code actually running, you will see little
endian values on the stack in a Windows JVM.

Logically Java is big-endian, but the carefully designed to make it
impossible to figure out which endian-ness is being used internally.

Obviously some of Sun's native classes know, but even they are sworn
to secrecy.

there are the system properties. See
http://mindprod.com/jgloss/properties.html
to find out indirectly.

 

[Roedy Green]

There's no sense asking about whether Java is big- or little-endian
internally.

DataOutputStream and the JNI interfaces are the only places where the
endianness is obvious.

 

[Arne Vajhøj]

The JVM itself is a big-endian machine by definition.

To be precise, since that statement is ambiguous and therefore
debatable, the JVM presents a view to its clients of a big-endian
virtual machine. Its own code runs on the endianness of the underlying
platform, which is what Andreas said.

So is a JVM big-endian? I say yes in the narrow sense that any code
running on the JVM thinks it's running on a big-endian platform.

????

A JVM uses the endianness it prefers => the endianess of the CPU.

DataInputStream/DataOutputStream classes always use network order
(big endian).

The JVM does not present any endianess to anyone.

If you send an int over to C via JNI then it uses endianess of
the CPU (host order).

Arne