[ ] Names of the common element with TextMatchMode support.
Should be offered, but ideally not used often due to obfuscation randomizing names.
[ ] Names of, or inclusion of, unknown attributes (Non-standard attributes defined by JVMS spec)
[ ] Annotations
[ ] Check for duplicates (Not allowed by javac)
[ ] Name matching
[ ] Number of annotations
[ ] Class properties
[ ] Inner classes
[ ] Names
[ ] Number of items
[ ] Duplicate check
[ ] Field properties
[ ] Values of fields.
Create an example/test case showcasing matching of WinRegistry.java
[ ] Method properties
[ ] Check if local variable slot 0 in virtual methods is not named this. javac emits this by default, always. Different values imply obfuscation.
Now, for detecting obfuscation some ideas:
[ ] Add some kind of entropy checking option to TextMatchMode to facilitate name obf detection
Currently all options define BiPredicate<String, String> so how will we pass an entropy cut off value? Do we just provide different entropy cutoff points as enum entries? Would be the most simple way to go, but hinders customization.
Alternatively, we don't add this feature to TextMatchMode and go about it in a different way with its own unique matcher
[ ] Method control flow cyclomatic complexity detection
Comment in code: StandardScan.java#L46
Capabilities to address:
TextMatchMode
support.javac
)this
.javac
emits this by default, always. Different values imply obfuscation.Now, for detecting obfuscation some ideas:
TextMatchMode
to facilitate name obf detectionBiPredicate<String, String>
so how will we pass an entropy cut off value? Do we just provide different entropy cutoff points as enum entries? Would be the most simple way to go, but hinders customization.TextMatchMode
and go about it in a different way with its own unique matcherFeel free to discuss additional ideas.