[fjfaase]

I wonder if they use any of the decompiler tools that are available. There is decompiler support for the Xtensa esp32 instruction in ghidra version 11.0. I also guess that rev.ng, which uses QEMU as its disassembler, could be used for decompiling as QEMU has support for the Xtensa esp32 instructions as well.

My experience with decompilers is that are not 100% perfect and that the output often still needs a lot of clean-up. I tried rev.ng on a binary written in assembler that used a register based calling convention (not stack based) and rev.ng produced a huge file many times the size you would expect from the assembler input. It seems that decompiler can only do the most trivial step of the reverse engineering process.

[linuxlizard]

Decompiling the microcode blob might run afoul of intellectual property laws. A clean room implementation needs to be done without reading any of the product's actual code.

[fjfaase]

Clean room design [1] comes down to one team reverse engineering the code and translate that to some high-level specification and let another team write the code based on that high-level specification. This still allows the use of a decompiler by the first team.

[1] https://en.wikipedia.org/wiki/Clean_room_design

[AshamedCaptain]

Even printing the call stack as they are doing is already very risky; some judges may argue that this is not strictly necessary.

[pabs3]

One of the posts mentioned they use Ghidra and Qemu forks for their work.

[pantalaimon]

All the newer ESP32 MCUs are RISC-V based if that may help