Hello! I want to decompile SuperH-4 executables for Dreamcast with IDA Pro. However, IDA currently does not support decompiling SuperH-4 platform. I feel like I am pretty confident with C++ and had already done some plugins for IDA Pro, although not so complicated. I guess the whole heavy lifting is done on the decompiler side is transforming the binary code to microcode to the ctree? It’s clear that for each different CPU architecture you need to implement binary code → microcode translator, but is the ctree to decompiled code transformation universal or I would need to write my own too? It seems that the hexrays.hpp is not complete enough to write your own decompiler driver based on hexrays. I want my decompiler to be fully compatible with IDA workflow and information stored in the database. Is there is any comprehensive guide on how to create a decompiler driver for a certain architecture based on hexrays SDK? Thanks!
Hi,
Unfortunately, currently this is not possible for third parties.
In 2020 I demonstrated (in ida plugin contest) how to hijack an existing disassembler and decompiler to decompile a custom architecture. It’s not super stable but if you have a lot of time and patience then you can adapt this approach to any architecture. Since I could not find the past plugin contests on hex-rays.com I uploaded it to GitHub - milankovo/bf-decompiler.
This is utterly unfortunate. Is this at least planned in the near future?
Hello @void_17
Enabling users to create their own decompilers is not a feature that will be shipped with the next version of IDA. However, we are working on easing the integration between disassemblers and decompilers and improving the decompiler API as well. There is no specific timeline to share at this stage.
While it’s probably not the answer that you were hoping for, we’re still keeping an eye on user interest and open to reconsidering this in the future.
just make hexrays as opensource
and this will be enough
If split decompiler in two parts - one for microcode generation and manipulation and one for ctree manipulation, plus allow to user control activation of internal plugins, it will make to add support of new archs much simpler. You need to do much only microcode part and not to recreate ctree part.