What do you want done with JauntePE in the near future?

[m^(2)]

The whole library would need to have "inject dll into a process" capabilities, api-hooking/unhooking capabilities, and a way to recover and pass on the module handle for the api caller.

Can I assume that I have PROCESS_ALL_ACCESS rights to the process?

The dll injector and api hooker would need access to a generic pc-cpu code dis-assembler to ensure that the "stepped on" code was complete.

Can you explain? What code are you going to disassemble?

The api hooker would need to hook implicitly loaded, delay loaded, and explicitly loaded library functions.

Implicitely - no problem. Explicitely - a bit more work, but can be done.
I don't know how does delayed loading work, but I have an idea...
For functions in delay and explicitely loaded dlls, I could call LoadLibrary() on setting a hook. It could slightly slow application initialization down, but should work. Is it acceptable?
I guess you're going to pass me dll and function names and the library is supposed to find it?

It would also need to capture the handle of the module making the api call so that it could later be retrieved and used by JPE for its module inclusion/exclusion list processing.

Never did it before, but sounds easy.

You ask for a very generic thing, it requires too much work. But I think we can significantly simplify it. I.e. When do you set hooks? If you do it just after CreateProcess(CREATE_SUSPENDED) it would be much easier.

Let's better continue the discussion via email. I'll PM you my address.

[redllar]

@m^(2):

I don't really have much time for anything these days re: this project, other than trying to get it modified for a statically linked MCH, so you're kind of on your own with this if you want to pursue it. What I can tell you is that for the way JPE works right now your assumptions should be fine. Also, the hooks are applied within the dll that's injected into the child process by the parent process that created the child. They're not applied by the parent process.

The only thing you need to make sure of, that most hooking code I've seen doesn't, is that if you use a hooking and/or injection method that involves overlaying existing code with your own, you must do so at an instruction boundary. You can't assume grabbing an arbitrary 5 or 6 bytes is sufficient. That's what the disassembler is for.

My suggestion is to look at the samples from both Detours and MadCodeHook. AFAIK, they both do things essentially the same way as far as the hooking library usage is concerned. Also, IIRC, madshi has a nice little synopsis on the various hooking methods in use along with a write-up of why a disassembler is needed.

[redllar]

@all:

Just an "fyi" that I sent off my first cut of the JPE-specific MCH wrapper dll to madshi for approval. I did go ahead and add in functions for the hooks necessary to handle the 020 plugins I had already coded up. And I was able to find and fix the "fake drive" "Save As" bug. So at least you'll have a basic crypto drive to use with this last release I put out.

The downside to this is that I'll have to put out a new set of JPE exes as well. And I don't think I'll have time to fix all of the bugs in them. The best I'll be able to do is comment out any new stuff that's really buggy and leave that for someone else to fix.

[m^(2)]

The only thing you need to make sure of, that most hooking code I've seen doesn't, is that if you use a hooking and/or injection method that involves overlaying existing code with your own, you must do so at an instruction boundary. You can't assume grabbing an arbitrary 5 or 6 bytes is sufficient. That's what the disassembler is for.

I know how to do this, I did it several times, but I still don't know what the disassembler is it for..to check whether the function isn't too short? When we're talking just about WINAPI hooking, the code is optimized, so the function body starts at function address (in debug code there can be just a jump). And there are only a few functions that can be shorter than 7 bytes (5 is minimum, but 7-easier to implement), GetCurrentProcess is the only I can think of now. Such functions can't be hooked anyway so, as MadHook works in JPE, my library w/out disassembler also should.

[redllar]

You really can't safely assuming anything about the api function's entry point code other than it's possibly not what you think it is. There are just too many ways for it to be modified, both within the dll file and at runtime.

Thus the need to decode it to ensure that you won't crash the app when you replace it and relocate it elsewhere. I don't think you need a full disassembler for this. When I first started thinking about this last year the 3 things that came immediately to mind were function length, instruction boundaries, and relative addressing. There's probably others since I haven't really done any extensive low-level coding in a long, long, time. I can't say that relative addressing would even be a possibility, for instance.

[m^(2)]

I know. And the only thing I need to know about it is code length.

But now I know what is disassembler for. Yesterday, while reading about totally different thing, I found an article with interesting approach - it executes the original code relocated, which requires fixing jumps / calls / push-returns. Possibly MadHook does the same... and I'm also going to. It has many advantages over restoring the original code every time you want to call the original function.

[redllar]

Sorry, I didn't realize you were only using copy and replace instead of copy and relocate.

Copy and replace wouldn't work with JPE unless there was some mechanism for JPE to tell the hook library to let the call go through to the api function, or not. It's also known to be prone to missing calls due to the need to get the original code back in after the hook call. For the same reason it also slows things down since it has to play games with thread execution while it's replacing the code.

madshi gives a general background of the various hooking methods currently in use, plus the ones he uses, at http://help.madshi.net/ApiHookingMethods.htm . There's some useful info there, especially regarding hooking kernel functions on 9x.

[Kundalini]

Here is my 1.5 cents worth. Hopefully it'll be helpful. Madshi's library isn't the only API hooking/dll injecting library/software out there. There are other options. In the past I found a website that had a hook library, unfortunately, its associated with the hacker/cracker types and would need some serious looking at, which is way beyond my Icon making skill. Recently, I found this, which is much more legit than the previously mentioned one & GPL: WinAPIOverride32, http://jacquelin.potier.free.fr/. I'm not much of a coder type, but maybe it can be used in place of the madChook.

If I'm crazy...take it with a grain of salt.

Cheers,

K

[redllar]

Just an update on where things stand:

No word back from madshi yet. But there's the possibility that we may be able to get the builds done by someone who has a licensed version of MCH and is willing to act as the project lead. We'll see.

I've gone ahead and begun reworking the code for 9x usage. I decided to do this since the exe and dlls will all be changing anyway. I was able to successfully portably launch, inject, and hook MetaPad on 98 first edition and keep it out of the system registry. Unfortunately it crashes on file opening, so more work's still needed. But at least it's a start.

Oh, and it looks like parking the sources on SourceForge is probably a no-go. I've contacted them twice now about the project and its "situation" re: the MCH usage, but no one's bothered to respond. An offer for server use for the distributables was made earlier so I'm going to see it's still available and what could be done re: project management, if anything.

[Zach Thibeau]

What about the other library that M^2 is writting couldn't we try that once it's complete and see if it could work and use that instead

[Andrew Lee]

No word back from madshi yet. But there's the possibility that we may be able to get the builds done by someone who has a licensed version of MCH and is willing to act as the project lead. We'll see.

Just exploring all the possibilities here. If we pool together and pony up $199 for a commercial license, would that give us the go ahead?

If enough people are interested eg. 10 - 20, each person only has to come up with $10 - $20.

[Firewrath]

oooh,
thats sounds good, ill help,

[Kundalini]

I'm down. As long as JPE doesn't drop off the earth soon after. I'm sooo down. Maybe we could drop it into a paypal account?

[grannyGeek]

Great Idea !!!
Count me in for donation. Since I can't program, and not even an informative beta-tester, I'd love to be able to contribute to the project in some way.

[spacemonkey]

Im in the same position as grannyGeek. Would be good to be able contribute in a practical way. Count me in