październik 2024 – Strona 2

Bezpieczna strukturalna obsługa wyjątków

Celem ochrony Bezpieczna strukturalna obsługa wyjątków (SafeSEH) jest zapobieganie nadpisywaniu i używaniu struktur SEH przechowywanych na stosie. Jeśli program jest kompilowany i linkowany z opcją linkera /SafeSEH, nagłówek tego pliku binarnego będzie zawierał tabelę wszystkich prawidłowych obsługi wyjątków; tabela ta będzie sprawdzana, gdy zostanie wywołana obsługa wyjątków, aby upewnić się, że znajduje się ona na liście. Sprawdzanie jest wykonywane jako część procedury RtlDispatchException w ntdll.dll, która wykonuje następujące testy:

Zapewnia, że rekord wyjątku znajduje się na stosie bieżącego wątku.
Zapewnia, że wskaźnik obsługi nie wskazuje z powrotem na stos.
Zapewnia, że obsługa jest zarejestrowana na autoryzowanej liście obsługi.
Zapewnia, że obsługa znajduje się w obrazie pamięci, który jest wykonywalny.

Jak widać, mechanizm ochrony SafeSEH podejmuje kroki w celu ochrony obsługi wyjątków, ale jak zaraz zobaczysz, nie jest on niezawodny.

Zrozumienie i omijanie typowych zabezpieczeń pamięci systemu Windows

https://chacker.pl/

Jak można było się spodziewać, z czasem atakujący nauczyli się wykorzystywać brak zabezpieczeń pamięci w poprzednich wersjach systemu Windows. W odpowiedzi, mniej więcej w czasie Windows XP SP2 i Server 2003, Microsoft zaczął dodawać zabezpieczenia pamięci, które przez pewien czas były dość skuteczne. Jednak atakujący ostatecznie nauczyli się również obejść te początkowe zabezpieczenia. Jest to ciągła ewolucja technik eksploatacji i zabezpieczeń w celu udaremnienia sukcesu tych technik. Na przestrzeni lat dodano wiele nowych zabezpieczeń, a nawet zestawy narzędzi łagodzących, takie jak Windows Defender Exploit Guard, który zadebiutował w systemie Windows 10 w wersji 1709. Gdy te zabezpieczenia są połączone, mogą one znacznie utrudnić wykorzystanie luki.

Zrozumienie obsługi wyjątków strukturalnych

https://chacker.pl/

Gdy programy ulegają awarii, system operacyjny udostępnia mechanizm o nazwie Obsługa wyjątków strukturalnych (SEH), aby spróbować odzyskać operacje. Jest to często implementowane w kodzie źródłowym za pomocą bloków try/catch lub try/exception:

System Windows śledzi rekordy SEH, korzystając ze specjalnej struktury:

Struktura EXCEPTION_REGISTRATION ma rozmiar 8 bajtów i zawiera dwa elementy:

prev Wskaźnik do następnego rekordu SEH
handler Wskaźnik do rzeczywistego kodu obsługi

Te rekordy (ramki wyjątku) są przechowywane na stosie w czasie wykonywania i tworzą łańcuch. Początek łańcucha jest zawsze umieszczany w pierwszym elemencie bloku informacji o wątku (TIB), który jest przechowywany na maszynach x86 w rejestrze FS:[0]. Jak pokazano na rysunku , końcem łańcucha jest zawsze domyślny systemowy program obsługi wyjątku, a wskaźnik prev tego rekordu EXCEPTION_REGISTRATION jest zawsze równy 0xFFFFFFFF.

Gdy zostanie wyzwolony wyjątek, system operacyjny (ntdll.dll) umieszcza następującą funkcję C++ na stosie i wywołuje ją:

W przeszłości atakujący mógł po prostu nadpisać jeden z programów obsługi wyjątków na stosie i przekierować kontrolę do kodu atakującego (na stosie).

Jednak później pewne rzeczy uległy zmianie:

Rejestry są zerowane tuż przed wywołaniem programów obsługi wyjątków.
Wywołania programów obsługi wyjątków, znajdujących się na stosie, są blokowane.

Łańcuch SEH może być interesującym celem, ponieważ często, nawet jeśli nadpisujesz wskaźnik powrotu na stosie, wykonanie nigdy nie osiąga instrukcji powrotu. Jest to zwykle spowodowane naruszeniem dostępu do odczytu lub zapisu, które ma miejsce przed osiągnięciem epilogu funkcji, spowodowane dużą liczbą znaków wysłanych do bufora, które nadpisały krytyczne dane. W takim przypadku dalej w dół stosu za buforem znajduje się lokalizacja łańcucha SEH dla wątku. Naruszenie dostępu do odczytu lub zapisu spowoduje, że FS:[0] zostanie poddane getdereferenced, co zawiera wskaźnik do adresu stosu wątku, gdzie przechowywana jest pierwsza wartość „Next SEH” (NSEH). Rejestr segmentu FS zawsze wskazuje na Thread Information Block (TIB) dla aktualnie aktywnego wątku. TIB to struktura użytkownika na wątek, która przechowuje dane, takie jak wskaźnik do początku łańcucha SEH dla wątku w FS:[0], limity stosu i wskaźnik do Process Environment Block (PEB) w FS:[0x30]. Bezpośrednio pod pozycją NSEH na stosie znajduje się adres pierwszego wywołanego programu obsługi. Nadpisanie tego adresu adresem niestandardowym jest często łatwym sposobem na uzyskanie kontroli, jeśli nie można tego zrobić za pomocą nadpisywania wskaźnika powrotu. SafeSEH ma na celu uniemożliwienie działania tej techniki, ale jak zobaczysz, można ją łatwo ominąć.

Debugowanie Exploitu, jeśli to konieczne

https://chacker.pl/

Czas zresetować system wirtualny i uruchomić poprzedni skrypt. Pamiętaj, aby szybko podłączyć się do wsshd.exe i nacisnąć klawisz F9, aby uruchomić program. Pozwól programowi osiągnąć początkowy wyjątek. Kliknij w dowolnym miejscu sekcji demontażu i naciśnij klawisze CTRL-G, aby wyświetlić okno dialogowe Wprowadź wyrażenie do wykonania. Wprowadź adres z Mona, którego używasz do przejścia do ESP, jak pokazano poniżej. W tym przykładzie było to 0x7c345c30 z MSVCR71.dll. Naciśnij klawisz F9, aby osiągnąć punkt przerwania.

Jeśli program ulega awarii zamiast osiągnąć punkt przerwania, istnieje prawdopodobieństwo, że masz zły znak w kodzie powłoki lub w skrypcie występuje błąd. Problemy ze złymi znakami zdarzają się od czasu do czasu, ponieważ podatny program (lub program klienta SCP w tym przypadku) może reagować na pewne znaki i powodować przerwanie lub inną modyfikację exploita. Aby znaleźć zły znak, musisz przejrzeć zrzut pamięci debugera i dopasować ten zrzut pamięci do rzeczywistego kodu powłoki wysłanego przez sieć. Aby skonfigurować tę inspekcję, musisz powrócić do systemu wirtualnego i ponownie wysłać skrypt ataku. Gdy zostanie osiągnięty początkowy wyjątek, kliknij sekcję stosu i przewiń w dół, aż zobaczysz litery A. Kontynuuj przewijanie w dół, aby znaleźć kod powłoki, a następnie wykonaj ręczne porównanie. Innym prostym sposobem wyszukiwania złych znaków jest wysyłanie wszystkich możliwych kombinacji pojedynczego bajtu sekwencyjnie jako danych wejściowych. Możesz założyć, że 0x00 to zły znak, więc wpisz coś takiego:

UWAGA: Może być konieczne wielokrotne powtórzenie procesu wyszukiwania złych znaków, aż kod zostanie wykonany poprawnie. Generalnie należy wykluczyć wszystkie znaki odstępu: 0x00, 0x20, 0x0a, 0x0d, 0x1b, 0x0b i 0x0c. Należy wykluczać po jednym znaku na raz, aż wszystkie oczekiwane bajty pojawią się w segmencie stosu.

Gdy to będzie działać poprawnie, należy osiągnąć punkt przerwania ustawiony w instrukcjach PUSH ESP i RETN. Naciśnij klawisz F7, aby wykonać pojedynczy krok. Wskaźnik instrukcji powinien teraz wskazywać na wypełnienie NOP. Krótkie sanki lub wypełnienie powinny być widoczne w sekcji deasemblera, jak pokazano tutaj:

Naciśnij F9, aby kontynuować wykonywanie. Na ekranie powinien pojawić się kalkulator, jak pokazano poniżej, pokazując w ten sposób wykonanie kodu powłoki w naszym działającym exploicie! Zademonstrowaliśmy teraz podstawowy proces rozwoju exploita Windows na rzeczywistym exploicie.

Więliśmy podatną na ataki aplikację Windows i napisaliśmy działający exploit, aby naruszyć system docelowy. Celem było zwiększenie Twojej znajomości Immunity Debugger i wtyczki Mona od Corelan Team, a także wypróbowanie podstawowych technik powszechnie stosowanych przez twórców exploitów w celu skutecznego naruszenia bezpieczeństwa aplikacji. Identyfikując moduły, które nie uczestniczyły w różnych kontrolach ograniczających ataki, takich jak ASLR, byliśmy w stanie użyć ich do uzyskania niezawodnego exploita. Następnie przyjrzymy się bliżej różnym zabezpieczeniom pamięci i technikom obejścia.

Budowanie exploita

https://chacker.pl/

Jesteśmy wreszcie gotowi, aby złożyć części razem i zbudować exploit:

UWAGA: Czasami wymagane jest użycie NOP lub padding przed shellcode. Shellcode Metasploit potrzebuje trochę miejsca na stosie, aby zdekodować się podczas wywoływania procedury GETPC, jak opisano przez „sk” w jego artykule Phrack 62:

Określanie wektora ataku

https://chacker.pl/

W systemach Windows stos znajduje się w dolnym zakresie adresów pamięci. Stanowi to problem z techniką ataku Aleph 1, której użyliśmy w exploitach Linuksa. W przeciwieństwie do scenariusza programu meet.exe w przypadku exploitów w świecie rzeczywistym nie możemy po prostu kontrolować EIP za pomocą adresu powrotu na stosie. Adres prawdopodobnie będzie zawierał 0x00 na początku i spowoduje problemy, gdy przekażemy ten bajt NULL do podatnego programu. W systemach Windows trzeba będzie znaleźć inny wektor ataku. Często znajdziesz część (jeśli nie całość) swojego bufora w jednym z rejestrów, gdy program Windows ulegnie awarii. Jak pokazano w poprzedniej sekcji, kontrolujemy obszar stosu, w którym program ulega awarii. Wszystko, co musimy zrobić, to umieścić nasz kod powłoki zaczynający się od bajtu 496 i nadpisać wskaźnik powrotu adresem kodu operacji, aby jmp lub wywołać esp. Wybraliśmy ten wektor ataku, ponieważ każdy z tych kodów operacji umieści wartość ESP w EIP i wykona kod pod tym adresem. Inną opcją jest znalezienie sekwencji instrukcji, która wykonuje push esp, a następnie ret. Aby znaleźć adres żądanego kodu operacji, musimy przeszukać załadowane moduły (biblioteki DLL), które są dynamicznie powiązane z programem ProSSHD. Pamiętaj, że w Immunity Debugger możesz wyświetlić listę połączonych modułów, naciskając ALT-E. Użyjemy narzędzia Mona, aby przeszukać załadowane moduły. Najpierw użyjemy Mona, aby ustalić, które moduły nie uczestniczą w kontrolach ograniczających eksploatację, takich jak /REBASE i randomizacja układu przestrzeni adresowej (ASLR). Często zdarza się, że moduły dołączone do aplikacji innej firmy nie uczestniczą w niektórych lub wszystkich tych kontrolach. Aby dowiedzieć się, które moduły chcemy wykorzystać jako część naszego eksploitu, uruchomimy polecenie !mona modules z wnętrza Immunity Debugger. Możesz również użyć !mona modules -o, aby wykluczyć moduły systemu operacyjnego. Wystąpienie wsshd.exe, do którego wcześniej dołączyliśmy za pomocą Immunity Debugger, powinno być nadal aktywne, pokazując poprzedni wzorzec w EIP. Jeśli nadal nie jest aktywne, kontynuuj i ponownie uruchom poprzednie kroki, dołączając do procesu wsshd.exe. Po dołączeniu debugera do procesu uruchom następujące polecenie, aby uzyskać takie same wyniki:

Jak widać z próbki danych wyjściowych Mona, moduł MSVCR71.dll nie jest chroniony przez większość dostępnych kontroli exploitmitigation. Co najważniejsze, nie jest on ponownie bazowany i nie uczestniczy w ASLR. Oznacza to, że jeśli znajdziemy nasz pożądany kod operacji, jego adres powinien być niezawodny w naszym exploicie, omijając ASLR! Będziemy teraz nadal używać wtyczki Mona od Petera Van Eeckhoutte’a (znanego również jako corelanc0d3r) i zespołu Corelan. Tym razem użyjemy jej, aby znaleźć nasz pożądany kod operacji z MSVCR71.DLL. Uruchom następujące polecenie:

Weź wynik poprzedniego polecenia i dodaj go do skryptu ataku (zauważ, że zmienimy nazwę zmiennej z buf na sc). Wykluczamy bajt „\x00”, ponieważ bajty null są zazwyczaj problematyczne. W module scp.py znajduje się parametr o nazwie sanitize. Domyślnie jego wartość jest ustawiana przez wywołanie funkcji o nazwie _sh_quote, która zwraca nasz ciąg znaków ujętych w pojedyncze cudzysłowy. Jest to prawdopodobnie ochrona w kodzie, aby zapobiec lukom w zabezpieczeniach związanym z wstrzykiwaniem poleceń. Zauważysz w nadchodzącym kodzie, że ustawiliśmy sanitize na wartość równą funkcji lambda, która po prostu zwraca tę samą wartość.

Określanie przesunięć

https://chacker.pl/

Następnie będziesz musiał użyć wtyczki mona.py PyCommand od Corelan Team, aby wygenerować wzorzec, który określi liczbę bajtów, w których uzyskamy kontrolę. Aby uzyskać mona.py, przejdź do https://github.com/corelan/mona i pobierz najnowszą kopię narzędzia. Zapisz ją w folderze PyCommands w folderze Immunity Debugger. Będziemy używać skryptów wzorca przeniesionych z Metasploit. Najpierw chcemy skonfigurować nasz katalog roboczy, w którym będą zapisywane dane wyjściowe generowane przez Mona. Dlatego uruchom instancję Immunity Debugger. Nie martw się ładowaniem programu w tym momencie. Kliknij w powłoce poleceń Pythona u dołu okna debugera, a następnie wprowadź polecenie pokazane tutaj:

Jeśli Immunity Debugger przejdzie do okna dziennika, możesz po prostu kliknąć przycisk „c” na pasku wstążki, aby powrócić do głównego okna CPU. Teraz musimy wygenerować 500-bajtowy wzór do wykorzystania w naszym

który wygeneruje 500-bajtowy wzór, przechowując go w nowym folderze i pliku, w którym kazałeś Monie zapisać jego dane wyjściowe. Sprawdź swój katalog C: \grayhat\mona_logs\ pod kątem nowego folderu, prawdopodobnie zatytułowanego wsshd. W tym katalogu powinien znajdować się nowy plik o nazwie pattern.txt. To jest plik, z którego chcesz skopiować wygenerowany wzór. Jak mówi Mona, nie kopiuj wzoru z okna dziennika Immunity Debugger, ponieważ może zostać obcięty. Zapisz nową kopię skryptu ataku prosshd1.py na swojej maszynie wirtualnej Kali Linux (w tym przykładzie użyto nazwy prosshd2.py). Skopiuj wzór ASCII z pliku pattern.txt i zmień wiersz req, aby go uwzględnić, w następujący sposób:

UWAGA: Wzór po skopiowaniu będzie bardzo długą linią. Sformatowaliśmy linię pokazaną tutaj tak, aby zmieściła się na wydrukowanej stronie. Uruchom nowy skrypt z okna terminala Kali Linux za pomocą python3 prosshd2.py. Wynik jest pokazany poniżej.

Można zobaczyć, że po 492 bajtach bufora nadpisujemy wskaźnik powrotu z bajtów 493 do 496 wartością 41347141. Jest to widoczne po przejrzeniu sekcji Stack programu Immunity Debugger. Następnie, 4 bajty dalej, po bajcie 496, reszta bufora znajduje się na górze stosu po awarii programu. Narzędzie Metasploit pattern offset, którego właśnie użyliśmy z Mona, pokazuje przesunięcie przed rozpoczęciem wzorca.

Kontrolowanie wskaźnika instrukcji

https://chacker.pl/

Otwórz swój ulubiony edytor na swojej maszynie wirtualnej Kali Linux i utwórz następujący skrypt, zapisując go jako prosshd1.py, aby zweryfikować podatność serwera:

UWAGA: Moduły paramiko i scp są wymagane do tego skryptu. Moduł paramiko powinien być już zainstalowany, ale musisz zweryfikować, czy Twoja wersja Kali zawiera scp. Jeśli spróbujesz uruchomić poniższy skrypt i otrzymasz błąd dotyczący scp, musisz pobrać i zainstalować moduł scp, uruchamiając pip3 install scp. Będziesz również musiał połączyć się raz z domyślnym klientem SSH z powłoki poleceń w Kali Linux, aby podatny serwer docelowy znalazł się na liście znanych hostów SSH. Musisz utworzyć konto użytkownika na docelowej maszynie wirtualnej Windows z uruchomionym ProSSHD, którego użyjesz w swoim exploicie. Używamy nazwy użytkownika test1 z hasłem asdf. Utwórz to konto lub podobne i użyj go w tym laboratorium.

Ten skrypt zostanie uruchomiony z hosta atakującego i skierowany na cel (uruchomiony w środowisku VMware).

UWAGA: Pamiętaj, aby zmienić adres IP tak, aby odpowiadał Twojemu podatnemu serwerowi i sprawdź, czy utworzyłeś konto użytkownika test1 na swojej maszynie wirtualnej z systemem Windows.

Okazuje się, że w tym przypadku luka istnieje w procesie potomnym, wsshd.exe, który istnieje tylko wtedy, gdy istnieje aktywne połączenie z serwerem. Dlatego będziemy musieli uruchomić exploit, a następnie szybko podłączyć debuger, aby kontynuować analizę. Dlatego funkcja sleep() jest używana z argumentem 15 sekund, co daje nam czas na podłączenie. Wewnątrz maszyny VMware możesz podłączyć debuger do podatnego programu, wybierając Plik | Dołącz. Wybierz proces wsshd.exe, a następnie kliknij przycisk Dołącz, aby uruchomić debuger.

UWAGA: Może być pomocne posortowanie ekranu Attach według kolumny Name, aby szybko znaleźć proces. Jeśli potrzebujesz więcej czasu na dołączenie, możesz zwiększyć liczbę sekund przekazanych jako argument do funkcji sleep(). Oto, co trzeba zrobić! Uruchom skrypt ataku z Kali za pomocą następującego polecenia, a następnie szybko przełącz się na cel VMware i dołącz Immunity Debugger do wsshd.exe:

Gdy debuger się uruchomi i załaduje proces, naciśnij klawisz F9, aby „kontynuować” program. W tym momencie exploit powinien zostać dostarczony, a prawy dolny róg debugera powinien zmienić kolor na żółty i wyświetlić napis „Wstrzymano”. W zależności od wersji systemu Windows, której używasz jako celu, debuger może wymagać ponownego naciśnięcia klawisza F9 po pierwszej pauzie. Dlatego jeśli nie widzisz 0x41414141 w rejestrze EIP, jak pokazano poniżej, naciśnij klawisz F9 jeszcze raz. Często przydatne jest umieszczenie okna ataku w pozycji, która umożliwia wyświetlenie prawego dolnego rogu debugera, aby zobaczyć, kiedy debuger się zatrzymuje.

Jak widać, mamy kontrolę nad EIP, które teraz zawiera 0x41414141.

Wykorzystywanie serwera ProSSHD

https://chacker.pl/

Serwer ProSSHD to serwer sieciowy SSH, który umożliwia użytkownikom „bezpieczne” łączenie się i zapewnia dostęp do powłoki przez zaszyfrowany kanał. Serwer działa na porcie 22. Kilka lat temu wydano ostrzeżenie ostrzegające przed przepełnieniem bufora w przypadku akcji po uwierzytelnieniu. Oznacza to, że użytkownik musi już mieć konto na serwerze, aby wykorzystać lukę. Luka może zostać wykorzystana poprzez wysłanie ponad 500 bajtów do ciągu ścieżki polecenia GET protokołu SCP (Secure Copy Protocol).

W tym momencie skonfigurujemy podatny serwer ProSSHD v1.2 na gościnnej maszynie wirtualnej (VM) VMware z systemem Windows 10 x64 20H2 Enterprise. Możesz również wybrać inną wersję systemu Windows. Każda wersja systemu Windows z uruchomionym Immunity Debugger może dawać nieco inne wyniki; jednak ostateczny exploit użyty w tym rozdziale został przetestowany w wielu wersjach systemu Windows. Użyjemy VMware, ponieważ pozwala nam uruchamiać, zatrzymywać i ponownie uruchamiać naszą maszynę wirtualną znacznie szybciej niż ponowne uruchamianie.

UWAGA: Ponieważ uruchamiamy podatny program, najbezpieczniejszym sposobem przeprowadzenia testów jest ustawienie wirtualnej karty sieciowej (VNIC) VMware w trybie sieciowym tylko dla hosta. Zapewni to, że żadne zewnętrzne maszyny nie będą mogły połączyć się z naszą podatną maszyną wirtualną.

Wewnątrz maszyny wirtualnej pobierz i zainstaluj aplikację ProSSHD, korzystając z opcji pobierania pod następującym linkiem: https://www.exploitdb.com/exploits/11618. Po pomyślnej instalacji przy użyciu „typowej” opcji instalacji uruchom program xwpsetts.exe z katalogu instalacyjnego (na przykład instalacja może znajdować się w C:\Users\Public\Program Files (x86)\Lab-NC\ProSSHD\xwpsetts.exe). Po uruchomieniu programu kliknij Uruchom, a następnie Uruchom jako exe (jak pokazano poniżej). Może być również konieczne kliknięcie Zezwalaj na połączenie, jeśli pojawi się zapora sieciowa. Jeśli wersja próbna jest wyświetlana jako wygasła, może być konieczne ponowne uruchomienie maszyny wirtualnej lub wyłączenie opcji automatycznego ustawiania czasu, ponieważ ta wersja ProSSHD nie jest już obsługiwana, jak to ma miejsce w przypadku wielu programów zawierających luki w zabezpieczeniach.

UWAGA: Jeśli funkcja Data Execution Prevention (DEP) jest uruchomiona dla wszystkich programów i usług na docelowej maszynie wirtualnej, musisz tymczasowo skonfigurować wyjątek dla ProSSHD. Najszybszym sposobem sprawdzenia jest przytrzymanie klawisza Windows i naciśnięcie klawisza BREAK na klawiaturze, aby wyświetlić Panel sterowania systemem. Po lewej stronie panelu sterowania kliknij Zaawansowane ustawienia systemu. W menu podręcznym kliknij Ustawienia w obszarze Wydajność. Kliknij prawy panel zatytułowany Zapobieganie wykonywaniu danych. Jeśli opcja „Włącz funkcję DEP dla wszystkich programów i usług z wyjątkiem tych, które wybiorę” jest już wybrana, musisz dodać wyjątek dla programów wsshd.exe i xwpsshd.exe. Po prostu kliknij Dodaj, wybierz te dwa pliki EXE z folderu ProSSHD i gotowe!

Teraz, gdy serwer SSH jest uruchomiony, musisz określić adres IP systemu i użyć klienta SSH, aby połączyć się z nim z komputera Kali Linux. W naszym przypadku maszyna wirtualna z uruchomionym ProSSHD znajduje się pod adresem 192.168.209.198. Musisz albo wyłączyć zaporę systemu Windows z poziomu powłoki poleceń administracyjnych za pomocą polecenia NetSh Advfirewall set allprofiles state off, albo po prostu dodać regułę zezwalającą na ruch przychodzący na port TCP 22 dla SSH. W tym momencie podatna aplikacja i debuger działają na podatnym serwerze, ale nie są jeszcze podłączone, dlatego zaleca się zapisanie stanu maszyny wirtualnej VMware poprzez utworzenie migawki. Po zakończeniu migawki możesz powrócić do tego punktu, po prostu powracając do migawki. Ta sztuczka pozwoli Ci zaoszczędzić cenny czas testowania, ponieważ możesz pominąć wszystkie poprzednie konfiguracje i ponowne uruchomienia w kolejnych iteracjach testowania.

Przegląd procesu opracowywania exploitów

https://chacker.pl/

Proces tworzenia exploitów często składa się z następujących kroków:

Kontroluj wskaźnik instrukcji.
Określ przesunięcie(a).
Określ wektor ataku.
Zbuduj exploit.
Przetestuj exploit.

6. Debuguj exploit, jeśli to konieczne.