[core] A really obfuscated app consumes a lot of resources and is never decompiled completely

[bagipro]

Issue details

I'm trying to decompile the following app: https://drive.google.com/file/d/1dZlRPLi-gqqOtjFtD6ANyGCJBGRbWhwI/view?usp=sharing

But the JadxGUI consumes a lot of resources and decompilation never finished

Relevant log output or stacktrace

I ran `jstack`, it dumped the following hangs:

"jadx-task-p-15-6" #45 [42915] prio=5 os_prio=31 cpu=81552.16ms elapsed=110.76s tid=0x0000000c328eea00 nid=42915 runnable  [0x000000017ecaf000]
   java.lang.Thread.State: RUNNABLE
	at java.util.Collection.removeIf(java.base@23.0.1/Collection.java:581)
	at jadx.core.dex.visitors.typeinference.TypeUpdateInfo.rollbackUpdate(TypeUpdateInfo.java:45)
	at jadx.core.dex.visitors.typeinference.TypeUpdate.requestUpdate(TypeUpdate.java:229)
	at jadx.core.dex.visitors.typeinference.TypeUpdate.updateTypeForSsaVar(TypeUpdate.java:198)
	at jadx.core.dex.visitors.typeinference.TypeUpdate.updateTypeChecked(TypeUpdate.java:120)
	at jadx.core.dex.visitors.typeinference.TypeUpdate.allSameListener(TypeUpdate.java:491)
	at jadx.core.dex.visitors.typeinference.TypeUpdate$$Lambda/0x00000f8001162e40.update(Unknown Source)
	at jadx.core.dex.visitors.typeinference.TypeUpdate.runListeners(TypeUpdate.java:247)
	at jadx.core.dex.visitors.typeinference.TypeUpdate.requestUpdate(TypeUpdate.java:227)
	at jadx.core.dex.visitors.typeinference.TypeUpdate.updateTypeForSsaVar(TypeUpdate.java:198)
	at jadx.core.dex.visitors.typeinference.TypeUpdate.updateTypeChecked(TypeUpdate.java:120)
	at jadx.core.dex.visitors.typeinference.TypeUpdate.allSameListener(TypeUpdate.java:484)
	at jadx.core.dex.visitors.typeinference.TypeUpdate$$Lambda/0x00000f8001162e40.update(Unknown Source)
	at jadx.core.dex.visitors.typeinference.TypeUpdate.runListeners(TypeUpdate.java:247)
	at jadx.core.dex.visitors.typeinference.TypeUpdate.requestUpdate(TypeUpdate.java:227)
	at jadx.core.dex.visitors.typeinference.TypeUpdate.updateTypeForSsaVar(TypeUpdate.java:203)
	at jadx.core.dex.visitors.typeinference.TypeUpdate.updateTypeChecked(TypeUpdate.java:120)
	at jadx.core.dex.visitors.typeinference.TypeUpdate.suggestAllSameListener(TypeUpdate.java:524)
	at jadx.core.dex.visitors.typeinference.TypeUpdate.arithListener(TypeUpdate.java:508)
	at jadx.core.dex.visitors.typeinference.TypeUpdate$$Lambda/0x00000f80011636e0.update(Unknown Source)
	at ...

Provide sample and class/method full name

No response

Jadx version

No response

[jpstotz]

Loading this APK is indeed very slow. On my system it took ~15 minutes (without any source code decompilation).

Using VisualVM I found out that a very large part of the spend CPU time JadxGUI executes something within java.io.File.getCanonicalFile() (called from JadxZipSecurity.isValidEntryName(). As the APK contains more than 22000 entries this takes quite a bit of time.

Disabling ZIP security is possible for the command-line version, I wasn't sure if JadxGUI also supports it, thus I simply commented out JadxZipSecurity.isValidEntryName() and loading time reduced from 15 minutes to less than 2.

In the next tests I replaced the calls to java.io.File with calls to the modern java.nio.file API

 public boolean isValidEntryName(String entryName) {
		[..]
		try {
			Path cwd = Paths.get("./").toAbsolutePath().normalize();
			Path entryPath = cwd.resolve(entryName).normalize();
			if (entryPath.startsWith(cwd)) {
				return true;
			}

jadx/jadx-commons/jadx-zip/src/main/java/jadx/zip/security/JadxZipSecurity.java

Lines 60 to 64 in ae1a5e9

	File currentPath = CWD;
	File canonical = new File(currentPath, entryName).getCanonicalFile();
	if (isInSubDirectoryInternal(currentPath, canonical)) {
	return true;
	}

I am not 100% sure if this code behaves exactly the same as the old code but it should also be able to identify path traversal attacks and it is way faster. Using it the APK loads in 2 minutes.

[skylot]

Root issue found in very big method: o.ocx$Activity.EZpvd, during type inference variables tree became too big and processing it cause stack overflow error, but that error was handled and jadx was trying other strategies to resolve types... and got another stack overflow... and another 🤣

I commit a fix to halt type inference on first stack overflow and mark method with error to stop further processing.
I plan (I hope in near future 🙂) to refactor type inference to use iterations instead of recursion to not be limited by stack.

Also, this sample generates a big usage data, so it took a big chunk of time during loading, this issue also needs to be fixed.

Anyway, @bagipro thanks for nice sample 👍