| Starting BeEF (wait a few seconds)..................... | |
| Loaded suite BeEF DNS Unit Tests | |
| Started | |
| E | |
| =============================================================================== | |
| Error: TC_Dns | |
| NameError: uninitialized constant BeEF::Core::Router | |
| /home/soh_cah_toa/src/git/beef/extensions/dns/rest/dns.rb:11:in `<module:Dns>' | |
| 8: module Dns | |
| 9: |
As the name implies, extensions serve to "extend" the capabilities of BeEF. Extensions differ slightly from modules. They are a way to add new functionality to the core features of BeEF whereas modules usually have a narrow set of abilities that perform a specific task. This helps prevent feature creep by modularizing new core features. So if you're asking yourself...
Does it change the way BeEF behaves? Extension
Does it change the way zombies behave? Module
The purpose of this design document is to communicate the vision for cotitan, describe its contents in detail, and suggest a plan for its implementation.
This is a living document that is subject to continuous editing and revisal as development progresses. As different directions are explored, over time it shall become an elaborate archive of all aspects of the game.
| A debug data format provides a way for storing high-level source information about a program. This | |
| allows analysis software such as debuggers and profilers to form a relationship between the | |
| executable code and the original source code that generated it. This is the purpose of PODDS: | |
| Parrot Opcode Debug Data Serialization format. | |
| The full PODDS specification is quite lengthy. Therefore, this document is meant to serve as a | |
| quick introduction to PODDS. If you'd like to see the full specification, visit https:/ | |
| gist.github.com/1133182. | |
| The most basic entity in PODDS is called a "Data Description Entity" or DDE. A DDE consists of a |
| As of 3.6.0, the debug segment in Parrot bytecode is severely lacking to say the least, | |
| containing merely a line number to opcode mapping that is very unreliable. What we need is a | |
| standardized data debugging format. One of the challenges in this is how to describe the | |
| relationship between the generated bytecode and the original source with enough detail so that a | |
| debugger can provide the user with detailed information. Additionally, this description must be | |
| short and sweet so that it doesn't eat up a lot of space or take too much processing time to | |
| interpret. | |
| There already exists several debugging formats: COFF, stabs, DWARF, etc. However, these are | |
| generally used in object files and executables and not virtual machine bytecode (with the |
| Kevin Polulak | |
| # CONTACT INFORMATION: | |
| Email: kpolulak@gmail.com | |
| Google ID: kpolulak | |
| IRC: soh_cah_toa | |
| # NEW PARROT DEBUGGER: |