79 replies to this topic

[MedEvil]

Seems we had to many off topic posts, that nobody remembers the ones further down the line.

BTW: What does "RegReMapper Explorer.exe" mean?

RegReMapper is a placeholder for the RegistryReMapper.exe which would do the Registry remapping. ie. The code you were writing, Peter.

But I have some concerns:

During the time the 'MedEvil' keys are mapped, every write into registry is written to 'MedEvil'.

As you've already found out here:

Bad news: The redirection is only valid for the current process.

this is not the case since the mappings arn't global but are local for just one process, they can not even be inherited, which is actually our problem.

That means: Redirection does not remain when the redirecting program finishes.

This problems has already been addressed by me, with 2 posts.
- My first solution was, to use memory injection to use RegOverridePredefKey with more than just the current process.
Idea was actually posted here: http://www.codeproje...2k/regsvrex.asp

but as posted her: http://www.boot-land...?...ost&p=18326
I have no experience with memory injections and have no clue if it can be applied to our problem in an easy way.

- Second idea was to use rather hooks than memory injections. http://www.boot-land...?...ost&p=18345
I came up with the idea, when i detected a flaw in our initial idea.

Remapping the registry will be good enough to create an automatic script builder. Because all that would be required, is installing and seting up. Both processes, that do not need global access.

But if we wanna run apps directly from an USB stick, we will need a little different behaviour.
We want our apps to take advantage of the guest OS.
So when i start a file manager from my USb stick, i want it to use the file associations that i saved on my stick, but for all the associations that i have not set up, i would want it to use the assotiazions of the guest OS!

To achieve this, my idea was to use hooks. Our hooked dll would change the behaviour of openKey, readKey, writeKey, closeKey, usw in the following way:
- writeKey - from 'our' apps always to 'our' registry. (In my example, that was the MedEvil key.)
- readKey - first in 'our' registry, if it isn't found there, check the 'real' Registry, if nothing there too - Failure.
- openKey - same as readKey
- closeKey - same as readKey

The one problem still unsolved is, how the hooked dll can tell our apps, that run from the USB-stick, from those running from system.

[pscEx]

this is not the case since the mappings arn't global but are local for just one process, they can not even be inherited, which is actually our problem.
This problems has already been addressed by me, with 2 posts.
- My first solution was, to use memory injection to use RegOverridePredefKey with more than just the current process.
Idea was actually posted here: http://www.codeproje...2k/regsvrex.asp

but as posted her: http://www.boot-land...?...ost&p=18326
I have no experience with memory injections and have no clue if it can be applied to our problem in an easy way.

- Second idea was to use rather hooks than memory injections. http://www.boot-land...?...ost&p=18345
I came up with the idea, when i detected a flaw in our initial idea.

I remember that during my first researches for 'RegOverridePredefKey' I found a good explained method to inject the 'redirectRegistry' into an InMemory EXE (the install program!)

I hope I'll find it again.

Peter

[MedEvil]

A user called John has just refered JauntPE and it might actually help to complete this missing step.
http://www.portablef...opic.php?t=1528
http://www.portablef...wforum.php?f=10
http://www.portablef...opic.php?t=1824

In the meanwhile, also found another program (not sure how good)

http://portableapps....registry_rapper

A few nice finds. I'm just about checking them.

Registry Rapper is unfortunazely not useful for us, as it is a template that has to be coded/configured for the specific application it is to be used with.
Pretty much like our scripts. They can do a lot, if properly written, but one can't just switch the attachments and use it for another app. They are specific and work just with the app they are intended for.

Besides Registry Rapper is working rather stupid, as in the case of a crash, the wrong setting will remain in the registry. Maybe RR is smart enough to fix this when restarted after a crash, but is RR is destroyed by something like a virus the guest OS user is screwed.

JPE on the other hand, seems to be pretty close to what we attempt.

* Firewrath: JPE and Sandboxie work differently.
Sandboxie installs and uses a service for its redirection, JPE does this by injecting a dll into the program itself.

JPE can be customized to where you want your registry info/files redirected to and all kept in one folder with one registry*, or separated by app.
(*i Think, ive never done this after the separate app registry option was added, as its aLot faster.)

Really its easyer if you just download the zip and check the readme files, they explain how it all works. ^-^

Will see if i can find some better descriptions of its workings..

[MedEvil]

I remember that during my first researches for 'RegOverridePredefKey' I found a good explained method to inject the 'redirectRegistry' into an InMemory EXE (the install program!)

I hope I'll find it again.

Peter

I think you're talking about this one: http://www.codeproje...2k/regsvrex.asp

[pscEx]

I think you're talking about this one: http://www.codeproje...2k/regsvrex.asp

That was the first one I looked into.
But deep in my mind there is something with 'Delphi'

Peter

[MedEvil]

But deep in my mind there is something with 'Delphi'

[MedEvil]

JaunterPE looks very good.
Unfortunately i can't find anything specific, on the claims that it is not working 100%.
Found also no detailed explaination of inner workings or source code.

[Brito]

It's coded in AutoIt based on the comments of the respective forum members on portableapps.com when trying to motivate the author to move onto C.

Peter, you mentioned delphi?

http://www.boot-land...?...ost&p=18249

I *think* this was the only reference on delphi code since we've started this discussion thread.

[MedEvil]

It's coded in AutoIt based on the comments of the respective forum members on portableapps.com when trying to motivate the author to move onto C.

JauntePE is written in Autoit? You're kidding right?

[Brito]

I'm not sure - but would strange since some people even use simpler batch files for registry and file redirection tasks..

[MedEvil]

I'm not sure - but would strange since some people even use simpler batch files for registry and file redirection tasks..

Well, in this case.
Where are our Autoit gurus? Can an Autoit exe/dll, be decompiled?

[pscEx]

Well, in this case.
Where are our Autoit gurus? Can an Autoit exe/dll, be decompiled?

For decompile three options are possible, set by the author when building the exe.

• Allow generally
• Allow with password
• Disallow

Peter

[pscEx]

Now it finally seems to be proofed that registry changes by an installation cannor be captured by RegOverridePredefKey.

(see http://www.ddj.com/d...dows/184416328)

The fact that RegOverridePredefKey() affects both reads and writes to the registry makes it difficult to use in some circumstances. As I’ve mentioned, if your registration code calls COM components, you may need to provide their registry entries in your substitute key.

Peter

[Brito]

It only mentions that some COM entries will call other COM entries - but can't the default COM entries found on a fresh XP install be made available on this redirected registry path?

When a program is installing on a new machine it will only rely on a few COM/ActiveX components - most likely some related IE (first one to come in memory) and such that already come bundled inside Windows.

Microsoft apps may rely on this - but would it also be a pattern for all other programs that need to register their OCX's?

[pscEx]

It only mentions that some COM entries will call other COM entries - but can't the default COM entries found on a fresh XP install be made available on this redirected registry path?

When a program is installing on a new machine it will only rely on a few COM/ActiveX components - most likely some related IE (first one to come in memory) and such that already come bundled inside Windows.

Microsoft apps may rely on this - but would it also be a pattern for all other programs that need to register their OCX's?

In the article speaking about COM ('A COM Registration Spy')!

But in a usual installation program all registry reads and writes are redirected.
If there is e.g. a query for an environment variable (Session Manager), the query is redirected to e.g. HKLM\MedEvil\...\Session Manager.

And this place is empty!

Peter

[Brito]

Maybe a crazy idea, but how about..

- Copy the target hkey to disk (as original.reg file for example)
- Redirected reg read/Write to new location of target hkey
- Restore modified original.reg file to write data on the new redirected location

- Register OCX/DLL files as already done

- Compare result and export changes to output.reg

- Write output on target windows hives


--------------------------------------------------------------

This is the long way around a problem that would be simple if there was an Ex version of this function that only filtered the write operations - even thought I understand they must have thought that newly written keys would also need to be read while processing the OCX - but there should me a better method as it is currently used by FBWF.

----------

It won't solve the write operations on other keys inside Hkeys which are not being filtered (it's only a single hkey at time, right? )

But wouldn't we be able to compare and export differences as already used by regshot?

----------

Also worth some feedback on Vista enabled machines: http://forums.micros.......48&SiteID=1

[MedEvil]

In the article speaking about COM ('A COM Registration Spy')!

But in a usual installation program all registry reads and writes are redirected.
If there is e.g. a query for an environment variable (Session Manager), the query is redirected to e.g. HKLM\MedEvil\...\Session Manager.

And this place is empty!

Peter

I don't know how many of those 'problem points' you've found, but wouldn't it be easiest to copy/map the needed information beforehand into the 'MedEvil key'?



PS:

If there is e.g. a query for an environment variable (Session Manager), the query is redirected to e.g. HKLM\MedEvil\...\Session Manager.

Environment variables shouldn't be a problem. It isn't the registry that get's checked for them, else changing the Environment, like in my batch files, wouldn't work.

[Brito]

..
Environment variables shouldn't be a problem. It isn't the registry that get's checked for them, else changing the Environment, like in my batch files, wouldn't work.

hadn't remembered that detail, good point..

[pscEx]

I don't know how many of those 'problem points' you've found, but wouldn't it be easiest to copy/map the needed information beforehand into the 'MedEvil key'?



PS:

Environment variables shouldn't be a problem. It isn't the registry that get's checked for them, else changing the Environment, like in my batch files, wouldn't work.

I wrote 'E.g.'
There are thousands of installation programs, and following Murphy's Law, most of them look ???
I think it is not efficient to collect possible examples until you agree.

There is another more important issue. As Nuno already recognized, there is only one registry redirection at a time possible.

So, to catch all registry changes caused by a setup, you must run the setup program at least three times.

Maybe it is possible to do it programmatically, but I do not want to design or code such a crazy program.

Peter

[Brito]

It's not your fault, this could have been improved all the way as expected by MS ever since 2000 - but we do need a solution that even looking ugly and slow at least gets the job done.

And how long would it take anyways?

An OCX file registers itself in less than an eye blink on my machine whose hardware specs are quite average.

Even if repeating the same slug method took 3~90 seconds, wouldn't the end result still be worth the wait?

[MedEvil]

I wrote 'E.g.'
There are thousands of installation programs, and following Murphy's Law, most of them look ???
I think it is not efficient to collect possible examples until you agree.

I guess we will have to do some tests on this topic, have never cared about how installers work or not.
Just assumed that they will check if the file/registry key they wanna create is already there, if not just go ahead and if yes eighter do nothing or ask.

There is another more important issue. As Nuno already recognized, there is only one registry redirection at a time possible.

Why can you only do one redirection at any time? I didn't see anything that would prohibit doing several.



btw, Did you get the memory injection to work?

[Brito]

Hmm.. My head is slow today, guess I'll just go home and get a few hours of rest before coming back online..

If MedEvil is correct, then no more obstacles are posed since we can indeed save/restore/filter as needed without installing anything on the real HKEYS.

Good luck! (crossing my fingers here)

[pscEx]

Why can you only do one redirection at any time? I didn't see anything that would prohibit doing several.

I cannot tell you why. And Bill G. does not worry about whether you see anything that would ...

It is just a fact I learned during my trials to implement the 'DllInstall'.
It caused me to code:

Result := passReg(HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, hTarget, dllPath, DLLs, 'WB-Temp', 'WB-Temp', hiveKey + '\Classes');  if not Result then exit;  Result := passReg(HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, hTarget, dllPath, DLLs, 'WB-Temp', 'WB-Temp\Software', hiveKey);  if not Result then exit;  Result := passReg(HKEY_CURRENT_USER, HKEY_CLASSES_ROOT, hTarget, dllPath, DLLs, 'WB-Temp', 'WB-Temp\Software', hiveKey);  if not Result then exit;  Result := passReg(HKEY_USERS, HKEY_CURRENT_USER, hTarget, dllPath, DLLs, 'WB-Temp', 'WB-Temp\.Default\Software', hiveKey);

Did you get the memory injection to work?

I did not try yet, of course.
It does not make any sence as long as the 'basic' (see above) does not work as needed.

Peter

BTW: if you are interested in the results of the above code, here it is for browseui.dll:
 browseui.txt   242.87KB   416 downloads

[MedEvil]

I cannot tell you why. And Bill G. does not worry about whether you see anything that would ...

Ganz schön schnippisch heute!
What i meant, is one mapping overwriting another, or what? Frome the code in one of the links it seemed like they would map 2 keys simultaneously.

I did not try yet, of course.
It does not make any sence as long as the 'basic' (see above) does not work as needed.

Good thinking!

BTW: if you are interested in the results of the above code, here it is for browseui.dll:
 browseui.txt   242.87KB   416 downloads

Sure am.

[pscEx]

Ganz schön schnippisch heute!
What i meant, is one mapping overwriting another, or what? Frome the code in one of the links it seemed like they would map 2 keys simultaneously.

Mir reicht's auch langsam
In DllInstall I first tried:

Map HKCR to HKCU\WB-Test
Map HKLM to HKCU\WB-Temp

Whatever was first, the corresponding target was empty.

I think that is the proof!

Peter

BTW: If I do not answer anymore today: That is not because I give up. I'm simply invited tonight.