-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Representing code types for arbitrary architectures and calling conventions in ptypes? #4
Comments
I think initially the calling convention interface will start out as being a The upside of this (rather than using things like |
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 theia32
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.The text was updated successfully, but these errors were encountered: