Jakiś czas temu analizowałem pewien malware, na który nałożony został bardzo ciekawy paker...

Jak wiadomo, każdy PE paker robi dwie rzeczy:
1. Szyfruje/kompresuje oryginalny kod aplikacji
2. Dorzuca loader którego zadaniem jest rozszyfrowanie/dekompresja oryginalnego kodu, i skok do niego
I w ten sposób z oryginalnego exeka, dostajemy spakowany exek, który rozpakowuje się w momencie uruchomienia.

Loader użyty we wspomnianym przeze mnie malwarze teoretycznie był zgodny z tym schematem, jednak od innych loaderów różniło go to, że rozpakowane dane umieszczał w procesie potomnym. A robił to w następujący sposób:
1. Pobierał ścieżkę/nazwę swojego exeka (GetModuleFileName)
2. Tworzył nowy zatrzymany (CREATE_SUSPENDED) proces na bazie własnego exeka (CreateProcess)
3. Rozszyfrowywał/dekompresował dane, przy czym każdy element rozszyfrowany trafiał do utworzonego procesu na odpowiednie miejsce (WriteProcessMemory wspomagany VirtualProtectEx)
4. Przestawiał EntryPoint na rozszyfrowany kod. Niestety nie pamiętam jaką to metodą robił, ale wyjść jest kilka - od użycia SetThreadContext i zmiany EIP (choć tego bym nie polecał) lub rejestru w którym jest przechowywany EP (hint: zobacz w którym momencie loader proces się zatrzymuje przy CREATE_SUSPENDED), aż do wstawienia na OEP PUSH Addr + RET
5. Robił ResumeThread i kończył działanie

Powyższe rozwiązanie ma wady i zalety. Zacznijmy od zalet (czyli dlaczego to powyższe miałoby utrudniać RE):
- OllyDbg z jakiegoś dziwnego powodu nie pokazuje procesów (przy Attach) które zostały wstrzymane przy utworzeniu, i jeszcze nie zostały wznowione (ale wystarczy ustawić Olliego jako JIT-debugger, i podpiąć go z TaskMgr (PPM/Debuguj))
- Trzeba przełączać debugger na następny proces (co się może stać uciążliwe jeżeli następny proces utworzy kolejny, itd)
- Jest to na tyle mało spotykana metoda, że może "kupić" kilka dodatkowych minut programowi (a może to jakiś standardowy packer o którym nie wiem?)
- Może kapkę przechytrzyć antywirusy które skanują proces bezpośrednio po jego utworzeniu, na podstawie emulacji procesu, itp (ciche założenie: AV nie wykryje exeka-matki)

Co do wad (czyli dlaczego to niekoniecznie jest dobre zabezpieczenie):
- WriteProcessMemory nie jest szczególnie szybkie (ale można je używać do kopiowania większych partii materiału)
- Tak na prawdę wystarczy zrobić break na ReasumeThread, i dumpnąć nowy proces - i nawet nie musimy się w części przypadków o zmianę EP martwić
- Dynamiczne rozpakowywanie łatwe do zautomatyzowania

Można się jednak pokusić o rozwinięcie tego zabezpieczenia, i sprawić aby potomne procesy się ze sobą komunikowały (np. przesyłały sobie jakieś wyniki WriteProcessMemory/ReadProcessMemory/potokami/etc) - wtedy debugowanie tego niekoniecznie będzie przyjemne. Jednak i szybkość ucierpi.
Jak będę miał chwilę to pewnie zaimplementuje jakiś przykładowy kod i go gdzieś tu wrzucę.

OK, the end.