核心轉儲未寫入分段錯誤

我現在正在閱讀 The Shellcoder 的手冊：發現和利用安全漏洞，第 2 版。

在第二章中考慮了像這樣的簡單緩衝區溢出問題（C 程式碼）：

int main () {
   int array[5];
   int i;
   for (i = 0; i <= 255; i++ ) {
       array[i] = 10;
   }
}

作者編譯程式碼cc並執行它：

shellcoders@debian:~/chapter_2$ cc buffer2.c
shellcoders@debian:~/chapter_2$ ./a.out
Segmentation fault (core dumped)

然後通過以下方式查看了書面核心轉儲gdb：

shellcoders@debian:~/chapter_2$ gdb -q -c core
Program terminated with signal 11, Segmentation fault.
#0 0x0000000a in ?? ()
(gdb)

問題是在我的案例中沒有編寫核心轉儲。我只有消息：zsh: segmentation fault ./a.out。

我在 VirtualBox 中使用 Kali 2021.4a。我已嘗試更改預設 shell，chsh -s /bin/bash但它沒有任何更改，並且終端保持打開為zsh.

如何使核心轉儲寫入故障？看起來它應該是與執行檔在同一目錄中寫入的文件。

首先，您需要使用ulimit命令（在 bash 或 zsh 中）檢查您的限制中的核心文件大小。

# ulimit -c
0

如果它為零，則需要增加它。例如，將其增加到無限：

# ulimit -c unlimited
# ulimit -c          
unlimited

其次，您需要檢查 coredump 的創建位置。在較舊的發行版上，預設值通常是 CWD 中名為“core”的文件。這可能是本書寫作時的預設設置。

# /sbin/sysctl kernel.core_pattern
kernel.core_pattern = core

但是，今天在大多數發行版上不再適用。今天通常使用生成核心systemd-coredump(8)。

# /sbin/sysctl kernel.core_pattern
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e

來自男人systemd-coredump(8)：

預設情況下，systemd-coredump 會將核心轉儲記錄到日誌中，如果可能的話包括回溯，並將核心轉儲（程序記憶體內容的映像）本身儲存在 /var/lib/systemd/中的外部文件中核心轉儲。

您可以在該目錄中找到核心轉儲，也可以使用coredumpctl列出這些轉儲（您可能需要 sudo 或以 root 身份執行它）：

# coredumpctl list
TIME                            PID   UID   GID SIG PRESENT EXE
Wed 2022-01-26 12:53:06 IST   10347   111   222 11  *       /tmp/a.out

“ *PRESENT”下的 表示已創建核心轉儲文件。

您可以使用以下命令查看（壓縮）核心轉儲的位置coredumpctl info <pid>：

# coredumpctl info 10347 |grep Coredump
     Coredump: /var/lib/systemd/coredump/core.a\x2eout.111.1bd8e22a25e844f1b03a87d378b4ed9b.10347.1643194386000000.xz

xz您可以使用以下命令解壓縮此文件：

# xz --decompress --stdout '/var/lib/systemd/coredump/core.a\x2eout.111.1bd8e22a25e844f1b03a87d378b4ed9b.10347.1643194386000000.xz' > core

或使用以下命令將核心轉儲到某個目的地。

# coredumpctl -o core dump 10347

這些命令中的任何一個都將創建文件：

# gdb -q -c core
[New LWP 10347]
Core was generated by `/tmp/a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000af7a56725 in ?? ()

引用自：https://unix.stackexchange.com/questions/688000