ERROR: Failed to process zip file

[irrisolto]

Issue details

Hi, i was trying to reverse a malware sample i found on internet but i can't decompile it using jadx. Here's the error:

jadx.core.utils.exceptions.JadxRuntimeException: Failed to process zip file: C:\Users\Linux\Downloads\chrome_update_v136.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.dex.DexFileLoader.collectDexFromZip(DexFileLoader.java:89)
	at jadx.plugins.input.dex.DexFileLoader.load(DexFileLoader.java:72)
	at jadx.plugins.input.dex.DexFileLoader.loadDexFromFile(DexFileLoader.java:49)
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
	at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(Unknown Source)
	at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
	at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(Unknown Source)
	at java.base/java.util.stream.AbstractPipeline.evaluate(Unknown Source)
	at java.base/java.util.stream.ReferencePipeline.collect(Unknown Source)
	at jadx.plugins.input.dex.DexFileLoader.collectDexFiles(DexFileLoader.java:44)
	at jadx.plugins.input.dex.DexInputPlugin.loadFiles(DexInputPlugin.java:42)
	at jadx.plugins.input.dex.DexInputPlugin.loadFiles(DexInputPlugin.java:38)
	at jadx.api.JadxDecompiler.loadInputFiles(JadxDecompiler.java:156)
	at jadx.api.JadxDecompiler.load(JadxDecompiler.java:120)
	at jadx.gui.JadxWrapper.open(JadxWrapper.java:75)
	at jadx.gui.ui.MainWindow.lambda$loadFiles$3(MainWindow.java:537)
	at jadx.core.utils.tasks.TaskExecutor.wrapTask(TaskExecutor.java:166)
	at jadx.core.utils.tasks.TaskExecutor.runStages(TaskExecutor.java:142)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.util.zip.ZipException: invalid CEN header (encrypted entry)
	at java.base/java.util.zip.ZipFile$Source.zerror(Unknown Source)
	at java.base/java.util.zip.ZipFile$Source.checkAndAddEntry(Unknown Source)
	at java.base/java.util.zip.ZipFile$Source.initCEN(Unknown Source)
	at java.base/java.util.zip.ZipFile$Source.<init>(Unknown Source)
	at java.base/java.util.zip.ZipFile$Source.get(Unknown Source)
	at java.base/java.util.zip.ZipFile$CleanableResource.<init>(Unknown Source)
	at java.base/java.util.zip.ZipFile.<init>(Unknown Source)
	at jadx.core.utils.files.ZipFile.<init>(ZipFile.java:30)
	at jadx.core.utils.files.ZipFile.<init>(ZipFile.java:18)
	at jadx.core.utils.files.ZipFile.<init>(ZipFile.java:14)
	at jadx.api.plugins.utils.ZipSecurity.visitZipEntries(ZipSecurity.java:130)
	... 24 common frames omitted

Decompiling other applications works. This one is the problem. I know this was an issue while decompiling some malwares but i tought it was fixed in 1.51. Here's the sample

Jadx version

1.51

Java version

23.0.1

OS

• Windows
• Linux
• macOS

[skylot]

@irrisolto thank you for sample 👍

Now we have several approaches for fix zip parsing issues

1. First one (currently used) is a zip patching implemented by @qfalconer in PR Adding automatic patching for semi-corrupted APKs #2298.
   Maybe he will help to adjust it for this case.
2. Another is to implement a custom zip parser to fight tampering. I have done an attempt on it (check zip branch) and it worked for this sample, although some other issues still preventing decompilation.
   I will continue my work on it 🙂

Related to #2171

[irrisolto]

thanks for your work

[skylot]

I merged zip branch into master and code in sample can be decompiled now, check latest unstable build.
Although, sample contains several weird files which have zip magic, but can't be decoded, looks like these are fake zip files.
Also, resources decoding still failing 😢

[qfalconer]

Sorry for being terribly late :( I'm pretty bad at keeping track of my online accounts.

OP's APK has bit 0 set in many Central Directory headers and Local File headers. This bit denotes an encrypted entry but it is yet another bit the Android runtime ignores.
I see your custom ZIP decoder can handle this just fine and that you added support for folders with names matching a file 🥳

Thank you for your work! JADX is such an awesome project!

If I manage to find some free time I'd love to take a look at the resources.asrc decode error, but I cannot make any promise 🤕

BTW, the APK is pretty much decoded, the weird files are, as you pointed out, just fake decoy zip. OP can simply search for attachBaseContext and see how the uzpilxcocefppumw is decoded into a DEX file (or just take the decoded file with an emulator and adb), where all the malicious classes live. This is a standard technique and the resources are rarely used by malwares.
So I'd say JADX is already letting OP successfully analysing this malware.

[qfalconer]

Hi,

I took a look a the reason the resources aren't decoded.

There is a null chunk before the string bool, this is used by the REAndroid ARSCLib to add a comment to itself. I added a method to check the presence of this chunk and skip it.

Then, the ResTable_config chunk has a very small size (0x10 bytes) and JADX expected at least 28 bytes.
Looking at the AOSP source it seems that Android zero-fill the ResTable_config objects (I may be wrong on this) and only read the data effectively present according to the ResTable_config size field. A ResTable_config can technically have any size, even smaller than 28 bytes, it's a mess that changes layout frequently (apparently).
To get around this, in parseConfig I made a byte array of size at least 52 bytes (because that's the biggest size JADX can handle) and read the ResTable_config data into it. This byte array can be larger than 52 bytes if the ResTable_config also is.
Then I made the rest of the parseConfig code read from this array. This way, we read zero if a field is not present, which is the default anyway.

This should make the resource load. I don't know if ResTable_config should be parsed according to some rule, there are a lot of unions on that struct, based on its size and maybe SDK version.

I hadn't time to make a PR, sorry, I made a path file though You can use it as git apply parse_res_tableconfig.patch

parse_res_tableconfig.patch.zip

[skylot]

@qfalconer thank you, great patch 👍
I commit it, although I slightly change a way of skipping null type chunk to make it more general, hope it will not break something 🙂