I need general outlook on organization of java applications.

1. I need to know the basic structure of such an app.
2. Are java apps like vb runtime interpreted and thus do work slower?
3. Why java exe needs to export lots of funtions with names including word java in them?
4. To me java app is a regular exe calling java routines. Am I correct?
5. What is the purpose of jre named directory at the root of a tipical application tree?

I need this in order to know where to look and what to expect.

Maybe some knows where I could read more about this?

Thanks

1. I need to know the basic structure of such an app.

there's a class that acts as a main entry point to the application, and that is the primary consumer of other application's classes.

2. Are java apps like vb runtime interpreted and thus do work slower?

Java apps are not compiled to machine code but to a 'bytecode' that is interpreted by the Java VM (Virtual Machine) and by it translated into machine and host system code. Obviously as any interpreted language it results into slower code, even if with the recent Hot Spot lets code running faster because of an optimization.

3. Why java exe needs to export lots of funtions with names including word java in them?

That is not really clear man, what u mean with "java exe"?

4. To me java app is a regular exe calling java routines. Am I correct?

Definitely not, a java app is a collection of (bytecode) classes loaded up into a process that is the Java VM and by it executed.

5. What is the purpose of jre named directory at the root of a tipical application tree?

the JRE (Java Runtime Environment) is the (Java) Environment in which a java app is executed, we have in it all the wrapper DLLs, the VM itself and the base classes of the language, to let java applications interfacing with the underlying system .... Obviously every OS on any Platform has its own JRE.
The javac tool and the other tools under the bin directory are only wrapper of java classes, they do nothing except calling particular java classes to perform such operations like compiling and so on .....

Thank you theCaller you are very helpful.

3. Why java exe needs to export lots of funtions with names including word java in them?

That is not really clear man, what u mean with "java exe"?

here goes short abstract from the exe export function list :

00000008 0040A510 _Java_mws_edit_Editor_fixPCR@12
00000009 0040A290 _Java_mws_edit_Editor_generate@16
0000000A 0040A0F0 _Java_mws_edit_Editor_native_1destroy@8
0000000B 0040A040 _Java_mws_edit_Editor_native_1init@12
0000000C 0040A140 _Java_mws_edit_Editor_setParams@32
0000000D 0040A220 _Java_mws_edit_Editor_setTransParams@28

Every entry contains Java word in the name. That way there are over 100 entries in total.

Is this normal or a maze of a particular application?

Thanks

that means that there's native code intarfaced by java. Using the JNI (Java Native Inteface) you can invoke methods not implemented in java but in native code that is funcions hosted in DLLs and so one. This can be obtained declaring some class methods as "native" so you inform the compiler that the implementation of that/those method/s is hosted in some native code libraries (read DLLs and so on on Win32 Platform) ......

When you finish coding your class with methods declared as native, you use a particular JDK tool called "javah" to create a ".h" prototype C/C++ file for the native language imlpementation of the methods you declared native.
In the JDK include directory you'll find the ".h" prototype files that wrap the Host System data Structures.

Obviously there's a standard naming convention for the methods you implement in your library, that is the Java_<package_listing>_<classname>_<methodname>.

You actually implement that/those methods in a C/C++ file, create a library (read DLL on Win32 OSes) and then put the resulting dynalib in the system path.

Though the Java call System.loadLibrary("<your library>"; in a static block of your java (main) code you let the VM load your library and link it at runtime to invoke the methods you declared as native.

Of course, you can call even Java code from you libraries, in a kinda reverse process. that is VM->DLL but you can even do DLL->VM through the VM environment pointer. Consider then that this approach can be really slow.

regards.
theCaller.

Hiya,



As theCaller said, a java app is NOT a regular .exe as it is controlled and executed by the java virtual machine. Nevertheless, it might be worth mentioning from a reversing perspective that one can potentially attack the native implementation of java on a specific platform. I mean, on the x86 architecture, everything must eventually resolve down to the good ol' ASM that we know and love, eh? In the case of win32, this is the msjava.dll, fully disassemblable, patchable, and attackable in softICE Msjava.dll, for example, is responsible for loading classes into the Java virtual machine and some of the security checks verifying the integrity of class files. At one point, I "unpacked" a Java app by using SoftICE and patching the class loader API in MsJava.dll to dump all of the decrypted class files to disk. It was pretty interesting to disassmble msjava.dll, look at its exported functions, and realize java can be just as vulnerable to SoftICE on a low level as the next protection... At that point, I couldn't write a line of Java code to save my life... Just putting my 2 cents in that there may be creative alternatives if you know ASM, but don't know Java programming very well.

Cheers,
Clandestiny

eheheheh