View Full Version : path of a running applet class file

April 15th, 2011, 10:22
Hi all,
I have a question which I am trying to understand.

How the browser launches the JVM when it finds an applet inside an html page? Looking the JVM process I see there are several named pipes between JVM and the calling browser.

So the question is which of these options is good
1. the browser downloads the .class file and gives it back to the JVM which executes it (for example using an IPC mechanism)
2. the browser invokes the JVM giving only the url (therefore the Java Network Launch Protocol is used)

What I want to have is the access to the real .class which is actually executed by the JVM and possibly hook the moment into which the JVM starts the class execution.


April 15th, 2011, 23:19
Hmm, I'd be interested in that myself. I've been caught a couple of times, getting hit with a driveby java applet. Suddenly the JRE icon would pop up and I knew something was up. Fortunately Comodo prevented anything bad from running.

The first time I was able to get the straight .class files from a temp directory, the second time, which happened just the other night, I got 2 exes.

I took a look at the Java control panel settings and found temp files are also kept under

C:\Documents and Settings\~\Application Data\Sun\Java\Deployment\cache

Searching the subfolders by date I found some interesting stuff from the most recent attack. IDX files seem to contain the actual url's that redirect to the malware downloads. The randomly named binary files had identifying headers. One was a PE and identical to one of the exes I pulled from another temp directory. One had a PK signature and when changed to a zip extension I extracted several .class files. And one had the CAFEBABE sig of a class file.

This probably doesn't answer your question per se, but I found it interesting that you can do a post mortem by looking under that \cache directory.


April 16th, 2011, 17:13
indeed after some investigations I found these things.

1. the cache doesn't store all the class files you can usually find in the html pages. Still don't exactly know which criteria it uses to store or not class files into the cache.
2. the memory dump of the jvm holds the running applet (of course). Still anyway don't know if it gets it from the browser through a pipe or downloads it directly. I have not run any special net sniffer yet to chose which of the two options are in place.

April 22nd, 2011, 16:06
That's how applet <-> browser handling works ..


Each applet has four methods that determine its life cycle. Calling this method automatically when certain user actions from the browser. These actions include, for example, the loading of an applet or leaving an HTML page in which an applet is embedded. Some of these methods:

init () Is always called when the applet is initialized. This occurs immediately after it is loaded.

start () Is executed after the initialization of an applet. There will also use this method instead of whenever the browser or the applet viewer from the icon display is restored to normal size. With browsers, start () then called up when a page where an applet is located, load times will be repeated on.

stop () Is the counterpart to start () . A call occurs when the browser or the appletviewer reduced to an icon or an HTML page is exited with an embedded applet in a browser.

destroy () Is always called when the applet is destroyed. The destruction occurs, for example, when it is removed from the browser. During a Web session may be downloaded lots of applets. Thus, a large amount of memory available. This reduces the amount of used memory is not constantly increasing, creating, for example, the Netscape Navigator Court, be removed by excessive memory load old applets. If a remote applet loaded again, it goes through the initialization again.

By default, the above methods any code. They can be in an appropriate manner of writing to the functionality required to give his applet. init () is usually implemented with applets, since this procedure store the applet is executed first and after the initialization tasks, such as creating objects, takes over . The other methods can be overridden as required.

To get an idea of ​​how the life cycle methods are called, you can test the following applet:

import java.applet.Applet;

public class demo extends Applet {cycle

public void init () {
System.out.println ("init";

public void start () {
System.out.println ("start";

public void stop () {
System.out.println ("stop";

public void destroy () {
System.out.println ("destroy";


The applet gives each the name of the method that is called by the interpreter, on the standard output, ie either on the console from which the applet viewer is started, the Netscape Communicator, for example, by selecting the menu "Communicator | Java Console or call the Java plug-in by enabling the Java console on the Java icon in the taskbar. Figure 7.1 life cycle methods shows the dependence of the calls by the actions of the user.

Applet and browser to communicate with each other. As a browser communicates with the call of methods of the life cycle of an applet, as demonstrated in the previous section.

An applet also has the ability to communicate with the browser. An applet can:

a new URL in the browser,
the status bar of the browser change,
Message exchange with applets that are on the same HTML page.

This communication is via the interface applet context settled. applet context but not by the applet, but the browser or applet viewer is implemented. applet context of the particular environment is replaced by the one from the class by calling the Applet method provided getAppletContext () .

applet context contains all the methods to communicate with the browser are required to. The individual methods are described in more detail.

Show the data in a URL

An applet has the option of data from a new URL in the browser to load. This can be applied for example to implement a navigator. Another possibility is to implement an image map. In an applet can be status text, depending on mouse position change (see next section) and then pressure in mice, a new URL 's. For this purpose, we use the method show document () of the applet context . showDocument () is available in two versions:
showDocument (URL) Shows the data from the specified URL in the browser.
showDocument (URL, String) Shows the data from the specified URL as the string passed in browser frame. However, this method can be applied only to a browser capable of displaying frames (eg Netscape Navigator). The individual values ​​for string, see the reference.
For example: A browser is to be divided into two frames. A browser frame is used to display the HTML pages that contain information and the second frame contains an applet that is used for navigation.

The applet has two navigation buttons. Each of the buttons representing a HTML page. If you press a button, the page information in the frame is loaded.

Viewing a document introduced by the following two lines:

URL page = new URL (getCodeBase (), "FirstPage.html";
getAppletContext () showDocument (page, "data";.

The above code is executed when the button is clicked, the page should load SecondPage.html.

First class is a copy of the URL generated. This is necessary because one of the parameters show document () of type URL 's. The class URL is in Section 13.1 explains in detail.

Thereafter, the data of the URL with the method show document () appears. The location and name of the browser frame in which the data will be displayed, passes them as parameters. In this case, "the file FirstPage.html in frame with the name" data is displayed.

April 22nd, 2011, 16:23
thanks a lot for the explanatory reply, but the links are in german..gasp! Nothing in english??

April 22nd, 2011, 20:52
hmm .. just use google translator it makes good results

July 2nd, 2011, 10:14
Sorry to bring up this old thread.

But for Drive-By as mentioned by Kayaker, i thought one of the more commonly used methods is using JNLP.
Nowadays everyone installed Java and if attacker grabs all the banners and wordings used by Oracle for JRE. Victims will fall for it and click "OK".

But using this method might not be so simple, most attackers which i've seen that adopt such techniques is using MiTM or already compromised the website.

@Shub: Yoz boss, just wondering are you trying to target JRE so that the applets that are running will run untrusted code and eventually will gain full privileges of the user executing the browser process.

Will the articles on this site help anyone?

[ Gunther ]