Follow Effect Hacking - Learn To Hack and Protect on Feedspot

Continue with Google
Continue with Facebook


A modular visual interface for GDB in Python.

This comes as a standalone single-file .gdbinit which, among the other things, enables a configurable dashboard showing the most relevant information during the program execution. Its main goal is to reduce the number of GDB commands issued to inspect the current program status allowing the programmer to focus on the control flow instead.

InstallationJust place .gdbinit in your home directory, for example:
wget -P ~ git.io/.gdbinit

  • Single GDB init file.
  • Write the dashboard to the main GDB console or to an external file/TTY.
  • Interaction with GDB using the native Python API.
  • Several default modules are included to address the most basic needs: source code, assembly, registers, etc.).
  • User-defined modules can be easily developed by extending a Python class.
  • Additional configuration files (both GDB and Python) are read from ~/.gdbinit.d/.
  • Fully stylable user interface and dynamic command prompt.
  • Optional syntax highlighting using the Pygments Python library.
  • No GDB command has been redefined, instead all the features are available as subcommands of the main dashboard command.

Default Modules:
Follows the list of bundled default modules. Refer to the GDB help system for the full syntax.
  • assembly shows the disassembled code surrounding the program counter. The instructions constituting the current statement are marked, if available.
  • history lists the last entries of the GDB value history.
  • memory allows to inspect memory regions.
  • registers shows the CPU registers and their values.
  • source show the program source code, if available.
  • stack shows the current stack trace including the function name and the file location, if available. Optionally list the frame arguments and locals too.
  • threads lists the currently available threads.
  • expressions watches user expressions.

    Dashboard Output:
    By default the dashboard is displayed in the GDB terminal but the -output command of both the dashboard and modules can change this behavior. When the output of a module is not specified then the global output is used.

    Display the whole dashboard in another terminal

    It may be useful to move the dashboard to another terminal so the main terminal can be used exclusively for GDB commands and target I/O.
    1. start GDB in one terminal;
    2. open another terminal (e.g. tmux pane) and get its TTY with the tty command (e.g. /dev/ttys001, the name may be different for a variety of reasons);
    3. issue the command dashboard -output /dev/ttys001 to redirect the dashboard output to the newly created terminal;
    4. debug as usual.

            Display the whole dashboard in a web browser

            Pushing this even further, one could use a web browser as an auxiliary terminal using gotty. Of course, using the method described above, one can also display the output of individual modules in one or more web browser instances.
            1. start GDB in one terminal;
            2. open another terminal and execute gotty sh -c 'tty; cat';
            3. open a web browser, navigate to http://localhost:8080 and note the TTY;
            4. issue the command dashboard -output /dev/ttys001 to redirect the dashboard output to the web browser;
            5. debug as usual.

            CommandsThe GDB documentation is available at help dashboard. Just like any GDB command, abbreviations are possible, so da, dash, etc. all resolve to dashboard.

            • dashboard
            This is the root command and it is used to manually redisplay the dashboard.

            • dashboard -configuration [<file>]
            Display and optionally write to <file> the current configuration (layout, styles, outputs). This command allows to configure the dashboard live then make the changes permanent, for example:
            dashboard -configuration ~/.gdbinit.d/auto

            • dashboard -output [<file>]
            By default the dashboard is written to the GDB console but it is possible to redirect its output to a file or even to another terminal. If the target is a valid terminal TTY then its width is used to format the dashboard, otherwise fall back to the width of the main GDB console.

            Without argument reset this setting to the default.

            • dashboard -enabled [on|off]
            Enable or disable the automatic display of the dashboard whenever the target program stops. The dashboard is enabled by default and even when it is disabled, it can be manually displayed with dashboard.

            Sometimes it may be convenient to redraw the dashboard even if the target program has not changed its execution status, for example when the programmer switches the currently selected frame with the up or down commands. It is possible to do so by setting up some GDB hooks in the user-defined init file, for example:
            define hookpost-up

            define hookpost-down

            • dashboard -layout [<directive>...]
            By default, all the modules are enabled and placed within the dashboard in alphabetical order. As the number of modules grows, it is important to decide which modules will be part of the dashboard, and where.

            Each directive is in the form [!]<module>, when the ! is present then the corresponding module is disabled by default. The order of directives denotes the display order within the dashboard. For example:
            dashboard -layout source !assembly stack
            Modules which do not appear in the list are disabled and placed after the last element in alphabetical order.

            When executed without arguments, this command lists all the available modules in the form of a list of directives followed by the status of the output files of the modules.

            • dashboard -style [<name> [<value>]]
            Access to the stylable attributes of the dashboard, see Stylable attributes. For example, to change the prompt to something more familiar:
            dashboard -style prompt '(gdb)'
            The argument is parsed as a Python literal and converted to the proper type.

            When only the name is specified this command shows the current value, whereas without arguments prints all the attributes.

            Modules Subcommands
            • Every module adds its own subcommand dashboard <module> which is used to toggle the enable flag and to redisplay the dashboard.
            • Modules may also declare additional subcommands, see help dashboard <module> from GDB.
            • There are two additional predefined subcommands: -style and -output.
            If a module declares some stylable attributes then the command dashboard <module> -style will be available. Its functioning is equivalent to the dashboard -style command but it does apply to a module.

            Similarly, the dashboard <module> -output mimics the dashboard -style command but allows a finer grain of operation.

            Files in ~/.gdbinit.d/ are executed in alphabetical order, but the preference is given to Python files. If there are subdirectories, they are walked recursively. The idea is to keep separated the custom modules definition from the configuration itself.

            By convention, the main configuration file should be placed in ~/.gdbinit.d/ (say ~/.gdbinit.d/init) and can be used to tune the dashboard styles and modules configuration but also the usual GDB parameters.

            The alternative is to hard code changes in the provided .gdbinit, to do so just add new modules and GDB settings under # Default modules and # Better GDB defaults respectively.

            Per-project Configuration
            GDB natively support the auto-loading of .gdbinit files, this can come in handy to set up a different dashboard style according to the current project type (e.g., C++ development, reverse engineering, etc.). This feature is disabled by default for security reasons. To enable the auto-loading everywhere in the file system add this line to the main configuration file:
            set auto-load safe-path /

            Stylable AttributesThere is number of attributes that can be used to customize the aspect of the dashboard and of its modules. They are documented within the GDB help system. For what concerns the dashboard itself it can be reached with:
            help dashboard -style

            Whereas for modules:
            help dashboard <module> -style

            • ANSI escape codes
            Colors and text styles are specified using ANSI escape codes. For example setting a style to 1;31 will produce ^[[1;31m, which will result in displaying the text red (31) and bright (1). The ANSI output can be disabled by setting the ansi attribute to False (note that this will not affect the command prompt).

            • Syntax highlighting
            When the ansi attribute is set to True the Pygments Python library may be used by modules to provide syntax highlighting of the source code.

            The syntax_highlighting stylable attribute is a string which defines the Pygments style to use.

            The list of all the available styles can be obtained with (from GDB itself):
            from pygments.styles import get_all_styles as styles
            for s in styles():

            To conveniently cycle through and try each available style (press Return to try the next style and Ctrl-D to exit):
            from pygments.styles import get_all_styles as styles
            for s in styles():
            c = 'dashboard -style syntax_highlighting {!r}'.format(s)

            • Dividers
            A divider is basically a terminal-wide horizontal line with an optional label. Primary dividers are those used to separate the modules, whereas secondary dividers may be used inside modules to logically separate different sections. When a section or module is empty then the styles used for the divider are those with the off qualifier.

            • Common styles
            These are general purpose ANSI styles defined for convenience and used within the default modules.
            • style_selected_1
            • style_selected_2
            • style_low
            • style_high
            • style_error

              Custom Modules
              The idea of custom modules is that they provide ways to access readonly information from the target program status; it is safe to assume that they will be queried during the program execution only.

              Custom modules must inherit the Dashboard.Module class and define some methods:
              • label returns the module label which will appear in the divider.
              • lines return a list of strings which will form the module content. When a module is temporarily unable to produce its content, it should return an empty list; its divider will then use the styles with the off qualifier.
              The name of a module is automatically obtained by the class name.

              Modules are instantiated once at initialization time and kept during the whole the GDB session.

              Optionally, a module may include a description which will appear in the GDB help system by specifying a Python docstring for the class.

              Optionally, a module may define stylable attributes by defining the attributes method returning a dictionary in which the key is the attribute name and the value is another dictionary:

              The name of a module is automatically obtained by the class name.

              Modules are instantiated once at initialization time and kept during the whole the GDB session.

              Optionally, a module may include a description which will appear in the GDB help system by specifying a Python docstring for the class.

              Optionally, a module may define stylable attributes by defining the attributes method returning a dictionary in which the key is the attribute name and the value is another dictionary:
              • default is the initial value for this attribute.
              • doc is the documentation of this attribute which will appear in the GDB help system. This key can be omitted.
              • name is the name of the attribute of the Python object, defaults to the key value.
              • type is the type of this attribute, it is used to coerce the value passed as an argument to the proper type, or raise an exception. This key defaults to the str type.
              • check is a control callback which accept the coerced value and returns True if the value satisfies the constraint and False otherwise. This key is optional, when omitted no check is performed.
              Optionally, a module may declare subcommands by defining the commands method returning a dictionary in which the key is the command name and the value is another dictionary:
              • action is the callback to be executed which accepts the raw input string from the GDB prompt. Callbacks may raise exceptions to notify erroneous situations which message will be shown automatically to the user.
              • doc is the command documentation.
              • completion is the completion policy, one of the gdb.COMPLETE_* constants defined in the reference manual. This key is optional and defaults to None which is equivalent to gdb.COMPLETE_NONE.
              • Common Functions
              A number of auxiliary common functions are defined in the global scope, they can be found in the provided .gdbinit and concern topics like ANSI output, divider formatting, conversion callbacks, etc. They should be more or less self-documented, some usage examples can be found within the bundled default modules.
              • Example
              Default modules already provide a good example, but here is a simple module which may be used as a template for new custom modules, it allows the programmer to note down some snippets of text during the debugging session.

              class Notes(Dashboard.Module):
              """Simple user-defined notes."""

              def __init__(self):
              self.notes = []

              def label(self):
              return 'Notes'

              def lines(self, term_width, style_changed):
              out = []
              for note in self.notes:
              if self.divider:
              return out[:-1] if self.divider else out

              def add(self, arg):
              if arg:
              raise Exception('Cannot add an empty note')

              def clear(self, arg):
              self.notes = []

              def commands(self):
              return {
              'add': {
              'action': self.add,
              'doc': 'Add a note.'
              'clear': {
              'action': self.clear,
              'doc': 'Remove all the notes.'

              def attributes(self):
              return {
              'divider': {
              'doc': 'Divider visibility flag.',
              'default': True,
              'type': bool

              To use the above just save it in a Python file, say notes.py, inside ~/.gdbinit.d/, the following commands (together with the help) will be available:
              dashboard notes
              dashboard notes add
              dashboard notes clear
              dashboard notes -style

              Minimal Requirements:GDB dashboard requires at least GDB 7.7 compiled with Python 2.7 in order to work properly.

              Additional GDB front endsGDB dashboard is not meant to work seamlessly with additional front ends, e.g., TUI, Nemiver, QtCreator, etc.

              There are basically two options to work around this:
              • if the main debugging tool is GDB dashboard then it is recommended to prevent the front end from loading the .gdbinit file, they usually have an option to do so;
              • otherwise it is possible to load GDB dashboard manually, that is, install as usual then:
              mv ~/.gdbinit ~/.gdb-dashboard

              finally load it when needed from the GDB shell:
              source ~/.gdb-dashboard

              You might also like:
              • Show original
              • .
              • Share
              • .
              • Favorite
              • .
              • Email
              • .
              • Add Tags 

              V3n0M is a free and open source scanner. Evolved from Baltazar's scanner, it has adopted several new features that improve functionality and usability.

              This program is for finding and executing various vulnerabilities. It scavenges the web using dorks and organizes the URLs it finds.

              It is very useful for executing:
              • Cloudflare Resolver[Cloudbuster]
              • LFI->RCE and XSS Scanning[LFI->RCE & XSS]
              • SQL Injection Vuln Scanner[SQLi]
              • Extremely Large D0rk Target Lists
              • AdminPage Finding
              • Toxin [Vulnerable FTPs Scanner]
              • DNS BruteForcer
              • Python 3.6 Asyncio based scanning

              The official adoption of darkd0rker heavily recoded, updated, expanded and improved upon
              • Brand new, just outta the box!
              • Most efficient Cloudflare resolver around with easy to use interface.
              • Extremely quick "Toxin" Vulnerable IP scanner to scan potentially millions of IPs for known vulnerable services.
              • Largest and most powerful d0rker online, 14k+d0rks searched over ~ Engines at once.
              • Free and Open /src/
              • cross-platform Python-based toolkit
              • Release 425 Released on 18th February 2018
              • Licensed under GPLv3

              Tested on: ArchLinux 4.14, Ubuntu, Debian, Kali, MacOS, BlackArch, Manjaro/ArchLinux ARM Ed. Android-Termux.

              Note for Ubuntu users: Please make sure you have installed --> sudo apt-get install python3-bs4 and apt-get install python3-setuptools
                    Otherwise you may get Syntax Error stopping the program from running.
              Note for Kali users: Please make sure you have installed --> apt-get install python3-dev apt-get install python-dev

              Install Note:
              • Clone the repository:
              $ git clone https://github.com/v3n0m-Scanner/V3n0M-Scanner.git
              • Then go inside:
              $ cd V3n0M-Scanner/
              • Then install it:
              $ python3 setup.py install --user

              You might also like:
              • Show original
              • .
              • Share
              • .
              • Favorite
              • .
              • Email
              • .
              • Add Tags 

              PentestPackage is a collection of scripts for Pentesting.

              • Wordlists - Comprises of password lists, username lists, and subdomains
              • Web Service finder - Finds web services of a list of IPs and also returns any URL rewrites
              • Gpprefdecrypt.* - Decrypt the password of local users added via Windows 2008 Group Policy Preferences.
              • rdns.sh - Runs through a file of line separated IPs and prints if there is a reverse DNS set or not.
              • grouppolicypwn.sh - Enter domain user creds (doesn't need to be priv) and will communicate with the domain controllers and pull any stored CPASS from group policies and decode to plain text. Useful for instant Domain Admin!
              • privchecker.sh - Very young script that simply checks DCenum to a list of users to find their group access, indicated any privileged users, this list can be edited.
              • NessusParserSummary.py - Parses Nessus results to give a summary breakdown of findings plus a host count next to each.
              • NessusParserBreakdown.py- Parses Nessus results to give a host-based breakdown of findings plus the port(protocol) and CVSS rating.
              • NmapParser.py - Parses raw NMAP results (or .nmap) and will create individual .csv files for each host with a breakdown of ports, service version, protocol and port status.
              • NmapPortCount.py - Parses raw NMAP results (or .nmap) and will generate a single CSV with a list of Hosts, a count of how many open/closed/filtered ports it has, the OS detection and ICMP response.
              • Plesk-creds-gatherer.sh - Used on older versions of Plesk (before the encryption came in) that allows you to pull out all the credentials form the databases using a nice Bash menu
              • BashScriptTemplate.sh - Handy boiler plate template fro use in new scripts.
              • PythonScriptTemplate.py - Handy boiler plate template fro use in new scripts.
              • ipexplode.pl - Simply expands CIDRs and prints the IPs in a list, handy for when you need a list of IPs and not a CIDR
              • LinEsc.sh - Linux escalation script. This will test common methods of gaining root access or show potential areas such as sticky perms that can allow manual testing for root escalation
              • gxfr.py - GXFR replicates DNS zone transfers by enumerating subdomains using advanced search engine queries and conducting DNS lookups.
              • knock.sh - Simple script used to test/perform port knocking.
              • sslscan-split-file.py - Used to split a large SSLScan results file into individual SSLScan results.
              • TestSSLServer.jar - Similar tool to SSLScan but with different output.
              • wiffy.sh - Wiffy hacking tool, encapsulated in a single Bash script.
              • gophish_positions_export.py - A simple python script for taking 'results.csv' and getting statistics based on positions in the company.

              You might also like:
              • Show original
              • .
              • Share
              • .
              • Favorite
              • .
              • Email
              • .
              • Add Tags 

              Separate tags by commas
              To access this feature, please upgrade your account.
              Start your free month
              Free Preview