代码之家  ›  专栏  ›  技术社区  ›  baash05

如何截获所有关键事件,包括ctrl+alt+del和ctrl+tab?

  •  5
  • baash05  · 技术社区  · 15 年前

    我正在编写一个屏幕保护程序类型的应用程序,它需要阻止用户在不输入密码的情况下访问系统。我想抓住/抑制用户试图退出应用程序的各种方法,但我所做的所有研究似乎都指向“你不能”。

    C语言或C++中的任何东西都会很棒。 我已经考虑过禁用键盘,但是我还有其他问题。

    11 回复  |  直到 15 年前
        1
  •  15
  •   Community    7 年前

    要添加到Shog9所说的内容中,如果您的应用程序可以截获ctrl+alt+del,那么您的应用程序就可以假装成Windows登录对话框,通过这样做,欺骗最终用户将其凭据输入到您的应用程序中。

    如果要替换Windows登录对话框,请参见 Winlogon and GINA (但这意味着,“Gina DLL在Windows Vista中被忽略了”,而且我还没有听说Vista的用途)。

    如果有人问我,我不会告诉他们不能。

    更具体地说,你的“应用软件”不能这样做:相反,根据设计,只有“系统软件”可以这样做;这并不是说你不能或不能写系统软件,但你的操作似乎很清楚地问不写系统软件怎么做…答案是 那个 你不能这样做:因为系统的设计是为了防止应用程序钩住这些组合键。

    你能告诉我写系统的方向吗?我真的认为如果是系统级的话会更好。这是为了一个原始设备制造商,所以这一点真的。另外,如果我写的是系统级的,我可以写一个应用程序来控制它。

    例如,键盘过滤设备驱动程序或Gina DLL将被视为系统软件:由管理员(或OEM)安装并作为O/S的一部分运行。

    我不知道吉娜的名字;我已经(在上面)在msdn中给出了一个链接。我希望它是Win32用户模式代码。

    设备驱动程序是另一个主题:例如 Getting Started on Driver Development .

    有没有一种方法可以重新映射键盘,使删除操作不在原来的位置?

    我仍然不确定你和/或你的老板有正确的想法。imho您不应该是阻止用户按ctrl alt del的应用程序。如果要阻止用户在不输入密码的情况下访问系统,则应锁定(密码保护)系统,就像用户已按了ctrl alt del,然后选择了“锁定此计算机”。要解锁计算机,他们需要按ctrl alt del并将其凭据输入winlogon。

    然而,忽略你应该做的,集中精力做你能做的,如果你想截获键盘,显然它是可以做到的。我自己没学过键盘,但是 this post this post 通过编写“键盘筛选器驱动程序”(这是一种内核模式,而不是Win32设备驱动程序)来声明成功。如果你写了其中一个,你可能会得到一些回击,例如 this reaction from a DDK MVP this reaction from an anti-snooping product .

        2
  •  31
  •   Shog9    15 年前

    你不能。ctrl+alt+del的关键是只有系统能处理它,因为这样系统 可以 一定要处理好。

    幸运的是,Windows内置了对受密码保护的屏幕保护程序的支持(显示属性中的“继续时,密码保护”选项或通过组策略提供)。就用这个。

        3
  •  4
  •   Nick Dandoulakis    15 年前

    我没有测试过,但是使用setWindowsHookEx()怎么样?

    来自msdn文档: 键盘键

    Windows NT/2000/XP: 安装监视低级键盘输入事件的挂接过程。有关更多信息,请参阅低级键盘程序挂钩过程。

        4
  •  3
  •   Unknown    15 年前

    截获crtl+alt+del是可能的,尽管很明显微软让截获变得非常困难,因为这样你就可以弹出一个假锁对话框,记录人们的密码。

    答案是写一个设备驱动程序。我不记得你能不能只用一个普通的旧键盘过滤器,或者你必须写一个键盘ISR。不管怎样,这当然是有可能的,但是如果你没有驾驶经验的话,会非常痛苦。

        5
  •  3
  •   fr00ty_l00ps    12 年前

    因为这似乎是一个很好的收集点,可以通过各种方式来“拦截”三个关键的psuedo中断。 控制alt delete,这是我昨天遇到的可能有用的东西。

    http://cuinl.tripod.com/Tips/enablectrldel.htm

    在我看来 当看起来唯一可行和及时的选择是切断电源(即机械移除过载的安卓类手持电脑的电池)以停止任何导致相当坚实和完全(或长期)不负责任的游行或故障时——看起来危险和令人沮丧的血统还在继续。---继续恶化。

    尤其是在移除像机械式扬声器音量控制这样的简单易懂的东西之后。(当然,体积大,材料多,但这当然只是一件事,对一个人或一个存在有什么好处是无限完美的意识,没有对它的控制或它的经验?)

    它是设计环境的一系列方法,环境负责对用户的响应,这是关键且真正有意义的技术接口的一部分。(唯一的?)

    我说,至少在这些技术的软件方面完全适应人工软接口之前,把一些按钮——直接放在硬件控制上——放回这些东西上,我在所有启发式设置的详尽说明中解释了这一点。

    即使在宇宙的力学中,我敢打赌也有一个方便的重置、恢复、暂停、停止类型的功能,以确保存在的安全性和基本的生存能力,这将构成一切的设计者,这将引发永恒的存在之谜:智能意识和意志。

        6
  •  1
  •   kay.herzam    15 年前

    你可以在XP和以前的版本中实现这一点,但是在Vista中就不需要了。

        7
  •  1
  •   Arafangion    15 年前

    尝试研究是否可以编写一个以密码保护的屏幕保护程序启动的应用程序。

    屏幕保护程序可以做的不仅仅是显示漂亮的图片-我以前见过交互式屏幕保护程序,它使用鼠标和键盘提供了一个简单的游戏,但我记不清我在哪个版本的Windows上看到了这个运行…很可能是Windows95。(在这种情况下,所有赌注都取消了)。

        8
  •  1
  •   jcolebrand    15 年前

    在程序运行时截取ctrl和alt键,然后取消这些键?

    我不知道这有多好,如果在Vista,但它值得一试。

    我记得2001年的时候做过类似的事情,所以大概是98年的时候。我已经很久没有尝试过像锁定ctrl-alt-del这样的事情了。

        9
  •  1
  •   baash05    15 年前

    好啊。。我不想把密码贴在这里 但Gyst是这样的

    创建一个键盘挂钩。 当用户按下ctrl alt delete时,将bools设置为true。如果他们再按什么,就把它们都设为假。

    switch (p_key)
                {
                    default: Clear(); break;
    
                    case Keys.LMenu: altHit = true; break;
                    case Keys.RMenu: altHit = true; break;
                    case Keys.LControlKey: ctrlHit = true; break;
                    case Keys.RControlKey: ctrlHit = true; break;
                    case Keys.Delete: delHit = true; break;
    

    当屏幕有焦点时,将其松开给任务管理器,关闭血腥的东西。 屏幕闪烁得如此之快,用户从未注意到。 我可以随心所欲。

    我承认这是一个蹩脚的说法,但它确实产生了预期的效果。(哦,我真希望我不用这么做)

        10
  •  1
  •   a rosa    14 年前

    “Process Explorer”由Mark Russinovich(http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx)完成,在SysInternals被微软收购之前就已经完成了。

    这篇2002年的文章在2006年更新,它解释了一种不用编写键盘驱动程序就可以完成的方法。 http://www.codeproject.com/KB/system/preventclose.aspx?msg=1666328

        11
  •  0
  •   Himanshu THE ONLY ONE    12 年前

    你仍然可以拦截 Ctrl+Alt+Del 在Windows 7中。

    这是Process Explorer的工作方式:

    http://mygreenpaste.blogspot.com/2005/07/image-file-execution-options-good-evil.html