Is it possible to detect reads to the jitted code and present a version without emuhacks?

Possible in non-fast-mem, yes. but would require heavy checks for every read so is a non-starter performance-wise.

I've been thinking about trying some simple 2-level hash table instead of of overwriting instructions, PCSX2 uses that approach with good results but I don't know how it would compare speed-wise to the current approach.

It's hard to know how many games this affects. We can guess, but some things can also be jit bugs.

We could make it so that slow/safe mem (or some new dev option) makes all reads in the "possible emuhack op ranges" go through ReadInstruction. This would probably be a lot slower, but we could use it to safely determine which games might be affected.

Or we could just change it, but I suspect anything we do will make it slower, but maybe not really much slower.

-[Unknown]

@unknownbrackets
The same issue arises with SOCOM FireTeam Bravo 1 and 2 when the server sends anti-cheat queries to the client.
For example, server sends a hash query, which the client (game) executes, and of course it always results in different hashes because of the emuhacks thus triggering a false positive. Is there any workaround for this, such as invalidating the Icache before performing a memory read of the game's instructions? Could there be a good alternative to the jit blocks hack?

The right way is to separate the block lookup from RAM and stop overwriting first-instruction-in-a-block, although we'd lose the inherent "change detection" of emuhacks (when they get overwritten, we necessarily end up recompiling).

Detecting changes can be done in other ways like playing games with page protection and exception handling, although been reluctant to go this route because it's hard to support on some of the ports we support (or would like to support).