Is it possible to reverse - engineer a dll to find its methods that are acceptable to call? I don't think this is possible, but i am just asking. Also, if this is not possible how does the jvm make calls to the local OS? Did Sun produce their own .dlls for each OS so they could access native code? (Swing, AWT, and threads would be examples of making OS native calls.)
Thanks for your time,
Nate
> Is it possible to reverse - engineer a dll to
> find its methods that are acceptable to call?
Yes it is possible to reverse a dll. Or any piece of code for that matter. There are freeware and commercial products that will take object code and produce assembler, C and/or C++.
> Also, if this is not possible how does the jvm make calls to the local OS?
Sun uses the published API of each OS. There is no need for it to research the actual interfaces.
>Did Sun produce their own .dlls for each OS so they could access native code?
Yes. At least the stuff that they wrote. Other people wrote other stuff - like the jdbc drivers from Oracle.
Let me clarify my question some.
In reading the tutorial for JNI you must follow these steps:
1.) Create your java file and its required native method interfaces.
E.g.: public native void displayHelloWorld();
2.) Compile this java file into a class file using javac.
3.) Produce a .h file by running javah on your compiled class from above. This .h file is a header file that defines the interface that your corresponding .dll must implement or your JNI call will not work. Is this a correct statement or not?
Here is an example method that was produced in the .h file from trying the HelloWorld JNI Tutorial.
JNIEXPORT void JNICALL Java_HelloWorld_displayHelloWorld(JNIEnv *, jobject);
Now, if my .dll that i create does not implement this method i will get an error correct?
So, what my previous question was asking was: Is it possible to make Java call different methods then the ones defined in its created .h file? IF it is possible how do you do it?
Thanks for your time,
Nate
> interface that your corresponding .dll must implement or your JNI call will not work.
> Is this a correct statement or not?
If the native function is called then that exact interface must exist in a loaded dll. If not then you get a "Unsatisfied Link Error"
>Now, if my .dll that i create does not implement this method i will get an error correct?
You will get an error if you call the method and a loaded dll with that interface is not found.
>Is it possible to make Java call different methods then the ones defined in its
>created .h file? IF it is possible how do you do it?
I am guessing that you want to know if it can call a different interface than the one specified? Then the answer is no. The interface must match. But by writing a wrapper your interface can call another routine.
If interested there is also a package, commercial I believe, that will allow you to dynamically call window OLE stuff without writing your own wrapper. I haven't tried it but the description sounded interesting (but I don't seem to have a url.)
> Is it possible to make Java call different methods then the ones
> defined in its created .h file? IF it is possible how do you do it?
Before running a ntaive method, it goes a 2 step process:
- Load the library (System.loadLibrary)
- the VM locates the native method implementation
By default, the second step relies on a naming convention.
It's however possible to change the way methods are inked using:
(*env)->RegisterNatives(..), for example in the JNI_OnLoad handler.
This can be used:
- for efficiency. it's sometimes more efficient when you have a large number
of native methods (vs letting the VM link lazily)
- one can update the native implementation at run-time
- you embed a VM and the native method implementation is not in a library,
but in the exe.
- you don't like the default name mangling and dont care writing thousands
lines of code to change this.
This is explained in chapter 8.4 of the book 'The Java Native Interface -
programmer's guide and specification', a really good reference IMHO.
jschell wrote the following:
Yes it is possible to reverse a dll. Or any piece of code for that matter. There are freeware and commercial products that will take object code and produce assembler, C and/or C++.
I want to know which freeware or commercial products reverse engineer a dll into a source code
