www.hakin9.org

56

Hakin9 Nr 6/2004

O

br

on

a

www.hakin9.org

57

Hakin9 Nr 6/2004

Reverse engineering w analizie powłamaniowej

M

iesiąc temu podczas analizy skom-
promitowanego systemu natrafiłem
na pozostawiony przez intruza w ka-

talogu /usr/share/doc/shellutils program o na-
zwie kstatd. Standardowa analiza powłama-
niowa, oparta na badaniu informacji w pamięci
i na dysku skompromitowanego systemu, nie
pozwoliła na pełne ustalenie roli pełnionej
przez podejrzany plik. Nie miałem możliwości
odtworzenia śladów kodu źródłowego – pro-
gram albo został skompilowany na skompromi-
towanej maszynie i skutecznie usunięto ślady
jego kodu źródłowego, albo został wprowadzo-
ny do systemu w postaci skompilowanej. W ta-
kiej sytuacji jedynym rozwiązaniem było prze-
prowadzenie szczegółowej analizy kodu znale-
zionego programu, zwanej również inżynierią
odwrotną (reverse engineering).

Działania, które przeprowadziłem można

nazwać analizą statyczną – analizowany kod
nie był w ogóle uruchamiany. Końcowe wnioski
powstały wyłącznie na podstawie badania bu-
dowy i zawartości analizowanego obiektu.

Niezbędne narzędzia

Jako platformę do przeprowadzenia analizy wy-
korzystałem system Mandrake Linux 10.0. Za-

Inżynieria odwrotna

kodu wykonywalnego ELF

w analizie powłamaniowej

Marek Janiczek

Inżynieria odwrotna, kojarząca

się najczęściej z łamaniem

zabezpieczeń oprogramowania,

może być z powodzeniem

zastosowana w analizie

powłamaniowej. W jej wyniku

uzyskamy odpowiedzi na pytania

o rolę, możliwości i mechanizm

działania znalezionych

w systemie podejrzanych plików.

stosowane narzędzia to programy standardo-
wo dostępne w systemach Linux i rodzinie BSD
oraz kilka innych, dostępnych publicznie w Inter-
necie. Standardowe narzędzia systemowe do-
starczane w dystrybucjach to przede wszystkim
pakiet binutils (GNU binary utilities). Z tego pa-
kietu wykorzystamy następujące programy:

• ar – do uzyskania informacji o obiektach biblio-

tek (z archiwów *.a) oraz ich wydobywania,

• nm – do otrzymania listy odniesień symbo-

licznych (symboli) w obiektach,

• objdump – umożliwiający uzyskanie szcze-

gółowych informacji o obiekcie i jego za-
wartości,

Z artykułu nauczysz się...

• w jaki sposób przeprowadzić deasemblację ko-

du wykonywalnego ELF,

• jak wykorzystać inżynierię odwrotną podczas

analizy powłamaniowej w Linuksie.

Powinienieś wiedzieć...

• powinieneś znać przynajmniej podstawy pro-

gramowania w językach C i Asembler.

www.hakin9.org

56

Hakin9 Nr 6/2004

O

br

on

a

www.hakin9.org

57

Hakin9 Nr 6/2004

Reverse engineering w analizie powłamaniowej

• strings – do wydobywania cią-

gów drukowalnych znaków ASCII
z pliku.

Dodatkowo zastosujemy:

• ht – przeglądarkę, edytor i anali-

zator wielu typów plików wykony-
walnych,

• elfsh – narzędzie umożliwiają-

ce interaktywne przeglądanie
szczegółów formatu ELF,

• ndisasm – program do deasem-

blacji plików binarnych dla plat-
formy x86,

• elfgrep – narzędzie do wyszuki-

wania obiektów (na przykład bi-
bliotek) w innych obiektach ELF.

Poza narzędziami zastosowanymi
w trakcie analizy warto wspomnieć

o bardzo dobrym komercyjnym na-
rzędziu IDAPro. Jest to program
działający w środowisku Windows,
służący do deasemblacji różnych
typów plików wykonywalnych (rów-
nież ELF), dla różnych rodzin pro-
cesorów. Przeprowadza automa-
tyczną analizę oraz posiada moż-
liwość autokomentowania. My jed-
nak – ze względu na jego komer-
cyjny charakter i użyty do badania
system operacyjny – nie będziemy
go stosować. Wykorzystamy narzę-
dzia darmowe, udostępniane na li-
cencji GNU.

Wstępne

rozpoznanie obiektu

Proces analizy należy rozpocząć od
uzyskania podstawowych informacji
o analizowanym obiekcie. Informa-

cje uzyskane na tym etapie nada-
dzą kierunek naszym dalszym dzia-
łaniom. Do uzyskania tych informacji
wykorzystamy standardowe narzę-
dzie systemowe file.

# file kstatd
kstatd: ELF 32-bit LSB executable,
Intel 80386, version 1 (SYSV),
for GNU/Linux 2.2.5,
statically linked, stripped

W wyniku działania tego pole-
cenia uzyskaliśmy między in-
nymi informację o typie obiek-
tu – jest to program wykonywal-
ny w formacie ELF (patrz Ram-
ka Format ELF) oraz architektu-
rze, dla której został skompilowa-
ny (Intel 80386, 32-bit, LSB – least
significant byte). Uzyskaliśmy rów-
nież informację o tym, że ana-
lizowany obiekt jest skompilo-
wany statycznie (statically lin-
ked), oraz że został on podda-
ny procesowi strippingu (strip-
ped). Przykładem innych infor-
macji, które również można uzy-
skać w wyniku działania polecenia
file uruchamianego dla programu
wykonywalnego, są ewentualne
nieprawidłowości w nagłówku ELF.

Wyszukiwanie ciągów znaków

Kolejnym etapem wstępnego roz-
poznania jest wyszukanie w anali-
zowanym programie interesujących
(podejrzanych) łańcuchów znaków.
Przeszukanie programu pod tym ką-
tem da nam kilka wskazówek o plat-
formie, na której został zbudowa-
ny oraz pozwoli na wstępne ustale-
nie, jakie podejrzane działania mo-
że wykonywać. Należy pamiętać,
że nawet najdrobniejsze szczegó-
ły mogą się okazać pomocne w dal-
szej analizie.

Do wyszukania łańcuchów zna-

ków

zastosujemy

niezastąpio-

ne narzędzie strings, wyświetlają-
ce sekwencje drukowalnych zna-
ków (ASCII) ze wskazanego obiek-
tu, których długość ma nie mniej niż
4 znaki (wartość domyślna; można ją
zmienić – opcja

-n

). Stosując narzę-

dzie strings trzeba mieć jednak świa-
domość, że w przypadku obiektów

Format ELF

ELF (Executable and Linking Format) to typowy dla systemów Linux format trzech ty-
pów obiektów binarnych: realokowalnych, wykonywalnych oraz współdzielonych.

• Obiekty realokowalne (z rozszerzeniem *.o) to takie, które podlegają łączeniu z in-

nymi w celu utworzenia pliku wykonywalnego lub biblioteki współdzielonej – są to
pliki wynikowe kompilatorów i asemblerów.

• Obiekty wykonywalne to pliki gotowe do uruchomienia, już po procesie realokacji

i z rozwiązanymi odwołaniami symbolicznymi (z wyjątkiem tych, które dotyczą od-
wołań do bibliotek współdzielonych, rozwiązywalnych w trakcie uruchomienia).

• Obiekty współdzielone (z rozszerzeniem

*

.so) to takie, które zawierają kod i dane

mogące brać udział w procesie łączenia obiektów w dwóch kontekstach. Pierw-
szy to łączenie przez linker z realokowanymi lub współdzielonymi obiektami w ce-
lu utworzenia innego obiektu. Natomiast drugi to łączenie z kodem programu wy-
konywalnego przez systemowy program ładujący (linker/loader) w celu utworzenia
w pamięci obrazu procesu.

Podstawowym elementem plików w formacie ELF jest nagłówek ELF (patrz Rysunek 1).
Nagłówek ten stanowi swego rodzaju mapę organizacji pozostałej części pliku i znajdu-
je się zawsze na jego początku. W nagłówku ELF znajdują się m.in. takie elementy jak:
lokalizacja nagłówka programu i nagłówka sekcji względem początku pliku, adres (tzw.
entrypoint), pod który będzie przekazana kontrola po uruchomieniu programu oraz nie-
zależne od platformy sprzętowej informacje określające sposób interpretacji danych za-
wartych w pliku (ident).

Dla zapewnienia właściwej elastyczności formatu ELF zaprojektowano dwa rów-

noległe widoki obiektów w tym formacie: widok łączenia i widok wykonywania (patrz
Rysunek 2). W trakcie budowy obiektu, kompilatory, assemblery i linkery traktują plik
w formacie ELF jako zbiór sekcji opisanych w nagłówku sekcji (tzw. widok łączenia),
z opcjonalnym nagłówkiem programu (patrz Rysunek 3). Natomiast systemowy pro-
gram ładujący pliki wykonywalne (linker/loader) traktuje plik w formacie ELF jako zbiór
segmentów opisanych w nagłówku programu (tzw. widok wykonywania), z opcjonal-
nym nagłówkiem sekcji. Widok łączenia nie jest konieczny do poprawnego uruchomie-
nia i działania kodu wykonywalnego.

Do przeglądania i analizy struktury plików w formacie ELF oraz zawartych w nich

informacji można wykorzystać program objdump, narzędzie elfsh lub program ht peł-
niący jednocześnie rolę przeglądarki, edytora i analizatora.