如何调试MIPS固件二进制文件？DVRF二进制GDB调试故障求助

我之前调试MIPS架构嵌入式固件时也碰到过一模一样的问题，给你两个实用的解决思路：

方法一：修复chroot环境的依赖缺失 #

你遇到的Cannot exec /bin/bash本质是chroot环境里缺少MIPS架构的bash——GDB启动目标程序时会调用shell来执行，而你的chroot目录里刚好没这个关键文件；同时Unsupported syscall也和chroot内的动态链接库不全有关，具体步骤如下：

• 给chroot补上MIPS版bash：
  如果你的主机是Debian/Ubuntu系，执行以下命令下载并解压MIPSel架构的bash包到DVRF根目录：

  # 在主机终端执行，替换your-dvrf-dir为你的DVRF根目录路径
  apt-get download bash:mipsel
  dpkg-deb -x bash_*.deb ./your-dvrf-dir/
  

• 同步核心动态链接库：
  把主机/usr/mipsel-linux-gnu/lib目录下的核心库（比如libc.so.6、libdl.so.2等）复制到chroot的/lib目录下，确保qemu和GDB能找到必要依赖。

方法二：用gdb-multiarch远程调试（更省心） #

这种方法不需要在chroot里运行GDB，彻底绕开依赖问题，我平时调试嵌入式固件基本都用这个方案：

1. 在chroot里启动目标程序并开启qemu的gdbserver模式：

   sudo chroot . ./qemu-mipsel-static -g 1234 ./pwnable/Intro/stack_bof_01
   

   这里-g 1234是让qemu监听本地1234端口，等待GDB连接。
2. 在主机上启动gdb-multiarch（没装的话先执行sudo apt install gdb-multiarch）：

   gdb-multiarch ./pwnable/Intro/stack_bof_01
   

3. 在GDB里配置MIPS架构并连接远程目标：

   set architecture mips
   target remote localhost:1234
   

4. 接下来就可以正常用break设断点、continue运行、step单步调试这些命令了，完全不会出现之前的syscall错误。

为什么远程调试更靠谱？ #

错误里的Unsupported syscall: 4026是QEMU对某些MIPS系统调用的模拟支持不完善导致的，而远程调试时GDB运行在主机（x86架构），不需要在chroot里执行GDB本身，自然就不会触发这些有问题的syscall了。

内容的提问来源于stack exchange，提问作者Neolex