jDetours

https://sourceforge.net/projects/srloader/

jDetours is a sub-project to my loader (which is still under dev to the point that it won't compile and I'm working with a friend on a C# interface and lua integration which shall be epic).

To come in the project is a full x86-64 assembler (programmatic, not text based) and disassembler, this will complement the jDetours by removing the need to provide the # of bytes to patch in a target function, and it'll be useful for creating functions on the fly to inject. Following that I'll add a memory system that'll allow pattern matching, page walking, LDR-related api, and various other cool nifty things in a process-independent context so that you can attach the memory interface to any running process (if you have high enough privileges) and do all the same things, including getting a libraries exports/imports, sections, resources, IAT/EAT patching, etc etc. These are pretty far in the future as I have other things I'm working on + a job, so this is really just "when I have time to work on it" kindof stuff.

jDetours at this stage basically lets you create detours only on x86. It creates a trampoline for clean calls (using these is called pInvoking) and a gateway called the bootstrapper which takes care of all of the "hard stuff" and makes this work like magic.

You create a hook like demonstrated in the provided main.cpp file. There's no need to provide a pfn or anything, you can invoke the hooked function by using a c-style variadic function (a pInvoke function), either from the parent Detour object or the context object passed to each hook function. You simply pass the # of arguments, followed by those arguments.

jDetours isn't just a normal basic detour. It's meant to preserve CPU state (sans XMM, SSE, and the FPU stack, and several other technologies) across the original caller->callee boundary. This makes it useful in more situations where strict ABI compliance may not happen (for instance in hand-crafted ASM), however it does make some assumptions and may not work in some cases, but it should in many more than most detouring engines. As a result of this, the entire CPU state (regs + eflags) is made available to you in your handler function to modify or use. This makes it easy to pull args out of a fastcall function or grab the thisptr in thiscall functions, or even poison it to hook only certain instances of classes which don't have a vtable to make that easier.

Enjoy ;o, if you have any suggestions or requests go ahead, I'm all ears. That enable/disable feature was actually a suggestion made the day I opened this SF project. The DLL capability was one for a friend who said he might want to use it but didn't want to deal with GPL if he incorporated it directly into his code.


I'll make another thread when we get the loader into the first testing phase when it all compiles and works, and all the basic functionality has been debugged. It's going to be cool, trust :). A bit complicated to make an addon for it to inject your DLL but for the end-user, it's super epic.

I think it's funny that no one really replied, since no one really understands what you just said.

I'm afraid I have to agree with xSilv3rbullet a little.

It sounds really interesting and I'd love to see what's it about, but I understand jack shit of the most part, but still sounds interesting to follow.