This document outlines a project to build FuzzyDbg, a debugger with fuzzing functionality. It will allow debugging and testing binaries using a fuzzing engine. The implementation will include a generic debugger interface, program state dumping, and an automated mutation engine to generate input logs and crash logs. Key features will include attaching to processes, setting breakpoints, and viewing registers. Major modules will include the debugger interface, helper utilities, breakpoints, ELF parsing, context handling, and process attaching. The project aims to integrate fuzzing via Radamsa to generate test cases and find bugs in the debugged binaries.

1. FuzzyDbg
1 / 12
Department of Computer Science & Engineering Amrita School of
Engineering
Amrita Vishwa Vidyapeetham
Name Roll No
Ritvik Tanksalkar AM.EN.U4CSE18148
Sandhra Bino AM.EN.U4CSE18049
Vivek Kamisetty AM.EN.U4CSE18061
Vishnu Madhav AM.EN.U4CSE18144
Guide Vipin Pavithran

2. 2 / 12
➔ Problem Definition
➔ Problem Description
➔ Block Diagram
➔ Module Description
OUTLINE

3. Problem Statement
3 / 12
Generic debuggers like GDB don’t have functionalities like viewing call graphs
generated and an efficient fuzzing functionality. Fuzzing is the most advanced and
fastest way to find bugs in software. This project aims to build a simple and fast
debugger with an implementation of graph view and fuzzing functionality.

4. In our implementation, the tool would let the user debug and test their binary using the
fuzzing engine.
The end product would include a generic interface with the debugger, dump program state,
stack, memory maps, registers etc. An automated mutation engine would generate input
logs and crash logs along with a backtrace at the instance of a crash.
4 / 12
Problem Description

5. Block Diagram - fdb

6. Block Diagram - Debugger

7. Our implementation of the debugger has the following features:
➔ Attach to running process
➔ Set breakpoints and delete them
➔ View registers
Stages of Implementation

8. Stages of Implementation
➔ Debugger Attach to a process
◆ Fork and execve the target process
◆ Get address of entryPoint from elf header.
◆ Use ptrace to Set breakpoint at entryPoint.
◆ Continue execution and handle to user.
➔ Debugger Context
◆ Register values at every instruction

9. 9 / 12
Stages of Implementation
➔ Debugger Breakpoints
◆ Set breakpoint at a given address
◆ Use of a breakpoint structure table to save original address values.
◆ Await for events in the traced process.
◆ Handle events like Signals, termination conditions etc.

10. 10 / 12
The WIP project implementation consists of a Command line based debugger divided into the following major
modules:
➔ FuzzyDbg
◆ The main debugger interface
◆ Handles commands given by user
◆ Reads the elf-header for future use.
➔ fdb-utils
◆ Implementation of debugger helper functions like parsing inputs.
◆ Functionality to get and set register values from traced process.
Modules

11. 11 / 12
Module Description
➔ Breakpoints
◆ Functionality to set and delete breakpoints.
◆ Patching the required instruction with xcc debugger interrupt.
◆ Saving the patched address along with the original address into a breakpoint structure.
◆ Use this to repatch the address back to original state.
➔ Elf-utils
◆ Functionality to parse elf header.
◆ Useful to find information like entryPoint.
◆ Also helps in detecting if binary is dynamic executable , whether it is Position Independent or not
(PIE).
◆ Provides functionality to efficiently print out the elf header in an order.

12. 12 / 12
Module Description
➔ Context
◆ The main debugger interface
◆ Handles commands given by user
➔ Attach
◆ Implementation of attach functionality
◆ Responsible for forking the debugger and tracing the child process
◆ Execve the target process and trace it with parent.
◆ Handle events that occur in child with every functionality

13. Test binaries
Performance Metrics
Results
13 / 12
Experimental

14. Test Binaries
➔ Basic testing with test binaries
◆ Binaries can be dynamic or static executables.
◆ Binaries can be position dependent or not.

15. Performance Metrics
This unique implementation of a combination of debugger and Fuzz tester
has multiple variable for performance:
● The fuzzer efficiency result wrt number of faults found within the
test/debuggee application.
● Also corner cases and test cases of types of binaries that can work
smoothly on this fuzzer

16. Results

17. Results

18. Major Project milestones
Modules to be completed
Expected Deadlines
18 / 12
Future Work

19. The full completed project is a Debugger with added support to fuzz
test the binary or process loaded to the debugger using a Radamsa
based mutation generation engine.
The current implementation is complete in its first phase having the
basic features of a debugger.
The modules currently under WIP status are :
● Making debugger more robust and full of features.
● Graph View of the disassembly for easier visual static analysis
and
● Radamsa Integration for fuzzing the test binary passed as
argument to the debugger.
Modules to be Completed

20. Expected date to be Completed
The expected date of Completion for the Project is estimated to be around
April 2022 along with the Paper publication and submission for CFP at a
major conference for acceptance.

21. Thank You