You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
currently Vivisect doesn't have a good way to handle .ko IMPORTs.
the name doesn't exist, and so a call to makeImport() should handle the problem... however, for x86 kernel modules, the compiler uses a 32-bit offset branch, and uses R_X86_64_PLT32 to jam in an offset into the opcode itself.
without an actual target to point to, we currently just leave the branch alone (which branches to the next instruction).
in hellokernel, that appears like this:
@rakuy0 , we need to determine the best way to handle that. one option we started to discuss, is putting in the idea of an "extern" function that we can define and branch to that (making that the IMPORT, which would work with viv_loader as well), and jamming in the offset to that.
The text was updated successfully, but these errors were encountered:
currently Vivisect doesn't have a good way to handle .ko IMPORTs.
the name doesn't exist, and so a call to makeImport() should handle the problem... however, for x86 kernel modules, the compiler uses a 32-bit offset branch, and uses R_X86_64_PLT32 to jam in an offset into the opcode itself.
without an actual target to point to, we currently just leave the branch alone (which branches to the next instruction).
in hellokernel, that appears like this:
@rakuy0 , we need to determine the best way to handle that. one option we started to discuss, is putting in the idea of an "extern" function that we can define and branch to that (making that the IMPORT, which would work with viv_loader as well), and jamming in the offset to that.
The text was updated successfully, but these errors were encountered: