Re: [boost] Fwd: [gsoc18] Boost.Detour & Mentor Search

Subject: Re: [boost] Fwd: [gsoc18] Boost.Detour & Mentor Search
From: Michael Kiros (michaelakiros_at_[hidden])
Date: 2018-03-22 04:16:26

>
> I wouldn't call this mirror. I suppose there was at least a README file in
> the original repo.

That repo represents the last, latest state of the repository. The README
is located in the root folder but it doesn't
contain any documentation. If there's any confusion the library does more
than just hook functions. It also deals
with pattern finding and other (unrelated) concepts. I linked to the
include/memory/hadesmem/local folder because
that's the folder that works with hooking functions.

What is the expected steps to use this library to inspect proprietary
> applications?

With proprietary software, whether debug symbols exist or not, the primary
goal is to locate the address of a function.
This can be found by using debug symbols provided with the binary or by
reverse engineering the binary to
locate the address of the functions you need to hook. In cases where the
address of a function changes
then you'd need to find a way to dynamically figure out the address of the
function (e.g. base address of process/
module + offset). Then you can easily cast the address of the function to a
function pointer type matching the
function signature and use the library provided API.

Like you said, it's easier to work with DLLs because their functions are
exported so you'd just located the address
of the function using the export symbol table and the Windows API
functions/POSIX equivalent.

What exactly is a detour type?

I've used the words hook and detour interchangeably thus far but here on
out I'll start using the more
appropriate terms. The 'hook types' that would be required would be
specializations of a single type and each type
would represent a different approach to hooking a function. For example,
with the first planned method of hooking
(byte patching) the first few instructions in a function are overwritten to
redirect to the user's hook function. Another
hook type would represent a different way of hooking (e.g. leveraging the
vectored exception handlers + page
protection to redirect control flow every time an instruction is accessed).

Though I've been talking specifically about Windows so far the library is
planned to be cross-platform so any
OS-specific features will be accompanied by checks + error messages (i.e.
ifndef/error macros).

Let me know if there's anything else I can clarify :)