Tracing rt.jar?

[Stefan Ram]

Is there an rt.jar somewhere out there than can replace the
standard rt.jar, but was instrumented to trace° all incoming¹
calls with their argument values? Or some other technique
with that effect?

°) print, report, log

¹) Ideally, it would trace a call only when coming from a
non-rt.jar method, but not intra-rt.jar-calls.

Thus, when you have an application or applet running, you
can essentially see what it is doing, even if it was obfuscated.

 

[markspace]

Is there an rt.jar somewhere out there than can replace the
standard rt.jar, but was instrumented to trace° all incoming¹
calls with their argument values? Or some other technique

Hmm, you can step into rt.jar with a debugger, and if you have the
source loaded it will at least show you what lines are executed branches
are taken (although local variables have been optimized away).

I've also accidentally enabled "FINEST" level of debuging for java.*
files and gotten quite a lot of spew. That won't work if the classes
you are interested in don't log, but it might be worth a shot.

I don't know of anything that specifically does what you want, although
if you look into aspect oriented programming I think they might have
something there that can auto-magically instrument a .jar file with
logging. This would be a lot easier than trying to do the byte code
re-writting yourself.

Can you tell us specifically why you need this? What's the use case,
model, or failure mode here? You question is kind of general.

 

[Stefan Ram]

Can you tell us specifically why you need this? What's the use case,
model, or failure mode here? You question is kind of general.

To analyze an Java applet. I /can/ already enable the finest
trace level in the Browser's Java console and enable
logging, but that does not show that much. The class files
are obfuscated. The idea is to learn how the applet
accomplishes certain tasks.

 

[markspace]

To analyze an Java applet. I /can/ already enable the finest
trace level in the Browser's Java console and enable
logging, but that does not show that much. The class files
are obfuscated. The idea is to learn how the applet
accomplishes certain tasks.

Is it your applet, or are you actually analyzing something that someone
else wrote? Do you have access to the applet source?

Just curious: are there any DMCA issues involved here, or EULA issues,
per chance?

Have you considered running the applet outside of a browser? It's just
code you can download and run in any JVM. How much work are you willing
to put into this?

 

[Daniele Futtorovic]

Is there an rt.jar somewhere out there than can replace the
standard rt.jar, but was instrumented to trace° all incoming¹
calls with their argument values? Or some other technique
with that effect?

°) print, report, log

¹) Ideally, it would trace a call only when coming from a
non-rt.jar method, but not intra-rt.jar-calls.

Thus, when you have an application or applet running, you
can essentially see what it is doing, even if it was obfuscated.

I wouldn't bet on the existence of such an rt.jar, but it seems to me
you should be able to achieve what you want with Instumentation, and
perhaps a library like this one: <http://jiapi.sourceforge.net/>.

 

[Arne Vajhøj]

Is there an rt.jar somewhere out there than can replace the
standard rt.jar, but was instrumented to trace° all incoming¹
calls with their argument values? Or some other technique
with that effect?

°) print, report, log

¹) Ideally, it would trace a call only when coming from a
non-rt.jar method, but not intra-rt.jar-calls.

Thus, when you have an application or applet running, you
can essentially see what it is doing, even if it was obfuscated.

It would be trivial to write an aspect in AspectJ and weave it
into all the classes in non-rt.jar!

Arne