5

Currently reversing a .jar program recreationally, and I understand the workflow proposed here:

https://www.netspi.com/blog/technical/thick-application-penetration-testing/patching-java-executables-the-easy-way/

But whenever I go to repackage the folder containing the .class files into my .jar a couple of things go wrong. Firstly the file is a different size than the original, and the .jar will not run at all and instead throws a manifest error.

""" no main manifest attribute, in xxx.jar """

The only change I am making at this time is to a string changing it from "Welcome!" to "LOL!xox!".

I repackage the .jar with the following command: jar -cvf xxx-2.jar -C xxx-1/ .

If I extract the new .jar again and diff the two directories I get changes in directories that I didn't touch

  • └──╼ $diff -q xxx-1/ xxx-2/

    Common subdirectories: xxx-1/META-INF and xxx-2/META-INF

    Common subdirectories: xxx-1/net and xxx-2/net

    Common subdirectories: xxx-1/org and xxx-2/org

It's worth noting that after executing jar -cvf xxx-2.jar -C xxx-1/ .

I see a significant amount of deflation (30-60%) during execution. I suspect this is some sort of Java version issue, currently running:

  • └──╼ $java -version

    openjdk version "13.0.5.1" 2020-11-06

    OpenJDK Runtime Environment (build 13.0.5.1+1-Debian-1)

    OpenJDK 64-Bit Server VM (build 13.0.5.1+1-Debian-1, mixed mode)

And the Manifest contains the following version information:

  • Manifest-Version: 1.0
  • Ant-Version: Apache Ant 1.10.10
  • Created-By: 16.0.1+0 (Homebrew)
  • Main-Class: net.xxx-1.Main
  • Build-Date: 2021-08-02
  • Build-Revision: 8736

Original header: https://i.stack.imgur.com/HP0fE.jpg

"patched" header https://i.stack.imgur.com/qk5Rz.jpg

Original footer: https://i.stack.imgur.com/rwojo.jpg

"patched" footer: https://i.stack.imgur.com/zb5Ys.jpg

How do I generate a .jar file where the only change is the string I want to change?

Edit: Added header and foot screenshots

triboulet
  • 51
  • 3
  • 1
    ZIP/JAR files have different compression levels up to uncompressed for each entry. Therefore the different file size can just mean you have chosen a different compression level when recreating the JAR file. Also relevant: What is the OS you use for patching the JAR file? Windows is case insensitive so files that only differ in case are lost/overwritten when unpacking. – Robert Jan 02 '22 at 16:29
  • I'm using Parrot Security, a Debian based distro. In my mind the different sizes are just an indication of some other issue. I have also tried extracting and re-compressing the jar without making any changes and I get the same error – triboulet Jan 02 '22 at 16:33
  • 1
    Depending on how the JAR originally was created there may be data hidden in it that is lost when unpacking it: 1. every ZIP file has a comment 2. Between the last zip file entry and the zip central directory at the end of the file an unlimited bytes can be inserted. https://en.wikipedia.org/wiki/ZIP_(file_format)#/media/File:ZIP-64_Internal_Layout.svg Google uses this section for placing cryptographic signatures in APK files (again ZIP files). – Robert Jan 02 '22 at 16:38
  • I should be able to see that in a hex dump of the original .jar vs the re-compressed on correct? Looking at the header and footers of the jar there are definitely differences, I'm not familiar enough with java to know if they're substantive

    Original header: https://imgur.com/a/PnnwuM7

    The "patched" jar header https://imgur.com/a/pFC8nPf

    Original footer: https://imgur.com/a/wQy4MWq

    "patched" footer: https://imgur.com/RuIH1Jl

     – triboulet Jan 02 '22 at 16:48
  • After looking through the hex dumps some more, it's very clear that there are significant differences between the two. Original (left) https://imgur.com/84G2g4A is garbled. It seems like if I want to continue with the project I'll have to decompile the whole project and recompile it myself? – triboulet Jan 02 '22 at 17:00
  • 1
    You should better edit your question and include all the new pictures and info there. I just remembered another ZIP trick: You can have multiple ZIP entries of the same name, or some entries are present as file-entries but not in the central directory (depending on if you enumerate the file entries or use the central directory you would get a different result). ZIP allows quite a few manipulations... – Robert Jan 02 '22 at 17:15
  • 1
    If you can't uncompress and recompress the content the only way is to manipulate the file data directly in the ZIP file (assuming the file is stored without compression), or extract the file, modify it, zip it and then use an hex editor to copy the compressed file entry (including header) over the original one (requires that the old entry has the same length as the new one). – Robert Jan 02 '22 at 17:38
  • 1
    Are you explicitly using the bytecode editor listed in the article? There are newer ones that do not require you to unpack and repack the jar, as they'll do it for you. – Col-E Jan 04 '22 at 04:40
  • Yes I was trying to use the byte editor mentioned in the article, but even using a tool like Krakatau gives me a .jar file that's smaller than the original (even with roudtrip mode). – triboulet Jan 08 '22 at 15:26
  • Depending on how the editor writes back the jar/zip it may/may not use compression. In some cases this matters (jar-in-jar loaded via classloader like in Spring), but in most other cases it doesn't...

    Class editing may vary between tools. Some will be very specific with the edits, while others will essentially 'recompute' how the class file's contents are organized. Can't say how each works without looking into each...

    The manifest error is not due to any of these things though. Repackaging is done incorrectly. Check META-INF/MANIFEST.MF's contents in the jar/zip for 'main-class'

     – Col-E Jan 21 '22 at 17:17

0 Answers0