morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #3771] [Feature] Improve Java 8 and Obfuscated JAR Decompilation #1465

New issue

Open

opened 2026-10-16 21:05:43 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-16 21:05:43 +00:00

Owner

Originally created by @t1zzo on GitHub (Oct 15, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3771

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

Setup, packaging, or upgrade

Current limitation

REA does not yet make it clear why decompilation is incomplete for some Java JARs, especially Java 8 or heavily obfuscated/protected files. It can be difficult to tell whether the issue is the class-file version, obfuscation, a packed or encrypted payload, missing dependencies, or a decompiler failure. When decompilation fails, I would like REA to explain the limitation and retain useful bytecode evidence instead of leaving the user unsure what could be recovered.

Use cases

When analyzing a Java 8 JAR or a heavily obfuscated/protected JAR, I want to identify which classes were successfully decompiled and understand why others were not. This would help me distinguish ordinary decompiler limitations from missing dependencies or a packed/encrypted payload, and decide whether bytecode inspection or another analysis approach is needed. I do not have frequency or performance measurements to report.

Desired outcome and success criteria

For Java 8 and obfuscated JARs, REA should report the detected class-file version and clearly show which classes were decompiled, partially decompiled, or not decompiled. For incomplete results, it should provide the available failure reason and retain bytecode evidence when possible. It should identify suspected packing or encryption as a limitation, without claiming to recover original source code when it cannot.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Target: local Java .class files and JAR archives, including Java 8 class files (major version 52). The proposed initial workflow is static analysis of files the user selects. It should not execute the JAR or modify the original files. Detecting a possible packed or encrypted payload and explaining the limitation are in scope; automatically bypassing protections or recovering decrypted code is not assumed to be in scope.

Verification available so far

Idea only; I need help defining checks

Verification details (optional)

A possible check is to analyze a self-built Java 8 fixture (class-file major version 52) and a separately obfuscated fixture. The output should report the detected version and class coverage, and distinguish successful, partial, and failed decompilation. For a fixture that is only a placeholder for an encrypted payload, REA should clearly report that static decompilation could not recover the payload rather than presenting guessed source code. I have not run this test yet.

Alternatives considered

Standalone decompilers such as Vineflower or CFR can be run manually on readable .class files or JARs, but their output may still be incomplete for obfuscated code, and they cannot reconstruct classes that remain encrypted or packed. REA's existing native-analysis and APK workflows do not provide a dedicated standalone Java/JAR workflow with class-level coverage and clear failure reasons. I have not compared these tools on the same sample.

Possible direction

As a starting point, REA could integrate an optional standalone Java decompiler for selected .class and JAR files, with Java 8 fixtures included in verification. Report class-level coverage and preserve bytecode when decompilation fails. If the input appears packed or encrypted, report that as a limitation rather than attempting to execute it or bypass its protections automatically. The choice of decompiler and exact scope should be decided by the maintainers.

References

Related REA proposal: https://github.com/morluto/rea/issues/1558

Java SE 8 JVM Specification, including the class-file format: https://docs.oracle.com/javase/specs/jvms/se8/html/

I do not have a public sample, measurements, or reproducible test results to attach yet.

Originally created by @t1zzo on GitHub (Oct 15, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3771 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Setup, packaging, or upgrade ### Current limitation REA does not yet make it clear why decompilation is incomplete for some Java JARs, especially Java 8 or heavily obfuscated/protected files. It can be difficult to tell whether the issue is the class-file version, obfuscation, a packed or encrypted payload, missing dependencies, or a decompiler failure. When decompilation fails, I would like REA to explain the limitation and retain useful bytecode evidence instead of leaving the user unsure what could be recovered. ### Use cases When analyzing a Java 8 JAR or a heavily obfuscated/protected JAR, I want to identify which classes were successfully decompiled and understand why others were not. This would help me distinguish ordinary decompiler limitations from missing dependencies or a packed/encrypted payload, and decide whether bytecode inspection or another analysis approach is needed. I do not have frequency or performance measurements to report. ### Desired outcome and success criteria For Java 8 and obfuscated JARs, REA should report the detected class-file version and clearly show which classes were decompiled, partially decompiled, or not decompiled. For incomplete results, it should provide the available failure reason and retain bytecode evidence when possible. It should identify suspected packing or encryption as a limitation, without claiming to recover original source code when it cannot. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) Target: local Java .class files and JAR archives, including Java 8 class files (major version 52). The proposed initial workflow is static analysis of files the user selects. It should not execute the JAR or modify the original files. Detecting a possible packed or encrypted payload and explaining the limitation are in scope; automatically bypassing protections or recovering decrypted code is not assumed to be in scope. ### Verification available so far Idea only; I need help defining checks ### Verification details (optional) A possible check is to analyze a self-built Java 8 fixture (class-file major version 52) and a separately obfuscated fixture. The output should report the detected version and class coverage, and distinguish successful, partial, and failed decompilation. For a fixture that is only a placeholder for an encrypted payload, REA should clearly report that static decompilation could not recover the payload rather than presenting guessed source code. I have not run this test yet. ### Alternatives considered Standalone decompilers such as Vineflower or CFR can be run manually on readable .class files or JARs, but their output may still be incomplete for obfuscated code, and they cannot reconstruct classes that remain encrypted or packed. REA's existing native-analysis and APK workflows do not provide a dedicated standalone Java/JAR workflow with class-level coverage and clear failure reasons. I have not compared these tools on the same sample. ### Possible direction As a starting point, REA could integrate an optional standalone Java decompiler for selected .class and JAR files, with Java 8 fixtures included in verification. Report class-level coverage and preserve bytecode when decompilation fails. If the input appears packed or encrypted, report that as a limitation rather than attempting to execute it or bypass its protections automatically. The choice of decompiler and exact scope should be decided by the maintainers. ### References Related REA proposal: https://github.com/morluto/rea/issues/1558 Java SE 8 JVM Specification, including the class-file format: https://docs.oracle.com/javase/specs/jvms/se8/html/ I do not have a public sample, measurements, or reproducible test results to attach yet.

bsakaguchi added the

triage

enhancement

labels

2026-10-16 21:05:43 +00:00

bsakaguchi commented

2026-10-16 21:05:44 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 15, 2026):

Good ask — the core pain is diagnosability: today a failed decompile gives the user no signal about whether it is a class-version issue, obfuscation, packing/encryption, or a decompiler bug. Reporting the detected class-file version up front plus per-class decompiled/partial/failed status with retained bytecode evidence would make the tool actually actionable. Agree that integrating an optional standalone Java decompiler behind the existing provider model is the right shape, with Java 8 fixtures in verification to guard against regressions. One suggestion: make sure the failure taxonomy (version unsupported vs obfuscated vs packed/encrypted vs decompiler error) is surfaced as a stable enum so downstream automation can branch on it.

@XinwangTao commented on GitHub (Oct 15, 2026): Good ask — the core pain is diagnosability: today a failed decompile gives the user no signal about whether it is a class-version issue, obfuscation, packing/encryption, or a decompiler bug. Reporting the detected class-file version up front plus per-class decompiled/partial/failed status with retained bytecode evidence would make the tool actually actionable. Agree that integrating an optional standalone Java decompiler behind the existing provider model is the right shape, with Java 8 fixtures in verification to guard against regressions. One suggestion: make sure the failure taxonomy (version unsupported vs obfuscated vs packed/encrypted vs decompiler error) is surfaced as a stable enum so downstream automation can branch on it.

bsakaguchi referenced this issue

2026-10-17 21:11:37 +00:00

[PR #1465] [MERGED] docs(process): clarify normalized terminal line representation #2904

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-10-31 00:30:53 +00:00

bsakaguchi referenced this issue

2026-10-31 00:50:26 +00:00

[GH-ISSUE #7582] [Bug] One-column process captures silently use a two-column rendered screen #4516