Klaus,
I spent a little bit more time on the issue and got some results.
First I created an image where I could perfectly repro the problem in a similar setup (Minlogon, netsh, EWF, RegFilter). Then I
debugged some system stacks to understand what's going on there when we change the IP with the RegFilter on and set to monitor the
keys I mentioned earlier. (I picked up EWF vs FBWF to simplify the debugging, having FBWF there won't change the picture)
I must admit the result was a bit surprising to me. Despite the fact thatthe behavior of the protected system with IP changed and
rebooted was quite strange - no sync in the results from ipconfig.exe tool and "netsh interface ip show address" command (the same
as you do with TCPIP GUI) - the source of the problem was not in the Tcpip stack or the registry keys picked up for the monitoring.
The tcpip driver (or a driver from the ipv4 stack) indeed reads the network adapters info into a buffer (link list) at
initialization off the registry Tcpip\Interfaces key. This, of course, includes the IP addresses. When you do "ipconfig /all" it
doesn't really go into the registry again but rather queries the driver for that info stored in the cache (buffer). While the netsh
commands are more "dynamic" and will scan and return the results from theregistry.
It is important to understand that RegFilter doesn't make the monitored keys transparent to the registry hives. The RegFilter rather
applies the new registry values - the values that were saved in the monitored keys on the protected system volume - to the image's
registry hives at the next boot time. Some time during the driver init itloads the ramdisk and reads the files on it. Then it sets
the actual values in registry to whatever values it reads from the file contents on ramdisk.
The tcpip driver will populate the internal stack buffer very early during the system boot. Looks like the initialization actually
happens before the RegFilter is loaded. This leads to the Tcpip structures populated with the old data but the registry info already
reflects the new data (laid out by the RegFilter) after the boot. So we end up with the IP addresses reported out of sync between
the ipconfig and the registry.
To summarize the above, the real problem there seems to be that the Regfilter and one of the drivers from Tcpip stack belong to the
same driver load group. Without the RegFilter enabled the IP would be changed properly (assuming the change can be flushed). This
fact is extremely easy to prove with the following simple experiment.
Forgot for a minute about the RegFilter. In fact remove the Tcpip relatedregistry paths from its MonitorKeys branch, commit EWF and
gracefully shutdown the image (now the RegFilter doesn't "unprotect" the tcpip keys). Load up the image SYSTEM hive offline (open it
with a regedit on a XP Pro machine). Go to the
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\{<Interface GUID>}] key and modify the value of the
"IPAddress" property there. Unload the hive and boot to the embedded image and verify that the address has changed and is in sync
between ipconfig and netsh results (or GUI). Note that you don't even have to mess with the
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\{<Interface GUID>}\Parameters\Tcpip] key as it will be automatically updated
during the boot (tcpip driver does that at the init time).
It is also easy to confirm with a hex editor that the ramdisk image from the runtime contains the new registry value (new IP
address) but the system registry hive has the old one (and this is ok when you think about the Regfilter architecture and design).
At this point I don't have a workaround for the Tcpip issue. Changing theloading order or adding extra dependencies for the Tcpip
driver to delay its load until RegFilter is loaded didn't help so there is probably some other drivers I'm missing from the picture
that may interfere with the Tcpip parameters in registry at the boot time.. If I figure it out, I'll post the results here.
Note that the Domain Secret Key and TSCAL issues were "easier" to fix forMicrosoft with the RegFilter approach since those keys are
only read late the boot process (by Winlogon and Terminal Services).
--
=========
Regards,
KM
Hi KM,
thanks again.
Yes the settings seams to be correct. If I search through the whole
regsitry after reboot,
I only can find the "new" IP-Address. There is no match for the "old"
one, but the ipconfig
connects to the "old" one while the TCPIP GUI displays the "new" one.
Is there perhaps another to monitor which saves the IP for example
binary, or as a word,...
Regards
Klaus
Either way, if you change the reg.value directly or change it with TCPIP GUI, it works well without the filter on.
Let me ask you this.
Did you make sure the GUIDs match for the keys you set for the RegistryFilter to monitor?
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters\Interfaces\{<Interface GUID>}],"IPAddress"
and
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\{<Interface GUID>}\Parameters\Tcpip],"IPAddress"
From your original post it is hard to get what exactly keys you are monitoring.
"Bingo500" <
[email protected]> wrote in messagenews:
[email protected]...
thanks for the response.
I do not change the IP-Address through the Registry I only use the
Property Editor in the Network settings, but I can see that the
Registry get´s changed after applying the settings.
Of course with disabled FBWF it´s working with the ipconfig and netsh.
Best regards
Klaus- Zitierten Text ausblenden -
- Zitierten Text anzeigen -
)