: WARNING - support of the decompiler is now VERY LIMITED. There are no active developers. This means waiting times in the issue tracker are very long and mostly depend on community. 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.
> What steps will reproduce the problem?
Go to a method that has a "try from" statement in the ABC assembly, but does not have a
jump statement for one or more of the labels used in the try from statement. Edit the ABC
and re-save it.
> What is the expected output? What do you see instead?
The expected output is that the offset labels will be managed by FFDec. But FFDec will
only place offset labels in the ABC where a jump statement (jump, ifeq, ifne, etc) points
to. If any of the offsets used in the try from statement are not labeled in the ABC
assembly, FFDec has no way of determining where they are supposed to point to, and so they
are set to ofs0000.
When creating ofsXXXX labels in the ABC assembly, FFDec should also look for offset
pointers in any try from statements.
> What version of the product are you using? Is it "nightly build"? Which operating system
do you have?
I am using version 7.1.2, on Windows 7.
It should be fixed in nightly 1210.
Thanks for reporting, this looks like pretty critical bug!
In the try statement, the "from" and "target" offsets were handled correctly,
but the "to" offset not because of earlier deobfuscation decision, that "to" is not an
Now it should work.