IDA Pro zawiera solidną obsługę debugowania, zarówno lokalną, jak i zdalną. Lokalne debugowanie jest obsługiwane przez platformy, na których zainstalowany jest IDA Pro, w tym macOS, Linux i Windows. Zdalne debugowanie jest obsługiwane na różnych platformach, w tym iOS, XNU, BOCHS, Intel PIN, Android i innych. W tej sekcji skupimy się na przykładzie zdalnego debugowania przy użyciu serwera GDB działającego na docelowej maszynie wirtualnej Kali Linux i IDA Pro działającego na maszynie wirtualnej z systemem Windows 10. IDA Pro zawiera wiele fragmentów zdalnego debugowania, które można skopiować do wybranego systemu docelowego, w którym aplikacja ma być debugowana. Przejdźmy od razu do przykładu zdalnego debugowania za pomocą IDA Pro. W tym przykładzie używamy skompilowanej wersji programu myProg dostarczonej w folderze ~/GHHv6/ch05, po uprzednim sklonowaniu repozytorium Git Gray Hat Hacking 6th Edition. To nie jest laboratorium; jeśli jednak chcesz kontynuować, ten program jest potrzebny w systemie, w którym zainstalowany jest IDA, a także w docelowym systemie Kali Linux. Wymagana jest łączność sieciowa pomiędzy systemem, na którym działa IDA Pro (debugger) a systemem, na którym działa program docelowy (debuggee), ponieważ serwer GDB nasłuchuje na wyznaczonym numerze portu TCP i oczekuje na żądanie połączenia. Poniższe polecenie uruchamia serwer GDB dla programu myProg i nakazuje mu nasłuchiwanie na porcie TCP 23946 w oczekiwaniu na połączenie przychodzące. Opcja –once kończy pracę Serwera GDB po zamknięciu sesji TCP, zamiast automatycznie uruchamiać ją od nowa.
Gdy serwer GDB działa w docelowym systemie debugowania, czas załadować program myProg do IDA Pro w systemie debugera. Pozwalamy IDA Pro przeprowadzić automatyczną analizę i wybrać opcję Remote GDB Debugger, jak pokazano na rysunku
Teraz klikamy Debuger | Opcje procesu z menu IDA Pro. Spowoduje to wyświetlenie okna dialogowego pokazanego na rysunku
Opcje aplikacji i pliku wejściowego są ustawione na folder lokalny, w którym znajduje się program myProg. Na przykład, gdybyśmy debugowali bibliotekę DLL załadowaną przez aplikację docelową, opcje aplikacji i pliku wejściowego byłyby inne. W opcji Hostname wprowadziliśmy adres IP docelowego systemu debugowanego. Domyślny numer portu to 23946, dlatego użyliśmy tej samej opcji w systemie docelowym z serwerem GDB. Po zaakceptowaniu tych opcji klikamy przycisk Odtwórz, pokazany na rysunku . Następnie pojawia się wyskakujące okienko z informacją: „Istnieje już proces debugowany zdalnie. Czy chcesz się do tego przywiązać?” Klikamy Tak, umożliwiając IDA Pro podłączenie się do zdalnego serwera GDB. Próba debugowania zakończyła się pomyślnie i po dołączeniu wstrzymuje wykonywanie, jak pokazano na rysunku
W oknie debugowania znajduje się kilka sekcji. Jeśli znasz inne debugery, sekcje powinny wyglądać znajomo. Główną i większą sekcją, zwaną IDA View-RIP, jest widok demontażu. Obecnie widzimy, że wskaźnik instrukcji (RIP) wskazuje adres pamięci zawierający instrukcję mov rdi, rsp. Większość sekcji w oknie debugowania można przewijać. Sekcja poniżej okna deasemblacji, zwana Hex View-1, zrzuca dowolny żądany segment pamięci w postaci szesnastkowej. Na prawo od widoku szesnastkowego-1 znajduje się widok stosu. Domyślnie zaczyna się od adresu wskaźnika stosu (RSP), zrzucając zawartość pamięci dla stosu bieżącego wątku. Nad sekcją Widok stosu znajdują się sekcje Wątki i Moduły. Wreszcie w prawym górnym rogu znajduje się sekcja Rejestry ogólne. W tej sekcji przedstawiono rejestry procesora ogólnego przeznaczenia, a także rejestry dodatkowe, w tym rejestr FLAGS i rejestry segmentowe. Elementy sterujące debugera są aktywowane za pomocą przypisanych skrótów klawiszowych, ikon menu na pasku wstążki lub przechodząc przez menu debugowania. Jeśli klikniemy Odtwórz, aby umożliwić kontynuowanie wykonywania programu, program po prostu się zakończy, ponieważ nie podaliśmy żadnych argumentów wiersza poleceń. Patrząc na tabelę Imports w tym programie, widzimy, że istnieje wywołanie przestarzałej funkcji strcpy, jak pokazano na rysunku
Następnie używamy przeglądarki zbliżeniowej do śledzenia ścieżki od funkcji głównej do strcpy, jak pokazano na rysunku
Patrząc na funkcję func1, możemy zobaczyć wywołanie strcpy, a także rozmiar bufora dla miejsca docelowego wynoszący 0x40, czyli 64 bajty. Następnie ustawiamy punkt przerwania w wywołaniu strcpy, jak pokazano na rysunku klikając adres i naciskając klawisz skrótu F2 punktu przerwania.
Po ustawieniu punktu przerwania w funkcji strcpy i zrozumieniu rozmiaru bufora docelowego, podajmy 100 bajtów jako nasz argument, aby sprawdzić, czy uda nam się spowodować awarię procesu. Modyfikujemy naszą komendę gdbserver tak, aby zawierała na końcu składnię języka Python:
Następnie klikamy przycisk Odtwórz wewnątrz IDA, aby zainicjować połączenie z debugowanym narzędziem. Po podłączeniu musimy ponownie kliknąć przycisk Odtwórz, aby przejść do punktu przerwania funkcji strcpy. Wynik pokazano na rysunku .
Argument źródłowy został zrzucony do sekcji Widok szesnastkowy, dzięki czemu możemy zobaczyć, co zostanie skopiowane do bufora docelowego na stosie. Naciśnięcie klawisza skrótu Kontynuuj wykonywanie F9 w IDA powoduje oczekiwaną awarię, jak pokazano na rysunku
Z debugera pobierane są fragmenty, które pokazują ostrzeżenie o błędzie segmentacji, czyli wynik Ogólne Sekcja rejestrów i sekcja widoku stosu.