IDA PRO Hex-Rays try-catch

Question

I've been working in IDA Pro with a project but there is an issue. Try-Catch statements don't look nice.

I've been searching and it seems like IDA does not support them so I was wondering if there is a way to either:

• Hide sections of the Pseudocode
• Create extensions for Hex-Rays to support them
• Tell IDA how and where the exceptions are

This is how the thing looks like at the moment:

  v3.SavedRegs = &savedregs;
  v3.Handler = &loc_43B24C;
  v3.Next = NtCurrentTeb()->NtTib.ExceptionList;
  __writefsdword(0, &v3);
  Controls::TControl::ReadState(Self, a2);
  __writefsdword(0, v3.Next);

And I would like to end up with something like this:

  try {
    Controls::TControl::ReadState(Self, a2);
  } ... {}

Or if I can just hide those parts...

  //try {          <- Block comment (parts hidden)
    Controls::TControl::ReadState(Self, a2);
  //} ... {}       <- Block comment (parts hidden)

Anything is good as long as I can hide those lines because they are distracting AF. Thank you very much!

Answer 1

I've considered doing this myself, but it's tricky for many reasons.

First, exception internals are not standardized across languages, platforms, or implementations. 64-bit Windows programs use a data-driven exception model, i.e., the RUNTIME_FUNCTION (etc.) entries in the .rdata segment. In this paradigm, the binary pre-registers information about exception scopes and handlers with the operating system via standardized structures, which takes care of lookup and dispatch when an exception occurs. Your example shows 32-bit Delphi; 32-bit Windows programs use a code-driven exception model, where the code is responsible for adding and removing exception handlers on demand, using proprietary metadata formats. As a result, adding exception support would require a lot of platform and language-specific effort, and may involve reverse engineering undocumented exception implementations across multiple runtime versions for a given language. While there would be benefits to adding exception support, it would also require a lot of work to develop (and maintain as the runtime support evolves over time).

Secondly, even if we were to decompile exception-related things into a simplified, language-independent representation, the most logical method of presentation would involve extending Hex-Rays to support things like try/catch/finally blocks as scoped constructs, and producing these things in the output. Unfortunately, extending the Hex-Rays ctree IR in this fashion is impossible for third-party developers. The valid ctree expression types are held in an enum called ctype_t. We'd need to add new entries like cit_try to this enum, we'd need to extend the union in cinsn_t to support an additional ctry_t * element, and we'd need to modify all of the existing ctree code in Hex-Rays to be aware of our modifications (for example, to print the try blocks in the decompilation listing). None of these things can be done by third-party plugins, as the existing, pre-compiled code will generate INTERRs upon encountering our cit_try instructions. Adding statement types to the ctree IR can only be accomplished via source-level modifications, not via plugins.

Finally, even though Hex-Rays technically has an option not to eliminate exception-related code, I'm not completely sure how it works. Exception-related code often manifests itself as "function chunks" attached to a given function, which have no incoming control flow references. As a result, that code is eliminated by the optimizer very early into the decompilation process. You'd need to find a way to preserve it.

It's a daunting prospect for a third-party developer; I myself abandoned the idea. It's also daunting for the first-party developers. I don't expect to see it in any major decompiler any time soon.

Answer 2

In the end, it seems like there is no way to do this in IDA up to 7.5. It's a shame.