"Free"-built JauntePE solution(s)

[redllar]

Thought I'd start a thread to relay any info I have on trying to get the JauntePE executables built via the various free development tools available. This is mainly for any future JPE devs after I leave.

I found some options to use with gcc that reduce the jpe dll size to just twice that of the VC++ 6 build. :) But the darn thing doesn't do anything. It gets injected okay but it's just sitting there. Hopefully it's just a missing switch or 2.

Also, the gcc/mingw32-built JPE launchpad hangs after successfully launching and injecting the dlls. But it looks like maybe there's a viable free solution available afterall. Still not as good as the vendor's solution, but that's to be expected.

[Master of Dice]

Which development environment do you use?

[pla]

(Lurker for a few weeks, finally tossing my hat into the ring)

If it helps, I do most of my development under MinGW, mostly because it makes cross-platform (with Linux, mostly) builds much easier. But I've done a fair bit of low-level Windows coding as well, so no amateur there.

If I can do anything to assist, let me know.

[Zach Thibeau]

if it also helps Dev-C++ uses mingw as it's base to compile (Of course you already knew that, I mean who hasn't heard that )

[Andrew Lee]

If MingW doesn't work out, a possible alternative might be Visual C++ Express.

[redllar]

Which development environment do you use?

VC++ 6.0 SP5 Professional edition with the last win32 SDK available for that version.

If I can do anything to assist, let me know.

Hey, and thanks. No problems with it yet that haven't been traced back to Dev-C++ limitations.

if it also helps Dev-C++ uses mingw as it's base to compile

Yeah, that's what I'm trying to use, since I figured that's what you guys would be using. It's a bit of a toy though. Kinda like moving from Thinstall to JauntePE, actually. :)

If MingW doesn't work out, a possible alternative might be Visual C++ Express.

Things would probably build and run w/o problems. But something would need to be done about the new C/C++ runtime dlls. Either statically link them into the executables, include them with every JPE-built portable package, or force the users to download and install them. I personally don't think any of those are good alternatives.

[redllar]

Just wanted to let you all know that I finally got things working.

There's an exported functions naming mismatch with the madCHook import library that I don't think can be resolved without tweaking the library, but using LoadLibrary and GetProcAddress works fine. The issue with the jauntePE dll not getting executed had to do with ye olde decorated function names incompatibilities between compilers. And the issue with the hanging JauntePE launchpad had to do with the jauntePE dll init code not being executed.

So I have a bit of work to do to make sure the launchers don't get stuck but the rest seems to be resolved enough that the gcc/mingw32 built executables are actually working now. I'm still looking into some more gcc switches to reduce the dll size. Right now it's at 82KB when upx'd.

[Master of Dice]

Thx redllar. Keep up the great work.

[ayanamist]

redllar, i used to think you were using Delphi with KOL to develop JauntePE because MadChook is a delphi component, but i am wrong.
i have a question: why do you write your own api-hook core instead of MadChook, so you can reduce the file size a lot since you can remove many unused libs. API-Hook documents can be found all over the internet.

[Zach Thibeau]

if he said he used C++ then he used C++ and he did say he compiled it correctly using mingw M$ Visual C++

[ayanamist]

if he said he used C++ then he used C++ and he did say he compiled it correctly using mingw M$ Visual C++

sorry i just mean i misunderstanded something, that's all.
so far MS VC 6+SP5 is the best compiler for redllar's request: best compatiblity, small file size, fast speed.
Dev Cpp, MinGW, Cygwin and all other gcc-based compilers will increase file size for unix emulation layer code (about 100kb).
MS VS 2003 and above will need runtime files.
Borland C++ Builder needs him to rewrite the whole project because of such different framework, but can give also a small file size too (if only use API but not VCL)

[redllar]

i have a question: why do you write your own api-hook core instead of MadChook, so you can reduce the file size a lot since you can remove many unused libs. API-Hook documents can be found all over the internet.

I'm assuming you meant "why don't you write" instead of "why do you write" in my response here.

I did start writing my own late last year once I figured out that we couldn't distribute the version of the Detours library I was using at the time. It was when I was researching what needed to go into an api-hook disassembler that I ran across the madshi site and the MadCodeHook library.

But to answer your question, it's simply a matter of time available and of the desire to "not reinvent the wheel." Not matter what MCH is written in, it's solid, it performs well, it's dead-simple to use and it's decently documented. And using it frees me up to devote what limited time I have to working on the portablization work. Yes it's a bit big due to the Delphi runtime built into it, but if things are set up correctly you only need one madCHook.dll file per drive at most. Technically you only need one mch dll per pc.

[Ttech]

i have a question: why do you write your own api-hook core instead of MadChook, so you can reduce the file size a lot since you can remove many unused libs. API-Hook documents can be found all over the internet.

I'm assuming you meant "why don't you write" instead of "why do you write" in my response here.

I did start writing my own late last year once I figured out that we couldn't distribute the version of the Detours library I was using at the time. It was when I was researching what needed to go into an api-hook disassembler that I ran across the madshi site and the MadCodeHook library.

But to answer your question, it's simply a matter of time available and of the desire to "not reinvent the wheel." Not matter what MCH is written in, it's solid, it performs well, it's dead-simple to use and it's decently documented. And using it frees me up to devote what limited time I have to working on the portablization work. Yes it's a bit big due to the Delphi runtime built into it, but if things are set up correctly you only need one madCHook.dll file per drive at most. Technically you only need one mch dll per pc.

It works fine. I have a directory on my drive that contains all the registry's from different apps and all the filesystem files. But I can't figure out how do ge the 1 madCHook.dll to work with all the portable apps?