Trapping UCHWYTU URZĄDZENIA w WOW64

Question

Próbuję rozwiązać problem powolnego uruchamiania pliku binarnego innej firmy (brak źródła). Jest to 32-bitowa aplikacja działająca w 64-bitowym systemie Windows 7.

Użyłem debuggera, aby włamać się do aplikacji, gdy jest zawieszony przy użyciu 0% użycia procesora podczas uruchamiania i wygląda na to, że czeka na ReadFile powrót. Pierwszym argumentem dla ReadFile jest wartość uchwytu, 000000f0. !handle komenda WinDBG opowiada mi:

Handle f0 
    Type   File 
    Attributes  0 
    GrantedAccess 0x120189: 
     ReadControl,Synch 
     Read/List,ReadEA,ReadAttr,WriteAttr 
    HandleCount  2 
    PointerCount 4 
    No Object Specific Information available 

Chcę wiedzieć, jakie urządzenie to odpowiada. Ale Sysinternals Process Explorer nie uwzględnia tego uchwytu na liście uchwytów procesów.

Użyłem windbg do śledzenia wszystkich połączeń do ntdll!NtCreateFile i wydrukowałem ścieżkę i zwracany uchwyt: Ten uchwyt nie jest wśród nich. Punkty przerwania na kernel32!CreateNamedPipeW, kernel32!CallNamedPipeW i kernel32!WaitNamedPipeW nigdy nie są wyzwalane (co jest nieparzyste, ponieważ Process Explorer pokazał inny uchwyt ze ścieżką \Device\NamedPipe\).

Dla porównania, tutaj jest komenda prześledzić NtCreateFile (akak ZwCreateFile) w systemie Windows x64:

bp ntdll!NtCreateFile "!ustr poi(@r8+10) ; r $t0 = @rcx ; gu ; dd @$t0 L1 ; gc" 

Thanks to Skywing for pointing me in the right direction on that.

Gdzie jeszcze można uzyskać UCHWYT typu File? Czy inne funkcje tworzenia HANDLE nie delegują na NtCreateFile dla rzeczywistej syscall (chyba nie)?

Answer 1

Wygląda na to, że informacje na temat obsługi plików można uzyskać tylko podczas debugowania jądra. Dostępne są 3 opcje.

1. Wykonaj debugowanie jądra lokalnego komputera, nie powinno to stanowić problemu, ponieważ potrzebujesz tylko informacji o uchwytach plików, które pozostaną statyczne. Zobacz: http://msdn.microsoft.com/en-us/library/windows/hardware/ff553382(v=vs.85).aspx
2. Wykonaj zdalne debugowanie jądra maszyny VM. "Bezpieczniej" w tym sensie, że nie możesz wysadzić swojej maszyny.
3. BSOD swoje pudełko i spójrz na zrzut w ten sposób. Znowu niezbyt przyjemna rzecz do zrobienia w pudełku, ale robiłem podobne rzeczy w przeszłości, kiedy musiałem być w stanie przeprowadzić pełną analizę na komputerze bez zmiany stanu maszyny.

Answer 2

Uchwyty mogą być dziedziczone i mogą być również tworzone przez DuplicateHandle(). Możesz spróbować wywołać GetFileInformationByHandleEx na uchwycie i kwerendy dla FileNameInfo.