FuzzyDebugger.pdf
- 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