Hi,
I got a driver which protects my software registry entries using SSDT hooking, it hooks ZwOpenKey and ZwCreateKey and it protects agains changes/deletes to keys and values by changing the permissions to read only on the protected keys.
I found out that on Windows 7 32bit, values aren’t protected, it seems that somehow the application that access the registry gets a handle to the key from another function which I can’t locate and thus it’s able to delete values.
I know there’s a registry filter workframe but changing my whole driver at this point is not an option. Any ideas on the unknown registry function?
Thanks,
Barak
Changing the driver is the only option. First you can’t hook on 64-bit,
second your hooks are probably incorrect since almost every
implementation out there is broken. Finally, there are a lot of
registry calls, and you haven’t hit all you need, for instance ZwSaveKey
and its friends can bypass most of what you are doing.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@komodia.com” wrote in message
news:xxxxx@ntdev:
> Hi,
>
> I got a driver which protects my software registry entries using SSDT hooking, it hooks ZwOpenKey and ZwCreateKey and it protects agains changes/deletes to keys and values by changing the permissions to read only on the protected keys.
>
> I found out that on Windows 7 32bit, values aren’t protected, it seems that somehow the application that access the registry gets a handle to the key from another function which I can’t locate and thus it’s able to delete values.
>
> I know there’s a registry filter workframe but changing my whole driver at this point is not an option. Any ideas on the unknown registry function?
>
> Thanks,
> Barak
I just can’t understand why the people try to do this stuff all the time. What’s the point of this exercise? Why these registry entries are so valuable?
> What’s the point of this exercise? Why these registry entries are so valuable?
To be honest, I just don’t see any legitimate reasons for this. However, if you want to develop, say, some malware that cannot be uninstalled by the Admin user without the clean OS reinstall while trying to appear invisible to the end user, the whole thing becomes perfectly understandable…
Anton Bassov
Don,
Thanks for your reply, I don’t mind about ZwSaveKey, the problem is that it works on XP but not on Win7 and I’m trying to find the function that gives the application the handle to the key without going through ZwOpenKey or ZwCreateKey. I already have a 64bit driver for registry but doing this radical change will require a massive QA and I prefer to just solve this issue (I’m talking about RegEdit, nothing fancy)
Alex and Anton, there are legitimate reasons for doing this, like parental control applications which wants to prevents the child from removing components of the software, specialy in schools which deals with teen agers.
Barak
> there are legitimate reasons for doing this, like parental control applications which wants to prevents
the child from removing components of the software, specialy in schools which deals with teen agers.
Oh, really…
In such case all that has to be done is setting up a guest-level account for the target user - go and say this BS to someone who is “not-so-well-versed in computers”, so to say…
I 'm trying to find the function that gives the application the handle to the key without going
through ZwOpenKey or ZwCreateKey.
Wow!!! It gets really exciting. You are not looking for a function that gives you a file handle without going through ZwCreateFile() and friends, by any chance…
Anton Bassov
xxxxx@komodia.com wrote:
I got a driver which protects my software registry entries using SSDT hooking, it hooks ZwOpenKey and ZwCreateKey and it protects agains changes/deletes to keys and values by changing the permissions to read only on the protected keys.
Perhaps you don’t realize how hopeless this is. Whatever you do can be
undone. Just use registry permissions. Make the keys read-only to
everyone, then change the owner to some protected system account.
That’s exactly what the registry security model was designed for, and it
is every bit as effective as the very delicate driver you are now using,
which will fail in 64-bit anyway. It will foil the casual observer, but
will succumb to a pointed attack, just as your waste-of-resources driver
will.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Anton,
Let me rephrase myself, regedit on windows7 gets a handle to keys without going via my ZwRegKey or ZwOpenKey.
I understand you are a good Driver developer, but obviously you don’t have experience in the parental control market. Telling a user to create a guest account means you will not sell your software. Everyone loves admin, yes it’s wrong but that’s the market and I’m not going to argue wit the market.
Here’s my site: http://www.komodia.com you also have my direct phone number and office address inside. If you want to help, then great, otherwise please let others help without implying what I’m not.
Barak
Have you tried using Sysinternals Process Monitor to see what the system
is doing?
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@komodia.com” wrote in message
news:xxxxx@ntdev:
> Anton,
>
> Let me rephrase myself, regedit on windows7 gets a handle to keys without going via my ZwRegKey or ZwOpenKey.
>
> I understand you are a good Driver developer, but obviously you don’t have experience in the parental control market. Telling a user to create a guest account means you will not sell your software. Everyone loves admin, yes it’s wrong but that’s the market and I’m not going to argue wit the market.
>
> Here’s my site: http://www.komodia.com you also have my direct phone number and office address inside. If you want to help, then great, otherwise please let others help without implying what I’m not.
>
> Barak
Don,
Thanks - that’s a good suggestion.
Barak
… it was said …
I understand you are a good Driver developer, but obviously you don’t have experience in the parental control market. Telling a user to create a guest account means you will not sell your software. Everyone loves admin, yes it’s wrong but that’s the market and I’m not going to argue wit the market.
…
Then, unfortunately, IMHO you have simply chosen the incorrect market and business model.
Seriously.
Here’s why: suppose that you develop some interesting way to do what you propose … this technology would be a boon to the malware and rootkit writers out there that would instantly disassemble your interesting way and insert it into their product – there are team of people doing just this every day.
This would also be of interest to the MS folks, who have a somewhat vested interest in preventing malware and rootkits from succeeding and, by the way, have several buildings full of people charged with doing just that – and by using Windows Defender and the Updates, a mechanism to combat these new rootkits and malware. This process also happens each and every day.
The MS folks would quickly issue an update to fill this hole that your product has exploited and *poof* the next time your end user gets an update (which they likely do automatically, as it comes in with the new virus definitions) your application stops working. You can complain, you can grumble, you can burn up your MSDN ticket tokens but fundamentally to MS *you* are a guest in *their* playground and they can (and will) change the rules to ensure that malware and rootkits are a thing of the past … even if that means your product is negatively impacted. This cycle, like the others, happens each and every day.
'sorry 'bout that … cheers!
Whether we like the product or the approach (hooking) there is a market
for this stuff. As far as the rootkit worry there is malware doing this
type of stuff already, so I would not worry about the OP creating new
problems. Personally, I would use other approaches on a system I own,
but there are those who feel the need for this, just like there are
those who want to disable some USB devices, or make some files protected
etc.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“choward@ix.netcom.com” wrote in message
news:xxxxx@ntdev:
> … it was said …
> I understand you are a good Driver developer, but obviously you don’t have experience in the parental control market. Telling a user to create a guest account means you will not sell your software. Everyone loves admin, yes it’s wrong but that’s the market and I’m not going to argue wit the market.
> …
>
> Then, unfortunately, IMHO you have simply chosen the incorrect market and business model.
>
> Seriously.
>
> Here’s why: suppose that you develop some interesting way to do what you propose … this technology would be a boon to the malware and rootkit writers out there that would instantly disassemble your interesting way and insert it into their product – there are team of people doing just this every day.
>
> This would also be of interest to the MS folks, who have a somewhat vested interest in preventing malware and rootkits from succeeding and, by the way, have several buildings full of people charged with doing just that – and by using Windows Defender and the Updates, a mechanism to combat these new rootkits and malware. This process also happens each and every day.
>
> The MS folks would quickly issue an update to fill this hole that your product has exploited and poof the next time your end user gets an update (which they likely do automatically, as it comes in with the new virus definitions) your application stops working. You can complain, you can grumble, you can burn up your MSDN ticket tokens but fundamentally to MS you are a guest in their playground and they can (and will) change the rules to ensure that malware and rootkits are a thing of the past … even if that means your product is negatively impacted. This cycle, like the others, happens each and every day.
>
> 'sorry 'bout that … cheers!
In win7, the write protected registry keys probably are virtualized and are placed somewhere under HKCU. Look for them there.
– pa
> I understand you are a good Driver developer, but obviously you don’t have experience in the parental
control market.
Actually, in my previous lifetime as a Windows driver writer I was specialized in security and doing
“not-so-conventional” things that would not even get into your head, but never mind…
Telling a user to create a guest account means you will not sell your software.
…and telling a user that the target OS has to be of 32-bit version (because 64-bit one would not allow hooking) is going just to boost sales. Being branded as a malware by all AV software in existence, plus possible interops with the other third-party solution on the 32-bit OS version is going to boost sales even further…
In any case, let’s say I want to uninstall your product. Judging from what you have said in so far I will be unable to do it. How should we proceed???
Anton Bassov
64-bit OS is most probably NT6, not XP. On NT6 hooking is not needed, because it has proper filtering API, bingo.
–pa
> On NT6 hooking is not needed, because it has proper filtering API, bingo.
IIRC, registry callbacks got introduced into back in the days of XP, and NT6 introduced the possibility to block executable section creation via a filtering callback…
Anton Bassov
On 10/14/2010 1:29 PM, xxxxx@hotmail.com wrote:
> On NT6 hooking is not needed, because it has proper filtering API, bingo.
IIRC, registry callbacks got introduced into back in the days of XP, and NT6 introduced the possibility to block executable section creation via a filtering callback…
You recall correctly but the functionality provided in the XP registry
filtering callbacks was limited to observation and not modification.
Hence you could, for example, see a given key/value was being accessed
but could not change it or the data returned. As well it was very prone
to crashing in load situations from my experience.
Hence if you need to filter the registry prior to Vista, excluding XP
x64, you need to patch the SSDT.
Pete
Anton Bassov
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Hi,
The thread has turned into a different direction so it’s important for me to clarify some points:
-
I already have a 64bit driver, but it makes more sense to fix the problem then to port and modify an existing product.
-
My driver isn’t recognised by any AV because I don’t sell for malware writers. It’s easier to go to rootkit.com and grab a source code then to purchase the SDK from me.
-
The driver is not 100% nor is it intended to. You can also use a live CD to remove it and I’m sure driver professional will be able to bypass it, my target market is not professional driver writers.
-
I already have about one million installations of my software, so I’m doing something right in terms of business model.
Barak
On 10/14/2010 6:01 PM, xxxxx@komodia.com wrote:
[SSDT hooking to prevent Registry changes]
Alex and Anton, there are legitimate reasons for doing this, like
parental control applications which wants to prevents the child from
removing components of the software, specialy in schools which deals
with teen agers.
How about protecting the registry keys via Windows’ built-in security
settings? (If the teens have admin rights, nothing will work anyway.)
For ultimate control, better build your own OS/software distribution.
Omit drivers for external ports (USB/SER/PAR), and severely restrict
what can be done with the installed programs.
Makes a nice, secure, locked ‘kiosk’ system.