This reminds me of timing side channel attacks in general. With VUSEC (VU University Amsterdam) we did flush/reload side channel attacks. I don't remember the s

This reminds me of timing side channel attacks in general. With VUSEC (VU University Amsterdam) we did flush/reload side channel attacks. I don't remember the specifics, I did this in 2018. But yea, basically if a cache hit versus a memory roundtrip will result in different time values, then you can iterate over all 256 bytes (assuming ASCII) and when you have a cache hit for a specific value, the time should be much lower. However, this also assumes you understand cache internals of the specific CPU and it means you need to know when caches fill up, why they fill up and how to do cache eviction. Knowing how to do cache eviction means that you need to know how many elements can be cached, and if I recall correctly that means you need to reverse engineer the cache size of the CPU. But once you can reliable evict values from the cache set and reliably fill them up, then the rough outline I mentioned above is possible. Again, this is like 50% accurate since it has been a long while and I currently work in marketing as a data analyst (I like a mix of fluffy marketing/psychology talk and being deeply technical - if you feel the same way, feel free to reach out. My email is on my profile). There's some of what I described on this website (and a whole bunch more) [1]. I think the reverse engineering of cache lines was specifically in the accompanied paper. [1] https://www.vusec.net/projects/glitch/ https://www.vusec.net/projects/glitch/