www.hakin9.org

Hakin9 Nr 6/2004

www.hakin9.org

Hakin9 Nr 6/2004

Reverse engineering w analizie powłamaniowej

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

Hakin9 Nr 6/2004

www.hakin9.org

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.