Improving fuzzing speed ideas

Hello @ifratric! I really enjoyed an elegant instrumentation idea behind the TinyInst.

However, I was thinking about reducing the slowdown caused by "entries" into the instrumented module and first idea that came to my mind was next.

Why not to put int3s on whole code section, instrument code as usual, and after that, put jump instead of particular int3s?

Several issues with this approach immediately arisen:

1. Basicblock size could be less than 5 bytes, this is not enough to place jmp <rel32>.

This could be tackled in several ways, which seams realistically solvable.

2. Code section could have data in it, thus int3s are damaging that data. For example some switch cases causing image relative offsets in code section.

This is major problem to me and this is actually my question. Several solutions came into my mind

2.1) It could be solved by taking information about basicblocks from huge disassemblers like IDA or Ghydra (this is what Mesos does) and placing int3s only at the start of the basicblock. This solution works (at least for my tests on regular Microsoft's dlls), but requires additional dependency.

2.1) Instrument each indirect mov instruction and check if the data is taken from code section and redirect it to proper data (similarly to the indirect branches current instrumentation). This is actually slow and would be a bit complex task to implement.

Am I'm overlooking anything? Maybe there is some fast code flow analysis tactic to distinguish data from code?

No files, tests, or concrete entry points are named. Start by reviewing TinyInst's current instrumentation of basic blocks and indirect branches, then evaluate the proposed int3 and jump approach against code-section data; the issue provides no defined acceptance criteria or clear stopping point.