Representing code types for arbitrary architectures and calling conventions in ptypes?

[arizvisa]

Would be cool to represent code and pointers to code with a native code type in ptypes.

This way a user wouldn't need to manually transform the semantics of a ptype instance into a way to execute it. The downside of this is that depending on how it's implemented, we could end up forcing the user into dispatching to their referenced code with whatever methodology we choose.

Ideally we want to avoid pigeon-holing the user so that users can interpret a code type using whatever implementation they choose. This way we can keep the flexibility of ptypes. We'd also want to dumb down the interface so that users can interpret the code in whatever context is relevant to them (running in the current process, remote process, in an emulator, etc.) and also allow them to describe the calling convention of whatever it is that they're trying to interpret.

There was a preliminary implementation of this under the ptypes.code module that tied it to the intel architecture using the udis package and the table-based instruction length disassembler that went into the ia32 library module. It ended up not being used for anything but shellcode, however, due to the reasons that were just mentioned. I'd like the interface for disassemblling the type and interpreting it to be exposed to the user in some global way rather than requiring the user to describe it specific to the type during its creation. Maybe something similar to the byteorder interface that is used for both integrals and binary types.

[arizvisa]

I think initially the calling convention interface will start out as being a ctypes wrapper as it's currently available and easy to test.

The upside of this (rather than using things like NtContinue, setcontext and makecontext, setjmp and longjmp) is that the ctypes module is easy to test with and is a very mature codebase (although the ctypes version of the libffi library is outdated, and so we're missing some conventions). However, the major downside (a huge one) is that ctypes is a binary module which will require re-linking and means we can't be self-hostable with just the fu library module anymore.