View Full Version : a question about un-signing signed java appets

April 13th, 2012, 12:15
Hi all,
in order to build a proof-of-concepts of a MITB attack (man in the browser) I need to un-sign a signed applet, in order to tamper it on the fly.

The question is therefore on how to transform a signed applet into a not signed one. BTW, the class files are not obfuscated.

What I read around the net is that it seems to be enough to remove the MANIFEST and *.RSA files inside the META-INF\ folder. Or rather eliminate that folder directly. This is what I found in the documentation, but actually it seems not to be enough. The JVM still complains that the jar file is not properly signed and refuses to execute my tampered jar file. Even jarsigner reports that the tampered jar has some problems with the signature (tested on a really not signed jar it correctly says that it's not signed, but on my tampered jar it reports an error). Clearly removing the META-INF folder is not enough!

So the question is, what is really needed to fully un-sign an already signed jar applet?

I think the process is almost the same for apk android files as far as I understand..

Thanks for replies.

April 13th, 2012, 13:18
Hi Shub,

it may sound dumb, but why don't you sign a .jar yourself and compare the signed one with a copy of the unsigned?
This way you should find any change made to the .jar by Jarsigner (or whatever you'll use to sign the .jar).

Sorry if you already did that.


April 14th, 2012, 11:05
Or better, why don't you take a page from Flexlm, and patch the JVM itself to return without errors.

Have Phun

April 16th, 2012, 06:09
Hi Shub-nigurrath,

you are right. What you did was not enough to unsign either an signed java jar file or an apk file.

What you have to do:

1. Open /META-INF folder
2. Remove *RSA/*DES/*ECC file + *.SF ( keep in mind that /META-INF can be considered to be a resource directory, so it is possible that there are also other signing file which are not used for jar file / apk file validation - for obvious reasons you shouldn't remove these )
3. Open MANIFEST.MF and remove all pair of...

Name: xxxxx/afilename.something
SHA1-Digest: uneX14xEH0gSHHheMmH71ypY7kU=

It is possible the the you will find entries which does not contain SHA1-Digest entries but instead different like MD5, etc...

Finally if you have removed all of them the jar / apk should be unsigned.

If the application still refused to run that is is very likely that your application is programmatically setting up an own security manager which will
prevent the application from running unless the application is not signed with the correct key. in that case you will have to patch the setting up
of the security manager in order to get around that limitation.

Hope that helps!


April 16th, 2012, 06:31
it helps indeed. Moreover I was using the sharpziplib which is creating wrong zip files: the size of data value in the header was always filled with FF (and it's a bug documented since 2009!). I now changed the c# library and now works..

But I am facing a problem similar to what you told: the applet uses it's own class SecureClassLoader: A property file inside the jar is dynamically loaded and converted into a class, which is turn executed.

I am over an https connection, what I am experimenting is to tamper the certificate with my own (typical end-point MITM attack using a proxy) and dynamically unsign the applet. The SecureClassLoader shouldn't work in this situation, right? And the property file cannot be dynamically loaded, right? How can I patch the class files in order to execute even in this case?


April 16th, 2012, 07:20
You have to supply more information about the problems you are exactly facing. I have a few questions.

0. Is the SecurityClassLoader loaded before or after loading the property file ?
1. The property file, is it a standard java properties containing lines of key = value pairs ?
2. If not, do you understand the format and can you edit it in a text editor ?
3. Does the property file contain the certificate you are talking about ?

As you mentioned your main problem is the SecurityClassLoader. As soon as it is setuped you have a problem, because as far as i know you cannot revoke the instantiation of the loader or even load a new SecurityClassLoader, but I'm not sure about that...
Nevertheless you have two possibilites:

Either you patch the code which is responsible for setting up the SecurityClassLoader in a way that makes the ClassLoader useless or you completly remove the classloader by replacing it with a simple ClassLoader which is not doing any verification. In each of these cases you will have to patch.

There is another possibility which is like firing a cannon on a bird but it will work

The manifest file should define a main class which is considered to be the entry point your applet right ? You could replace entry with one of your own classes. Then you register your own class loader instead and continue execution of the original application entry point. in that case you would gain control when the application is trying to instantiate the SecurityClassLoader. As soon as this happens you could use a binary instrumentation framework like ASM ( http://asm.ow2.org/ ) to manipulate the code from here like you need. You could as soon as the SecurityClassLoader is reaching your ClassLoader return you instance of your ClassLoader instead of really creating a ClassLoader. That should solve your signing problem.
Then there is only one thing to do. Identify the class which contains the certificate or which loads the certificate and intercept it before you https/ssl connection is created. you are done now

Second approach will take some time, but it will work for sure. Drawback here is that the for example the ASM library for runtime bytecode instrumentation is round about 2 MB of code. This is not very small, especially in the case of an applet.

Choose your way now!!!!!!! ;D


April 16th, 2012, 07:23
PS: Forgot so say, If you are allowed to send the sample you are working on I will have a look this evening.

April 16th, 2012, 08:27
unfortunately I cannot send any sample out.

BTW what I am trying now is to re-sign the applet on the fly with my own certificate, so as to "validate" the patches I did. This should quiet the secureclassloader. If this fails I'll consider the other alternatives you mentioned.

April 16th, 2012, 08:54
I'm not exactly sure what do you mean with signing it on the fly but if it means to sign the application after the first class is loaded then you won't be successfully. The signing stuff in java can be seen as preload validation. After the application is started the signture is not longer checked by the system.
Regarding the SecureClassLoader: It could be that even if you sign your application with your own key, that it won't run. If so you have to search for the so called Security Manager and or a Protection Domain.

Good luck!

Would be nice to leave us a note wether you have been successful or not


April 16th, 2012, 09:10
with signing on the fly I mean to remove all the signature files to transform the jar into a not-signed applet and then add a new signature using keytool and jarsigner "on-the-fly", online, just with the proxy holding the communication to the browser. I am doing a MITM attack thus my jar is intercepted on the GET request and tampered before the browser/jvm can ever see it.

April 18th, 2012, 11:29
at the end I solved the problem signing on-the-fly the applet with another certificate. This was enough to let the SecureClassLoader to succesfully execute the classes.

April 19th, 2012, 12:04
Can a tut on this be expected?

Have Phun

April 20th, 2012, 02:37
might be, before I have to understand what can be said and what cannot or to find public alternatives/similar stuffs to reproduce the experience.