1.3.1. Process Creation and Control

1.3.2. The Debugger Struct

1.3.3. The Run Function

1.3.4. Command Handling

1.3.5. Implementing Commands

1. Continue
   

   When the user enters the "continue" command, handle_command recognizes it and calls the continue command. The continue function uses the cont function from the nix crate to send a CONTINUE instruction to the debuggee program with its pid. (PTRACE_CONT request sent to the tracee)

   This allows the debugged program to continue execution until the next breakpoint or until it terminates.

2. break
   

   A crucial feature of any debugger is the ability to set and manage breakpoints. In my implementation, I've created a Breakpoint structure that encapsulates all necessary information for each breakpoint. Let's delve into the details of how this is implemented and used within the debugger.

   1. The brekpoint structure
      

      The Breakpoint structure contains the following fields:

      pub struct Breakpoint {
          pid: Pid,
          addr: *mut c_void,
          saved_data: i64,
          enabled: bool,
      }
      

      • pid: The process ID of the debuggee.
      • addr: The memory address where the breakpoint is set.
      • saved_data: The original byte of data at the breakpoint address.
      • enabled: A boolean flag indicating whether the breakpoint is currently active.

      (It may be slightly different in the code because I used dependency injection to be able to test data retrieval).

   2. Setting a breakpoint
      

      The process of setting a breakpoint involves several steps:

      1. User Input: The debugger prompts the user to enter the address where they want to set a breakpoint, typically provided as a hexadecimal string.

      2. Reading Original Data: Before setting the breakpoint, the debugger reads the original instruction at the specified address using the read function, which corresponds to the ptrace(PTRACE_PEEKDATA,...) function in C.

         let current_line = ptrace::read(self.pid, addr);
         

      3. Inserting the Breakpoint: The debugger replaces the least significant byte of the instruction with the int3 interrupt instruction (encoded as 0xCC). This sends a SIGTRAP signal to the process when executed.

         let int3 = 0xcc;
         let breakpoint_line = (current_line & !0xff) | int3;
         self.saved_data = (current_line & 0xff) as i64;
         

      4. Writing the Breakpoint: The modified instruction is written back to the address using the write function from the nix crate.

         ptrace::write(self.pid, addr as *mut c_void, breakpoint_line as *mut c_void);
         

   3. Disabling a Breakpoint
      

      The process of disabling a breakpoint essentially reverses the steps taken to set it:

      1. Reading Current Data: Read the current data at the breakpoint address.

         let line = ptrace::read(self.pid, self.addr as *mut c_void)?;
         

      2. Restoring Original Instruction: Compute the restored line by combining the original saved byte with the rest of the current instruction.

         let restored_line = (line & !0xff) | self.saved_data as i64;
         

      3. Writing Restored Data: Write the restored instruction back to the address.

         ptrace::write(self.pid, self.addr as *mut c_void, restored_line as *mut c_void)?;
         

      1. Adjusting Program Counter: After disabling the breakpoint, the program counter is adjusted to go back to the previous line, allowing execution to continue from the correct point.
   4. Software vs. Hardware Breakpoints
      

      This implementation uses software breakpoints, which offer several advantages:

      1. Unlimited Breakpoints: Unlike hardware breakpoints, which are limited in number by the CPU architecture, software breakpoints allow for an unlimited number of breakpoints.
      2. Portability: Software breakpoints work consistently across different hardware architectures.
      3. Flexibility: They can be easily set and unset dynamically during the debugging process.

      While hardware breakpoints can be more efficient in some cases, their limited number (often 4 or 8 on most CPUs) makes them less suitable for complex debugging scenarios that require many breakpoints.

   5. Challenges and Considerations
      

      Implementing breakpoints in this way comes with several challenges:

      1. Atomic Operations: Ensuring that the process of reading, modifying, and writing instructions is atomic to prevent race conditions.
      2. Instruction Alignment: Careful handling is required to ensure that breakpoints are set at the beginning of instructions, especially in architectures with variable-length instructions.
      3. Performance Impact: Software breakpoints modify the program's code, which can impact performance, especially with many breakpoints.
      4. Multi-threading : Special care is needed when dealing with multi-threaded programs to ensure breakpoints work correctly across all threads.
      5. Handling Signals : Proper handling of the SIGTRAP signal is crucial for the debugger to function correctly.
3. register
   

   To enable the continuation of execution after hitting a breakpoint, it is essential to reset the program counter to the previous instruction. This involves implementing functionality to manipulate the registers of a program, particularly the program counter.

   1. Register Functions Implementation
      

      The register module provides functionality to interact with the CPU registers of the debugged program. The key components are the Reg enum, the RegDescriptor struct, and functions to get, set, and manipulate register values.

      #[derive(Debug, Clone, Copy, PartialEq, EnumString)]
      #[strum(ascii_case_insensitive)]
      pub enum Reg { /*...*/ }
      
      #[derive(Debug, PartialEq, Clone, Copy)]
      pub struct RegDescriptor { /*...*/ }
      
      pub static REGISTERS_DESCRIPTORS: &[RegDescriptor] = &[ /*...*/ ];
      

      • Reg : enumerates all the registers available in the CPU
      • RegDescriptor : contains metadata about each register, including its name and DWARF index.
      1. Key functions
         

         • Register value getters and setters :

           pub fn get_register_value(pid: Pid, r: Reg) -> Result<u64, nix::Error> { /*...*/ }
           pub fn set_register_value(pid: Pid, r: Reg, value: u64) -> Result<(), nix::Error> { /*...*/ }
           

         These functions interact with the actual register values of the debugged process, permitting to modify their values or to retrieve them.

         • Another way of retrieving register value :

           pub fn get_register_value_from_dwarf_register(pid: Pid, reg_num: i32) -> Result<u64, nix::Error> { /*...*/ }
           

         This function permit to get the register value using its dwarf number.

   2. Modifying the debugger core logic
      

      • Introducing a new step_{overbreakpoint} function :

        fn step_over_breakpoint(&mut self) { /*...*/ }
        

      This function permits to step over a breakpoint. I start by moving back the program counter to the previous line (because the line where the breakpoint is needs to also be executed and the execution of the line with int3 interruption moves the program counter to the next line). Then I disable the breakpoint which restores the original lines where the breakpoint was (removing the int3 instruction). I finally send a step signal to the debuggee and at the end of the program when the main debugger program takes the control back, I re-enable the breakpoint.

      • Modifying the continue_execution function :

        To perform the correct logic, I've added a call to the step_{overbreakpoint} function in the beginning ot the continue_execution. Because the step_{overbreakpoint} perform verification about the existence of a breakpoint before applying its logic this doesn't affect the code in case there's no breakpoints.

      • Adding new register manipulation commands :

        To be able to manipulate registers in the debugger, I introduced new commands like register read (to get a particular register value), register write (to set a particular register value), and register dump (to display all registers values).

   3. Challenges and Learnings
      

      Developing this debugger presented several challenges:

      1. Understanding the intricacies of process control and the ptrace system call.
      2. Mapping C concepts and functinos to their Rust equivalents.
      3. Implementing a robust command parsing and handling system.

      However, shese challenges provided valuable learning experiences. I gained a deeper understanding of:

      • Low-level system interactions in Rust
      • The architecture of debugging tools
      • Effective use of Rust crates to simplify complex tasks