JaunePE 0.1.4 Bugs

[Local]

Thibeaz are you using the exact same JPE on your parents PC or did you leave a copy on there?

Could the one that doesn't work be corrupted by something?

Just realised too, I'm still using version 113 does this work for you on those machines?

[crownixx]

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

quite similar to this problem but i try to explain more detail

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]

Well 0.1.1 works fine for me on all my computers it's just from 0.1.2 to 0.1.4 that hasn't (Just tested 0.1.2 and same result as 0.1.4) but with my JauntePE exe I have no jpe icons in the top bar or the Color around the app on my computer (It launches fine though :S)

[redllar]

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.

[Zach Thibeau]

Thank You I'll test out the dll asap

[BAHeath]

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.

[Zach Thibeau]

Just a little testing done with the new dll it still doesn't fix my problem. so for now I'll use the package

[redllar]

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.

[Zach Thibeau]

OK I'll test it later when I get home
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

[redllar]

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

I think that means one of 3 things (or maybe some combination of them):

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.

[redllar]

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.

[Zach Thibeau]

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.

[redllar]

Well, I've done everything I can think of doing. What was the result of checking if the dlls got injected?

[BAHeath]

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.

[redllar]

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.