Common Binary Exploitation Protections & Bypasses
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Pliki core to rodzaj pliku generowanego przez system operacyjny, gdy proces ulega awarii. Pliki te przechwycają obraz pamięci awaryjnego procesu w momencie jego zakończenia, w tym pamięć procesu, rejestry i stan licznika programu, między innymi szczegóły. Ten zrzut może być niezwykle cenny do debugowania i zrozumienia, dlaczego doszło do awarii.
Domyślnie wiele systemów ogranicza rozmiar plików core do 0 (tj. nie generują plików core), aby zaoszczędzić miejsce na dysku. Aby włączyć generowanie plików core, można użyć polecenia ulimit (w bashu lub podobnych powłokach) lub skonfigurować ustawienia systemowe.
Używając ulimit: Polecenie ulimit -c unlimited pozwala bieżącej sesji powłoki na tworzenie plików core o nieograniczonej wielkości. Jest to przydatne w sesjach debugowania, ale nie jest trwałe po ponownym uruchomieniu lub w nowych sesjach.
Trwała konfiguracja: Aby uzyskać bardziej trwałe rozwiązanie, możesz edytować plik /etc/security/limits.conf, aby dodać linię taką jak * soft core unlimited, co pozwala wszystkim użytkownikom na generowanie plików core o nieograniczonej wielkości bez konieczności ręcznego ustawiania ulimit w ich sesjach.
Aby przeanalizować plik rdzeniowy, możesz użyć narzędzi do debugowania, takich jak GDB (GNU Debugger). Zakładając, że masz plik wykonywalny, który wygenerował zrzut rdzenia, a plik rdzeniowy nazywa się core_file, możesz rozpocząć analizę za pomocą:
To polecenie ładuje plik wykonywalny i plik rdzeniowy do GDB, co pozwala na zbadanie stanu programu w momencie awarii. Możesz używać poleceń GDB, aby eksplorować stos, badać zmienne i zrozumieć przyczynę awarii.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
