How to figure out the right modules?

[crownixx]

redllar says from the "firewrath FAQ documentation"

The 3 broad categories of modules are app-specific, app-generic, and system supplied.

in the "best practice"

2) Whether you use file system redirection or not, it looks like using module exclusion in combination with the other types of exclusion provides the best performance, as JPE tests for module exclusion first, so that's the point where the most code is skipped.

in the JPE runtimes provided

;
; Exclude all module access from redirection except for the app's modules.
; This makes shell access run close to normal.
;

[ModuleExclude]
1=*

Just more confirmation,
1. So we just need to Include app-specific modules?

2. Can the application still access the app-generic, and system supplied modules when they are excluded? because they need those to run properly

3. Is it right using "Discover Registry Usage" from JauntePE v0.2.0 to get the modules for the application?

I also use "Linos Dependency check"

This program will help identify all the OCX or DLL support files required to operate any Windows 32 bit executable (EXE) file. Very handy for beginner programers who wish to confirm they are supplying all the necessary files within their install program.

download 2.7mb

Code: Select all

http://www.linos-software.com/FileDownload/Depend_1_0.EXE

[redllar]

1. So we just need to Include app-specific modules?

Yes, if you exclude all modules first. This approach is similar to what you would do if you had the app's source code and modified it to use ini files instead of the registry and to store the rest of its data only within its own directory.

The downside to this approach is that it is not as stealthy as excluding everything since it will allow registry and/or file system modifications that are made only within the system modules. But that's what the additional registry and file system redirecting entries are for.

A good example of the non-stealthiness of this approach is if the app uses the built-in Windows internet capabilities to get and send files. You'll see the inet cache, cookies, etc., get changed unless the required settings are used by the app, which is unlikely. The app is still portable - you just don't carry around the inet stuff with it.

With the 020's plugin capability, preventing inet storage could be done via a simple plugin that tweaked any of the inet api settings to make sure that the inet storage wasn't used. This again, is probably the approach you would take if you had the source code. Don't redirect it, just prevent it from being stored entirely.

2. Can the application still access the app-generic, and system supplied modules when they are excluded? because they need those to run properly

Yes. Keep in mind that the module lists are only for registry and file system modification redirection, not module usage redirection. The code in all of the modules still runs as normal.

3. Is it right using "Discover Registry Usage" from JauntePE v0.2.0 to get the modules for the application?

Sure, that's a good way, imho, to find the modules an app uses. You can also use a dependency checker, but ultimately you do need to run the app to make sure that it doesn't load up any additional modules at runtime. But normally all you really need to be concerned about are the module files that come with the app.

And just fyi, all versions of JPE have that capability, not just 020. 020 will have expanded abilities though, as it will include file system usage in its discovery wizard.

[crownixx]

yes, i like the 020 abilities. hope there will be the same in the 012 version..
thanks for the response

[crownixx]

from here

The only thing I see wrong in the ini right now is the use of %#% within the ModuleInclude list. Those variables aren't needed there. Just include the filename.ext. The modules lists should never have path info in them.

EDIT: I also don't think that urlmon.dll, wininet.dll, msvcrt.dll, or advapi32.dll need to be in the module include list. msvcrt is the VC++ runtime and AFAIK it uses the other system dlls to do its registry and file system work. advapi32 actually contains the registry api so including it doesn't make much sense. And the other 2 dlls are for internet access. If you include them you'll wind up with the inet history, cookies, and cache data. Portable-wise you don't need to carry that stuff around. I guess maybe stealth-wise it makes sense to, but they're liable to be relatively big and slow things down if you're running off of a flash drive.

and here

2 -- It does not remember custom toolbar layouts, but always returns to default settings upon re-opening. (this might be a quirk of the app itself, I've never used it on a "normal" install, so can't be sure.)

The app probably isn't storing the toolbar info into the registry itself but is using one of the system dlls to do it. I think it's comctl32.dll so you might try adding that to the ModuleInclude list. You might also try JPE's Discovery mode since it will tell you what modules are doing what to what registry keys. Meanwhile I'll download the app to make sure and then get back to you.