Sprint z Pwndbg (4.06.2023)

[dominik.b...@gmail.com]

Hej,

organizuję mini "sprint" jutro (4.06.2023) o 19:30 w HS w soft roomie w celu rozwijania open source'owego projektu - Pwndbg - pluginu do GDB pisanego w Pythonie, który przydaje się przy debugowaniu czy inżynierii wstecznej binarek na Linuxa (w szczególności, gdy nie mamy źródeł) albo developowaniu exploitów np. podczas CTFów. Dla niewtajemniczonych, na samym dole napisałem trochę kontekstu o co chodzi z GDB i Pwndbg.

Jeśli chcecie pomóc to zapraszam. Przygotuję jakieś taski, które powinno dać się zrobić w kilka godzin i postaramy się aby każdy zrobił pull request do projektu :).

Do sprintu wystarczy znajomość Pythona, chociaż jakakolwiek znajomość C (albo asemblera, huh ;D) nie zaszkodzi. Dla uczestników stawiam jedzenie (pewnie pizze)/picie.

----

# Co nieco kontekstu:
GDB (GNU Debugger) to konsolowy program do debugowania natywnych programów (czyli takich pisanych np. w C, C++, Go, Rust). Zwykle używa się go do debugowania programów do których mamy kod źródłowy, nierzadko przez jakieś IDE (np. CLion, VSCode). Jak każdy debugger, GDB pozwala na zatrzymywanie się na danej funkcji/linii w danym pliku, podglądanie czy modyfikację zmiennych i pamięci programu czy też wykonywanie dodatkowego kodu w debugowanym programie. Poza tym, GDB pozwala też na debugowanie kodu natywnego, to znaczy instrukcji asemblera (bo procesor nie wykonuje kodu źródłowego, a jedynie kod wynikowy). Przydaje się to w różnych sytuacjach jak na przykład:

- w diagnozie trudnych problemów (np. gdy mamy core dump albo input który crashuje produkcyjną binarkę do której nie mamy symboli debugowych, a crash nie reprodukuje się w naszych/innych buildach) 

- gdy nie mamy symboli debugowych
- inżynieria wsteczna

- podczas developowania low levelowych rzeczy (np. softu na urządzenia wbudowane, firmware, kompilatorów, JITów itd.)

Pwndbg natomiast, to plugin, który skryptuje GDB w Pythonie (bo GDB wystawia API). Jego największą zaletą, to wyświetlanie kontekstu debuggera, gdy zatrzymujemy program, wraz z takimi rzeczami jak kolorowanie wartości (rejestrów czy pamięci) w zależności od tego, czy dana wartość wygląda jak* dana pamięć (stos, sterta, kod wykonywalny etc.) oraz automatyczna dereferencja wszystkiego co wygląda jak* wskaźnik. Dodatkowo mamy sporo komend, które ułatwiają te czy inne rzeczy. 

* "wygląda jak" - nigdy nie ma pewności, czy wartość danego rejestru procesora czy pamięci to faktycznie wskaźnik na coś w programie, czy po prostu coś innego (np. zwykły integer czy dane binarne) - bo zwykle nie mamy tej informacji na tym poziomie.

PS: Można też przeczytać ten post, żeby dowiedzieć się jak wyglądały poprzednie sprinty lub. Zachęcam też do pobrania i zainstalowania Pwndbg na Linuxie (albo w WSL2).

 

---

Zapraszam,

disconnect3d

[dominik.b...@gmail.com]

* Mała poprawka, data to oczywiście 4.07.2023 :)

[Dominik Czarnota]

Hi,

Przesyłam małe podsumowanie jak wyglądał sprint. Jak na dość późny czas ogłoszenia eventu (dosłownie o północy dzień wcześniej), było nas łącznie 4 osoby i coś tam się udało zrobić :).

1. Poprawić komendę 'telescope -r', tak, aby wyświetlała adres, który requestujemy.

Tak to wyglądało przed (nie wyświetla się adres $rsp):

Po:

2. Dodać komendę do "sprayowania pamięci" - żeby nie trzeba było robić 'pi pwndbg.gdblib.memory.write(...)' jak wyżej, tylko np. 'spray <adres> <length>'

3. Zmienić instalator tak, aby tworzył Pythonowy virtualenv i paczki instalował w nim

4. Usprawnić komendę 'heap' do wyświetlania metadanych z alokatora glibc tak, aby poza oryginalną wartością rozmiaru chunka, która zawiera 3 bity flag, wyświetlać też ten rozmiar bez tych bitów flag

5. Eksperymentowaliśmy również z komendą 'search', tzn. patrzyliśmy, czy zrównoleglając jej implementacje Pythonowymi wątkami jesteśmy w stanie ją przyśpieszyć - jak się okazało, niestety nie, najpewniej przez to, że GDB nie zwalnia Pythonowego GILa gdy wykonujemy kod z C (np. gdb.selected_inferior().search_memory(...))

6. Znaleźliśmy buga w GDB, którego zgłosiliśmy tutaj: https://sourceware.org/bugzilla/show_bug.cgi?id=30615

Podsumowując, udało nam się wysłać 4 pull requesty, z czego pierwszy jest już zmergowany, a pozostałe powinny zostać zmergowane na dniach, poeksperymentowaliśmy z zrównoleglaniem kodu oraz znaleźliśmy buga, którego zgłosiliśmy ;).

(A tak wyglądał nasz roboczy dokument w trakcie sprintu: https://hackmd.io/wgsHQcLbSBm_AAIh0142cg?both).

Pozdrawiam,

Disconnect3d

--
Otrzymujesz tę wiadomość, bo subskrybujesz temat w grupie „Hackerspace KRK” w Grupach dyskusyjnych Google.
Aby anulować subskrypcję tego tematu, otwórz https://groups.google.com/d/topic/hackerspace-krk/cRGPdzmtb1w/unsubscribe.
Aby anulować subskrypcję tej grupy i wszystkich jej tematów, wyślij e-maila na hackerspace-k...@googlegroups.com.
Aby wyświetlić tę dyskusję w internecie, otwórz https://groups.google.com/d/msgid/hackerspace-krk/f97fb02c-928b-4a94-92c9-408e7529b52dn%40googlegroups.com.