0xcafebabe -- per aspera ad astra

Narzędzie objdump okazuje się niezastąpione przy szybkich analizach plików binarnych, lub wszędzie tam, gdzie mamuty typu IDA Pro przestają dawać radę.

Być może ostatnie kilka wyrazów wepchnęło cię w osłupienie ;), ale po prostu czasami nie warto tracić czasu na uruchomienie dedykowanych deasemblerów, nie warto tracić kontekstu pracy przy tworzeniu nowych okien tych programów, nie warto tracić nerwów przy próbie dowiedzenia się, że standard rynkowy inżynierii wstecznej nie obsługuje jakiegoś mniej popularnego formatu wykonywalnego mniej popularnej architektury, czy też zwyczajnie nie warto wytaczać ciężkich dział przy polowaniu na muchy.

Program objdump jest jednym z tych programów, które okazują się szwajcarskim scyzorykiem podczas analiz plików binarnych, których formaty mają jakiś związek z formatami używanymi do enkapsulacji informacji opisujących program; przy czym najczęstsze przypadki jego użycia to wyświetlanie symboli plików wykonywalnych lub obiektowych, wyświetlanie metadanych służących do opisu typów i struktur zmiennych używanych w programie (popularnie zwane debug info), wyświetlanie tablic relokacji programu, oraz deasemblacja, która zawiera kilka ciekawych opcji, które nie są wyszczególnione na stronie man programu objdump.

Notacja asemblera – AT&T lub Intel

Przede wszystkim, opcją -M można wybrać notację asemblera używaną w dead-listingach. Domyślna notacja nazywa się notacją AT&T i niektórych przyprawia o migrenę ;), mimo tego, że jest standardową notacją używaną na systemach UNIX'owych. Turyści z systemu Windows szybko się jednak zniechęcają, ponieważ na Windowsach króluje notacja Intel'owska. Opcja -M intel zmienia sposób reprezentacji notacji, więc każdy powinien poczuć się jak w domu.

Przykład notacji AT&T:

Przykład notacji Intel:

Podkreślanie różnic pomiędzy tymi dwoma stylami reprezentacji kodu asm jest zupełnie bez celu – wielki Internet zawiera tysiące informacji na ten temat. Sugeruję użycie wielkiego brata, by wskazał prawidłową drogę ku oświeceniu ;).

Interpretowanie relokacji przy deasemblacji

Objdump nie interpretuje automatycznie relokacji w plikach. Dzieje się tak dlatego, że jest to dość podstawowy program, który nie ma zamiaru myśleć za użytkownika. Dlatego też domyślna opcja deasemblacji interpretuje opkody w sposób taki, jak są one zapisane w pliku – jeśli pewna część informacji zostanie nadpisana przez relokacje, wtedy faktyczny wygląd kodu w pamięci po załadowaniu programu będzie nieco odbiegał od informacji prezentowanych nam przez program objdump. Przykładowo, podczas deasemblacji pliku .o:

Offsety 5a, 6d i 80 zawierają instrukcję CALL, która woła pewną funkcję. Zgodnie z listingiem, jej adres to po prostu zero, co wydaje się błędne, ponieważ w tym wypadku funkcja wołałaby różne miejsca samej siebie trzy razy po kolei, co jest po prostu nielogiczne. Zamiast tego, podczas procesu ładowania pliku wykonywalnego do pamięci, niedługo przed rozpoczęciem jego wykonania, zera w argumencie opkodu E8 zostają relokowane przez program ładujący na inne wartości, które można obejrzeć korzystając z podglądu relokacji (przy pomocy argumentu -r):

Nie jest to jednak wygodne rozwiązanie, by manualnie szukać offsetów relokowanych i zapamiętywać podstawienia przy odpowiednich adresach, dlatego obie opcje – deasemblacji i wyświetlania relokacji – można połączyć w opcję „relokacyjnej deasemblacji” (-dr):

Od razu lepiej :)

Deasemblacja plików binarnych

Wybór rozmiaru kodu i rozmiaru adresowania zwykle jest wykonywany przez sam program deasemblujący na podstawie informacji zawartych w pliku kontenera (np. PE dla Windows, ELF dla UNIX'ów). Zwykle jest to informacja, czy zapisany w pliku kod jest kodem 16-bitowym, 32-bitowym, lub 64-bitowym. Problemem okazuje się plik, w którym nie ma formatu, a jedynie jest prostym zrzutem opkodów, np. pliki .com, czy pliki które sami stworzylismy poprzez Copy & Paste, czy inną metodę ;).

Karmiąc takimi plikami program objdump zwykle dostaniemy błąd w postaci nieznanej struktury pliku, jednak da się wymusić dekompilację na nasz wybrany sposób adresowania przy pomocy argumentu -b, -m oraz -M:

Co daje nam w rezultacie czysty 16-bitowy kod programu zapisanego w pliku .com. Adresowanie 32-bitowe można uzyskać modyfikując linię poleceń i zamieniając addr16,data16 na addr32,data32. Kod 64-bit wymagałby zmiany celu z i386 na cel 64-bitowy i zmianę trybu adresowania instrukcji i danych z 32 na 64 bity.

Deasemblacja od konkretnego offsetu

Czasami w kodzie znajduje się skok „w środek instrukcji”, co oczywiście nie jest skokiem w środek per se, ale sugeruje jedynie takie wrażenie, ponieważ zawartość kilku bajtów przed celem skoku może ułożyć się w taki sposób, że zmyli deasembler i zmusi go do kompilacji kodu, którego w rzeczywistości nie ma ;). Przykładowo, posłużę się znowu programem .com:

Jak widać na powyższym listingu, dekompilator nie załapał się na offset 0x4EC, ponieważ idąc z góry na dół, napotykając zero przy offsecie 0x4EB zinterpretował je jako instrukcję ADD, robiąc z offsetu 0x4EC, 0x4ED i 0x4EE argumenty instrukcji ADD. Jednak z semantycznego punktu widzenia, zero z offsetu 0x4EB stanowi wypełnienie (padding) lub bufor danych o niesprecyzowanym celu, za to bajt spod offsetu 0x4EC stanowi pierwszy bajt nowej instrukcji, co sugerowane jest przez skok w ten offset przy adresie 0. Przy okazji, technika ta (tutaj uzyskana raczej w losowy sposób) dość powszechnie stosowana jest w różnego rodzaju obfuskatorach kodu, które mają za zadanie ukryć prawdziwy kod przed prostymi dekompilatorami, typu objdump właśnie.

Bardziej zaawansowane dekompilatory typu IDA Pro potrafią automatycznie poradzić sobie z takimi problemami, jednak z uwagi na niskopoziomowość objdump tutaj nie mamy tego szczęścia i musimy poradzić sobie ręcznie, przy pomocy argumentu --start-address:

Po raz kolejny, kod stał się czytelny i można analizować go dalej ;).

Demanglement ;), lub też usuwanie dekoracji nazw symboli

Pod enigmatycznym określeniem „mangling” kryje się proces enkodowania zapisu typu symbolu z postaci języka programowania, do prostej, jednoznacznej metody, zaimplementowanej za pomocą prostego algorytmu. Innymi słowy, zmienne, funkcje, w klasach, czy nie, muszą mieć jednoznaczny identyfikator, który pomoże linkerowi w odróżnieniu, gdzie znajduje się dany symbol, do którego odwołuje się np. któraś funkcja. Linker nie może po prostu traktować symboli po samych ich nazwach, ponieważ pogubiłby się przy napotkaniu np. dwóch zmiennych nazywających się tak samo, ale istniejących w dwóch różnych namespace'ach, czy przy napotkaniu dwóch funkcji z przeciążonymi argumentami. Stąd konieczność uwzględniania w nazwie symbolu całej sygnatury danego obiektu, nie tylko nazwy; czyli razem z miejscem, gdzie dany obiekt się znajduje, typem obiektu, listą argumentów, jeśli obiekt jest funkcją, etc.

Kiedyś pisałem na ten temat krótką notkę, która brała na „ruszt” sposób enkodowania sygnatur w języku Java. Proces enkodowania nazwy obiektu na sygnaturę nazywa się więc mangling'iem, proces dekodowania – demanglingiem (niestety nie znam polskich nazw). Nie są to prawdopodobnie oficjalne nazwy, ponieważ nie mają za dużo wspólnego z oficjalnym stwierdzeniem „dekoracji nazw”, ale jakie to ma znaczenie ;).

Każdy kompilator ma swoją technikę manglowania nazw i nie ma jednej metody na odczytanie ich wszystkich. Objdump posiada kilka algorytmów, adresujących różne kompilatory (m.in. Java), dlatego opcja ta jest dość użyteczna.

Przykład domyślnych ustawień:

Przykład użycia opcji --demangle (-C):

Inne procesory

Dla innych procesorów, nawet takich z którymi IDA Pro nie potrafi sobie poradzić, stosuje się inne buildy programu objdump. Przykładowo, asembler wykorzystany w mikrokontrolerach attiny13 może być zdekompilowany przy użyciu programu avr-objdump:

Część opcji innych buildów jest kompatybilna z oryginalnym programem objdump, jednak wiadomo, że jeśli w grę wchodzi nowy procesor, część konceptów może być po prostu z nim niekompatybilna (np. adresowanie 64bit w attiny13), dlatego przed użyciem polecam jednak przeczytać tą j...ą instrukcję ;) danego builda objdump.