RD is not blocking a change to BootExecute value!!!

I use O&O Defrag Pro which allows boot-time defragging. To achieve this it adds "OODBS" as a new line in the BootExecute value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute

However, I had a system crash and now my system always does a boot-time defrag, even when I've disabled it from the GUI. To stop this happening I removed the "OODBS" line from the BootExecute value. When I rebooted, it never did a boot-time defrag, but when I checked the BootExecute value, it had been re-added.

To find out exactly what was re-adding it, I removed "OODBS" again and added BootExecute to RegDefend and set it to Block from Modifying both Reg Keys and Values.

I re-booted, expecting RD to block the change but when I checked the BootExecute value, the "OODBS" line had been added again. There was no mention of it in the RD log either.

I'm reasonably sure that the O&O Defrag Agent (a Windows XP service) is the culprit, but wanted to be sure.

How come RD is not catching this change and does this mean RD is flawed ?

 

Hmmm, everything is running fine for me here. Even when the Offline Defrag option is deactivated, O&O does not remove the "PDBoot.exe
autocheck autochk *
OODBS" entry from BootExecute in either:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager | BootExecute |

or

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager | BootExecute |


What may be of help in understanding this though is the fact that when Offline Defrag is activated for the first time, a service is created called OODBS (for which RegDefend would have alerted on - it did here anyway):

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\OODBS

and

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\OODBS


I think that this service may be the culprit for the "PDBoot.exe
autocheck autochk *
OODBS" entries being added again at boot time.

If you had allowed OODBS service entries to be created, then that would be my guess on why RegDefend is not alerting to the change. Jason however, may have more to input on this matter .


Regards,
Jade.

EDIT - Have you tried uninstalling and then re-installing O&O?

 

Ah, I didn't realise the OODBS entry in BootExecute was only created once the first time offline defrag is activated. It must have been something to do with O&O Defrag, whiich didn't seem to take any notice when I disabled offline defrag and deleted all jobs (which I was told to do by O&O Tech support).

However, I'm still surprised that RegDefend did not stop the OODBS entry being re-added to BootExecute (after I had manually deleted them), even if I've allowed the OODBS service entries to be created. Surely allowing a new Service entries to be added should not then give those services carte blanche to add/delete anything they want from the registry.

I would appreciate Jason's comments on this apparent hole in RD.

Only problem is that I've now re-installled XP since I was having issues with other software and couldn't wait since it was on my main machine. I have ideas on how to possibly re-create this scenario though.

EDIT: I also tried uninstalling and re-installing O&O Defrag but the same problem remained.

 

Hi,

this "hole" is something which every Windows security program has to live with. When Windows is starting up it isn't a reliable state to protect the system, due to the way device drivers are loaded, plus the usermode aspects of these drivers.

If you let some program on your computer install itself as a driver or service (which RD alerts on for the permanent services/drivers) then you must be willing to accept they will be able to change some items due to race conditions on startup.

 

Thanks for the explanation Jason. Is there no way to make RD start up first (or as early as possible), thereby giving max protection possible ?

 

Jason, I'm coming back to this topic since I had a similar problem when updating Outpost PFW to a new version. The registry entry mentioned in https://www.wilderssecurity.com/showpost.php?p=472244&postcount=96 was changed after a reboot during the installation process though it was protected by RD. I assume the reason is the "race conditions on startup" as you put it.

However, I don't understand one issue: RD is loaded as a kernel mode driver. According to http://research.pestpatrol.com/WhitePapers/AutoStartingPests.asp all applications are loaded during a LATER stage of the boot process with the BootExecute key in the first place. If this is true - how can it be that this key (or the one mentioned above) is changed before RD is loaded? And (since you didn't answer Defenestration's question) is it really impossible to prevent this?

 

The full initialization of RegDefend would usually occur a few seconds after you have logged in. Only services/kernel mode drivers have a chance to access the registry in this period of time.

From the time RegDefend is started, it is completely protecting the registry keys in question until the machine is turned off. So the only vector is early during the boot process.

Another common error is to not have a "correctly defined" rule, so you would have to rule this out first. Create the rule you wish and alert on every event, then load up regedit and try to see if regedit's behaviour is affected. If it isn't then the rule for some reason or another isn't working.

 

I posted a suggestion for an improvement to RegDefend which would allow it to detect EVERY change made to the registry, even if this change occurs while RD is not up and running.

While it could not prevent the change, it would allow RD to alert the user to the change, and offer the chance of restoring the original data.

Would you consider adding support for this Jason ?

 

I have seen that request, and also some of my testers have asked for something similar. It is something which interests me, but it isn't that high on the priority list due to the fact that RD would stop malicious driver/service installs, and hence this issue only revolves around "trusted" installed software. RD is an active component, so I am interested in getting it to start earlier than most things to remove these sort of issues relating to "trusted" software.

Eventually though, something like you asked for could be added (I'm not saying no ).

 

Good to know you're listening!

 

Jason, thanks for your reply which clarifies some things. But I'm still irritated. On http://kareldjag.over-blog.com/article-382176.html I read the following remarks about ProcessGuard (you are familiar with this software, aren't you ...): "takes too much time to load and to initialize :then the protection is limited during the boot (the PG's driver/service is just an autostart, not a system start or better: a boot start one) and an application or a driver/service can start and load without control".

Okay, it's about ProcessGuard but I thought the same problem (is it really one?) might apply to RD. I simply don't understand the words in red. What's the difference between an autostart driver/service and a boot start or system driver/service, and to which one belongs RD?

 

Everything is layers... generally only hardware starts as a BOOT driver. There would be no registry access to a malicious fake hardware driver until file systems are initialized anyway, including file locks. This happens way later. Registry hives are loaded later still, then you login and more stuff happens. Sure you can pretend you're an attacker... run something before this but how did it get there in the first place ie real attacks ? who knows

 

Depends how you look at it. No process can start before processguard or regdefend, if it hasn't been installed in the first place. So the objectives of PG and RD are to prevent the initial installation (in different ways). Both products are predicated on the proposition that they are being installed on a clean machine and only trusted programs/services/drivers are permitted to install thereafter. It is possible that the user is 'tricked". Therefore "layers of protection" (either within a single product or multiple products), may still be a preferred approach.

Rich

 

Rich, I absolutely agree with you. But this facts notwithstanding I think you go along with me that it's desirable that PG and RD start as soon as possible during the boot process. And in this context I've never heard of a differentiation between "autostart" and "boot" drivers/services. This confuses me.

I also agree on that. It's an approach I also follow by combining RD, PG, KAV, Outpost, router and - last but not least - my brain. And not to forget: I always surf under a restricted user account. It always astonishes me that even many of all these security aware or even "paranoid" participants here on Wilders Security Forums only use their administrator accounts thus giving any malware full rights over their system.