- The author must have decided to take down the repo very recently. Here's a mirror that I have: https://github.com/michaelkiros/hadesmem/tree/master/include/memory/hadesmem... - I've added two use cases inside of the proposal and updated the PDF file - I haven't thought of a detailed timeline yet but as a draft it would go something like this: 1. Work on setting up the project (includes setting up dependencies for disassembly, run time assembly etc.) 2. Start working on an abstract class that describes the most basic detour type 3. Start working on the very first detour implementation using byte patch 4. Add tests 5. Keep on working on current features and adding new detour types I'll work more on the project when I get the time (soon) and start a small sample implementation project on GitHub then link it here. On 20 March 2018 at 20:50, Vinícius dos Santos Oliveira < vini.ipsmaker@gmail.com> wrote:

2018-03-15 5:36 GMT-03:00 Michael Kiros via Boost <boost@lists.boost.org>:

...

Here's a link to the draft: https://drive.google.com/file/ d/1nh436adVvIHC_ AXTAJi6Wr_uLpM4-SSc/view?usp=sharing <https://drive.google.com/file/d/1nh436adVvIHC_AXTAJi6Wr_uLpM4-SSc/view?usp=sharing>

- The linked github repo is 404. - I'd like to see two use cases for hooking in the proposal. - You should include a detailed timeline for project implementation. What will you be working on each week?

-- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

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 :)