windows 7 - ultimate - Detección de virtualización de registro.

que hacer si mi pc no soporta virtualizacion

Question

Tengo un conjunto de aplicaciones C # (v2) y estoy teniendo problemas con la virtualización del registro en Win7 (y, en menor medida, en Vista).

Tengo un área de configuración de registro compartida a la que mis aplicaciones necesitan acceder en HKLM / Software / Company ... Antes de Vista, todo se escribía y se leía desde esa ubicación según fuera necesario.

El código detectó apropiadamente las fallas para escribir en esa clave de registro y se replegaría apropiadamente (al escribir a HKCU y notificar al usuario que la configuración que habían aplicado solo afectaría al usuario actual).

En Vista, la virtualización del registro rompió todo esto porque la verificación de acceso que estábamos usando para la escritura HKLM "se realizaría" de manera silenciosa y se virtualizaría en HKCR / VirtualStore / Machine ... en su lugar. En este caso, el usuario pensaría que había guardado la configuración de toda la máquina, pero que solo había escrito en la tienda virtual.

Lamentablemente, incluso al intentar enumerar los permisos en la clave de registro de HKLM se obtienen resultados explícitos que indican que el usuario tiene acceso, ya sea que lo tengan o no.

Cuando agregamos el soporte de Vista, la solución alternativa que utilizamos fue realizar una escritura de sondeo en HKLM ... y luego registrar HKCR / VirtualStore / Machine ... para el mismo valor y observar que la virtualización había ocurrido si se encontraba el valor.

Win7 parece haber roto esto (nuevamente) porque las consultas contra la ubicación virtual explícita (HKCR) ahora muestran resultados combinados de la ubicación HKLM incluso si la escritura no estaba virtualizada.

¿Alguien tiene alguna sugerencia para trabajar alrededor de esto?

Restricciones: - Necesito una solución que funcione sin requerir elevación (cuando no tenga permisos de administrador, recurriré a una configuración por usuario en HKCU, pero necesito poder detectar este caso de manera confiable).

• Necesita trabajar con una aplicación v2 C # (una opción que he visto para el código C ++ es incrustar un manifiesto que deshabilita la virtualización para el .exe pero no he podido hacer eso en C # V2, ver deshabilitar la virtualización de carpetas en Windows ) .

• Debe funcionar sin un "instalador" (esto impide la capacidad de deshabilitar la virtualización en la clave de registro que necesitamos para el comando REG FLAGS ...).

Answer 1

Esta es una excelente pregunta, +1 (¡Por qué es un wiki de la comunidad, merece puntos!)

En general, hay un conjunto de reglas (que [según lo que haya encontrado] variarán con el tiempo) que controlan si la virtualización de UAC [y, por lo tanto, implícitamente, Registro] está en juego.

Algunas partes destacadas de la documentación de los conjuntos de reglas de virtualización del registro en MSDN son:

1. [como dice jeffamaphone] si el manifiesto tiene un conjunto requiredPrivileges / requiredExecutionLevel, está desactivado. Parece que no ha descartado agregar un manifiesto, ¿puede indicar por qué esto no funciona para usted? (Dice "No he podido hacer eso en C # V2": hay una opción Agregar elemento para agregar un archivo de manifiesto de aplicación, y está disponible en VS2005)
2. Si el ejecutable está ejecutando 64 bits, está desactivado por defecto.
3. si no es un proceso interactivo (como un servicio, o alojado en IIS, etc.), se apaga

Si no está en posición de influir en ninguno de los puntos anteriores, que es el ideal, y por lo tanto desea detectar si la virtualización de UAC se aplica en el contexto actual, utilice esta respuesta a lo que, al principio, podría no ser un problema relacionado. pregunta (Obviamente, aún tendría que decidir si se aplica a la clave específica en la que está operando, que es un objetivo en movimiento que, obviamente, no querría implementar código que debe rastrear los cambios si se puede evitar, pero en la mayoría de los casos debería ser relativamente claro.

Answer 2

Puede habilitar / deshabilitar la virtualización por clave, de acuerdo con this , pero le indica que use una herramienta de línea de comandos. Pero debe haber una manera de hacerlo programáticamente.

Podría ser más fácil simplemente desactivar la virtualización en su aplicación configurando el nivel de ejecución solicitado en su manifiesto. Puede probar la opción más disponible, pero eso podría significar que su aplicación siempre se ejecuta como Administrador. Parece implicar que simplemente configurarlo en asInvoker desactivará la virtualización. Ver also

Answer 3

Tuve un problema similar y la introducción de un manifiesto lo resolvió.

Confiaba en la seguridad del registro para evitar que la aplicación (Win32) creara claves en el HKLM / Software / Wow6432Node cuando se ejecutaba como usuario estándar, y me sorprendió ver que estaba teniendo éxito, sin embargo, no había ninguna clave presente. creado en su lugar bajo esta nueva área de VirtualStore.

La virtualización del registro se apaga cuando se encuentra que el manifiesto PE contiene información relacionada con la seguridad. Para no requerir elevación de privilegios, mi manifiesto contiene el siguiente nodo:

<trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker">
</requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>

Para que el ejecutable sea compatible con Vista y XP, al parecer, cada nodo en la sección TrustInfo debe contener el espacio de nombres:

<ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
<ms_asmv2:security>
<ms_asmv2:requestedPrivileges>
<ms_asmv2:requestedExecutionLevel level="asInvoker">
</ms_asmv2:requestedExecutionLevel>
</ms_asmv2:requestedPrivileges>
</ms_asmv2:security>
</ms_asmv2:trustInfo>

Una vez que el manifiesto se incrustó correctamente en mi archivo .exe (me tomó un par de intentos modificando las propiedades apropiadas del proyecto), el programa finalmente fracasó como esperaba.

Para el código administrado, el manifiesto se puede incluir como un paso posterior a la compilación ejecutando la herramienta mt.exe. Por ejemplo, como se informó en el also

mt.exe –manifest YourFile.manifest –outputresource:YourApp.exe;#1

Prefiero usar el enfoque de manifiesto en lugar de modificar los indicadores de los nodos del registro usando reg.exe como se explica en este artículo, ya que esto hace que el comportamiento sea consistente en todas las máquinas.

Espero que ayude (incluso si, después de haber leído la fecha de la publicación original, estoy bastante seguro de que el problema se resolvió hace mucho tiempo!)

Alberto

Answer 4

Tenga en cuenta que HKCR es una tienda virtualizada, una combinación de HKLM/Software/Classes y HKCU/Software/Classes .

El mejor enfoque sería no permitir que la virtualización del registro tenga lugar. En primer lugar, comprobar si el usuario se eleva en el tiempo de ejecución y luego puede notificar al usuario que los cambios solo se aplicarán al usuario actual antes de que comiencen a realizar cambios.

Al detectar si usted es un administrador elevado en primer lugar, simplemente puede evitar escribir en HKLM cuando se va a virtualizar.

Ejemplo:

private bool IsAdministrator
{
get
{
WindowsIdentity wi = WindowsIdentity.GetCurrent();
WindowsPrincipal wp = new WindowsPrincipal(wi);
return wp.IsInRole(WindowsBuiltInRole.Administrator);
}
}

Nota: No codifico en C #, el ejemplo se levanta de la pregunta ¿Cómo puedo detectar si mi proceso se está ejecutando con UAC elevado o no?