2012-02-06 29 views
8

tôi đang chuẩn bị một mô-đun Delphi, mà đặt một cái móc trong một thread để ghi lại một macro:SetWindowsHookEx cho WH_JOURNALRECORD thất bại dưới Vista/Windows 7

FHandleRec := SetWindowsHookEx(WH_JOURNALRECORD, FRecordProc, HInstance, 0); 
FHandlePlay := SetWindowsHookEx(WH_JOURNALPLAYBACK, FPlayProc, HInstance, 0); 

Đó hoạt động tốt trên WinXP, nhưng trên Vista/Windows 7 không thành công với ERROR_ACCESS_DENIED. Tôi đã tìm thấy trong Google (this) tham chiếu (that). Báo giá:

Quy trình đặc quyền thấp hơn không thể:… Sử dụng móc tạp chí để theo dõi quy trình đặc quyền cao hơn .

Cố gắng nhưng không thành công:

  1. Chạy ứng dụng as administrator. Có lẽ sợi chỉ được bắt đầu với đặc quyền thấp hơn so với sợi chính (mặc dù tôi không đảm bảo 100% )
  2. Mạo danh luồng có ngữ cảnh bảo mật của quản trị viên cũng không giúp ích gì.

Mẫu mã:

if LogonUser(PWideChar(sAdminUser), PWideChar(sDomain), PWideChar(sPwd), 
      LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, hToken) then 
begin 
    if not ImpersonateLoggedOnUser(hToken) then 
    raise Exception.Create('Error impersonating the user'); 
end; 
FHandleRec := SetWindowsHookEx(WH_JOURNALRECORD, FRecordProc, HInstance, 0); 

LogonUserImpersonateLoggedOnUser thực hiện mà không có lỗi.

khả năng khác để thử:

  1. tắt UAC vĩnh viễn. Điều này giúp, nhưng tôi không thể ép buộc mô-đun người dùng làm điều đó.
  2. Một khách hàng mô-đun ký một ứng dụng và đặt nó ở vị trí đáng tin cậy . Không thử điều đó, nhưng điều đó làm phức tạp triệt để việc sử dụng mô-đun cho người dùng.
  3. Đặt mô-đun vào một số ứng dụng đã ký và phân phối EXE. Điều đó sẽ phá vỡ một số chức năng cốt lõi.

Bạn vui lòng hiển thị mã đang đặt móc dưới Visa/Windows 7 hoặc đề xuất giải pháp làm việc?

+2

Bạn cần nhúng tệp kê khai để yêu cầu người dùng cấp quyền. Tôi nghi ngờ rằng rơi vào thể loại "phức tạp triệt để". –

Trả lời

8

Đọc phần "Cách ly đặc quyền giao diện người dùng" của that article một lần nữa cẩn thận hơn. Nó đang đề cập đến mức độ toàn vẹn , không phải là quyền người dùng. Đó là lý do tại sao mạo danh người dùng khác không giải quyết được vấn đề. Mức độ toàn vẹn được thiết lập khi quá trình đầu tiên bắt đầu và không thể thay đổi động trong mã.

User Interface Privilege Isolation (UIPI) là một trong những cơ chế giúp cô lập tiến trình đang chạy như một quản trị viên đầy đủ từ tiến trình đang chạy như một tài khoản thấp hơn so với một quản trị viên trên máy tính để bàn tương tác tương tự. UIPI dành riêng cho cửa sổ và hệ thống con đồ họa , được gọi là USER, hỗ trợ cửa sổ và người dùng điều khiển giao diện.UIPI ngăn ứng dụng đặc quyền thấp hơn từ sử dụng thông báo Windows để gửi dữ liệu nhập từ một quy trình đến quy trình đặc quyền cao hơn . Gửi đầu vào từ quy trình này đến quy trình khác cho phép quy trình chèn đầu vào vào quy trình khác mà không cần người dùng cung cấp thao tác bàn phím hoặc chuột.

Windows Vista triển khai UIPI bằng cách xác định bộ giao diện người dùng cấp đặc quyền theo kiểu phân cấp. Bản chất của các cấp độ là mức độ đặc quyền cao hơn có thể gửi tin nhắn cửa sổ đến ứng dụng chạy ở các cấp thấp hơn. Tuy nhiên, mức thấp hơn không thể gửi tin nhắn cửa sổ đến các cửa sổ ứng dụng đang chạy ở các cấp cao hơn.

Cấp đặc quyền của giao diện người dùng ở cấp quy trình. Khi một quá trình được khởi tạo, hệ thống con người dùng gọi vào hệ thống phụ an ninh để xác định cấp độ toàn vẹn của máy tính để bàn được chỉ định trong mã thông báo truy cập bảo mật của quy trình . Mức toàn vẹn của máy tính để bàn được thiết lập bởi hệ thống phụ bảo mật khi quá trình được tạo và không thay đổi . Do đó, mức đặc quyền giao diện người dùng cũng được đặt bởi Hệ thống con của người dùng khi quá trình được tạo và không thay đổi.

Tất cả các ứng dụng do người dùng chuẩn điều hành đều có cùng một giao diện người dùng cấp đặc quyền. UIPI không can thiệp hoặc thay đổi hành vi của nhắn tin cửa sổ giữa các ứng dụng ở cùng cấp đặc quyền. UIPI có hiệu lực đối với người dùng là thành viên của nhóm quản trị và có thể đang chạy các ứng dụng với tư cách người dùng chuẩn (đôi khi được gọi là quy trình có mã thông báo truy cập được lọc) và cũng có các tiến trình đang chạy với quản trị viên đầy đủ mã thông báo truy cập trên cùng một màn hình. UIPI ngăn chặn các quy trình đặc quyền thấp hơn từ truy cập các quy trình đặc quyền cao hơn bằng cách chặn hành vi được liệt kê bên dưới.

  • Sử dụng móc tạp chí để theo dõi quy trình đặc quyền cao hơn.

Theo this article, ứng dụng của bạn cần một biểu hiện UAC mà xác định cả hai requestedExecutionLevel=requireAdministratoruiAccess=True. Các UIAccess đúng là rất quan trọng:

Bằng cách xác định UIAccess =”true” trong thuộc tính requestedPrivileges, ứng dụng được nêu một yêu cầu để vượt qua những hạn chế UIPI ... Một quá trình được đưa ra với quyền UIAccess:

  • Có thể đặt móc tạp chí.
+0

Remy, cảm ơn nhiều vì câu trả lời. Giả sử tôi có máy chủ COM ngoài quy trình - đã ký và hiển thị exe với uiAccess = True. Máy chủ thiết lập các thủ tục móc và trao đổi dữ liệu với ứng dụng người dùng thông qua các cuộc gọi lại của COM. Vì vậy, tất cả quá trình xử lý vẫn được thực hiện bởi ứng dụng người dùng.Câu hỏi: khi một ứng dụng UI chuẩn (không được ký và chạy mà không có độ cao quyền) sử dụng máy chủ COM như vậy, máy chủ sẽ vẫn có thể đặt các móc tạp chí? – AlexeyDaryin

+0

@AlexeyDaryin: như tên gọi của nó, một máy chủ COM ngoài quy trình chạy trong tiến trình riêng của nó. Quyền của quy trình ứng dụng chuẩn sẽ không ảnh hưởng đến quyền của quy trình máy chủ COM. Bạn có thể cần sử dụng 'CoInitializeSecurity()' để cho phép các quy trình quyền thấp hơn kết nối và sử dụng máy chủ COM của bạn. –

+0

Ok. Nhưng giải pháp này có hợp lý từ quan điểm đơn giản hóa cách sử dụng mô-đun không? Hoặc bất kỳ tùy chọn nào khác? – AlexeyDaryin