zydis in lancelot

[williballenthin]

I use zydis in (yet another underfunded binary analysis framework) lancelot via the Rust bindings.

I've found zydis to be really easy to use. Furthermore, its highly performant, so its reasonable to use silly algorithms (like disassemble from every offset looking for valid calls) while remaining quick enough for interactive use (e.g., fully analyze kernel32.dll in 0.4s or something). In fact, its so fast that rebuilding analysis on every invocation makes more sense than engineering a workspace file format, serialization, etc.

One place that zydis particularly helped me recently was when I was implementing a FLIRT matcher (and here). A key part of FLIRT are "reference names" - basically, "to confirm this potential match, this function should have a pointer to this other thing that we can recognize". Its encoded as an offset from the start of the function and its up to the matcher to figure out how to interpret the pointer and follow it (I think this is due to sigmake extracting relocations from object files). Notably, the offset may point to the middle of an instruction to where the pointer is encoded!

This makes it tricky to figure out how to decode the pointer - where does the instruction start so you can decode it and extract the pointer? Thanks to zydis exposing raw information, it wasn't too hard! We can disassemble backwards and then look for the raw offset of each operand and validate the pointer (e.g., here and here).

So, zydis provided just what I needed without any extra effort - thank you!

[athre0z]

Hey, thank you for sharing this, that's nice to hear!

Writing a proper binary analysis framework used to be on our TODO list for pretty long as well, but we never came around to actually writing one. The disp offset in raw was originally intended to allow users to easily patch it if they want to, but this is definitely an interesting use case as well!

Starting at -4, then going towards -1 is a good approach. In some gcc generated binaries I have experienced that some jumps and calls were padded with a 0x67 prefix (probably for alignment reasons?) and your code should be able to handle even those. :-)