windows security windows-7 vb6 uac

¿Cómo decide Windows si mostrar el indicador de UAC?



security windows-7 (4)

En mi aplicación VB6 abro otros archivos EXE. Mi aplicación se ejecuta sin ningún aviso de UAC, pero tengo un EXE que comprueba si hay actualizaciones de software. Esto solicita el aviso de UAC. Entonces, ¿cómo decide Windows si mostrar el indicador de UAC? Vi este link . Entonces, ¿depende del código que escribí en mi aplicación? Es interesante que mi aplicación (que es el archivo EXE principal) no solicite el UAC, mientras que un pequeño EXE que comprueba y descarga las actualizaciones solicita el UAC. Tengo todos los archivos EXE firmados digitalmente. Ya he echado un vistazo a los siguientes enlaces:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa511445.aspx

http://technet.microsoft.com/en-us/library/cc505883.aspx y algunos otros.

Pero todavía no lo tengo claro.


Alguien puede especificar en la configuración del archivo ejecutable que este archivo debe ejecutarse con privilegios más altos.

Cómo solicitar privilegios de administrador

No sé para qué sirve esta actualización, pero sugeriría que necesita actualizar un componente como un servicio, o algunos archivos que se encuentran en ProgramFiles-Dir. Por lo tanto, necesita privilegios de administrador.


El indicador de UAC se usa cuando se necesita una elevación de privilegios. Su propia aplicación VB6 no la necesita y, por lo tanto, el comportamiento predeterminado es correcto. Un actualizador necesitaría el privilegio, por lo que su autor marcó que el ejecutable lo requiere. Windows detecta eso y coloca el indicador de UAC.

Ahora, dependiendo de la versión de Windows exacta y las actualizaciones de seguridad, ese privilegio permanece disponible por un tiempo, incluso para otros procesos (secundarios). Esto puede evitar que las indicaciones de UAC se dupliquen.


Es casi seguro que está llegando a una heurística de compatibilidad con la tecnología de detección de Windows Installer . Windows intentará detectar cuándo una aplicación es un instalador y, probablemente, debe ser elevada.

La detección del instalador solo se aplica a:

  1. Ejecutables de 32 bits
  2. Aplicaciones sin un nivel de requestedExecutionLevel
  3. Procesos interactivos que se ejecutan como un usuario estándar con LUA habilitado

Antes de crear un proceso de 32 bits, se comprueban los siguientes atributos para determinar si es un instalador:

  • El nombre del archivo incluye palabras clave como "instalar", "instalar", "actualizar", etc.
  • Palabras clave en los siguientes campos de Recursos de versión: Proveedor, Nombre de la compañía, Nombre del producto, Descripción del archivo, Nombre del archivo original, Nombre interno y Nombre de la exportación.
  • Palabras clave en el manifiesto de lado a lado incrustado en el ejecutable.
  • Palabras clave en entradas específicas de StringTable vinculadas en el ejecutable.
  • Atributos clave en los datos RC vinculados en el ejecutable.
  • Secuencias apuntadas de bytes dentro del ejecutable.

Entonces, como dijiste:

pero tengo un exe que comprueba si hay actualizaciones de software

Mi conjetura es que este CheckForUpdates.exe está activando las heurísticas de compatibilidad.

Lo correcto a hacer es un manifiesto de ensamblaje a su archivo de "comprobación", informando a Windows que no debe elevar la utilidad. Esto se hace con un asInvoker de asInvoker en el manifiesto:

AssemblyManifest.xml:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="client" type="win32" /> <description>Update checker</description> <!-- Run as standard user. Disable file and registry virtualization --> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker" uiAccess="false"/> </requestedPrivileges> </security> </trustInfo> </assembly>

De esa manera, su aplicación "Buscar actualizaciones" nunca se elevará y nunca obtendrá privilegios administrativos por error.

Si desea que su actualizador aplique realmente las actualizaciones (actualizaciones que requieren privilegios administrativos), entonces iniciará su aplicación de actualización como administrador.

Código de muestra

//Check if there are updates available if (!CheckForUpdatesAvailable()) return; //no updates. We''re done //If the user is an administrator, then get the update if (IsUserAnAdmin()) { //Maybe throw in a "Hey, user, wanna get the update now?" dialog DownloadAndApplyUpdates(); return; } //The user is not an admin. //Relaunch ourselves as administrator so we can download the update //Maybe throw in a "Hey, user, wanna get the update now?" dialog. A button with a UAC shield on it ExecuteAsAdmin(Application.ExecutablePath, "/downloadUpdate");

Con las funciones de ayuda:

private Boolean IsUserAnAdmin() { //A user can be a member of the Administrator group, but not an administrator. //Conversely, the user can be an administrator and not a member of the administrators group. var identity = WindowsIdentity.GetCurrent(); return (null != identity && new WindowsPrincipal(identity).IsInRole(WindowsBuiltInRole.Administrator)); } private void ExecuteAsAdmin(string Filename, string Arguments) { ProcessStartInfo startInfo = new ProcessStartInfo(Filename, Arguments); startInfo.Verb = "runas"; System.Diagnostics.Process.Start(startInfo); }

Entonces, solo necesita buscar el parámetro de línea de comando / downloadUpdate en el inicio para saber que su trabajo es realmente trabajar:

public Form1() { InitializeComponent(); //Ideally this would be in program.cs, before the call to Application.Run() //But that would require me to refactor code out of the Form file, which is overkill for a demo if (FindCmdLineSwitch("downloadUpdate", true)) { DownloadAndApplyUpdates(); Environment.Exit(0); } }

Nota : Cualquier código se libera en el dominio público. No se requiere atribución.


Sus programas probablemente carezcan de manifiestos de aplicación que los marcan como no heredados. Como resultado, Windows aplicará heurísticas de detección del instalador mediante scripts para decidir si su programa es un instalador. Esta es prácticamente la única forma en que se genera un mensaje de UAC "inesperado".

Estas heurísticas incluyen búsquedas de palabras clave dentro del nombre del archivo EXE y varias de las propiedades extendidas del EXE, e incluso pueden buscar firmas binarias conocidas (es decir, cadenas de bytes) dentro del archivo.

Por cierto, su firma de cifrado no entra en esto en absoluto. Y no ayuda en nada si no fue emitido por un CA de confianza.

Para el caso, cualquiera que confíe en el código solo porque Windows informa el nombre de la empresa en el indicador de UAC es un tonto. Los autores de programas maliciosos los roban todo el tiempo y, para el caso, son triviales de obtener y casi nunca son reportados por los usuarios cuando los programas de basura causan problemas. Ahorre su dinero, los certificados de firma de código son un concepto fallido.