This might sound like a ridiculous question, but I have to ask it because I have a working product which is doing this.
I have an applet running inside a browser. This applet is just not just any applet, but a fairly complex package application for CRM/ERP. I was told by a vendor company that they are able to monitor what a user does inside the applet, by replacing applet's main class at runtime before launch with their own. The term used was "endorsing".
I am a bit clueless now. How can you look inside an applet and listen on user clicks and keyboard events, even if you could somehow hack into it? I can tell you that this is a true story, because I have seen this vendor company's applicaiton and it just sits in the background and records all the contextual information (for instance, user filled which textbox in the applet, the name of the textbox and etc).
Are they any hacks at classloading level (I feel stupid asking this), or something else that I have not come across in java that would let you do something 'urban legendary' like this?
Java Applets are loaded using a HTML tags like this:
<applet archive="ApplicationSP1.jar,Application.jar" code="Main.class" name="myApp" width="800" height="600"></applet>
As you can see, the "archive" attribute supports several .jar files.
You could use this technique to load your own versions of the Java Classes of the application by putting them in the ApplicationSP1.jar file. They will be loaded before those classes stored in the second Application.jar.
Obviously, you would need to do some reverse engineering to understand which classes from the original application to override or wrap. Then you have to create new ones named exactly (same package and class name) as those you want to override.
Other option would be developing Aspects to capture events in the application and load these aspects using same technique of multiple .jar in the archive attribute of the HTML applet tag.
The solution for capturing Swing/AWT event can be found in
Want javax.swing hook that tells me WHICH component in the hierarchy is executing an action
It is difficult for overwriting Swing/AWT class used by applet which launching from browser.
They have to breaking the protection of Java security manager and get writing permission of JRE endorsed library folder.
For this case, Java Endorsed Standards Override Mechanism is hard to implement without manually operation of end user.
Related
I know there is a security policy restriction that does not allow cutting, copying, and pasting between an applet and some other application in the more recent versions of Java. However, my users need this functionality. Changing the java security policy file as defined here:
https://blogs.oracle.com/kyle/entry/copy_and_paste_in_java
is impractical when dealing with a distributed application that is used by 100's of users. So are there other alternatives that can be done in code? This is a signed applet.
From within a Java applet, even a signed one, I could not figure out how to access the system clipboard. Statements like this:
Clipboard clipboard = Toolkit.getDefaultToolkit().getSystemClipboard();
Actually freeze the applet making it impossible to continue. This is using Java 1.8.
I read something here:
https://brooknovak.wordpress.com/2009/07/28/accessing-the-system-clipboard-with-javascript/
That provided the basis for a work around. Basically, you capture the selected text (assuming it is text that you want to move to the system clipboard) in java then make a call from within the applet to a Javascript method with the selected text as a parameter. Javascript has built in methods that allow population of the system clipboard. The details are in the link above. Note, this was only tested with Internet Explorer 11.
I am creating a java swing application and I need to set the my program as the default program for the file extension .mcsd (MIME type text/mcsd). This must work on windows, and it would be nice if it worked on OS X/Linux as well. I am somewhat new to java (3 or 4 months) so please don't bombard me with all kinds of expert talk.
I have seen associating a custom file extension with java app in windows, but I would prefer not to use the Java Web Start. If possible, I would also like to know how to set the icon of that file type. I have found exe4j as a way of creating the .exe and plan to use it, but if is not the best tool for convertinf to an exe or someone knows something better feel free to tell me. Another thing: I need to be able to get the data from this file after the program has opened.
So my question is: how do I do this?
Deploy the app. with Java Web Start:
JWS provides many appealing features including, but not limited to, splash screens, desktop integration, file associations, automatic update ..
See the file services demo. for an example of a JNLP that declares an interest in the .zzz file type.
This is how the association is declared in the JNLP:
<association
extensions="zzz"
mime-type="text/sleepytime" />
JWS is supplied by Oracle and works on Windows, *nix & OS X.
..but I would prefer not to use the Java Web Start. Because I would like to have a native installer that just installs the program, without opening a web page or anything. If that's not how (web start) works, then I'm happy to use it.
JWS works over the web or a network. But if you can invoke the opening of an URL (to the JNLP) from the desktop, there does not need to be any browser opened.
Would I do that using openConnection() on a URL object?
I would use the Desktop or BasicService API.
Desktop.getDesktop().browse(uri);
boolean result = basicService.showDocument(url);
As noted in the BasicService demo.
In Java 6+, a call to show another web start launch file (e.g. BasicService.showDocument(another.jnlp)) will be handed directly to JavaWS, with no browser window appearing.
I expect this has always been true of the Desktop API, given the JWS client is the default consumer for that file type.
I need some advice on how to load a big applet.
I need to make an instance of JWord text editor to work as an applet, but the editor is about 4 mb.
I'm aware of the java web start solution, but my boss doesn't like it, so I'm stuck with the applet solution.
What I would like to ask you is on how to reduce the user waiting time.
JWord needs about 10 external libraries, so the question here is:
-pack up all in a single big jar?
-make the jars load singularly?
I'm putting this in a jsp page, but the last time I developed an applet the tag "applet" was not deprecated. Now I saw that it's been substituted with "object" tag, can someone help me with that? Point the similarities/differences?
And finally, since this is a big applet, I would like to know if there's the possibility to remove the grey box in the waiting, maybe putting a loading bar in replacement? If so please provide examples! Never done that before..
Thank you
In deference to Thorbjørn Ravn Andersen, I think 4meg is a huge download for an applet. Perhaps that is just me talking from the perspective of my very slow wireless connection. Some people have gone (significantly) further in applet size on LANs with high bandwidth.
Decrease the size of the download.
Use Pack200
& obfuscation (one of the few end purposes for which obfuscation is well suited).
Provide information to the user as applet loads.
Before the applet loads
See Special Attributes of Applets - image.
image The image attribute allows you to replace the default animation with a custom graphic.
Use an animated GIF like the one below, to indicate that something is happening.
(Image courtesy of http://www.ajaxload.info/)
After a tiny 'splash' applet loads
Trusted? Loader applet using URLClassLoader for the bulk of the download. Pop a
JProgressBar for the downloads after the initial 'splash applet'.
JWS versus standard deployment
You seem to be assuming a 'JWS solution' will result in a free-floating app. That is not the case since the Plug-In 2 JRE (Sun's 1.6.0_10+). As mentioned in the info. page on the applet tag - visit that page and chase the links for more details.
To use the JWS abilities you might have:
One jar for compatibility applet (used by a pre Plug-In 2 JRE). This results in one single HTTP request & a slightly smaller1 final Jar. (1) Smaller than the total size of a number of Jars.
Multiple Jars for JWS/Plug-In 2 JRE. Lazy loading of dependent Jars by the JRE as needed, or programmatically using the DownloadService classes.
See also the JWS info. page for more information on JWS generally.
Deploying the applet- applet vs. object.
Don't hard-code HTML for it, use the deployJava.js script referred to in both info. pages linked above.
There is nothing wrong with having a large applet, and the dependent jar referred to from the invocation snippet in HTML.
See the applet trail in the Java tutorial - http://docs.oracle.com/javase/tutorial/deployment/applet/deployingApplet.html
Note that there is a limit to the memory available to an applet, and - especially for older Java deployments - this may be too small for your application. In that case the easiest way is most likely the Java WebStart (which for Java 6 supports Applets too) where you can specify your memory needs.
You can shrink your program with the Free and Open Source program proguard. It takes big jars, and removes every class which isn't used.
Kind of hard to explain in one line but my problem is essentially like this:
I made a java applet that I want to run on a web page that I packaged into a .jar file. I'm able to get the applet working fine using the <applet> tag but the problem is, if the user views the page source, they will see:
<applet archive="directory/program.jar">
Assuming .jar files can be easily opened and all the class files decompiled, all the user would have to do is go to www.url.com/directory/program.jar to download my .jar and they would have all my source code :(
So I'm wondering if there is either a way to protect my code/jar from being decompiled (other than obfuscation) or to use some kind of server-side script to feed the contents of the .jar directly to the browser from a server-side location not publically visible.
Any help is appreciated.
This is fundamentally impossible.
Java applets run the client.
Anything that runs on the client can be disassembled and modified by a sufficiently advanced user.
You should move your sensitive logic to the server and invoke it using HTTP requests ( and remember that the user can use Fiddler).
While you're at it, you should probably replace your applet with HTML and Javascript.
Other than obfuscation or encryption, no--one way or the other, the browser will have access to the jar.
You might be able to create an applet that loads more functionality at runtime.
There is no effective way to block access to the source code of any page; for the page to be readable by browsers and search engines, the source code has to be accessible, and therefore can be viewed and/or copied. That's just how the web works. HTML is sent as a text document and interpreted client-side.
Disabling the right-click is little more than an annoyance, and it works sporadically in alternative browsers. Even if you succeed, the View Source option in the menu is always present. The viewer could also use a download tool such as Wget, or even get the page from the Google cache without visiting your site at all.
Edit: Oops! I misunderstood your question. You should follow #SLaks advice and "move your sensitive logic to the server and invoke ot using HTTP requests ( and remember that the user can use Fiddler)."
While quantum mechanics do rule the universe, they have less of a grip on your code than you might suspect. You cannot both deploy code to the client browser and not deploy code to the client browser. You have the option of doing one or the other.
You can prevent direct browsing to your .jar file by locating it beneath the WEB-INF directory in your WAR file. This will also prevent <applet archive="directory/program.jar"> from working.
Once the jar is beneath the WEB-INF directory you will need something to feed the resource to the client browser; the Spring resources servlet is good for this (If you are using Java and Spring). I feel confident that other such tools exist. With the Sprint resours servlet, your would deploy your applet with something like this: <applet archive="resource/program.jar".
If you write your own resource distributor, you can add security to make it harder to get the jar file; perhaps add a header to your requests like IRGud: <user_id here> and fail any request that does not have that header (or acceptable contents in the header).
I have developed a command-line (read: no GUI) Java application which crunches through numbers based on a given dataset and a series of parameters; and spits out a series of HTML files as resultant reports. These reports hold a large amount of data in tables, so in order to give the users a easy and quick overview of the results, I utilized the JUNG2 library and created a nice graph.
Here's where it gets interesting; since I would like the graph to be interactive it should be deployed after the application has run and files are generated, whenever the user wants to view the reports. I decided to go with an applet based deployment, however I am not too happy with the current setup due to the following reasons:
I want to make the software as simple to use as possible (my users won't be tech-savvy, and even tech-intimidated in most cases). I would really like to distribute one JAR only, which forced me to put the applet with everything else it needs in a package in the same JAR as the main application.
The applet and the main application need to communicate the results, so I create a xML-based report which is used to hold information. As long as the files are on a local machine and are not moved around it all works fine. Unfortunately I also need the files to be moved around. A user should be able to take the "results" folder to a USB stick, go anywhere plug the stick to another computer and be able to use the report as he/she likes.
For the time being the applets are implemented with the following html code:
<applet code="package.myapp.visualization.GraphApplet.class"
codebase="file:/home/user/myApp"
archive="myApp-0.2.6-r28.jar"
width="750" height="750">
<param name=input value="results/test_name/results.fxml">
</applet>
As you can see this applet will not work if the parent folder is moved to another location.
As far as I know I have a couple of alternatives:
a) Change codebase to point to an URL on our webserver where I could put the jar file. This however creates the problem with permissions, as the applet will not be able to read the results file. Alternative is to upload the results file to the server when the user wants to visualize the graph, although I am not sure if that's a good option due to server security and also if it could be made so that upload happens automatically without bothering the user.
b) I can use a relative path on the codebase attribute, but then the whole folder hierarchy needs to be intact upon copy. This could be a last resort, if I cant come up with a better way to do it.
c) change the deployment method (would like to avoid this alternative to not spend more time on the development phase)
Any ideas? Am I missing something? How could I tackle this problem?
Thanks,
I'm not sure I entirely understand your use-case, but from what I do understand, I would suggest this:
Dump the applet for an application launched using Java Web Start. Have the JNLP file declare a file association for the fxml file type. When the user double clicks an fxml file, it will be passed as an argument to the main(String[]) of the JWS application.
A sand-boxed JWS application can gain access to resources on the local file system using the JNLP API. Here is my demo. of the JNLP API file services.