Comparing a jar'd class to the runtime class

[James D Carroll]

I'm looking for a way to do the following:

1. Inspect a jar and find out the contents of it. Having identified classes
I would like to get an MD5 hash of them.

2. Verify that the class I found in the jar and loaded via Class.forName()
is that same as the one in the jar.

 

[Sudsy]

I'm looking for a way to do the following:

1. Inspect a jar and find out the contents of it. Having identified classes
I would like to get an MD5 hash of them.

2. Verify that the class I found in the jar and loaded via Class.forName()
is that same as the one in the jar.

Well, duh! Jeesh!! What were you thinking ?!?

(direct quote from a previous response of yours...)

 

[James D Carroll]

HAHAHAHAHA!!!! Well played.

But then I bow to their knowledge of COM, etc.

I bow now to yours....

Any ideas?

 

[Sudsy]

HAHAHAHAHA!!!! Well played.

But then I bow to their knowledge of COM, etc.

I bow now to yours....

Any ideas?

As of 1.4.2, there wasn't a Class#toBytes method. It would still have
required some convolutions to generate an MD5 hash...
Can't you use Object#hashCode().equals()?
Trust me, the JCE is no place for the faint-of-heart!

 

[Liz]

I'm looking for a way to do the following:

1. Inspect a jar and find out the contents of it. Having identified classes
I would like to get an MD5 hash of them.

This will get you a list of the files in the jar file.
unzip -t filename.jar
But you will need to extract them to compute the md5.
Then for each file you can do this.
md5 filename
Where md5 is the well known program

2. Verify that the class I found in the jar and loaded via Class.forName()
is that same as the one in the jar.

Don't know this one.

 

[Chris Uppal]

1. Inspect a jar and find out the contents of it. Having identified
classes I would like to get an MD5 hash of them.

This can be done using the stuff in java.util.zip. Alternatively you can use
getResource() to find .class files in "the" source jar.

2. Verify that the class I found in the jar and loaded via Class.forName()
is that same as the one in the jar.

This cannot be done in general. You can create your own classloader which
retains (a hash of) the byte[] array of classes as they are defined, but for
classes that are not loaded via that classloader, this data is not available.

But then, if you are using your own classloader, why do you need to check that
it's loading the "right" class definition from the JAR file ?

You don't say what you are trying to achieve, but it may be that signing and
sealing the JAR would get some of what you are looking for.

-- chris

 

[Chris Smith]

I'm looking for a way to do the following:

1. Inspect a jar and find out the contents of it. Having identified classes
I would like to get an MD5 hash of them.

2. Verify that the class I found in the jar and loaded via Class.forName()
is that same as the one in the jar.

The first part is easy. Just use the java.util.zip package to inspect
the contents of the JAR. The second part is more difficult. If you
need to load classes from that JAR, why not just create a URLClassLoader
to do so, and load the class directly from there?

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Roedy Green]

2. Verify that the class I found in the jar and loaded via Class.forName()
is that same as the one in the jar.

Why wouldn't it be? If someone has tampered with the that process,
surely they could tamper with your code to check up on them.

Perhaps you could do a sanity check, make the class do some
computations and check it gives the expected result.

If this is anti-piracy logic, see
http://mindprod.com/jgloss/obfuscator.html
for some hints.

 

[Hemal Pandya]

Why wouldn't it be? If someone has tampered with the that process,
surely they could tamper with your code to check up on them.

Perhaps you could do a sanity check, make the class do some
computations and check it gives the expected result.

Or perhaps to verify that the class was indeed located from the
location the programmer intended for it to be loaded. See
http://groups.google.com/groups?\
threadm=MPG.17cad830743b828398a282%40news.altopia.com
for an approach that will work in some cases.

But if this is the case then I would say it should be tackled at the
level in your development enviroment rather then at run-time. See
http://mindprod.com/projects/pathtool.html for a possible approach.

Of course, I could be wrong.