Add support for deobfuscating the unsigned signlink simultaneously with the signed signlink #114

Closed
opened 4 years ago by gpe · 1 comments
gpe commented 4 years ago
Owner

I think this is probably achievable with the new class name prefixing code, it'd just need some code for ensuring the methods/fields are kept in the same inherited method/field sets. Class names would need some similar disjoint set code too.

I think this is probably achievable with the new class name prefixing code, it'd just need some code for ensuring the methods/fields are kept in the same inherited method/field sets. Class names would need some similar disjoint set code too.
gpe added the
feature
deobfuscator
labels 4 years ago
Poster
Owner

After having taken a look at the unsigned signlink, I'm not particular interested in doing this. It appears to be virtually identical to the signed signlink, just with a lot of the code stripped out (presumably with a C preprocessor).

This makes it very similar to the SD client, which I'm not that interested in for similar reasons.

It'd also be a pain to keep the names in the signed/unsigned signlinks in sync when refactoring, as javac can only resolve class/method/field references to one of them - not both.

Therefore, I don't think I'll bother with this.

After having taken a look at the unsigned signlink, I'm not particular interested in doing this. It appears to be virtually identical to the signed signlink, just with a lot of the code stripped out (presumably with a C preprocessor). This makes it very similar to the SD client, which I'm not that interested in for similar reasons. It'd also be a pain to keep the names in the signed/unsigned signlinks in sync when refactoring, as `javac` can only resolve class/method/field references to one of them - not both. Therefore, I don't think I'll bother with this.
gpe closed this issue 4 years ago
Sign in to join this conversation.
Loading…
There is no content yet.