This is default featured slide 1 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

Showing posts with label GDB. Show all posts
Showing posts with label GDB. Show all posts

gdbgui - A browser-based frontend/gui for GDB


A modern, browser-based frontend to gdb (gnu debugger). Add breakpoints, view stack traces, and more in C, C++, Go, and Rust! Simply run gdbgui from the terminal and a new tab will open in your browser. 


Install
[sudo] pip install gdbgui --upgrade
Since gdbgui is under active development, consider running this command fairly often.


Run
gdbgui [binary to debug]
A new tab in your browser will open with gdbgui in it.


Features
  • Debug a different program in each tab (new gdb instance is spawned for each tab)
  • Set/remove breakpoints
  • View stack, threads
  • Switch frame on stack, switch between threads
  • Inspect memory in hex/character form
  • View all registers
  • Dropdown of all files used to compile binary, with autocomplete functionality
  • Source code explorer with ability to jump to line
  • Show assembly next to source code, highlighting current instruction. Can also step through instructions.


Why gdbgui?
  • Actively developed and compatible with the latest version of gdb (7.12)
  • Does only one thing: debugs programs. No integrated build system, no project settings, nothing to make things more complicated than they need to be. Just a lightweight frontend.
  • Design influenced by the amazing Chrome debugger: source code on the left, side panel on the right with collapsable widgets, console on the bottom
  • Full gdb command line utility built in
  • Written in widely used languages (Python and JavaScript)
  • Open source and free

Examples
See https://github.com/cs01/gdbgui/tree/master/examples


Arguments
Positional arguments:
command : (Optional) The binary and arguments to run in gdb. This is a way to script the intial loading of the inferior binary you wish to debug. For example gdbgui ./mybinary -myarg -flag1 -flag2 . Binaries and arguments can also be input through the browser interface after launching.
Flags (all are optional):
-h, --help show this help message and exit
-p PORT , --port PORT
The port on which gdbgui will be hosted
--host HOST The host ip address on which gdbgui serve.
-g GDB , --gdb GDB
Path to gdb executable or lldb-mi executable. Defaults is 'gdb'. lldb support is experimental and not fully functional at this time.
-v, --version Print version
--debug The debug flag of this Flask application. Pass this flag when debugging gdbgui itself to automatically reload the server when changes are detected
-n, --no_browser
By default, the browser will open with gdb gui. Pass this flag so the browser does not open.

Compatibility
Python versions: 2.7, 3.4, 3.5, pypy
Operating systems: Ubuntu 14.04, Ubuntu 16.04, OSX
Browsers: Chrome, Firefox, Ubuntu Web Browser
Gdb: 7.7.1 (tested), 7.12 (tested), likely works with intermediate versions



How Does it Work?
It uses Python to manage gdb as a subprocess. Specifically, the pygdbmi library , which returns key/value pairs (dictionaries) that can be used to create a frontend. To make a usable frontend, first a server must made to interface with gdb. In this case, the Flask server is used, which does three things: creates a managed gdb subprocess with pygdbmi, spawns a separate thread to constantly check for output from the gdb subprocess, and creates endpoints for the browser including http requests and websocket connections.
As output is parsed in the reader thread, it is immediately sent to the frontend through the websocket. As the browser receives these websocket messages, it maintains the state of gdb (whether it's running, paused, or exited, where breakpoints are, what the stack is, etc.) and updates the DOM as appropriate. The browser also sends commands to gdb through a websocket to Flask server, which then passes the command to gdb. Gdb writes new output, which is picked up by the reader thread.
gdbgui was designed to be easily hackable and extendable. There is no build system necessary to run or develop this app.
The main components of gdbgui are
  1. backend.py : The backend consists of a single Python file, which makes use of pygdbmi to interact with a gdb subprocess, and Flask to set up url routing, websockets, and http responses.
  2. gdbgui.pug : HTML file that defines the frontend
  3. gdbgui.js : The majority of the application is contained in this file. It dynamically updates the page, and maintains gdb state. It sends AJAX requests and uses websockets to interact with gdb through the server, then gets the response and updates the DOM as necessary.
  4. gdbgui.css : css stylesheet


Screenshots
Enter the binary and args just as you'd call them on the command line. Binary is restored when gdbgui is opened at a later time.



Intuitive control of your program. From left to right: Run, Continue, Next, Step, Return, Next Instruction, Step Instruction, send interrupt signal (SIGINT) to inferior process.



Stack/Threads
View all threads, the full stack on the active thread, the current frame on inactive threads. Switch between frames on the stack, or threads by pointing and clicking.



Source Code
View source, assembly, add breakpoints. All symbols used to compile the target are listed in a dropdown above the source code viewer, and have autocompletion capabilities.




With assembly. Note the bold line is the current instruction that gdb is stopped on.



Variables and Expressions
All local variables are automatically displayed, and are clickable to explore their fields.



Arbitrary expressions can be evaluated as well.




Expressions record their previous values, and can be displayed in an x/y plot.




Memory Viewer
All hex addresses are automatically converted to clickable links to explore memory. Length of memory is configurable. In this case 16 bytes are displayed per row.



Registers
View all registers. If a register was updated it is highlighted in yellow.




gdb console
Read gdb output, and write to the gdb subprocess as desired. Don't let any gdb commandline skills you've developed go to waste.



gdbgui at launch:


ansvif - An Advanced Fuzzing Framework Designed To Find Vulnerabilities In C/C++ Code.


ansvif, written primarily in C++, is designed to find code bugs by throwing garbage input at programs to see how they react. This is great for finding bugs, because not every type of input is always handled, and buffers are not always checked, etc. It also comes in handy when writing (and protecting against), buffer overflow exploitation, as well as string input validation vulnerabilities (the %s bug).

Dependancies:
automake autoconf-archive zlib1g-dev libcrypto++ g++ gcc

Compliation:
Linux:
$ aclocal && autoconf && automake -a && ./configure && make

Or, if you would like to play with the syscall fuzzer:

$ aclocal && autoconf && automake -a && ./configure --enable-syscalls && make

OpenBSD:
$ AUTOMAKE_VERSION=`ls /usr/local/bin/automake-* | head -n 1 | sed -e 's/.*-//'`\
AUTOCONF_VERSION=`ls /usr/local/bin/autoconf-* | head -n 1 | sed -e 's/.*-//'`\
aclocal && AUTOMAKE_VERSION=`ls /usr/local/bin/automake-* | head -n 1 | sed -e 's/.*-//'`\
AUTOCONF_VERSION=`ls /usr/local/bin/autoconf-* | head -n 1 | sed -e 's/.*-//'`\
autoconf && AUTOMAKE_VERSION=`ls /usr/local/bin/automake-* | head -n 1 | sed -e 's/.*-//'`\
AUTOCONF_VERSION=`ls /usr/local/bin/autoconf-* | head -n 1 | sed -e 's/.*-//'` automake -a\
&& CXX=eg++ ./configure && make
Windows:
Windows binaries are now desgined to be compiled with MinGW-W64 (since we use threading download a version of MinGW-W64 g++ with seh).
(Go to where you installed MinGW-W64 and click mingw-64.bat)
g++.exe src/common.cpp src/win/bin2hex.cpp src/win/bin2hex_pc.cpp src/win/popen2.cpp src/win/main.cpp src/win/help.cpp src/match_seg.cpp src/win/sys_string.cpp src/win/sys_string_pc.cpp src/win/man_read.cpp src/randomizer.cpp src/trash.cpp -I./ -I./include -std=c++11 -lstdc++ -lpthread -O2 -o ansvif.exe -static -static-libgcc -static-libstdc++
gcc src/win/printf.c -o printf.exe
Note: cygwin .dll external files are no longer required as we now compile with g++ from MinGW. In Windows 7 Powershell v2 is installed by default, however, this program requires atleast Powershell v5. Windows 10 includes powershell v5. You can go to Microsoft's site and download the Windows Management Framework (which includes newer Versions of Powershell here:
https://www.microsoft.com/en-us/download/details.aspx?id=50395

Testing:
If you would like to try out the example code, you can compile faulty.c with:
$ gcc faulty.c -o faulty
Using the example code: You can point the memory back at address \xff\x05\x40\x00\x00\x00\x00\x00 (the subroutine containing the code that spawns bash) with: $ ./faulty -a $(perl -e 'print "A"x24;print "\x00\xff\x05\x40\x00\x00\x00\x00\x00"') The address may be a little different under your distro, check gdb if you really want to try it out. The code above /should/ drop you at a bash prompt. If the code is set to a mode where all are able to execute as another user, it will attempt to spawn a root shell. or simply run make test .

Usage:
Important note: Windows users will have to run ansvif.exe from Powershell for it to work!
$ ./find_suid /usr/bin/ /bin/ /sbin/
$ ./ansvif -[tm] [template/manpage] -c /path/to/executable -b buffersize

Examples:
Linux/BSD:
$ echo "Marshall" ./ansvif -t examples/template -c ./faulty -b 64
$ ./ansvif -m mount -c /bin/mount -e examples/mount_e.txt -x examples/mount_o.txt\
-f 8 -b 2048
$ ./ansvif -t examples/blank.txt -F tmp/tmphtml -x examples/htmltags.txt -c /usr/bin/iceweasel -b\
128 -A "file:///home/username/src/ansvif/tmp/tmphtml" -f 2 -n -R "sleep 3 && killall\
iceweasel" -S ">"
$ cat examples/linux_syscalls_implemented.list | xargs -P \
`cat examples/linux_syscalls_implemented.list | wc -l` -I {calls} ./ansvif -t examples/space.txt \
-B "{calls} " -c ./syscalls -o syscall_crash -f 1 -z -d -b 16
Windows:
PS C:\ansvif\bin\ansvif_win> .\ansvif -t ..\..\examples\space -F ..\..\tmp\tmphtml -x `
..\..\examples\htmltags -c `
'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe' `
-b 128 -A "file:///C:\\Users\marsh\OneDrive\Documents\Code\ansvif\tmp\tmphtml" `
-f 2 -n -S ">" -R "sleep 2 ; Stop-Process -Name chrome"

Options:
  -t This file should hold line by line command arguments as shown in the example file.
-e This file should hold line by line environment variables as shown in the example
file. You can usually get these by doing something like:
$ strings /bin/mount | perl -ne 'print if /[A-Z]=$/' > mount_envs
-c Specifies the command path.
-p Specifies the manpage location (as an integer, usually 1 or 8)
-m Specifies the commands manpage.
-D Dumps whats found in the manpage.
-f Number of threads to use. Default is 2.
-b Specifies the buffer size to fuzz with. 256-2048 Is usually sufficient.
-r Uses only random garbage data.
-o Writes output to log file.
-z Randomize the buffer size from 1 to what is specified by -b.
-x Other junk to put in. Usernames and such can go here.
-S Seperator between options.
-s Omitted character specification. Defaults are <>\\n |&\[]\()\{}:;\ and newline is mandatory.
-T Timeout for threads.
-W Timeout for threads.
-L Unpriviledged user to run as if root.
-A Always put whats after this after command to run.
-B Always put whats after this before the command to run.
-F File to feed into the program that -x along with normal fuzzing data will be put in.
-n Never use random data in the fuzz.
-R Run this command after each fuzz.
-C A Non standard error code to detect.
-V Use Valgrind if installed.
-1 Try to make it fault once, if it doesn't happen, throw error code 64. Useful for scripting.
-P Use % to represent binary in fuzz.
-M Max arguments to use in the fuzz.
-y Short for -b 0 and usually only useful with -A or -B
-K Keep fuzzing after a crash in the target.
-v Verbose.
-d Debug data.
-h Shows the help page.

Recommendations: It is recommended that if you are doing long fuzzes or file fuzzing, if possible put the files (including the binary you are fuzzing if possible) in memory. This means, put them somewhere like /var/run/shm where disk thrash will be minimal, and fuzzing will be somewhat faster, especially if large files are being handled. Be warned however: You will lose your fuzzed files if they are in shm and you reboot the machine!

DO NOT RUN THIS CODE IN A PRODUCTION ENVIRONMENT! If you try setting faulty.c's output to suid(0) then PLEASE do it in a virtual machine. or atleast a machine that you don't care about. Other than that, just play around and have fun!

Notes:
Windows users must have ansvif running from Powershell. Linux and Windows code should be relatively stable. Syscall fuzzing under linux is under heavy development.