IAT Redirection

Themida to exe-protektor, który posiada opcję ukrywania tabeli importów aplikacji poprzez ukrycie faktycznych adresów funkcji w bibliotekach DLL.

Działa to na tej zasadzie, że w zabezpieczonej aplikacji, po jej uruchomieniu, adresy funkcji w tabeli importów, które normalnie wskazuja na jakieś funkcje, np. na ExitProcess(), sa zamienione adresami kodu, który w końcu wykona skok do przykładowego ExitProcess().

Technika ta ma nazwę API Redirectingu lub inaczej – IAT Redirection, Import table redirection (w obiegu jest kilka nazw).

Celem tej techniki zabezpieczeń jest uniemożliwienie odtworzenia struktury pliku wykonywalnego z pamięci, praktycznie każdy nowoczesny protektor wykrzystuje jakąś formę tej ochrony.

Tablica importów

Struktura tabeli importów w bardzo dużym skrócie przedstawia się następująco (dla bardziej zaciekawionych polecam poszukać IMAGE_IMPORT_DESCRIPTOR):

Tak wygląda ona w niezabezpieczonym pliku, czyli mamy bloki odpowiadające kolejnym bibliotekom, z których korzysta nasza aplikacja, w każdym bloku znajdziemy adresy tych funkcji (po załadowaniu aplikacji, wskazują na bezpośredni kod np w KERNEL32.dll).

Po potraktowaniu pliku protektorem Themida, po jego załadowaniu do pamięci, struktura będzie wyglądać następująco:

Przykładowa funkcja ExitProcess() ma taki kod:

Widać, że po zabezpieczniu, oryginalne instrukcje z funkcji zostały pomieszane z kodem zaciemniającym.

Jak działa redirecting w Themida

Proces redirectingu wygląda następująco:

• Themida tworzy tymczasowy bufor pamięci na kod redirectora
• oryginalna funkcja ExitProcess() poddana jest procesowi deasemblacji
• w kodzie redirectora umieszczane są bloki i instrukcje zaciemniające działanie (nie robiące nic, taki syf po prostu)
• początkowe instrukcje z funkcji ExitProcess() poddane są mutacji (jedna instrukcja jest rozbijana na równoważny zestaw innych instrukcji)
• kod zmutowanych instrukcji oryginalnej funkcji jest pomieszany z kodem zaciemniającym
• na samym końcu kodu redirectora, umieszczony jest skok do pozostałego fragmentu funkcji ExitProcess()

Całość sprawia, że wywołanie funkcji ExitProcess() z poziomu aplikacji przebiega dokładnie tak samo, jak to ma miejsce w niezabezpieczonej aplikacji.

Jak odtworzyć tak zabezpieczoną tablicę importów?

Publiczne narzędzia jak np. ImpRec posiadają wtyczki potrafiące poradzić sobie z różnymi zabezpieczeniami tabel importów, jednak akurat mój przypadek był taki, że musiałem skorzystać ze skryptu ODbgScript, który służy do sterowania debuggerem OllyDbg.

Jak działa mój skrypt

Kilka słów o działaniu mojego skryptu, kolejne etapy przedstawiają się tak:

Skanowanie obszaru tabeli importów

Aplikacja po załadowaniu do debuggera i dojściu do OEP jest zatrzymywana po czym skrypt skanuje ręcznie wybrany obszar wskazujący na tabelę importów (na tabelę wskaźników do funkcji).

Na tym etapie odrzucane są błędne wskaźniki oraz funkcje, które nie zostały  poddane procesowi zabezpieczenia, są to np. adresy funkcji, które nie są funkcjami, a np. wskaźnikami na dane w bibliotece DLL, przykład to funkcja _acmdln() z rodziny bibliotek MSVCRT.dll).

Odbudowa kodu redirectora

Jeśli znaleziony zostanie kod redirectora dla kolejnej funkcji, poddawany jest on takim procesom jak:

• optymalizacja mająca na celu usunięcie śmieci z kodu redirectora (tzw. junki)
• przebudowa adresów docelowych instrukcji jxx (branche), które podczas zabezpieczenia kodu funkcji były rozwinięte do form długich (jxx near), oraz ich skrócenie do form krótkich (jxx short)
• demutacja rozbitych instrukcji na oryginalne formy, Themida stosuje niewielki zestaw kilku mutacji dla najpopularniejszych instrukcji
• ponowna optymalizacja kodu, poprawienie branchów, usunięcie śmieci powstałych z demutacji

Tworzenie patternów

Odbudowany kod redirectora po takim procesie będzie w 99% wierną kopią zredirectowanych początkowych instrukcji zabezpieczonej funkcji.

Teraz, mając fragment oryginalnej funkcji, tworzony jest z niej wzorzec binarny (z maskowaniem adresów niektórych instrukcji, np. „E9????????”).

Taki wzorzec jest następnie poszukiwany w pamięci bibliotek DLL aplikacji i jeśli zostanie znaleziony jest to równoznaczne ze znalezieniem poprawnej funkcji, której adres może być umieszczony w pamięci tabeli importów i tym razem bezproblemowo można skorzystać z narzędzi typu ImpRec do odbudowy tabeli importów i symbolicznych nazw wykorzystanych funkcji.

Wady, zalety i efekty uboczne

Do wad skryptu należy to, że w 1% przypadków odbudowany kod niekoniecznie będzie idealnie taki jak kod ze zredirectowanej funkcji i tym samym nie będzie możliwe po jego wzorcu znalezienie tej owej oryginalnej funkcji (zostaje ręczna robota przy tym).

Sporą wadą, chociaż bardziej efektem ubocznym jest też czas wykonywania skryptu w OllyDbg, który może sięgać 5 minut dla zabezpieczonych aplikacji.

Zaletą jest natomiast cała reszta, która pozwala w prosty sposób odbudować tabele importów oraz dokonać błyskawicznych zmian, biorąc poprawki na jakieś wyjątkowe warunki w kodzie.

Kod skryptu

Kod skryptu do ściągnięcia – themida_iat_rebuilder.zip (6 kB)

Wszelkie uwagi mile widziane.