+ update 2020: WARNING - support of the decompiler is now VERY LIMITED. There are no active developers. This means we will NOT develop new features and/or fix most of bugs. We left the tracker running in case somebody from community would like to work on it. Sorry for the inconvenience.
State: closed new: Initial state. As long as issue is in this state, the work on the issue has not yet begun. opened: Opened state means developer started working on the issue. Feature/Fix will probably be in the next release. postponed: This means developer is not working on it now, for some reason it cannot be implemented now. Issue may be opened again in the future. upgraded: Issue is in upgraded state when developer made changes to the program and new version was released. closed: This means the user is satisfied with issue results and no more changes are needed. invalid: These issues cannot be solved. ignored: Developer decided to take no action on this issue. returned: Program changes were made but user is not satisfied and returned the issue.
Hi, it would be nice to add the optional ability to delete unreachable opcodes. For
example, many obfuscators add code like that to corrupt the control flow:
//// HERE BEGIN JUNK OPCODES ////
So, if remove opcodes between jump and label(L15:) it would be clean control flow.
most of the obfuscators do also the trick with
and then use these local variables to change flow with
and then they can insert junk opcode almost everywhere...
unreachable opcodes can be deleted, but this is not very useful because all of the other
tricks obfuscators do...
Well, yeah, about tricks with local bool vars I know too. But they can be easily replaced
by jump and then just remove it. Usual are local Boolean variables don’t change the
value, they just announced at the beginning of methods.