iced

>"MISHEGOS is a differential fuzzer for x86-64 instruction decoders. Instead of relying on a “golden” decoder or hardware decoder for ground truth within its difference oracle, MISHEGOS runs multiple unreliable decoders in parallel on an instruction candidate and uses their consensus or disagreement to mark the input as likely erroneous. As of writing, nine x86-64 instruction decoders written in a variety of languages can be fuzzed by MISHEGOS: • GNU libopcodes (C) [21] (https://www.gnu.org/software/binutils/) • Capstone (C++) [22] (https://github.com/capstone-engine/capstone) • DynamoRIO (C and C++) [2] (https://github.com/DynamoRIO/dynamorio) • fadec (C) [23] (https://github.com/aengelke/fadec) • Udis86 (C) [24] (https://github.com/vmt/udis86) • Intel XED (C) [25] (https://github.com/intelxed/xed) • Zydis (C) [26] (https://github.com/z

An unfortunate name clash with one of the best x86 decoders I've ever used, also written in Rust[1]. [1]: https://github.com/icedland/iced

> It might be worth noting that strictly speaking this isn't safe to apply to an arbitrary binary. That is 31 c0 and 33 c0 might behave identically when executed as xor, but they could, for example, also be part of a larger instruction where the swap results in a change in behavior. > Presumably this implementation disassembles the binary which gives a very high probability of determining whether these bytes are only executed as xor, but this isn't in general enough since the way the program is executed at runtime may not correspond to disassembly [0]. Yep: steg86 uses iced[1] internally to decode and re-encode instruction sequences. Arbitrarily replacing `31 C0` with `33 C0` (or vice versa) in the instruction text would certainly not go well. And yes: it's possible to contrive pathological programs that make these kinds of patches imposs