Basically, what EWF does is redirecting any writes or changes in the protected partition (system partition for me) to RAM. And when I restart, as RAM is cleared, the protected partition will be reverted back like the original state when the EWF is activated.
That's why, JauntePE is perfect for systems that use EWF as JPE prevents any writes to the system. This would be very good for XP on USB.
If somehow you are interested in EWF I would be happy to explain more to you, I have some tricks up my sleeve. Like, I actually set my shell to a script (in non-protected partition) that I create to launch applications, so I can set what application or shell to launch on startup.
Okay. Thanks. I'll PM you if I need more info.
Regarding Registry redirection, I believe this key is not important "...\CurrentVersion\Explorer\MountPoints2\E". But, if it is in the JPE-reg, it means that the application tries to make change to that key.
Well, yes and no. Technically that is a key that the explorer shell dll's modify while running within the app's process space, meaning that it was the app trying to make the change but it wasn't one of the app's modules, it was a system module. Those reg entries get updated by the shell dlls every time you use one of their file system "browsing" dialog boxes like the standard Open File and Save As ones.
You should probably take that key out of the .reg because it may potentially cause problems if you try to run the app with that .reg on another system. It being in the .reg means that somewhere along the line of running the app, either the shell dlls registry accesses were redirected completely or the default set of registry exclusions that comes with JPE were not in use, but some subset were. There's probably more in there that shouldn't be. Really, under normal conditions you don't want anything from explorer in your .reg.
If I put the key to [RegistryExclude], there will be write to registry, right?
If the shell module(s) that write to that key aren't included in redirection. And assuming you're not using the .reg across multiple apps.
On some keys, like directx, DirectDraw, ActiveMovie I deny their registry permission to prevent write to system registry and till now my apps work okay without problem.
So my question is, would it be better to put it in [RegistryIgnore]? What do you think about the performance?
As a general rule I'd say that the explorer keys should not be redirected as they are integral to file system browsing. Ditto for the DirectX keys for the same graphics-oriented reason. That's why I had them in the default JPE runtime ini. I don't think that preventing them from being modified in the system reg makes the app more stealthy and all it does is clutter up your portable .reg with potentially portablizing-harmful values. The system already knows you've popped in a removal drive for instance. The system already knows that you're running a DirectX app. There are things "beneath" the level that JPE operates at that go on that you just can't affect unless you write a kernel mode driver. But ultimately, as long as you understand what list is used for what purpose, it's up to you.
Performance-wise, the more stuff you redirect the more work there's to do to see if that "thing" has or has not already been redirected. And the ignore list is only used after it's already been determined that the thing does not exist in the portablized data. So the only time savings for registry keys would be the access to the system registry, which would be an almost unmeasurable value since the system's registry is highly optimized. The overall best performance would be to make sure that the shell dlls are completely excluded from any redirection efforts.
EDIT: Maybe option to put redirected file system in RAM, would improve FileSystem redirection's performance. Obviously, this option would be used for application that redirect small size filesystem.
Or, user could put the maximum size, example: 3 Mb. So, if the filesystem that would be changed is bigger than 3 Mb, it will not be put in RAM, just would be redirected normally.
I've already looked into this and there may be a future option that will significantly help with file system redirection performance. It won't be an in-memory file system; to me that's a last resort option as it involves duplicating what the OS already does for you. It will be more like what I'm doing with the registry accesses. Just enough to find out quickly, using an in-memory list, whether or not a directory or file already exists as a portablized directory or file, as that's where most of the time is being spent right now when a request for a potentially redirected file system object is being made.
One more question, using JauntePE would make the application to be 100% stealth, right? I didn't check yet as I deny reg permission on unneeded keys & perhaps there are entries that are not from the application but is written when certain condition of system is met by running that application.
It depends upon your definition of stealth. It is absolutely impossible for the system to not know certain things. Even if JPE was running in kernel mode and hooked into every running process there would still be registry and file system modifications going on that it could not prevent. The only way to do that would be to write drivers that completely replaced those sub-systems of the OS. And I don't think it's even possible to write a driver to replace the registry.
JPE will capture and redirect a lot of stuff if you completely blank out all of the JPE runtime lists, but not everything. There are also certain modifications that it can't redirect at all because they happen before the api-hooking takes place. There are ways to prevent this but it's not worth the time right now as the app's doing this are minimal and don't really do enough to hurt portability.