Reassigning the Secure Attention Sequence in Windows XPFollow

Does anyone know a way to change the Secure Attention Sequence in Windows XP from "Control-Alternate-Delete" to something else?
In before "Why do you want to change it?"

The reason that CTRL-ALT-DEL is used is because it is the only keyboard command that cannot be intercepted by other programs - it always sends an "interrupt" to the system itself. This has to do with the computer architecture itself (e.g. how all of the components are hard-wired).

Any other keyboard combination can be intercepted by other programs instead of passing it along to the operating system. Typically, this would be an annoyance (I accidentally triggered my 1-hour ability), but it could also be abused by malicious programs (to harvest your passwords, etc).

Actually, yes. CTRL-ALT-DEL sends a hardware interrupt to the system. Not software, hardware. Software can't catch or stop it. The hardware receives the interrupt and asks the top-level application (your operating system) what to do with it.

References:

http://codingforums.com/archive/index.php?t-79499.html (posts 4&5, as well as further down).
http://www.mp3car.com/vbulletin/input-devices/112348-mapping-ctrl-alt-del-alt-tab-f6-f7-tc.html (posts 7&8 discuss the hardware-basis preventing remapping of CTRL-ALT-DEL keys)
http://cboard.cprogramming.com/archive/index.php/t-43942.html (this post talks about how, to generate CTRL-ALT-DEL in program code, you have to write it to the keyboard input flow. There is no method for software to trigger this hardware interrupt without pretending to be the physical keyboard).

Better, more concrete references are available in assembly language and computer architecture textbooks, but I don't know of any that are freely available on the internet to use for easy-access citation.


In my brief research here, I did find out that I was incorrect about one item in my previous post: CTRL-ALT-DEL is not the only hardware interrupt. Many CTRL- combinations are hardware interrupts, that then ask the operating system what to do. Most of the time, the operating system passes the interrupt to the currently active program, making this transparent to the user. Here is a link to an MSDN blog discussing why CTRL-ALT-DEL was chosen instead of a different hardware interrupt: http://blogs.msdn.com/larryosterman/archive/2005/01/24/359850.aspx.


Edited, Mar 21st 2008 2:54pm by garfunkel

Then please enlighten me Smasheroo. Seriously. I do not intend or desire to go around spreading misinformation.

I am giving you the benefit of the doubt and looking up further information when you claim something, but you don't provide any references to back up what you say. So I'm left to find information on my own.

For example, I consulted wikipedia's entry on interrupts (http://en.wikipedia.org/wiki/Interrupt), which says the following:



Note that the memory subsystem would be hardware as well, so either implementation indicates a hardware-based interrupt system.


In an attempt to look further, I looked at the wikipedia entry on interrupt handlers (http://en.wikipedia.org/wiki/Interrupt_handler) and found the following:



This interrupt handler is a piece of software ("...callback routine in an operating system or device driver..."). However, this piece of software is triggered by the interrupt itself, which is generated by the hardware that handles the interrupts.

Since the interrupt handler is software, it could potentially be affected or corrupted by viruses, malware, etc, causing the interrupts to not behave as normal. But the hardware still generates the interrupt. It is the interrupt handler software that does not process the interrupt.


One more thing I found: Phoenix BIOS even includes error beeps for when the programmable interrupt controller goes bad. The solution: replace it. If the interrupt controller was software, I don't think you would need to replace it (ref: http://www.speedguide.net/read_articles.php?id=1576, under Phoenix Biox codes, beep pattern 1-2-1).