2009-03-16 3 views
0

대학 캠퍼스에서 다양한 관리되는 사용자 랩을 유지 관리합니다. 이 컴퓨터는 모두 현재 Windows XP를 실행하고 있으며 키보드 또는 마우스 입력을 차단하여 컴퓨터를 "잠그는"데 사용되는 Windows 서비스가 있습니다. 스크립트 OS 설치 중에 잠금이 발생하여 사용자가 실수로 프로세스를 중단하거나 중단 할 수 없습니다. 또한 사용자가 주어진 실험실의 프론트 데스크에서 체크 아웃 될 때까지 시스템에 로그인하지 못하도록하는 데 사용됩니다. Ctrl + Alt + Del은 키보드 필터 드라이버를 통해 차단되고 나머지 키와 마우스는 현재 user32.dll의 BlockInput() 함수를 사용하여 차단됩니다.Vista의 서비스에서 마우스 입력 차단

XP에서는 서비스가 로컬 시스템으로 실행되고 성공하려면 BlockInput() 호출에서 "서비스와 데스크톱 상호 작용 허용"확인란을 선택해야합니다. Vista에서는 Session 0 isolation 변경으로 인해 더 이상 추측 할 수 없습니다. 호출은 성공하지만 입력은 실제로 차단되지 않습니다.

키보드 필터 드라이버는 여전히 정상적으로 작동하며 Ctrl + Alt + Del 대신 전체 키보드를 차단하는 데 사용할 수 있습니다. 그러나 나는 지금 우리가 어떻게 마우스를 막아야할지에 관해서는 손해를보고있다. 세션 0 격리가 책임이 있다는 것을 완전히 확신하지 못합니다.

누구든지 비스타와 그 이후의 서비스에서 마우스 입력을 차단할 수있는 수정 프로그램이나 임시 해결책을 추천 할 수 있습니까? 나는 운이없는 대안의 win32 API를 찾았다. 세션 0 격리가 비난한다고 가정 할 때, 세션 1에서 함수를 호출하는 합법적 인 방법이 있을까요, 아니면 고립의 목적을 물리 칠 것입니까? 사용자 로그인을 실행하고 서비스와 통신하는 상승 된 companion exe에 의존해야합니까?

답변

0

서비스에서 WTSEnumerateSessions를 사용하여 로그온 한 모든 사용자 세션을 가져오고 WTSQueryUserToken을 사용하여 로그온 한 사용자의 토큰을 얻은 다음 해당 토큰과 함께 CreateProcessAsUser를 사용하여 사용자의 데스크톱에서 실행중인 코드를 가져올 수 있습니다. 이것은 코드가 로그온 한 사용자로 실행된다는 단점이 있습니다. 모든 입력이 비활성화되어 있기 때문에 이것은 아마도 안전하고 기존의 XP 솔루션만큼 안전 할 것입니다.]

편집 : BlockInput에는 높은 필수 무결성 수준이 필요합니다. 이 그룹을 토큰에 추가 할 수는 있지만 데스크탑에서 실행되는 더 높은 권한을 가진 코드가 있으며 잠재적으로 공격에 노출 될 수 있습니다.

시스템의 모든 HID 클래스 장치를 비활성화하기 위해 서비스를 사용하는 것일 수도 있습니다.

+0

아직 실제로 테스트 할 기회가 없었습니다. 문제는 콘솔 사용자가 권한있는 계정이 아니며 BlockInput 호출이 실패한다는 것입니다. –

+0

BlockInput은 여전히 ​​작동해야하며 권한이 필요하다고 생각하지 않습니다. – Michael

+0

Vista에서 제한된 사용자로 전화를 테스트하는 간단한 콘솔 앱을 작성했지만 제대로 작동하지 않았습니다. 전화가 완전히 실패했는지 또는 성공했는지 여부를 잊어 버리고 작동하지 않았습니다. 응용 프로그램을 실행하면 잘 작동합니다. –