Repair inner class nesting when stripped by an obfuscator - #362
Open
RDIL wants to merge 1 commit into
Open
Conversation
There's a lot going on here, so I'm going to try and break it down as simply as I can: - Enigma has two concepts of how nesting works which disagree with each other. (1) It grabbed it from the `$` in a class name, but (2) decompilers get it from the InnerClasses attribute. - Some obfuscators (like the one used on Charles Proxy, not sure which it actually is) strip out this nesting attribute, which lead to phantom classes that Enigma could tell were nested, but the decompiler couldn't. - This meant you couldn't edit them! (Or even see them in the GUI's source tree) So, how have I gone about fixing this? Glad you asked! Class trees, class search, `Gui.showReference`, `moveClassTree`, javadoc/stat invalidation (and many more) are now all aware of this and can handle appropriately. Most importantly, we stop silently dropping `$` classes. A lovely new test has been added to prevent it from regressing (I hope)
RDIL
commented
Aug 24, 2026
| } | ||
|
|
||
| for (ClassEntry classEntry : this.classRanges.keySet()) { | ||
| String[] parts = classEntry.getContextualName().split("\\$"); |
Author
There was a problem hiding this comment.
without this refactor, it tries to find an outer class with a named inner class that doesn't exist, and would throw.
RDIL
commented
Aug 24, 2026
| this.currentIsKeyed = false; | ||
| this.classRanges.clear(); | ||
| this.classDeclarations.clear(); | ||
| this.classStack.clear(); |
Author
There was a problem hiding this comment.
existing bug!: this wasn't cleared between runs, which could lead to a different file's tokens occasionally being leaked onto an unrelated file, in very particular circumstances
RDIL
commented
Aug 24, 2026
Comment on lines
-84
to
-85
| tokenCollector.set(new EnigmaTextTokenCollector(next)); | ||
| return tokenCollector.get(); |
Author
There was a problem hiding this comment.
this didn't work because tokenCollector.get() would only ever resolve the current file, even if we're asking for a different file!
supersaiyansubtlety
self-requested a review
August 25, 2026 03:10
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
There's a lot going on here, so I'm going to try and break it down as simply as I can:
$in a class name, but (2) decompilers get it from the InnerClasses attribute.So, how have I gone about fixing this? Glad you asked!
Class trees, class search,
Gui.showReference,moveClassTree, javadoc/stat invalidation (and many more) are now all aware of this and can handle appropriately. Most importantly, we stop silently dropping$classes.A lovely new test has been added to prevent it from regressing (I hope)