JaunePE 0.1.4 Bugs
Re: JaunePE 0.1.4 Bugs
quite similar to this problem but i try to explain more detailthibeaz wrote:I made an app portable then all of a sudden when making other apps portable with it nothing gets redirected at all. I think it's a JauntePE dll problem
just to play with the new JauntePE, i use 2 type of apps behavior below to run some test..
testing app behavior
Iconoid: the app only use registry, no filesystem is used
Excalibur: the app dont use registry, use filesystem- it add Excal32.dat on the system32 dir
i test it on Vmware XP (my laptop use pentium centrino)
using JauntePE 014 build portable launcher
>if i redirect registry & Filesystem, the app didnt redirect at all
>then i redirect registry, turn off Filesystem redirection, the app is JPE'd
>then turn off registry redirection, redirect Filesystem, the app didnt redirect
::curious that this is mybe jauntePE.dll 014 bugs when the filesystem is turn on, i simply replace the jauntePE.dll 011 version.use the same portable launcher& same jpe runtime ini
>success to JPE'd the application when Filesystem is turn on
now i change the testing variable
>between Vmware XP
>my normal XP
In my VMware XP
> 011 jauntePE.dll doesnt have a problem in redirecting registry & filesystem
>013 & 014 jauntePE.dll, simply when turn on the Filesystem, all the hooking fail (i already post redllar a video on this). however, if i only use Registry redirection, jauntePE able to make the hooking process
In my normal XP
>011 jauntePE.dll doesnt have a problem in redirecting registry & filesystem
> 014 jauntePE.dll doesnt have a problem in redirecting registry OR redirecting filesystem*
*my 1st attempt to redirect both registry & filesystem using 014 make my app crash upon exit. and it leave the application process in my Task Manager. but if i make the jpe runtime ini more specific to redirect neccessary registry key & filesystem, JPEd application using 014 can run fine
conclusion
>I really dont know why running 013&014 in VMware XP & normal XP can have different result. but this doesnt occur for 011
> 011 still relevan for me
- Zach Thibeau
- Posts: 251
- Joined: Tue Nov 28, 2006 3:26 pm
- Contact:
Yeah guys, you know what's really new since 012? I just realized it myself. Maybe it's the deal breaker for all of the different variations of cpus, VMs, etc. Thanks for posting all that info, btw. Now it's making some sense.
From the 012 readme:
v 0.1.2 - jauntePE dll changes only
- rebuilt with most performance optimizations turned on, sacrificing size for speed
Do you guys want a 014 built the way 011 was built? Without all of the compiler optimizations?
EDIT: removed link.
From the 012 readme:
v 0.1.2 - jauntePE dll changes only
- rebuilt with most performance optimizations turned on, sacrificing size for speed
Do you guys want a 014 built the way 011 was built? Without all of the compiler optimizations?
EDIT: removed link.
Last edited by redllar on Fri Aug 17, 2007 1:09 pm, edited 1 time in total.
- Zach Thibeau
- Posts: 251
- Joined: Tue Nov 28, 2006 3:26 pm
- Contact:
I have also seen similar results as those posted.
I built the portable launcher with FileSystem redirection turned off but the Registry set to redirect all. The first time the app launched if worked fine, I then went back to clean up the Registry settings by making changes in the ini. After that redirection broke, nothing would redirect no matter what I changed including setting it back to how I had it in the beginning.
I am also running JPE in a virtual machine (VirtualBox) so it sounds like a common thread.
I would be willing to try a non optimized version.
I built the portable launcher with FileSystem redirection turned off but the Registry set to redirect all. The first time the app launched if worked fine, I then went back to clean up the Registry settings by making changes in the ini. After that redirection broke, nothing would redirect no matter what I changed including setting it back to how I had it in the beginning.
I am also running JPE in a virtual machine (VirtualBox) so it sounds like a common thread.
I would be willing to try a non optimized version.
- Zach Thibeau
- Posts: 251
- Joined: Tue Nov 28, 2006 3:26 pm
- Contact:
Make sure that neither the jauntePE dll nor the madCHook dll are upx'd as well. The jpe dll linked to here isn't but I did upx the mch dll in the emailed 014 zip.
Also, have you turned on logging to see what the running process says its JPE runtime settings are? It's doc'd in the 014 readme but basically you just put a [Redirection]Logging=1 line into the JPE runtime ini used by the app and you should get a %appname%_jauntePE.log file created in the app's exe's directory. This might give you some indication of what's going wrong if it's not a cpu and/or VM or something else related problem.
EDIT: removed link.
Also, have you turned on logging to see what the running process says its JPE runtime settings are? It's doc'd in the 014 readme but basically you just put a [Redirection]Logging=1 line into the JPE runtime ini used by the app and you should get a %appname%_jauntePE.log file created in the app's exe's directory. This might give you some indication of what's going wrong if it's not a cpu and/or VM or something else related problem.
EDIT: removed link.
Last edited by redllar on Fri Aug 17, 2007 1:09 pm, edited 1 time in total.
- Zach Thibeau
- Posts: 251
- Joined: Tue Nov 28, 2006 3:26 pm
- Contact:
I think that means one of 3 things (or maybe some combination of them):EDIT: I tried the other dlls but then remembered I already have them on my system. when I entered the thing about the log I got nothing no .log creation at all
1) You're not running with a JPE 014 dll
2) You're not running with the JPE runtime ini that you think you are
3) The JPE runtime dlls are not getting injected into the process
You can verify 3 by using Process Explorer, selecting the app's process, Making sure View->Show Lower Pane is on and that View->Lower Pane View is set to DLLs. You should then be able to see whether or not the jauntePE.dll and madCHook.dll modules are in that process's DLL list.
If not then the injection failed for some reason. I don't think there's anything that I can do about that because the JPE exes haven't changed at all since 010, and they are the ones that inject the dlls into the launched app's process.
If the dlls are in that list then it means, I think, that either 1) or 2) is/are the cause.
Just to cover all bases on my end (that I can think of), I have taken my backup of the MSVC++ program files directory from my old machine, that the 011 build was made off of, and replaced the MSVC++ program files directory on the machine I've been using for the subsequent builds. And rebuilt all of the JPE executables using their current code base.
In comparing the results there's definitely something different between the 2 resulting jpe dlls, as their MD5 sum calcs come out different. The sizes, down to the byte, are exactly the same.
EDIT: removed link.
In comparing the results there's definitely something different between the 2 resulting jpe dlls, as their MD5 sum calcs come out different. The sizes, down to the byte, are exactly the same.
EDIT: removed link.
Last edited by redllar on Fri Aug 17, 2007 1:10 pm, edited 1 time in total.
- Zach Thibeau
- Posts: 251
- Joined: Tue Nov 28, 2006 3:26 pm
- Contact:
I'll give it a test and let you know the out come
EDIT: I just tested it out on my Desktop PC and still nothing (i still yet to test it on my laptop yet).
I'll post my pc OS specs and see if that helps any
Windows XP Pro Sp2 dotnetframework 1.1 and 2.0 (including 3)
and all the current security fixes in it too.
EDIT: I just tested it out on my Desktop PC and still nothing (i still yet to test it on my laptop yet).
I'll post my pc OS specs and see if that helps any
Windows XP Pro Sp2 dotnetframework 1.1 and 2.0 (including 3)
and all the current security fixes in it too.
redllar, I was able to do some tests tonight while using process explorer.
Using 0.1.4 in a VM with FileSystem turned on, jauntePE.dll would not get injected and madCHook.dll would. If I turn FileSystem off, both dll's get injected.
0.1.1 in a VM with FileSystem off or on both dll's were injected.
I used the non upx'd non optimized version of jauntePE.dll in all tests within the VM.
In regular XP I could get all versions (0.1.1, 0.1.4, upx'd & non) to work properly.
Using 0.1.4 in a VM with FileSystem turned on, jauntePE.dll would not get injected and madCHook.dll would. If I turn FileSystem off, both dll's get injected.
0.1.1 in a VM with FileSystem off or on both dll's were injected.
I used the non upx'd non optimized version of jauntePE.dll in all tests within the VM.
In regular XP I could get all versions (0.1.1, 0.1.4, upx'd & non) to work properly.
Thanks for that very useful info BAHeath.
I've uploaded one more version to try. I found a "Processor Pack" for VC++ that I had not installed that I think I had installed on my old box. It's only supposed to be for 3dNow, MMX, SSE, and SSE2 asm code but maybe that's the difference.
EDIT: removed link.
I've uploaded one more version to try. I found a "Processor Pack" for VC++ that I had not installed that I think I had installed on my old box. It's only supposed to be for 3dNow, MMX, SSE, and SSE2 asm code but maybe that's the difference.
EDIT: removed link.
Last edited by redllar on Fri Aug 17, 2007 1:07 pm, edited 1 time in total.