Sprint z Pwndbg (1.08.2023)
80 views
Skip to first unread message
dominik.b...@gmail.com
Jul 30, 2023, 1:30:23 PM7/30/23
to Hackerspace KRK
Hi,
Zapraszam we wtorek (1.08) o 19:30 na sprint z Pwndbg, czyli wspólne kodzenie open source'owego pluginu do GDB pisanego w Pythonie.
---------------------------------------------------------
# Więcej informacji:
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. GDB umożliwia 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
- w procesie inżynierii wstecznej, gdy chcemy zrozumieć jak działa jakiś program
- 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 (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.
---
Zapraszam,
disconnect3d
Zapraszam we wtorek (1.08) o 19:30 na sprint z Pwndbg, czyli wspólne kodzenie open source'owego pluginu do GDB pisanego w Pythonie.
Pwndbg przydaje się przy debugowaniu, inżynierii wstecznej czy exploitowaniu programów na Linuxa. Poniżej więcej informacji o GDB/Pwndbg.
Dla uczestników stawiam jedzenie i picie.
Na poprzednich sprintach:
Lokalizacja: softroom w Hackerspace (ul. Zacisze 5/P1, na domofonie dzwonimy na 1 i idziemy do piwnicy).
Wymagania: fajnie zainstalować GDB oraz Pwndbg przed przyjściem na sprint, ale można to też zrobić na miejscu.
---------------------------------------------------------
# Więcej informacji:
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. GDB umożliwia 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
- w procesie inżynierii wstecznej, gdy chcemy zrozumieć jak działa jakiś program
- 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 (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.
---
Zapraszam,
disconnect3d
Reply all
Reply to author
Forward
0 new messages