利用安装程序完成程序初始化

对于开启了UAC保护的Windows系统,一种常见的绕过UAC保护的方法就是:

很多应用软件在安装结束前通常都会给出一个选项(默认选中),让你可以方便的在安装完成后直接启动应用。

安装程序作为一类特殊的程序,一般都会要求用户赋予其管理员权限以完成正常的安装动作。这样其启动的应用软件自身作为安装程序的一个子进程启动,便会继承其父进程的全部既得权限。

这样启动的应用程序可以利用管理员权限完成一些初始化工作。

这个方法适用于:比较方便的自注册,但外部完成注册则较麻烦或者冗余

  • COM类插件:通过宿主应用注册比较简单,但通过写注册表,则相对麻烦。

这些内容源于一片文章——《当心应用软件借安装程序绕过UAC》,但换个角度思考问题也许会更好


Q:
Windows 7, C++, VS2008 I have a COM DLL that needs to be registered using "runas administrator" (it is a legacy app that writes to the registry) The DLL is used by a reports app which instantiates it using CoCreateInstance. This failed unless I also ran the reports app as administrator; until I changed the linker setting from /MANIFESTUAC to /MANIFESTUAC:NO

Can anyone tell me why this works? Does it mean that I can write apps that bypass the UAC using this setting?

A:
If your installer/registerer app has a manifest, and it says "don't run elevated", when you try to write to HKLM it fails. If you have a manifest and it says "run elevated", when you try to write to HKLM it succeeds. If you have no manifest (which you request with /MANIFESTUAC:NO), when you try to write to HKLM it writes to a virtualized location instead.

When you run the reports app, a similar triple applies although it it can read HKLM. Therefore if the reports app has a manifest, whether elevated or not, it reads HKLM. Without a manifest it reads the virtualized location. This is why you have success when both apps have a manifest or don't have a manifest.

It would probably be preferably to have your installer app with a manifest that requests elevation, and your reports app have a manifest that does not request elevation. That way all your apps are telling the truth and everything works. Plus you know why it's happening.

posted @ 2014-08-01 09:47  kevinzhwl  阅读(...)  评论(... 编辑 收藏