How did reverse engineering m16c prove challenging? I recently extracted a 4 stage encrypted payload from an M16C arch that also used time-based encryption. Each time it was run, the output was different. The time based key was also rotating.
It used a very simple custom encryption for the time stuff and AES in ECB mode.
Protip Ghidra does not emulate inherent CPU behavior of INDEX instructions, behaviour not specified in ISA. I had to backport M32C instructions and patch M16C slaspec to emulate this behavior, caused by compiler bugs.
Have you published anything about this anywhere? I also had to work on the SLEIGH file for the M16C.
Overall it just seemed like the processor definition for Ghidra needed more work.
Particularly for this adventure, I have kept it strictly private. It was a hobby project and also was a challenge to myself.
In the process I learned not only of M32C(backwards compatible with M16C processor module in Ghidra), but as I mentioned, certain compiler bugs(not following the ISA spec strictly) that it is more flexible despite what the M16/M32C software manual says. However this meant that emulation produced wrong results, and thus my patches to fix it and ultimate success
I have opened a Ghidra support ticket, but I needed to provide proof that there is ISA behavior not described in the software manuals.