HASP pozwala na szyfrowanie pojedynczych plików jak i całych katalogów z danymi aplikacji poprzez dodatkowe narzędzie:

W samym envelope określa się rodzaj plików, które zostały zaszyfrowane:

Zaszyfrowane pliki aplikacji może odczytać jedynie zabezpieczona aplikacja, realizowane jest to poprzez system hooków na funkcje systemu plików na poziomie usera.

Jeśli aplikacja zostanie rozpakowana, dostęp do oryginalnej treści zaszyfrowanych plików będzie niemożliwy (brakuje tych hooków, które w locie deszyfrują dane).

Jak uzyskać zatem dostęp do oryginalnej treści zaszyfrowanych plików?

Należy do działającej i zabezpieczonej aplikacji wstrzyknąć kod, który wykorzysta jej funkcje systemu plików (na które nałożone są hooki HASPa) i po prostu zaemulować czytanie wybranych plików.

Najprościej można to zrealizować poprzez skrypt ODBScript:

; wolna przestrzen po sekcji kodu
	mov	dump_hasp,008864D5
 
	mov	eip,dump_hasp
	asmtxt	eip,"dumper.asm"
 
; alokuj 2 bufory na nazwe pliku wyjsciowego i wejsciowego
	alloc	512
	mov	input_file,$RESULT
	alloc	512
	mov	output_file,$RESULT
 
; zrzuc 1 plik
	mov	x, "C:\PATH\APP\DATA.DAT"
	call	dump_file
 
; zrzuc 2 plik
	mov	x, "C:\PATH\APP\CONFIG.DAT"
	call	dump_file
 
	ret
 
; funkcja do zrzucania zaszyfrowanych plikow
dump_file:
 
	fill	input_file, 512, 0
	mov	[input_file], x
 
; plik wyjsciowy bedzie posiadal rozszerzenie .x
	add	x, ".X"
	fill	output_file, 512, 0
	mov	[output_file],x
 
; ESI -> sciezka pliku wejsciowego
; EDI -> sciezka pliku wyjsciowego
	mov	esi,input_file
	mov	edi,output_file
 
; ustaw EIP na adres procedury dumpujacej
	mov	eip,dump_hasp
 
; exec ... ende za chiny nie dziala u mnie... inaczej bym tu dal call dump_hasp?
; uruchom kod z biezacego EIP do napotkania instrukcji RET
	rtr ;run to return
 
	mov	x, ""
 
	ret

Pomocniczy kod w assemblerze dla skryptu:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; odczytaj plik wejsciowy
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
; zapamietaj na stosie nazwe pliku wyjsciowego
	push	edi
 
; otworz plik wejsciowy
	push	0				; hTemplate
	push	0				; attribs
	push	3 ;OPEN_EXISTING		; creation
	push	0				; security
	push	1				; share mode
	push	80000000 ;GENERIC_READ
	push	esi				; lpFileName
	call	[0800004] ;CreateFileA
	mov	ebx,eax
 
	push	0
	push	ebx				; hFile
	call	[0800008] ;GetFileSize
	mov	edi,eax
 
; zaalokuj pamiec do odczytania danych pliku wejsciowego
	push	4 ;PAGE_READWRITE
	push	3000 ;MEM_RESERVE or MEM_COMMIT
	push	edi				; size
	push	0
	call	VirtualAlloc
	mov	esi,eax
 
; czytaj plik wejsciowy korzystajac z hookowanych API
	push	0
	mov	eax,esp
 
	push	0				; dwOverlapped
	push	eax				; &dwRead
	push	edi				; dwSize
	push	esi				; lpBuffer
	push	ebx				; hFile
	call	[0800024] ;adres funkcji ReadFile w zabezpieczonym pliku
 
	pop	edx
 
; zamknij plik wejsciowy
	push	ebx
	call	[0800088] ;CloseHandle
 
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; zapisz plik wyjsciowy
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 
; zdejmij ze stosu nazwe pliku wyjsciowego (odszyfrowany)
	pop	eax
 
	push	0				; hTemplate
	push	0				; attribs
	push	2 ;CREATE_ALWAYS		; creation
	push	0				; security
	push	0				; share mode
	push	40000000 ;GENERIC_WRITE
	push	eax				; lpFileName
	call	CreateFileA
	mov	ebx,eax
 
; zapisz odczytana tresc pliku wejsciowego
	push	0
	mov	eax,esp
 
	push	0				; overlapped
	push	eax				; &dwWritten
	push	edi				; size
	push	esi				; buffer
	push	ebx
	call	WriteFile
 
	pop	edx
 
; zamknij plik wyjsciowy
	push	ebx
	call	CloseHandle
 
; zwolnij pamiec
	push	8000 ;MEM_RELEASE
	push	0
	push	esi
	call	VirtualFree
 
	ret

Przedstawiona technika pozwala z łatwością odczytać wszystkie zaszyfrowane pliki.

ArcaBit

Dzisiaj ciekawe opinie o pracy w tej firmie znalazłem na forum 4programmers, a docelowo znajdują się na portalu o pracy GoWork, jeden z ciekawszych cytatów:

Właściciele mają samochody za kilkaset tysięcy [każdy] a w biurze nie ma nawet sprzątaczki.
Jest biuro na parterze i tam ludzie mają grafik, kto i kiedy sprząta [myje podłogi, odkurza i czyści kible - tak kible]. Biuro na piętrze jest sprzątane przez Panią W. [odkurzanie, mucie naczyń, kurze i kible]. Warto nadmienić że Pani W. jest szefową biura a mimo wszystko w godzinach pracy w elegandzkim stroju – sprząta.
Najlepsza było przyjęcie wigilijne – było owszem ciasto i Cola i ….. no niestety nic więcej nie było.
Okropne dziadostwo

Oryginalny wpis:

http://www.gowork.pl/opinie_czytaj2,33733,0,0

PS.
Dzisiaj wyszedł news o upadłości firmy MKS, R.I.P gorszego dziadostwa antywirusowego nie widziałem, jeszcze w czasach wersji DOS-owej skasował mi połowę exeków z dysku, a w czasach Windowsa nie chcieli ze mną nawet rozmawiać o false-positivach w moich pierwszych exe-pakerach.

Zestaw narzędzi do analizy .NET-owych aplikacji znacznie różni się od klasycznych narzędzi dla zwykłych aplikacji x86 / x64, odmienna architektura kodu wymusiła utworzenie całej gamy dedykowanych narzędzi dla plików wykonywalnych .NET, spróbuję przedstawić kilka z nich, które mogą się przydać w reversingu.

Dekompilacja kodu

Pierwszym i podstawowym narzędziem, które chyba zna większość osób zajmujących się analizą oprogramowania i nie tylko jest dekompilator .NET Reflector.

.NET Reflector

Pozwala on na dekompilację plików wykonywalnych z formatu kodu przejściowego CIL (Common Intermediate Language) do kodu wysokiego poziomu w wybranym lub ulubionym przez nas języku np. C#, VB# etc.

Jest to najbardziej znany dekompilator i nie tylko, gdyż dzięki całej masie wtyczek umożliwia np. modyfikację plików binarnych (wtyczka Reflexil), debugowanie aplikacji (wtyczka Deblector) i wiele innych czynności związanych z analizą kodu.

Ostatnio .NET Reflector stracił na popularności, gdyż projekt od początku istnienia był darmowy, jednak po przejęciu go przez firmę Red Gate Software (notabene twórców obfuscatora SmartAssembly, z czego można wysnuć teorię spiskową, że chcieli ograniczyć dostęp do jednego z najpopularniejszych narzędzi do analizy aplikacji) i początkowych zapewnień o utrzymaniu jego darmowego statusu, po jakimś czasie został przekształcony w komercyjną wersję, z najtańszą licencją za 35 USD. W Internecie można jednak znaleźć złamane kopie jak również całkowicie zrekompilowane (wraz ze źródłami), bardziej odporne na narzędzia zabezpieczające.

Strona domowa — www.reflector.net

Lista wtyczek  — http://reflectoraddins.codeplex.com/

IL DASM

Warto wspomnieć również o tym narzędziu, chociaż z mojego doświadczenia wynika, że jest ono raczej mało używane, to deasembler dla .NET-owych binariów firmy Microsoft dołączany do SDK .NET-a oraz dostarczany wraz z Visual Studio.

Pozwala on na przeglądanie struktury pliku oraz deasembling do kodu przejściowego w związku z czym nie jest tak poręczny w analizie jak .NET Reflector.

Simple Assembly Explorer

Jest to kolejny deasembler i edytor jednak już bardziej zaawansowany od IL DASM-a, posiadający masę opcji, pozwalających na łatwą modyfikację kodu IL, kopiowanie instrukcji, wycinanie, wszystko bardzo poręcznie skonstruowane, od jakiegoś czasu jest to mój faworyt jeśli chodzi o modyfikację .NET-owych plików binarnych.

SAE posiada system wtyczek oraz wbudowany deobfuscator, który może przydać się w analizie zabezpieczonych aplikacji.

Jeśli chcesz nauczyć się podstaw programowania w IL, zmodyfikować szybko i sprawnie binaria to jest to idealne narzędzie.

Strona domowa — http://code.google.com/p/simple-assembly-explorer/

Dis#

Dis# to stosunkowo mało znany dekompilator, być może ze względu na to, że to komercyjne narzędzie, projekt dawno nie był aktualizowany, ale może być traktowany jako ciekawostka, gdyż posiada kilka interesujących cech jak wbudowany deobfuscator, edytor kodu pozwalający w prosty sposób zamieniać nazwy funkcji, zmiennych etc.

Strona domowa — http://netdecompiler.com

Debuggery

Z moich obserwacji i doświadczeń wynika, że większość analiz związanych z .NET da się rozwiązać statycznie (w przeciwieństwie do natywnych aplikacji), jednak i tutaj może przydać się prześledzenie wykonywanego kodu.

Dotnet IL Editor (DILE)

Dile to prosty w obsłudze debugger dla .NET-owych aplikacji, troszkę przypomina debugger z Visual Studio.

Strona domowa http://sourceforge.net/projects/dile/

Identyfikatory

Dla aplikacji natywnych podstawowym identyfikatorem jest PEiD oraz częściej uaktualniany Protection ID (oraz kilka innych), dla .NET powstał odpowiednik PEiD o nazwie DNiD.

Wykrywa on obecnie większość stosowanych zabezpieczeń stosowanych dla aplikacji .NET-owych. Do ściągnięcia lokalna kopia  — DNiD.v0.11-Rue.rar (384 kB)

Dumpery

Aplikacje .NET-owe obecnie rzadko rozprowadzane są w czystej formie po kompilacji, gdyż dzięki narzędziom takim jak .NET Reflector jest to praktyczne równoznaczne z rozprowadzaniem open source i większości wypadków do zabezpieczania używane są obfuscatory.

Część obfuscatorów oprócz modyfikacji kodu IL, całość aplikacji “opakowuje” w kod ładujący (z ang. loader) w formacie natywnym (x86), który zwykle deszyfruje całe .NET-owe assembly i dopiero w odszyfrowanej formie ładuje je do pamięci.

Taka forma zabezpieczenia nie pozwala na używanie narzędzi .NET-owych i wymagane jest najpierw zrzucenie z pamięci załadowanych assembly .NET-owych w celu dalszej analizy.

.NET Generic Unpacker

Projekt autorstwa Daniela Pistelli (obecnie pracujący nad IDA w HexRays), generyczny jak nazwa wskazuje dumper, który potrafi wykryć w pamięci obraz pliku wykonywalnego .NET mimo zewnętrznego natywnego loadera.

Strona domowa —  http://www.ntcore.com/netunpack.php

DotNetDumper

Prosty w użyciu dumper, który również posiada obsługę zrzucania z pamięci plików kilku rodzajów zabezpieczeń, generalnie z tymi dwoma dumperami można sobie poradzić z większością zabezpieczeń natywnych.

Do ściągnięcia lokalna kopia  — DotnetDumper.zip (66 kB)

Oprócz dedykowanych dumperów, równie dobrze działają klasyczne metody przeszukiwania pamięci np. w OllyDbg w poszukiwaniu sygnatur .NET-owych aplikacji (np. stringów “_CorExeMain”).

Fixery

Po zrzuceniu z pamięci obrazu pliku .NET jest on często niezdatny do analizy w narzędziach takich jak .NET Reflector, wynika to ze zmian jakie wprowadzają najczęściej obfuscatory, aby dodatkowo utrudnić analizę. Tak zrzucone obrazy plików należy naprawić.

Universal Fixer

Do ściągnięcia lokalna kopia  — Universal_Fixer.zip (31 kB)

Zawsze aktualna kopia — http://forum.tuts4you.com/topic/25376-universal-fixer/

Deobfuscatory

Liczba obfuscatorów dostępnych na rynku jest ogromna, mogę śmiało powiedzieć, że przebija ilość dostępnych narzędzi zabezpieczających dla natywnych aplikacji. W związku z tak zmasowanym atakiem, powstały deobfuscatory dla wielu narzędzi, często zintegrowane i obsługujące wiele rodzajów zabezpieczeń.

de4dot

de4dot to aktywnie rozwijany deobfuscator obsługujący sporą listę zabezpieczeń, podstawa jeśli ktoś myśli poważnie o analizie oprogramowania .NET

Do ściągnięcia ze strony —  https://github.com/0xd4d/de4dot/downloads

Podsumowanie

Obecny stan zabezpieczeń .NET-owych może z początku przerazić i zniechęcić do dalszej analizy, ale jak widać istnieje wiele narzędzi, które potrafią ułatwić nam życie.

Celowo nie opisywałem tutaj gotowych unpakerów, które można z łatwością znaleźć samemu, gdyż nie zawsze sprawdzają się w działaniu i warto wtedy wiedzieć jak sobie poradzić bez ich pomocy.

Jeśli natknę się na jakieś ciekawe narzędzie to dopiszę je do artykułu, a jeśli wy znacie coś interesującego do analizy aplikacji .NET — opiszcie w komentarzach, a ja to przejrzę i z chęcią dodam opis do artykułu.

Na koniec jeszcze kilka linków, gdzie można znaleźć narzędzia do analizy .NET-owych aplikacji:

BlackStorm — http://portal.b-at-s.net/download.php?list.9

RCE Tool Library — http://www.woodmann.com/collaborative/tools/index.php/Category:.NET_Tools

Mateusz “j00ru” Jurczyk

W dniach 24-25 maja w Krakowie, odbyła się dziewiąta edycja jednej z najlepszych polskich konferencji, poświęconych ogólnopojętemu bezpieczeństwu IT.

W tym roku, organizatorzy zdecydowali się na wprowadzenie pewnej odmiany, gdyż impreza odbywała się w zabytkowej przepompowni wody na Bielanach (poprzednio, konferencja miała miejsce w krakowskim kinie Kijów). Moim zdaniem był to strzał w dziesiątkę – sprzyjająca pogoda oraz wolna przestrzeń sprzyjały rozmowom “przy piwie”, oraz dobrej zabawie uczestników.

Tradycyjnie, prelekcje prowadzone był w dwóch, równoległych sesjach, dzięki czemu każdy mógł w dowolnym momencie wybrać interesujący go temat. Niestety zdarzały się sytuacje, w których jedna z sal była przepełniona – na szczęście było to rzadkie zjawisko, najczęściej rozkład słuchaczy na obu torach był w miarę równomierny.

Do najciekawszych – moim zdaniem – wystąpień zaliczyć można:

• The Son of Stuxnet aka “the very next scenarios” – Raoula Chiesa
• Building Custom Disassemblers – Feliksa ‘FX’ Lindnera,
• Modern Heap Exploitation using the Low Fragmentation Heap – Chrisa Valaseka
• Defeating x64: The Evolution of the TDL Rootkit – Aleksandra Matrosova oraz Euegene Rodionova.

Wszystkich zainteresowanych zachęcam do rzucenia okiem na slajdy z powyższych prelekcji.

Oprócz części merytorycznej, organizatorzy zadbali również o możliwość zmierzenia się z różnego typu wyzwaniami, bezpośrednio związanymi z IT security. I tak, uczestnicy mogli wziąć udział w trzech niezależnych konkursach:

• CONFidence 2011 REVERSME
• ESET Crackme
• Gringo Warrior

Głównym zadaniem uczestnika w poszczególnych zawodach, było kolejno: wykonać analizę oraz opisać działanie dostarczonego pliku wykonywalnego, znaleźć poprawne dane rejestracyjne dla CrackMe (lub stworzyć uniwersalny generator kluczy), oraz otworzyć jak największą ilość zamków (w kajdankach, drzwiach itp.), bez użycia oryginalnego klucza.

Ostatecznie, zwycięzcą pierwszego konkursu został Tomasz Smolarek, natomiast nikomu z uczestników w trakcie trwania konferencji nie udało się poradzić sobie z zabezpieczeniem zaimplementowanym przez firmę ESET; w związku z tym, konkurs został przedłużony o kolejny tydzień. W tym czasie owo CrackMe zostało rozwiązane przez kilka osób (m.in. mnie).

Warto wspomnieć również o wyzwaniu rzuconym uczestnikom przez firmę TippingPoint. Tym razem, głównym celem zabawy była podmiana strony WWW, po uprzednim włamaniu się na lokalny serwer chroniony autorskim systemem IPS wspomnianej firmy. Co ciekawe, również w tym przypadku nikomu nie udało się wykonać oczekiwanego deface’a, NAWET po wyłączeniu dodatkowego poziomu ochrony (IPS), i bezpośrednim wystawieniu serwera na świat.

Oprócz turniejów ściśle technicznych istniała również możliwość wzięcia udziału w zabawie “Tresure Hunt”, polegającej na zbieraniu oraz dostarczaniu przeróżnych, dziwacznych przedmiotów (na przykład: pozytywnego testu ciążowego).

Ponadto, do dyspozycji uczestników pozostawał także kącik ATARI, gdzie można było zagrać w mniej lub bardziej popularne ośmiobitowce, oraz Lockpicking Village, gdzie prowadzono specjalne warsztaty poświęcone pickowaniu zamków, oraz każdy mógł na własną rękę pobawić się różnymi, ciekawymi zamknięciami / kłódkami.

Jak co roku, nie zabrakło również nieodzownej, wieczornej części konferencji – “przedłużenia” imprezy w postaci Before Party, After Party oraz Chill-out Party. Każde z nich odbywało się w innym lokalu, dzięki czemu przyjezdni mieli okazję poznać odrobinę pięknego miasta jakim jest Kraków.

Wieczornym rozmowom w kuluarach towarzyszyły wykłady nt. animacji oraz demosceny, a lokale były opuszczane najczęściej późną nocą lub nad ranem

Podsumowując, uważam, że poziom organizacji konferencji poprawia się z roku na rok. Lokalizacja imprezy w miejscu nieco oddalonym od centrum sprzyjała intergracji uczestników, którzy byli “zmuszeni” do pozostania na miejscu podczas lunchu; ponadto natura budowli, która hostowała konferencję zdecydowanie sprzyjała undergroundowemu klimatowi. Uznaję konferencję za bardzo udaną, i z niecierpliwością czekam na kolejną edycję.

hasherezade

Tegoroczne CONfidence było dla mnie pierwszym, więc nie mam porównania jak plasowało się na tle wcześniejszych. Z tego co rozmawiałam z różnymi osobami, klimatem nawiązywało do początkowych edycji – w pozytywnym tego znaczeniu. Natomiast jeśli mogłabym porównać je z dwoma wcześniejszymi konferencjami na których byłam (SecDay i SEConference) to mogę tylko stwierdzić, że różnica jest diametralna.

CONfidence zorganizowane jest z imprezowym rozmachem i wykłady są tylko jednym (choć  oczywiście bardzo istotnym) z elementów całego wydarzenia. Jak zwykle przewidziano dwa równoległe tracki prezentacji, więc każdy mógł znaleźć coś dla siebie. Poziom i tematyka były zróżnicowane. Znalazły się zarówno pogadanki teoretyczne, jak i typowe techniczne “proof of concept”. Bardzo dużo miejsca poświęcono lockpickingowi.

Pierwszy wykład zaraz po otwarciu konferencji, stanowił wprowadzenie do tematu. Potem, przez całe dwa dni, można było spraktykować zdobytą wiedzę w “locpicking village” – gdzie udostępniono do zabawy różnego poziomu zamki i narzędzia.

Drugiego dnia imprezy odbył się też związany z zagadnieniem konkurs “gringo warrior” – podczas którego, w ciągu pięciu minut zawodnicy musieli otworzyć jak najwięcej różnego rodzaju kłódek i zamków. Myślę że na każdym, kto widział taką demonstrację po raz pierwszy, musiało to zrobić mocne wrażenie. Ja osobiście, po tym co zobaczyłam, czuję się w 100% przekonana do uwierzenia w przesłanie prezentacji, że “bezpieczeństwo danych zaczyna się na poziomie zerowym”. Już nigdy nie zostawię swojego laptopa samego w pokoju hotelowym . Trochę pocieszający jest fakt, że z popularnym u nas zamkiem “Gerda” nie poszło tak łatwo – prezenter przyznał, że wciąż nie złamał najnowszego jej typu.

Nieco pesymistycznie nastroił mnie natomiast panel dyskusyjny “David vs Goliat”. Wynikało z niego bowiem, że osoba, która odkryła lukę w zabezpieczeniu i zdecydowała się skontaktować z właścicielem portalu, nigdy nie może być pewna, że nie obróci się to na jej niekorzyść. Szczególnie niepolecanym modelem zachowania było żądanie, a wręcz wyłudzanie zapłaty za wykrycie buga (to akurat dość łatwo przewidzieć). Jednak, nawet osoba o dobrych intencjach, jest tak naprawdę zdana na łut szczęścia – w zależności od tego na kogo trafi po drugiej stronie, jej zgłoszenie może być potraktowane bardzo przychylnie, bądź wręcz wrogo.

Sporo uwagi skupiło się na wirusie Stuxnet – temat ten pojawiał się niezależnie na wykładach kilku różnych osób (m. in. Rauol Chiesa, Piotr Linke, Felix Linder). Wykład Felixa (o budowie  dizasemblerów) – był moim zdaniem jednym z lepszych podczas pierwszego dnia konferencji. Mocno
techniczny, ilustrujący wprowadzane koncepty przykładami.

W dniu drugim były dwa takie “niskopoziomowe” wykłady na wysokim poziomie . Rano – “Modern Heap Exploitation using the Low Fragmentation Heap” (przygotowany przez Chrisa Valaseka) i po południu “Defeating x64: The Evolution of the TDL Rootkit”. Panowie z ESET pokazali, w jaki sposób można oszukać system dodając do niego rootkita, gdzie i jak patchować, aby ingerencja nie została wykryta. Czekam z utęsknieniem ;P aż materiały pojawią się na stronie – dużo ciekawych wskazówek do eksperymentowania.

Poza tym – miła i ładna prezentacja Michała Sajdaka zapadła mi w pamięć: “Remote rootshell on Cisco router”. Zdalne wykonywanie komend poprzez buga w oprogramowaniu routerów Cisco. Sprawa o tyle ciekawa, co bardzo świeża – release łatki był przewidziany dokładnie w dniu prezentacji (więc, admini, nie śpijcie i sprawdźcie czy waszego sprzętu problem nie dotyczy!).

Oprócz wykładów przygotowano wiele dodatkowych atrakcji. Konkursów było tym razem więcej niż na poprzednich edycjach. Obok propozycji ściśle związanych z bezpieczeństwem, takich jak ESET CrackMe, ReverseMe i serwera wystawionego do shackowania przez firmę HP, pojawiły się zawody w lockpickingu i totalnie wykręcony “treasure hunt”. “Treasure hunt” – polegał na drużynowym zaliczaniu wyzwań z listy. A wyzwania były godne prawdziwych śmiałków ;P (np. przebiegnięcie w samej bieliźnie przez salę konferencyjną). Nagrodą – niespodzianką dla zwycięskiej drużyny okazał się karton wódki – było więc o co walczyć

Ogólnie mówiąc, atmosfera była stymulująca dla obu półkul mózgowych, a zdobywanie wiedzy odbywało się w stanie relaksacji

Po wykładach mogliśmy rozruszać zesztywniałe od siedzenia ;P mięśnie na afterparty zorganizowanym w klubie.

W tym miejscu chcę podziękować wszystkim, których miałam okazję poznać w ciągu tych dwóch dni – no i oczywiście tym którzy przyczynili się do przyznania mi darmowej wejściówki . Było super i na pewno będę CONfidence mile wspominać i polecać.

Grzegorz “haker500″ Jastrzębski

Konferencja bardzo mi się podobała, duże wrażenie zrobił na mnie wykład “Bezpieczeństwo Twojej sieci zaczyna się na poziomie zero” prowadzony przez Devianta Ollama i Babaka Javadi. Była to prezentacja i praktyczny pokaz lockpickingu. Po wykładzie oraz następnego dnia można było spróbować samemu opanować sztukę otwierania zamków i kłódek. Ja niestety nie spróbowałem.

Ciekawy był też wykład Felixa “FX” Lindnera dotyczący budowy własnego disasemblera. Wykład Chrisa Valaska mówił o nowoczesnej eksploatacji stosu przy użyciu małej fragmentacji.

Spodobały mi się wykłady Alexeya Sintsova “DNS dla złych” oraz Travisa Goodspeeda, którego prezentacja dotyczyła praktycznego ataku na urządzenie sprzętowe Freescale MC13224 ZigBee SoP. Ciekawy był również wykład prowadzony przez Alexandra Matrosova i Eugene’a Rodionova, mówiący o Ewolucji Rootkita TDL. Uczestniczyłem też w wykładzie prowadzonym przez Sandy “Mouse” Clark oraz Brada “RenderMana” Hainesa.

Widziałem również prezentacje: Michele Orru’ a.k.a. antisnatchora, Andreasa Bogka, Gregora Knopfa, Michała Sajdaka i Piotra Linke oraz końcówkę panelu dyskusyjnego David vs Goliat – jak zgłosić podatność i nie zrobić sobie przy tym krzywdy.

Na konferencji panowała niepowtarzalna atmosfera, przekąski były bardzo dobre. Fajnie, że były konkursy takie jak: ESET Crackme i CONFidence 2011 REVERSME. Ja niestety nie mogłem w nich wziąć udziału, bo nie mam laptopa. Fajny był również konkurs Gringo Warrior, chociaż dokładnie nie widziałem, kto w nim uczestniczył i nie wiem kto wygrał.

Bardzo podobała mi się lokalizacja, w której odbywała się konferencja, ponieważ można było tam podziwiać przepiękny krajobraz, no i pogoda dopisała. Nie mogę również nie wspomnieć o ładnych i sympatycznych hostessach pracujących podczas konferencji. Fajnie wyglądały dwie hostessy grające w piłkę w spodenkach z szelkami i w białych koszulach.

Ogólnie wspomnienia z konferencji mam bardzo pozytywne. Cieszę się, że po raz pierwszy mogłem brać udział w tym wydarzeniu, które powinno być obowiązkowe dla każdego, kto pasjonuje się bezpieczeństwem komputerowym.

Poniżej galeria zdjęć wykorzystanych w całym raporcie, które wykonał Grzegorz Jastrzębski (oprócz dwóch ostatnich dostarczonych przez Geda).

Dodatkowo filmik nakręcony przez Grześka.

Do ściągnięcia — whitepaper_antidebugging.pdf (207 kB)

Stuxnet is embarrassing, not amazing

Jak się tak zastanowić, to sam mam wątpliwości czy istnieją jeszcze wirusy z polimorficznymi czy metamorficznymi silnikami?

Clipper to język programowania z czasów DOS-a, ściśle związany z operowaniem na bazach danych, można powiedzieć, że to protoplasta Visual FoxPro.

Piszę o tym, ponieważ przed świętami otrzymałem zlecenie na modyfikację starego programu napisanego w środowisku Clipper, modyfikacja miała polegać na zmianie stawki VAT z 22% na 23% i 7% na 8%, czyli popularny ostatnio temat, związany z noworoczną zmianą stawki podatkowej.

Opiszę jedynie jak zabrać się za tego typu oprogramowanie, ponieważ w sieci nie znalazłem praktycznie żadnych materiałów o analizie aplikacji Clippera.

Rozpoznanie

Po czym poznać, że stara aplikacja DOS jest utworzona w Clipperze? Ja poznałem po tym, że jak załadowałem ją do IDA to nic nie rozumiałem z kodu ani żadnych ciekawych tekstowych referencji nie znalazłem, po prostu syf w czystej postaci, nawet sobie pomyślałem, że to jakaś aplikacja z DOSowego piekła rodem.

Przeglądając binarkę pod HIEW dostrzegłem jednak ciekawe informacje:

A więc wiadomo, że to Clipper w wersji 5.2. Mamy jakiś punk zaczepny.

Analiza

Aplikacje w Clipperze kompilowane są do pseudokodu (p-code), więc jeszcze lepiej zapowiadała się analiza, nawet nie wiedziałem, że w czasach DOSu ludzie mieli taką fantazję, żeby już tworzyć podwaliny pod platformę .net

Jednak ku mojemu zaskoczeniu i długim wyszukiwaniu, udało mi się znaleźć działający dekompilator, co uznałem wręcz za cud (w końcu były święta), ponieważ wiek samego anailzowanego programu jak i dekompilatora był już dość spory.

Odnaleziony dekompilator to Valkyrie 5, stworzony przez tą samą firmę, która jest odpowiedzialna za środowisko CA-Clipper.

Po otworzeniu głównego pliku aplikacji w dekompilatorze, ukaże się nam okno z informacjami i statystykami dla aplikacji:

Co ważne i na co należy zwrócić uwagę, to że aplikacja w Clipperze oprócz funkcji samego Clippera posiada również funkcje napisane w C/Assemblerze, które nie zostaną zdekompilowane, a jedynie uzyskamy dostęp do informacji o ich położeniu w pliku binarnym.

Domyślnym oknem w dekompilatorze jest lista modułów, z których zbudowana jest aplikacja oraz ich funckje:

Składnia języka Clipper nie jest zbyt skomplikowana (przypomina trochę Pascala) i można w miarę szybko ją zrozumieć, co ciekawe i co zwróciło moją uwagę to funkcja EVAL, która pozwala wykonać podany blok kodu źródłowego (jak eval z PHP).

Przykładowa zdekompilowana funkcja:

Oprócz kodu w HLL, można samą funkcję obejrzeć w p-code (i jak się można domyśleć modyfikacje również muszą być dokonywane manipulując na p-code):

Oprócz funkcji napisanych w języku Clipper, wspominałem wyżej, że plik może również zawierać natywny kod, listę tych funkcji możemy podejrzeć po wybraniu Menu -> View -> Externals:

Do ich podglądu należy skorzystać już z HIEW.

Bazy danych

Aplikacje Clipper domyślnie są aplikacjami bazodanowymi, a format plików jakim operują to *.DBF, muszę przyznać, że trochę czasu mi zajęło znalezienie odpowiedniej aplikacji do podglądu tego typu plików i pierwsza z nich, którą polecam to DBF Viewer 2000, a jeśli posiadacie środowisko Visual FoxPro to również z jego poziomu można przeglądać bazy danych w tym formacie, co było małym zaskoczeniem, że obsługiwane są bazy w tak starym formacie.

Uruchamianie

Z aplikacją, z którą ja pracowałem, miałem problem, żeby w ogóle ją uruchomić, pod konsolą DOS w systemie Windows odmawiała posłuszeństwa, DOSBox 0.74 również niewiele pomógł, ratunkiem okazał sie po prostu natywny MS-DOS 6.22 uruchamiany pod VMWare.

Przy okazji próbowałem dobrać się do tej aplikacji jakimś starym debuggerem jednak bez większych efektów, bo jak się okazało Clipper i SoftICE za bardzo się nie lubią, ale na pamiątkę strzeliłem screenshota:

Czego się nie nauczyłem?

Głównie tego jak poprawnie debugować tego typu aplikacje i jak modyfikować więcej niż kilka instrukcji, nie mówiąc o podmianie całych bloków kodu. Clipper należy już z zasadzie do przeszłości, ale mimo wszystko warto czasami zobaczyć jak zbudowane były i jak funkcjonowały stare aplikacje, bo wiele z tych technik (czy zamysłów) jest obecnie wykorzystywanych.

SecDay 2010 – materiały, relacja
http://j00ru.vexillium.org/?p=632&lang=pl

Prezentacja
http://j00ru.vexillium.org/blog/29_09_10/x86_vs_x64.pdf

Prezentacja w formacie PDF i PPTX

Więcej informacji na — http://j00ru.vexillium.org/?p=301&lang=pl

Struktura aplikacji Visual FoxPro

Z nielicznych kontaktów z oprogramowaniem Visual FoxPro wiedziałem, że każda taka aplikacja składa się z prostego loadera (który uruchamia cały engine VFP znajdujący się w dodatkowych plikach DLL) oraz właściwej aplikacji, która znajduje się na końcu pliku wykonywalnego (zapisana jako overlay), całość jest więc w jednym pliku wykonywalnym. Tak jest w przypadku programów niezabezpieczonych:

W przypadku zabezpieczenia HASP, na końcu zabezpieczonego pliku faktycznie znajdują się jakieś dane, ale nie są to dane aplikacji VFP, gdyż nie można jej zdekompilować oprogramowaniem ReFox.

Zabezpieczenia dla aplikacji z overlayami

Dane overlay (tak zapisane dane są w aplikacjach Flash, Director, Shockwave etc.) nie są mapowane w pamięci procesu i muszą być odczytane bezpośrednio z dysku. Popularną metodą ochrony takich aplikacji jest szyfrowanie tych danych i hookowanie funkcji systemu plików (np. CreateFile, ReadFile etc.) w samej aplikacji, poprzez podstawienie adresów funkcji zastępczych w tabeli importów aplikacji. Jeśli aplikacja otworzy swój własny plik i będzie probowała czytać dane overlaya, nie zostanie odczytane to co jest na dysku, ale to co zostało wczesniej zaszyfrowane.

Takie rozwiązanie przez hookowanie tabeli importów działa jedynie w przypadku samodzielnych plików (bez dodatkowych bibliotek), w przypadku aplikacji VFP, dane z pliku wykonywalnego czytane są przez dodatkowe biblioteki, więc wymagany byłby system wide hook.

Envelope HASP dla aplikacji VFP

System zabezpieczeń HASP dla takich plików, działa w ten sposób, że sterownik systemowy HASP-a podpina się pod funkcje systemowe Windows odpowiedzialne za czytanie plików i obecność oryginalnego overlaya jest emulowana tylko dla zabezpieczonej aplikacji i jej bibliotek. Wygląda to mniej więcej tak:

Odczytanie overlaya

Jak zatem uzyskać obraz całego overlaya? Z przeprowadzonych eksperymentów wynika, że dane nie są nigdzie czytane w całości, więc nie ma takiego punktu w programie (a grzebanie w engine VFP nie należy do najprzyjemniejszych), gdzie by można było zrzucić pamięć całego overlaya.

Jednak jeśli czytanie danych overlaya jest emulowane dla samej zabezpieczonej aplikacji, można wstrzyknąć kod czytający zawartość całego pliku do zabezpieczonej aplikacji i dzięki temu uzyskać dane odszyfrowanego overlaya.

Jest tutaj kilka problemów. Po pierwsze, aby wstrzyknąc kod należy dojść do OEP zabezpieczonej aplikacji, co może sprawić trochę problemów, ja skorzystałem z OllyDbg i pluginu Phant0m, ponieważ envelope HASP-a wykrywa popularne narzędzia do debuggowania, co można zobaczyć na zrzuconym obrazie zabepieczonego pliku:

Znalezienie OEP jest relatywnie proste, wersja dla leniwych — zrzucić działający program z pamięci i wyszukać standardowego entrypoint-a dla aplikacji skompilowanych pod Visual C++ (szukać funkcji GetStartupInfoA). Potem wgrać na nowo plik i ustawić hardware breakpoint na tym adresie.

Będąc na adresie OEP można teraz wstrzyknąć kod odpowiedzialny za czytanie pliku. Aby zaoszczedzić trochę kodu, ja wykorzystałem fakt, że plik aplikacji jest przez nią otwierany w pewnym momencie, dzięki czemu nie trzeba pobierać jego ścieżki i go otwierać, a od razu mamy jego uchwyt, który można wykorzystać do odczytania overlaya:

Następnie skorzystałem ze skryptu ODBScript, żeby pod adresem 4015EE załadować kod, który odczyta zawartość pliku i zapisze go na dysku:

; usun wszystkie breakpointy
        bphwcall
        bc
 
; ustaw hardware bp na OEP
        bphws   401873,"x"
 
        run
 
; ustaw hardware bp na kod po _lopen
        bphws   4015F4,"x"
 
        run
 
        bphwcall
 
; kompiluj kod z pliku pod adres EIP
        asmtxt  eip, "C:\fox_dumper.asm"
 
; pomocniczy bp
        bphws   401644,"x"
 
        run
 
; zrzuc pamiec pod adresem ESI o rozmiarze EBX
        dm esi, ebx, "c:\dump.bin"
 
        log "VFP dumper zrobione."
 
        pause

Kod dumpera ładowany jest z zewnętrznego pliku, a nie jest wykorzystywana funkcja ODBScript wykonująca kod assemblera w przestrzeni adresowej aplikacji, ponieważ to po prostu nie działało (jakby ktoś pytał):

; w EAX jest uchwyt pliku
        mov     edi,eax                 ; hFile
 
; nawiguj na koniec pliku (korzystajac z funkcji
; z tabeli importow aplikacji)
        push    2                       ; FILE_END
        push    0                       ; offset
        push    edi                     ; hFile
        call    [40203C] ;_llseek
        mov     ebx,eax                 ; eax = current offset = size
 
; alokuj pamiec na rozmiar overlaya
        lea     eax,[ebx-4]             ; na koncu overala zapisany jest DWORD
                                        ; ktory wskazuje offset poczatku overlaya
                                        ; w pliku
        push    0                       ; FILE_BEGIN
        push    eax                     ; offset
        push    edi                     ; hFile
        call    [40203C] ;_llseek
 
; odczytaj DWORD, ktory okresja polozenie overalaya w pliku
        push    0
        mov     eax,esp
 
        push    4                       ; size
        push    eax                     ; &memory
        push    edi                     ; hFile
        call    [402040] ;_lread
 
        pop     eax                     ; esi - raw offset overlaya
 
        push    0                       ; FILE_BEGIN
        push    0                       ; offset
        push    edi                     ; hFile
        call    [40203C] ;_llseek
 
; alokuj pamiec na calego overlaya
        push    ebx
        push    40                      ; GMEM_FIXED or GMEM_ZEROINIT
        call    GlobalAlloc
        mov     esi,eax
 
; odczytaj calego overlaya do nowo zaalokowanej pamieci
        push    ebx                     ; size
        push    esi                     ; &memory
        push    edi                     ; hFile
        call    [402040] ;_lread
 
; zamknij oryginalny plik
        push    edi
        call    [402038] ;_lclose
 
; utworz nowy plik
        sub     esp,512
        mov     eax,esp
 
; "C:\x"
        mov     edx,785C3A43
        mov     [eax],edx
        xor     ecx,ecx
        mov     [eax+4],ecx
 
; esi - ptr
; ebx - size
 
        push    0
        call    ExitProcess

Po wykonaniu skryptu, w pliku C:\x otrzymamy zrzut całego pliku (nie tylko overlaya).

Odbudowa oryginalnego pliku wykonywalnego

Posiadając zrzucony overlay (rozpoznamy jego bajty po sygnaturze FE F2 EE), należy go dokleić do odbudowanego loadera VFP. Sam loader po zabezpieczeniu i zrzuceniu wymaga odbudowy importów,  tutaj można trochę oszukać, wszystkie loadery VFP (danej wersji) są takie same, różnią się jedynie wersją językową, ikoną i zasobami z nazwą i numerem wersji aplikacji. Jeśli posiadacie środowisko Visual FoxPro 9, można stworzyć projekt w stylu Hello World, skompilować do pliku wykonywalnego, usunąć oryginalny overlay i wkleić nasz, a aplikacja będzie działała poprawnie (można potem w edytorze zasobów podmienić ikonę i wersję aplikacji).

Wnioski

Było trochę problemów z samą zabezpieczoną aplikacją i jej działaniem w OllyDbg z włączonym pluginem Phant0m (dużo restartów, nie dało się normalnie zamknąć aplikacji), jednak sama metoda jest dosyć szybka i uniwersalna, z późniejszych poszukiwań udało mi się jeszcze znaleźć doskonały artykuł prezentujący szereg innych zabezpieczeń stosowanych w aplikacjach VFP, polecam na koniec:

Security in FoxPro — www.foxpert.com/docs/security.en.htm

PS. Pozdro dla wszystkich burtoniarzy