Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

The secure attention key is designed to make login spoofing impossible, as the kernel will suspend any program, including those masquerading as the computer's login process, before starting a trustable login operation.

Why other programs cannot simulate control + alt + del?

What is stay behind this?

share|improve this question
    
see stackoverflow.com/q/886076/866172 –  Jalayn Jul 27 '12 at 11:45
    
IIRC (and my memory is rusty, this comment might be enough to give you some google search terms) it is from way back in DOS. It was the only keystroke sequence that a program could not add an interrupt to. Back in the day a TSR program like Sidekick could add an interrupt handler (to 09h?) that would register its key sequence. When the user pressed the sequence then Sidekick could intercept it and then display itself. Ctrl-Alt-Del on a DOS system would reboot it, so maybe Microsoft decided not to let anyone else use it. Maybe the folks over at superuser or serverfault could help –  james Jul 27 '12 at 12:46

4 Answers 4

up vote 6 down vote accepted

Larry Osterman wrote about "Why is Control-Alt-Delete the secure attention sequence (SAS)?" back in 2005. The answer is so short that there is no real need to summarize it, although I am eliding a few side notes.

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.

So there you have it, the reason why Ctrl+Alt+Del was chosen for the secure attention sequence.

Most likely on DOS there was no real technical reason why you couldn't possibly have caught Ctrl+Alt+Del and used it for some other purpose, but nobody in their right mind would have done that in a DOS application since it would break so much of users' expectations of how their computers worked. Note that Windows 3.x (when running in 386 Enhanced Mode; I don't think it did so when running in Standard Mode, and certainly not Win 3.0 in Real Mode) caught and handled Ctrl+Alt+Del, which demonstrates that it could be done even when running on top of BIOS + DOS. Probably the code that did the grunt work for that was just a few assembly language instructions, hooked to the appropriate interrupt vector, which looked for DEL with the CTRL and ALT modifiers set, doing a bit of magic if it found that particular combination.

As for simulating it, I'd go with "why would you want to?". I do recall reading somewhere (maybe it was at Larry Osterman's blog, maybe it was somewhere completely different) that technically the secure desktop is a separate session started and maintained by the Windows initialization code, and thus inaccessible to any non-privileged process. That said, apparently there is a SendSAS() function in SAS.DLL (which on Win7 is in System32) wich will simulate the user pressing Ctrl+Alt+Del; see SendSas Step by Step for a short code example. Caveat: I haven't tried that one myself.

share|improve this answer
    
i read Larry Osterman before...but i want more information.i I would not know "how impelemnt it" i want know why i can't do this! –  Jeson Park Jul 27 '12 at 15:33
2  
@JesonPark: you can't do it for the simple reason that the designers of Windows don't want you to be able to do it. –  Bryan Oakley Jul 27 '12 at 18:01
    
It seems this is only for Windows!... –  Jeson Park Jul 28 '12 at 6:38
    
@JesonPark: yes, you are correct, this is a issue specifically related to the Windows OS. –  Bryan Oakley Jul 28 '12 at 12:43
1  
@JesonPark Linux has no concept of a secure attention sequence the way Windows does. Some desktop's login manager might, though. (And that has nothing to do with the subject matter of Programmers.SE.) –  Michael Kjörling Jul 30 '12 at 11:27

Why it cannot be intercepted:

  1. Because it would be a huge security risk. Imagine an application which launches at logon. It shows a false logon screen to the user and invites the user to enter a password. To avoid this scenario, you often have (in business environments or on Windows Server) to press Ctrl+Alt+Delete before logging in; this ensures that you're not entering your password in a false logon screen.

  2. Because Ctrl+Alt+Delete is known for being the last resort where a full-screen application hangs and you cannot switch to another one (Alt+Tab) or to the start menu (Win). If Ctrl+Alt+Delete is intercepted too, the only way to exit such application would be to power down/unplug/force reboot the PC.

Why it cannot be simulated:

  1. Because you don't need it. You can already do whatever you want with the user session (given enough privileges), including the logoff.

  2. Probably because it's difficult to implement. Since those keys cannot be intercepted, it might be that for the same reason, a piece of software (aside drivers) cannot emulate those keys.

share|improve this answer
3  
You explain why it should not be intercepted, not why it is impossible, or what mechanism prevents it. –  Useless Jul 27 '12 at 12:04
1  
@Useless: The OS prevents it, because it should not be intercepted. Now, how is it implemented internally? I have no idea, and I imagine that only developers from Microsoft who work on Windows core know those internals. –  MainMa Jul 27 '12 at 12:10
1  
@MainMa:tanq for response but as UseLess say :"how is it implemented internally??" you say "Since those keys cannot be intercepted..." i want to know how those keys cannot be intercepted! –  Jeson Park Jul 27 '12 at 15:29
    
They can be intercepted. VMware implements this with their "enhanced virtual keyboard" feature. –  MichaelGG Apr 8 at 7:51
    
@MichaelGG: I imagine that VMware installs drivers and intercepts the keys at driver level. The question, on the other hand, is about applications, not drivers. –  MainMa Apr 8 at 11:49

In a comment to another answer you said the answer explained why it shouldn't be intercepted, but you are asking why it can't, not why it shouldn't be intercepted.

Maybe I'm pointing out the obvious, but it can't be intercepted simply because that's how windows was designed. The OS obviously intercepts it, and it simply refuses to pass that event on to applications. It was a design decision by the makers of the OS.

share|improve this answer

The answer is that it can be intercepted -- you just have to do it before it gets to Windows (i.e at the driver level or the firmware of the device). The reason you can't intercept it once the OS has it is because the OS doesn't allow it.

share|improve this answer
    
as i say i know this...but how??and Michael Kjörling in first answer say about this! –  Jeson Park Jul 28 '12 at 19:47
1  
See the answer by Bryan Oakley...in short, the OS somewhere has an If statement... –  jmoreno Jul 29 '12 at 1:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.