Przechwyć ruch dla określonej aplikacji

11

Mam aplikację, która komunikuje się z jakimś serwerem. Chcę wiedzieć, jaki jest adres IP tego serwera. Jak mogę przechwycić cały ruch z konkretnej aplikacji, a nie tylko cały ruch, tak jak Wireshark?

— melco-man
źródło

Jakiego systemu operacyjnego używasz? Ile wiesz o aplikacji? Czy wiesz, czy używa określonych portów?

— James Polley,

Windows Server 2008 R2 / Windows 7 Nic nie wiem o numerach portów. Jest to ruch IP (TCP / UDP).

— melco-man

1

Aby to wyjaśnić. Chcesz zobaczyć przynajmniej identyfikator procesu. Ale coś takiego, jak netstat -aon, nie zrobi tego, ponieważ chcesz sprawdzić, czy nie uda się nawiązać połączenia. (Nic nie wiem, a będziesz miał szczęście, jeśli ktoś to zrobi, ale czy możesz wyjaśnić, że tego właśnie chcesz?)

— barlop

Czy wiesz, gdzie aplikacja będzie próbowała się połączyć? Myślę, że możesz użyć Wireshark i filtrów do drążenia w dół do docelowego hosta / adresu IP?

— emtunc

Ponadto, w zależności od rodzaju aplikacji, możesz zmusić ją do przejścia przez serwer proxy i użyć czegoś w rodzaju skrzypka do przechwytywania ruchu tej aplikacji. Nigdy tego nie próbowałem, ale nie rozumiem, dlaczego to nie zadziała. Może to być tak proste, jak zmiana ustawień proxy IE na skrzynkę proxy (domyślnie port 8888) lub tak trudne, jak ponowne skompilowanie aplikacji do korzystania z proxy lub w jakiś sposób zmuszenie aplikacji do korzystania z proxy - jestem pewien, że są tam aplikacje to może to zrobić.

— emtunc

3

Możliwe jest przechwytywanie całego ruchu sieciowego dla danej aplikacji poprzez przechwytywanie wywołań interfejsu API Windows Sockets. Są to narzędzia, które mogą pomóc.

Proxocket napisany przez Luigi Auriemma. Przechwytuje wywołania API i zapisuje przechwycony ruch jako plik .cap zgodny z Wireshark w formacie tcpdump. Nic nie jest bardziej objaśniające niż obraz dostarczony przez samego Luigiego:
NirSoft ma aplikację SocketSniff , która umożliwia przechwytywanie ruchu określonego procesu. Zdjęcie jest również warte tysiąca słów:

Niestety wspomniane narzędzia prawdopodobnie nie będą obsługiwać aplikacji 64-bitowych. Możliwe jest jednak napisanie niestandardowego przechwytywacza przy użyciu biblioteki mhook obsługującej zarówno 32-bitowy, jak i 64-bitowy interfejs API.

— PF4Public
źródło

+1 za darmowe narzędzia NirSoft, które są niewiarygodnie dobre i zwykle przenośne (pojedyncze .exe) i małe (<500 KB). Bardzo utalentowany programista!

— Basj

2

Microsoft Network Monitor może powiedzieć „przechwytuj tylko pakiety wysyłane do i z tej aplikacji”.

-1 dla niejasnej i najczęściej zgadywanej odpowiedzi.

— Cylindryczny

1

Najłatwiejszym w użyciu jest Fiddler 2. Jest to debugger, który pozwala przeglądać żądania HTTP, HTTPS i FTP (oba, jeśli są skonfigurowane) za pomocą dowolnej aplikacji na komputerze.

Po zainstalowaniu, aby wybrać konkretną aplikację, kliknij i przytrzymaj element menu „ Dowolny proces ”, a następnie przeciągnij kursor do otwartego okna i zwolnij go. Będzie wyświetlać tę ukierunkowaną aplikację tylko do momentu kliknięcia prawym przyciskiem myszy elementu menu, który teraz czyta docelowy proces na czerwono, aby ją zwolnić.

http://fiddler2.com/

— cbabb
źródło

Jak korzystać z aplikacji Fiddler do żądań innych niż HTTP / FTP?

— Pacerier

0

W systemie Windows TCPView powinien robić to, czego potrzebujesz: może pokazywać wszystkie połączenia TCP i UDP, które otworzył dany program.

Myślę jednak, że przyda się to tylko wtedy, gdy program otwiera połączenie i pozostawia je otwarte; nie będą pokazywać całego ruchu sieciowego przez dany program. Możliwe jest na przykład, że wykonuje bardzo krótkie połączenie telefoniczne z domem podczas ładowania, ale połączenie zostaje zerwane przed uruchomieniem TCPView.

Process Monitor może pomóc uzyskać więcej szczegółów, ale nie korzystałem z niego, więc nie jestem pewien, jak dużo przechwytuje o gniazdach sieciowych.

— James Polley
źródło

4

TCPView pomoże tylko przy nawiązywaniu połączeń. Muszę zobaczyć nawet nieudane próby połączenia TCP.

— melco-man

1

W takim razie nie mam pomysłów. Prawdopodobnie warto jednak dodać to do pytania.

— James Polley