[core] Caused by: java.util.zip.ZipException: invalid CEN header (bad compression method: 7261)

[ohyeah521]

Issue details

The malware exploits the Android system's failure to verify zip flag tampering, causing an exception to be thrown when parsing the apk.

Relevant log output or stacktrace

jadx.core.utils.exceptions.JadxRuntimeException: Failed to process zip file: C:\Users\test\Desktop\test.apk
        at jadx.api.plugins.utils.ZipSecurity.visitZipEntries(ZipSecurity.java:148)
        at jadx.api.plugins.utils.ZipSecurity.readZipEntries(ZipSecurity.java:154)
        at jadx.plugins.input.java.JavaInputLoader.collectFromZip(JavaInputLoader.java:91)
        at jadx.plugins.input.java.JavaInputLoader.loadReader(JavaInputLoader.java:71)
        at jadx.plugins.input.java.JavaInputLoader.loadFromFile(JavaInputLoader.java:50)
        at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
        at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
        at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
        at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
        at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
        at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
        at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
        at jadx.plugins.input.java.JavaInputLoader.collectFiles(JavaInputLoader.java:37)
        at jadx.plugins.input.java.JavaInputPlugin.loadClassFiles(JavaInputPlugin.java:36)
        at jadx.plugins.input.java.JavaInputPlugin.loadClassFiles(JavaInputPlugin.java:32)
        at jadx.api.JadxDecompiler.loadInputFiles(JadxDecompiler.java:153)
        at jadx.api.JadxDecompiler.load(JadxDecompiler.java:119)
        at jadx.cli.JadxCLI.processAndSave(JadxCLI.java:51)
        at jadx.cli.JadxCLI.execute(JadxCLI.java:38)
        at jadx.cli.JadxCLI.main(JadxCLI.java:22)
Caused by: java.util.zip.ZipException: invalid CEN header (bad compression method: 7261)
        at java.base/java.util.zip.ZipFile$Source.zerror(ZipFile.java:1597)
        at java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1557)
        at java.base/java.util.zip.ZipFile$Source.<init>(ZipFile.java:1299)
        at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1262)
        at java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:733)
        at java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:842)
        at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:248)
        at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:177)
        at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:191)
        at jadx.api.plugins.utils.ZipSecurity.visitZipEntries(ZipSecurity.java:130)
        ... 20 common frames omitted

Provide sample and class/method full name

test.zip

Jadx version

1.5.0

[jpstotz]

It is a known problem that ZIP implementation of Java does not support archives with unknown compression methods. As you can see from the stack trace this happens when creating the ZipFile instance, thus there is no way to ignore or skip this error.

The only way to solve this problem would be using a completely different ZIP implementation.

[ohyeah521]

You are right. Maybe we can analyze the source code by referring to the zip of the source code and ignore some of the verification fields that throw exceptions.

[jpstotz]

To my knowledge there is no option or other possibility to skip this check. initCEN is always executed when opening a new ZIP file

See https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/share/classes/java/util/zip/ZipFile.java

[ohyeah521]

It is true that Java is very difficult to implement. Perhaps introducing an external decompression tool is a better choice. Instead of calling the system library directly, it can be made into a configuration option. When encountering confusion, users can choose the decompression tool themselves. In this way, decompilation can continue. I think this implementation is better than exiting directly.

[jpstotz]

You have the sample file. Feel free to test other libraries but to my knowledge there are not many like ZIP libraries that have an own implementation. Just two candidates come to my mind: apache-commons-compress and zip4j.

[skylot]

@jpstotz
I tried zip4j, but it also not support fake compression method 😢

Caused by: net.lingala.zip4j.exception.ZipException: Unknown compression method
	at net.lingala.zip4j.model.enums.CompressionMethod.getCompressionMethodFromCode(CompressionMethod.java:52)
	at net.lingala.zip4j.headers.HeaderReader.readLocalFileHeader(HeaderReader.java:543)
	at net.lingala.zip4j.io.inputstream.ZipInputStream.getNextEntry(ZipInputStream.java:115)
	at net.lingala.zip4j.io.inputstream.ZipInputStream.getNextEntry(ZipInputStream.java:105)
	at jadx.api.plugins.utils.ZipSecurity.visitZipEntries(ZipSecurity.java:135)

Will try other lib 😕

[skylot]

Apache Commons Compress also doesn't support fake compression method:

Caused by: org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException: Unsupported feature compression method used in entry AndroidManifest.xml
	at org.apache.commons.compress.archivers.zip.ZipUtil.checkRequestedFeatures(ZipUtil.java:145)
	at org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.java:915)

Looks like the only way to fight such tampering is to write own zip reader implementation 🤣

[jackwpa]

Looks like the only way to fight such tampering is to write own zip reader implementation

It must be what JEB has done (link to JEB API). It's working fine for me with JEB 5.12: