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

Discuss anything related to JauntePE, the utlimate utility to help you tame non-portable applications. Share your experience about the apps that work with JauntePE, and the apps that don't.

What do you want done to JPE after the MCH DLL is no longer distributed with JPE?

Leave the JPE distributables as is without the MCH DLL and continue with the 01* bug fixing
2
13%
Leave the JPE distributables as is without the MCH DLL and finish the 02* version
0
No votes
Statically link MCH into JPE so the distributed JPEs are usuable by all and continue with the 01* bug fixing and then maybe later on someone will find an MCH replacement
12
80%
Stop distribution, create a source-code only project on SourceForge, and wait for someone to add their own dll-injecting and api-hooking library to it
1
7%
 
Total votes: 15

Message
Author
redllar
Posts: 411
Joined: Thu Aug 03, 2006 7:52 pm
Contact:

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

#1 Post by redllar »

As some of you already know, madshi, the creator of madCHook (MCH), the dll-injection and api-hooking library that JPE currently uses, decided to pull his "free for non-commercial use" dll version of MCH from the net a while back due to persistent malware writers use. In a recent conversation with him it was agreed upon that MCH should be removed from the JPE distributions.

But madshi has made the offer to statically link MCH into JPE, with one condition. The condition is that the list of apis being hooked would need to be frozen. Meaning that no additional hooks could be added if needed. Which means that no plugin version of JPE could be made since it relies on being able to hook any api that a plugin dev might need to manipulate. It also means that the project as a whole would be considered closed source since the dll I woud create to "house" the statically linked MCH could not be changed. I could "open source" that code but the MCH files used for the build would not be available.

So, I'm in a bit of a quandry here as to what to do with what time I have left and am looking for some advice. Do you want me to burn the time necessary to get MCH statically linked into JPE so that any current bugs can continued to be squashed? Or would my time be better spent looking for an MCH replacement? Or should I just finish up the 0.2.0 plugin version and leave it for any potential future project dev(s)? Or?

EDIT: Another path to take that I just now realized, is to go ahead and remove MCH from the distributions and then just proceed as usual, with the assumption that anyone new to the project would get a copy of the MCH dll somehow.

EDIT: Just to make sure it's clear, out of respect for madshi's wishes the MCH DLL will be removed from the JPE distributables.
Last edited by redllar on Thu Sep 27, 2007 10:02 am, edited 4 times in total.

Chris
Posts: 106
Joined: Sun Dec 03, 2006 10:08 am

#2 Post by Chris »

To be honest, I think no one would be able to improve JauntePE better as you would, not many have knowledge like you have, and no one knows JauntePE better than you do. Even though portability is getting popular, no one thinks like you and create this kind of portable application or other just failed. So, your decision to leave JauntePE would surely be missed by many.

However, if it is your final decision... I think it is better to get MCH statically linked into JPE then bug hunting, to prepare JauntePE for any future project dev(s).
But personally, I can't wait for JauntePE context menu.

I have suggestion which surely would take more time, find MCH replacement then bug hunting, it would be good for long-run development and easier for future project dev(s) to pick up JauntePE.

I'm not an expert, so I guess someone should have better suggestion.

User avatar
Firewrath
Posts: 321
Joined: Mon Aug 28, 2006 2:36 pm

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

#3 Post by Firewrath »

redllar wrote:EDIT: Another path to take that I just now realized, is to go ahead and remove MCH from the distributions and then just proceed as usual, with the assumption that anyone new to the project would get a copy of the MCH dll somehow.
im almost in favour of this, till it comes to like, 2-3years down the road,
(and dont tell me ppl wont be using it then, you know they will, :P)

as for the 020 stuff, id Love to see the drives fixed, one way or the other, :P

but as far as JPE goes,
thats really up to you,
(*Cough* you could, always, ...add the drives to the basic JPE O=P
which overall isnt a bad idea considering how handy the nonencrypted one would be, like how you started with the idea, but yeah,)

unfortunately, if there was a replacement for the MCH.dll, i dont think he'd have to take it off the net or would be having the problems he does,

and i dont like locking JPE down, but if thats the best way to go, and will let it continue, then i geuss itll have to be done, =/


ofcourse i have to agree with Chris here:
Chris wrote:To be honest, I think no one would be able to improve JauntePE better as you would, not many have knowledge like you have, and no one knows JauntePE better than you do. Even though portability is getting popular, no one thinks like you and create this kind of portable application or other just failed. So, your decision to leave JauntePE would surely be missed by many.
but yeah, we've been over that, :P

User avatar
Andrew Lee
Posts: 3052
Joined: Sat Feb 04, 2006 9:19 am
Contact:

#4 Post by Andrew Lee »

I am also of the opinion that you should just remove madCHook.dll from the distribution, and concentrate on the bug fixes/improvement. Let those who want to use it worry about where to get madCHook.dll.

When you open-source JPE in the future, some bright guy might come along and create an open-source replacement for madCHook.dll. You never know...

Chris
Posts: 106
Joined: Sun Dec 03, 2006 10:08 am

#5 Post by Chris »

I thought removing MCH first was a good idea, but could JauntePE hook on the process without MCH? Without MCH, JauntePE would not work properly, no?

sgp
Posts: 67
Joined: Sat May 12, 2007 1:05 am

#6 Post by sgp »

If you remove MCH from the distribution it's like relegating JPE into the realm of the "illegal". Any new user would need to download MCH from a "questionable" Internet site to get a working distribution. Is this what you want for JPE?
Also, if MCH coudn't be distributed with JPE, then it couldn't be distributed with any of the app wrappers that we'd be adding to portable freeware forum. Not good.
It seems to me that MCH has to stay with JPE one way or another.
Sure, I'd like for you to work on new features and stuff, but what's the use of it if then the base JPE package can't be easily distributed to more people?
As for whether your time should be spent into looking for a MCH alternative, you probably know what's out there already, my hunch is that you've already made the best choice with MCH.

crownixx
Posts: 403
Joined: Sat May 12, 2007 6:26 am

#7 Post by crownixx »

Stay with a standard MCH for now until JauntePE has ready in beta stage or for public release then statically link MCH into JPE later on.Can it be that way?
redllar wrote:So, I'm in a bit of a quandry here as to what to do with what time I have left and am looking for some advice... Or would my time be better spent looking for an MCH replacement?
If there is still a time and the work doesnt too much i really hope that you can consider this option. Find another replacement has alot of advantage for the JauntePE future. One reason why the open source guy cannot give a help in jpe devep is that MCH is not an open source component. MCH replacement will give a new life n new story of portable world
http://portableapps.com/node/7707

the choice is yours in i will give full support to it

redllar
Posts: 411
Joined: Thu Aug 03, 2006 7:52 pm
Contact:

#8 Post by redllar »

Thanks for the feedback so far. Although some of you have just "muddied the waters" a bit by not telling me what you want. :)

To clarify, out of respect for madshi's wishes, the MCH DLL is going to be removed from the JPE distributables. Which means what's to be decided upon is what this means to JPE. As far as I can see, there are only a few options, which I think I'm going to go ahead and add to my original thread post as a poll. Hopefully that will help you decide what you want done.

redllar
Posts: 411
Joined: Thu Aug 03, 2006 7:52 pm
Contact:

#9 Post by redllar »

EDIT: Removed blathering by me.
Last edited by redllar on Thu Sep 27, 2007 2:53 pm, edited 1 time in total.

Chris
Posts: 106
Joined: Sun Dec 03, 2006 10:08 am

#10 Post by Chris »

I also think find the replacement is quite important. I do not know it really works, however if changing the hooking library would need many recode of the JauntePE, it would be waste of time in the future or would hinder the development later on.
But, if it's easy to change the library without much work, I think bug fixing is better.

User avatar
Kranor
Posts: 120
Joined: Sun Jan 14, 2007 7:15 am
Location: uk

#11 Post by Kranor »

I think the static link and bugfixing is the way to go at the moment. Meanwhile everyone put out the feelers for a replacement.

redllar
Posts: 411
Joined: Thu Aug 03, 2006 7:52 pm
Contact:

#12 Post by redllar »

I did a bit more thinking on this, and it looks like to get MCH statically linked into JPE I'll need to do enough code shuffling that I'll probably go ahead and at least include a function to support the api-hooking necessary for the fake-drive functionality.

Also, I forgot to ask madshi about what compiler/linker he would be using to build the wrapper dll. Anything newer than VC++ 6 will result in a much larger runtime since the C runtime will either have to be statically linked in or distributed as well. This would probably make any distributed app portablizing JPE packages "big".

Regarding alternate dll injection and api hooking code, I isolated all of this functionality last year when I switched from Detours to MCH. And I did find some source code last year, but it turned out to be too similar to MS Detours for my liking. Which is kind of funny because it's for a fairly popular malware-prevention app. kundalini also recently sent me a link to a site that had this type of code, but it's from a hacker/cracker group so it would need to be gone over quite thoroughly before it could be trusted.

User avatar
m^(2)
Posts: 890
Joined: Sat Mar 31, 2007 2:38 am
Location: Kce,PL
Contact:

#13 Post by m^(2) »

2redllar:
Can you provide me interface you want for such library? What exactly are your needs? I've been playing with such tricks for some time.

redllar
Posts: 411
Joined: Thu Aug 03, 2006 7:52 pm
Contact:

#14 Post by redllar »

m^(2) wrote:2redllar:
Can you provide me interface you want for such library? What exactly are your needs? I've been playing with such tricks for some time.
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. 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. The api hooker would need to hook implicitly loaded, delay loaded, and explicitly loaded library functions. 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.

User avatar
Zach Thibeau
Posts: 251
Joined: Tue Nov 28, 2006 3:26 pm
Contact:

Well

#15 Post by Zach Thibeau »

My suggestion is for now to use JauntePE as is, and fix the bugs in it, as for the Madshi library I agree in making a new library thats open-source :)

Post Reply