Wdrożenie Win32 Hooks DLL do aplikacji Zbudowane przeciwko "Any CPU"

Question

Pracuję nad projektem, który przechwytuje wszystkie interakcje użytkownika. MSDN mówi (this)

SetWindowsHookEx może być użyty do wstrzyknięcia biblioteki DLL do innego procesu. 32-bitowa biblioteka DLL nie może zostać wstrzyknięta do procesu 64-bitowego, a 64-bitowa biblioteka DLL nie może zostać wstrzyknięta do procesu 32-bitowego. Jeśli aplikacja wymaga użycia haków w innych procesach, wymagane jest, aby 32-bitowa aplikacja wywoływała SetWindowsHookEx w celu wstrzyknięcia 32-bitowej biblioteki DLL w 32-bitowe procesy , a 64-bitowe wywołanie aplikacji SetWindowsHookEx w celu wstrzyknięcia 64-bitowa biblioteka DLL na procesy 64-bitowe.

Moje pytanie brzmi, co się stanie, jeśli aplikacja została zbudowana przeciwko Any CPU. Czy muszę zadzwonić pod numer SetWindowsHookEx z biblioteki DLL zbudowanej na bazie Any CPU.

Pisałem HookLogger_32.exe ładuje HookFunctions_32.dll (zarówno x86) i HookLogger_64.exe ładuje HookFunctions_64.dll (zarówno x64) ustalanie WH_CBT i WH_MOUSE globalnie (nie konkretny wątek).

Pliki HookLogger_32.exe, HookLogger_64.exe, HookFunctions_32.dll i HookFunctions_64.dll są napisane w C++.

Po kliknięciu na aplikację .NET zbudowaną na bazie Any CPU, te biblioteki DLL zostają wstrzyknięte (przez SetWindowHookEx). System operacyjny Windows zawiesza się & Muszę na siłę zrestartować mój komputer.

Gdy ta sama aplikacja .NET jest zbudowana przeciwko architekturze x86 lub x64, a po kliknięciu aplikacji po uruchomieniu HookLoggers (zarówno 32 & 64 bit) wszystko działa poprawnie.

Przyczyny tego niezdefiniowanego zachowania.

Platforma, na której pracuję, to komputer 64-bitowy.

Answer 1

Trzeba wstrzyknąć z biblioteki DLL odpowiednią bitnse - tzn. "Dowolny procesor" staje się 32 lub 64-bitowy w czasie wykonywania ... a twoja biblioteka DLL musi być zgodna z wersją środowiska wykonawczego!

coś pożytecznego w danej sytuacji jest znany jako „zespołu side-by-side” (dwie wersje tego samego zespołu, jeden 32 i drugi 64-bitowy) ... Myślę, że znajdziesz te pomocne:

• Using Side-by-Side assemblies to load the x64 or x32 version of a DLL
• http://blogs.msdn.com/b/gauravseth/archive/2006/03/07/545104.aspx
• http://www.thescarms.com/dotnet/Assembly.aspx

Tutaj można znaleźć ładny instruktażu, który zawiera wiele informacji pomocnych sztuk - opisuje .NET DLL wrapping C++/CLI DLL referencing a native DLL

UPDATE:

Aby zahaczenie bardzo proste i wytrzymałe zobaczyć this well-tested and free library - między innymi współpracuje z AnyCPU!

Answer 2

Domyślam się, że Twoim głównym problemem jest to, że próbujesz wtłoczyć procesor .NET do natywnego procesu, który z pewnością nie zadziała. Nie jestem nawet pewien, czy SetWindowsHookEx obsługuje wstrzykiwanie zestawu .NET w procesie CLR. Rozwiązaniem problemu jest:

1. Przepisz/skompiluj bibliotekę dll za pomocą natywnego kompilatora, takiego jak C++/Delphi/VB itp., Dla platform x86 i x64.
2. Upewnij się, że dll zależy tylko od bibliotek systemowych. Na przykład nie powinno zależeć od żadnej biblioteki DLL, która nie jest dostarczana z oknami, ponieważ możesz zawiesić proces docelowy. Do identyfikacji zależności można użyć narzędzia "Dependency Walker".
3. Jak wspomniano w MSDN, powinieneś mieć wykonywalny wtryskiwacz dla każdego procesora, który chcesz obsługiwać. W tym przypadku x86 i x64.

Można też użyć lepszej biblioteki do wtrysku/zaczepiania, takiej jak madCodeHook lub Objazdy. W ten sposób przezwyciężysz problem nr 3, nie wspominając o dziesiątkach profesjonalistów, których dostarczają.

Answer 3

Właśnie z twojego opisu problemu zgaduję, że ... Twój skompilowany program Any CPU ładuje się z kodem x86, który uruchamia twój hak 32-bitowy, następnie sprawdza kody x86 i widzi, że środowisko ma 64-bitową obsługę i uruchamia się 64-bitowa wersja CLR.

W tym scenariuszu 32-woltowa biblioteka Hook pobiera komunikat WH_SHELL i próbuje wstrzyknąć do procesu (kod x86), który już się zakończył lub wstrzyknięcia 32-bitowego haka do 64-bitowego procesu CLR. W ten sposób twoja "bardzo niejednoznaczna i musi zostać opracowana na temat" awarii systemu.

Jeśli chcesz wyjaśnić, co faktycznie robi twój kod, to otrzymasz więcej pomocy (i mniej uogólnień oraz "skorzystaj z programu A"). Czy faktycznie wprowadzasz kod do procesu lub wołasz SetWindowsHookEx z dwThreadId procesu.

Answer 4

Na komputerze 32-bitowym powinno być oczywiste, że aplikacja typu Any CPU przyjmuje dowolność.

Komputer 64-bitowy otrzymuje dwie osobne instalacje platformy .NET Framework: po jednej dla każdej bitness. Aplikacja .NET skompilowana tak, jak w przypadku dowolnego procesora, ponieważ cel zwykle działa w 64-bitowej instalacji, ale może również działać w 32-bitowej instalacji, jeśli odwołuje się do innej aplikacji, która jest bezpośrednio skierowana na x86. Dzięki temu możesz być pewien, co otrzymujesz, jeśli wiesz, jak aplikacja jest uruchamiana: jako niezależny proces lub przez odniesienie.

Nie podałbym żadnych założeń. Nie należy zakładać, że proces jest 64-bitowy na komputerze 64-bitowym: może on być potencjalnie 32-bitowy. Sprawdź go poprawnie, aby zobaczyć, w którym trybie działa. Następnie wstrzyknij odpowiednio 32-bitowy lub 64-bitowy.

Powodem, dla którego musisz używać tej samej bitness co proces docelowy, jest to, że z przyczyn technicznych, których nie otrzymam, takie haki nie mogą przekroczyć tak zwanej bariery SysWOW. SysWOW pozwala aplikacjom 32-bitowym działać na 64-bitowym komputerze, 16-bitowym aplikacjom na komputerze 32-bitowym itp. "Przekraczasz barierę", gdy komunikujesz się między aplikacjami działającymi po różnych stronach SysWOW - tak, jeden działa w obrębie SysWOW (32-bitowy), a drugi nie (64-bitowy). Mówiąc najprościej, proces musi być całkowicie w SysWOW lub poza nim. W związku z tym nie można dodać 32-bitowego kodu do procesu 64-bitowego i na odwrót.