¿Hay alguna manera de detectar si el reloj del sistema se ha cambiado hacia atrás en Windows?

Question

En una máquina con Windows, ¿hay alguna manera de averiguar si el tiempo se ha cambiado hacia atrás sin monitorizar continuamente los mensajes WM_TIMECHANGE?

Por ejemplo, me gustaría hacer que lo primero que hace mi aplicación al inicio es ver si se ha cambiado el tiempo desde la última vez que ejecuté la aplicación.

Por lo que puedo decir, la única forma de ver un cambio es mirar el mensaje WM_TIMECHANGE, pero solo lo veré si mi aplicación se está ejecutando.

Answer 1

Sí. Puede leer el Windows Event Logs y buscar cambios en la hora del sistema. (Los cambios de tiempo del sistema son uno de los eventos del sistema que se registran automáticamente.) Por ejemplo, acabo de ajustar la hora del sistema unos segundos y aparece lo siguiente en el registro del evento del sistema:

Información 10/21/2011 11:16:26 AM Kernel-General 1 Ninguno

La hora del sistema ha cambiado a 2011 - 10 - 21T16: 16: 26.000000000Z de 2011 - 10 - 21T16: 16: 26.000000000Z.

Puede use the Win32 API to get access to the event logs luego consultar estos eventos para determinar si la hora fue efectivamente modificada. Lo mejor de esta solución es que está incorporada y siempre en ejecución. No es necesario supervisar los eventos a través de un servicio personalizado, etc. Solo debe consultar los datos del sistema operativo.

Esto todavía no es una solución a prueba de balas ya que las personas con derechos de administrador pueden tener la posibilidad de configuración, registros claros, etc. Pero sin dudas sería laico a prueba de su aplicación. Los registros de eventos del sistema no son algo que los usuarios habituales de Windows piensen.

El XML para ese evento en particular: (sin identificación de la seguridad privacidad &)

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> 
    <System> 
    <Provider Name="Microsoft-Windows-Kernel-General" 
     Guid="{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}" /> 
    <EventID>1</EventID> 
    <Version>0</Version> 
    <Level>4</Level> 
    <Task>0</Task> 
    <Opcode>0</Opcode> 
    <Keywords>0x8000000000000010</Keywords> 
    <TimeCreated SystemTime="2011-10-21T16:16:26.001000000Z" /> 
    <EventRecordID>138478</EventRecordID> 
    <Correlation /> 
    <Execution ProcessID="40044" ThreadID="50016" /> 
    <Channel>System</Channel> 
    <Computer>xxxxx.xxxxxxxxx.org</Computer> 
    <Security UserID="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" /> 
    </System> 
    <EventData> 
    <Data Name="NewTime">2011-10-21T16:16:26.000000000Z</Data> 
    <Data Name="OldTime">2011-10-21T16:16:26.000000000Z</Data> 
    </EventData> 
    </Event> 

Answer 2

No, no puedes. Es por eso que los esquemas DRM sensibles al tiempo son en general bastante inútiles.

podría tratar de evitar el uso de un servicio, y luego tendría que trabajar en el tiempo de inactividad del servicio mediante el uso de otro truco, y otro truco encima de eso también.

De todos modos, si eso es todo lo que estamos tratando de hacer a continuación, simplemente almacenar en algún lugar (cifrada, posiblemente) el valor de la hora del sistema en el cierre de su programa, a continuación, asegurándose de que no se ha pasado al inicio del programa debe bastar. No detendrá a los usuarios que básicamente "congelaron" el tiempo desde el cierre hasta el inicio, pero será suficiente para 9/10 de las personas que intentan pasar su prueba cronometrada.

Answer 3

Usted podría tener su aplicación (mientras que pasa a estar en ejecución) comparar periódicamente la hora del sistema con un tiempo de descargue de un recurso de servidor en alguna parte. Si de repente ve que la diferencia entre la hora del sistema y la hora del servidor ha aumentado, eso significa que la hora del sistema se ha retrasado.

Obviamente, esto no funcionaría en una máquina sin acceso a Internet.

Answer 4

Una idea a la anterior (aunque observo que verificar con un reloj externo es la respuesta definitiva si es factible) - también puede leer periódicamente el reloj del sistema y almacenarlo, tal vez encriptado, en un archivo oculto en alguna parte. Cada vez que hace esto, verifica que el nuevo valor sea más reciente que el del archivo. El disparador para hacer esto podría estar en cada arranque, etc.

Como todos los métodos internos, este es vulnerable a que alguien averigüe el archivo oculto. También puede marcar un problema si falta el archivo oculto o si su sello de fecha no coincide con su contenido.