Results 1 to 13 of 13

Thread: a question about un-signing signed java appets

  1. #1
    Super Moderator Shub-nigurrath's Avatar
    Join Date
    May 2004
    Location
    Obscure Kadath
    Posts
    430

    a question about un-signing signed java appets

    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.
    (`._.[*~-.,.-~* ŜħůβŇĝŕřāŧħ ₪*~-.,.-~*]._.)
    There are only 10 types of people in the world: Those who understand binary, and those who don't
    http://www.accessroot.com

  2. #2
    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.

    Regards
    darkelf
    I flout Chuck Norris, Spongebob barbecues underwater!

  3. #3

    As Above...

    Or better, why don't you take a page from Flexlm, and patch the JVM itself to return without errors.

    Have Phun
    Blame Microsoft, get l337 !!

  4. #4
    ::[ Reverse Engineer ]:: OHPen's Avatar
    Join Date
    Nov 2002
    Location
    .text
    Posts
    399
    Blog Entries
    5
    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!

    Regards,
    OHPen
    - Reverse Enginnering can be everything, but sometimes it's more than nothing. Really rare moments but then they appear to last ages... -

  5. #5
    Super Moderator Shub-nigurrath's Avatar
    Join Date
    May 2004
    Location
    Obscure Kadath
    Posts
    430
    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?

    BR
    (`._.[*~-.,.-~* ŜħůβŇĝŕřāŧħ ₪*~-.,.-~*]._.)
    There are only 10 types of people in the world: Those who understand binary, and those who don't
    http://www.accessroot.com

  6. #6
    ::[ Reverse Engineer ]:: OHPen's Avatar
    Join Date
    Nov 2002
    Location
    .text
    Posts
    399
    Blog Entries
    5
    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

    Regards,
    OHPen
    - Reverse Enginnering can be everything, but sometimes it's more than nothing. Really rare moments but then they appear to last ages... -

  7. #7
    ::[ Reverse Engineer ]:: OHPen's Avatar
    Join Date
    Nov 2002
    Location
    .text
    Posts
    399
    Blog Entries
    5
    PS: Forgot so say, If you are allowed to send the sample you are working on I will have a look this evening.
    - Reverse Enginnering can be everything, but sometimes it's more than nothing. Really rare moments but then they appear to last ages... -

  8. #8
    Super Moderator Shub-nigurrath's Avatar
    Join Date
    May 2004
    Location
    Obscure Kadath
    Posts
    430
    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.
    (`._.[*~-.,.-~* ŜħůβŇĝŕřāŧħ ₪*~-.,.-~*]._.)
    There are only 10 types of people in the world: Those who understand binary, and those who don't
    http://www.accessroot.com

  9. #9
    ::[ Reverse Engineer ]:: OHPen's Avatar
    Join Date
    Nov 2002
    Location
    .text
    Posts
    399
    Blog Entries
    5
    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

    Regards,
    OHPen
    - Reverse Enginnering can be everything, but sometimes it's more than nothing. Really rare moments but then they appear to last ages... -

  10. #10
    Super Moderator Shub-nigurrath's Avatar
    Join Date
    May 2004
    Location
    Obscure Kadath
    Posts
    430
    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.
    (`._.[*~-.,.-~* ŜħůβŇĝŕřāŧħ ₪*~-.,.-~*]._.)
    There are only 10 types of people in the world: Those who understand binary, and those who don't
    http://www.accessroot.com

  11. #11
    Super Moderator Shub-nigurrath's Avatar
    Join Date
    May 2004
    Location
    Obscure Kadath
    Posts
    430
    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.
    (`._.[*~-.,.-~* ŜħůβŇĝŕřāŧħ ₪*~-.,.-~*]._.)
    There are only 10 types of people in the world: Those who understand binary, and those who don't
    http://www.accessroot.com

  12. #12

    As Above...

    Can a tut on this be expected?

    Have Phun
    Blame Microsoft, get l337 !!

  13. #13
    Super Moderator Shub-nigurrath's Avatar
    Join Date
    May 2004
    Location
    Obscure Kadath
    Posts
    430
    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.
    (`._.[*~-.,.-~* ŜħůβŇĝŕřāŧħ ₪*~-.,.-~*]._.)
    There are only 10 types of people in the world: Those who understand binary, and those who don't
    http://www.accessroot.com

Similar Threads

  1. java obfuscators, which ones?
    By Shub-nigurrath in forum Advanced Reversing and Programming
    Replies: 4
    Last Post: June 7th, 2012, 08:37
  2. Singnatures signed by Verisign
    By zdr in forum Advanced Reversing and Programming
    Replies: 7
    Last Post: April 22nd, 2006, 08:11
  3. Vista - drivers signing
    By begemott in forum Off Topic
    Replies: 22
    Last Post: February 23rd, 2006, 04:42
  4. java BigInteger
    By neur0n in forum The Newbie Forum
    Replies: 2
    Last Post: November 24th, 2004, 07:43
  5. java : PE & .class
    By keyser in forum Advanced Reversing and Programming
    Replies: 1
    Last Post: December 23rd, 2000, 13:45

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •