Fwd: [gsoc18] Boost.Detour & Mentor Search
---------- Forwarded message ---------- From: Michael Kiros <michaelakiros@gmail.com> Date: 15 March 2018 at 02:30 Subject: Re: [boost] [gsoc18] Boost.Detour & Mentor Search To: David Bellot <david.bellot@gmail.com> Hi David, I have written the draft of a proposal to add a new library (or work on it during the Summer of Code 2018). It's a proposal for the addition of Boost.Hook, a function hooking and control flow augmentation library. It's something I've worked on a lot in the past and would like to incorporate into Boost so that both I and others have a centralized, agreed way of taking an approach to function hooking. I also have plans of integrating it with Boost.Process and some memory mapping libraries from Boost so that there are fewer "third-party dependencies". Here's a link to the draft: https://drive.google.com/file/d/1nh436adVvIHC_ AXTAJi6Wr_uLpM4-SSc/view?usp=sharing I would really like to know the feedback to this and if anyone's interesting in mentoring me during the build up of this project. It's a very interesting, useful topic. I can assure anyone that. On 14 March 2018 at 07:01, David Bellot <david.bellot@gmail.com> wrote:
an explanation of the idea with examples would be good. Please follow the instructions on https://github.com/boostorg /boost/wiki/Boost-Google-Summer-of-Code-2018
On Wed, Mar 14, 2018 at 12:50 PM, Michael Kiros <michaelakiros@gmail.com> wrote:
Would the proposal be in the form of code or just an explanation of the idea?
On Mar 14, 2018 7:41 AM, "David Bellot" <david.bellot@gmail.com> wrote:
Hi Michael,
as it is a new project in Boost, ideally you want to write a first draft proposal and submit it to this list too (via a link please, do not attach document).
I'm sure someone would be interested in mentoring for GSoC especially if the idea is brilliantly explained. As we have a few days left before submission to Google, I encourage you to start working on it right now.
Cheers, David
On Wed, Mar 14, 2018 at 8:19 AM, Michael Kiros via Boost < boost@lists.boost.org> wrote:
Hello,
I'm a C++ developer and have been developing in C++ for over 6 years now in my personal time. I wanted to accomplish two things with this post:
1. Propose the idea of boost::detour 2. Find a mentor in the process
Boost.Detour is not something new that I'd like to implement but a concept in programming that I have been using for a very long time now and would love to have it easily accessible with the inclusion of a simple <boost/detour.hpp>. The idea is to have function hooking easily accessible to everyone using C++. Though it may seem like a niche feature, function hooking is more commonly used than most people think (e.g. modifying binaries after compilation for feature addition, reverse engineering proprietary software). It's a beautiful concept when you see it working.
In the process I need a mentor to guide me through the process of putting down my ideas to paper and implementing them according to the standards that Boost holds. This includes replacing components from my library with Boost concepts (e.g. boost::process).
I'm also a student at Texas Tech University studying Computer Science.
Can't wait to hear from someone.
Michael
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost
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
- 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/
- 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/
2018-03-21 0:23 GMT-03:00 Michael Kiros <michaelakiros@gmail.com>:
- 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/local <https://github.com/michaelkiros/hadesmem/tree/master/include/memory/hadesmem/local>
I wouldn't call this mirror. I suppose there was at least a README file in the original repo.
- I've added two use cases inside of the proposal and updated the PDF file
What is the expected steps to use this library to inspect proprietary applications? The interface only hints me on how to use it to inspect proprietary DLLs.
- 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
What exactly is a detour type? -- 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 :)
2018-03-22 1:16 GMT-03:00 Michael Kiros <michaelakiros@gmail.com>:
That repo represents the last, latest state of the repository [...]
Thanks. [...] 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.
I was more concerned with the separation of library/application when I made the question. Suppose I want to change Tibia to cheat the game. There is a main function there on the executable (it's not _your main_). What's the proper interception place then? What's the workflow? Open the executable using your executable and transfer control flow once you prepare the hooks? 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.
Thanks. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
participants (2)
-
Michael Kiros
-
Vinícius dos Santos Oliveira