La chiave di attenzione sicura è progettata per rendere impossibile lo spoofing di accesso, in quanto il kernel sospenderà qualsiasi programma, compresi quelli che si mascherano come processo di accesso del computer, prima di avviare un'operazione di accesso affidabile.
Perché altri programmi non possono simulare il controllo + alt + del ?
Qual è la ragione di questo?
Larry Osterman ha scritto su "Perché Control-Alt-Elimina l'attenzione sicura sequenza (SAS)? " nel 2005. La risposta è così breve che non è necessario riassumerlo, sebbene io elimini alcune note a margine.
When we were designing NT 3.1, ... we needed to have a keystroke sequence that couldn't be intercepted by any application. ...
It turned out that the only keystroke combination that wasn't already being used by a shipping application was control-alt-del, because that was used to reboot the computer. And thus was born the Control-Alt-Del to log in.
Quindi ecco fatto, il motivo per cui Ctrl + Alt + Canc è stato scelto per la sequenza di attenzione sicura.
Molto probabilmente sul DOS non c'era una vera ragione tecnica per cui non si potesse aver preso Ctrl + Alt + Canc e usato per qualche altro scopo, ma nessuno sano di mente l'avrebbe fatto in un'applicazione DOS dal momento che romperebbe così tante delle aspettative degli utenti su come funzionavano i loro computer. Si noti che Windows 3.x (quando è in esecuzione in modalità 386 avanzata, non credo che lo abbia fatto quando si esegue in modalità standard, e certamente non in Win 3.0 in modalità reale) catturato e gestito da Ctrl + Alt + Canc, il che dimostra che potrebbe essere fatto anche quando è in esecuzione su BIOS + DOS. Probabilmente il codice che faceva funzionare il grunt era costituito da poche istruzioni di linguaggio assembly, agganciato al vettore di interrupt appropriato, che cercava DEL con i set di modificatori CTRL e ALT, facendo un po 'di magia se trovava quella particolare combinazione. / p>
Per quanto riguarda la simulazione, andrei con "perché vorresti?". Ricordo di aver letto da qualche parte (forse era nel blog di Larry Osterman, forse era completamente diverso) che tecnicamente il desktop sicuro è una sessione separata avviata e gestita dal codice di inizializzazione di Windows, e quindi inaccessibile a qualsiasi processo non privilegiato. Detto questo, apparentemente c'è una funzione SendSAS () in SAS.DLL (che su Win7 è in System32) che simulerà l'utente premendo Ctrl + Alt + Canc; vedi SendSas passo dopo passo per un breve esempio di codice. Avvertenza: non l'ho provato io stesso.
Perché non può essere intercettato:
Perché sarebbe un enorme rischio per la sicurezza. Immagina un'applicazione che viene lanciata all'accesso. Mostra una schermata di accesso errata all'utente e invita l'utente a inserire una password. Per evitare questo scenario, è spesso necessario (in ambiente aziendale o su Windows Server) premere Ctrl + Alt + Elimina prima di accedere; questo assicura che non stai inserendo la tua password in una schermata di accesso falso.
Poiché Ctrl + Alt + Elimina è noto per essere l'ultima risorsa in cui si blocca un'applicazione a schermo intero e non è possibile passa a un altro ( Alt + Tab ) o al menu di avvio ( Win ). Se è stato intercettato anche Ctrl + Alt + Elimina , l'unico modo per uscire da tale applicazione sarebbe quello di spegnere / scollegare / forzare il riavvio del PC .
Perché non può essere simulato:
Perché non ne hai bisogno. Puoi già fare ciò che vuoi con la sessione utente (con privilegi sufficienti), inclusa la disconnessione.
Probabilmente perché è difficile da implementare. Dal momento che tali chiavi non possono essere intercettate, potrebbe essere che per lo stesso motivo, un pezzo di software (driver a parte) non possa emulare quelle chiavi.
In un commento ad un'altra risposta hai detto che la risposta spiegava perché non dovrebbe essere intercettata, ma ti stai chiedendo perché non può , non perché non dovrebbe essere intercettato.
Forse sto indicando l'ovvio, ma non può essere intercettato semplicemente perché è così che sono state progettate le finestre. Il sistema operativo ovviamente lo intercetta e si rifiuta semplicemente di passare quell'evento alle applicazioni. È stata una decisione progettuale dei produttori del sistema operativo.
La risposta è che può essere intercettato: devi solo farlo prima che arrivi a Windows (cioè a livello di driver o firmware del dispositivo). Il motivo per cui non è possibile intercettarlo una volta che il sistema operativo lo ha è perché il sistema operativo non lo consente.