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 Reverse Engineering. Show all posts
Showing posts with label Reverse Engineering. Show all posts

ScratchABit - Easily retargetable and hackable interactive disassembler with IDAPython-compatible plugin API


ScratchABit is an interactive incremental disassembler with data/control flow analysis capabilities. ScratchABit is dedicated to the efforts of the OpenSource reverse engineering community (reverse engineering to produce OpenSource drivers/firmware for hardware not properly supported by vendors).
ScratchABit supports well-known in the community IDAPython API to write disassembly/extension modules.
ScratchABit is a work in progress, features are added on as needed basis, contributions are welcome.
ScratchABit is released under the terms of GNU General Public License v3 (GPLv3).

Requirements/manifesto
  1. Should not be written in an obfuscated language. These includes languages which are too low-level, which allow to access non-initialized variables, which don't differentiate between variables and functions/procedures, which start array indexes from arbitrary numbers, etc., etc. ScratchABit is written in Python (modern version, Python3) for your pleasure and sanity.
  2. User interface framework should allow user interaction of the needed level, not add dependencies, bloat, issues, and incompatibilities between framework's versions. ScratchABit currently uses simple (no color even) full-screen text user interface, using ANSI/VT100 terminal escape sequences (yes, even curses library was deemed too bloat a dependency to force upon users).
  3. Should leverage easy to use text formats to store "database", to facilitate easy reuse and tool writing, and storage in version control systems.

Quick start
To use ScratchABit, you need Python3 installed and VT100 (minimum) or XTerm (recommended) terminal or terminal emulator (any Unix system should be compliant, like Linux/BSD/etc., see FAQ below for more).
Clone the code using:
git clone --recursive https://github.com/pfalcon/ScratchABit
If you cloned code without --recursive , run git submodule update --init .
If you want to disassemble a file in self-describing executable format (like ELF), just pass it as an argument to ScratchABit.py . The repository includes example-elf (x86 32bit) for quick start:
python3 ScratchABit.py example-elf
Alternatively, if you want to disassemble a raw binary file, you need to create a .def (definition) file, to specify what memory areas are defined for the code, at which address to load binary file, etc. (Note: a .def file may be useful for .elf and similar files too.) The repository includes a simple x86_64 raw binary code, and the corresponding .def file:
python3 ScratchABit.py example.def
Press F1 if in doubt what to do next (ScratchABit works similarly to other interactive dissamblers; some previous experience or background reading may be helpful). Press F9 to access menus (mouse works too in XTerm-compatible terminals).

Using Plugins
IDAPython processor plugins can be loaded from anywhere on the Python module path. Alternatively, you can symlink the plugin .py file into the plugins/cpu/ subdirectory.
After the plugin is made available, create a new definition file based on example.def that sets the plugin module name in the cpu xxx line.
For a very simple example that uses an external plugin, see this esp8266.def file that works with the xtensa.py plugin from the ida-xtensa2 repository .

TODO/Things to decide
  • Currently uses multiple files for "database", each storing particular type of information. Switch to a single YAML file instead?
  • Add color (low priority, (unbloated!) patches welcome).
  • Few important UI commands to implement yet for comfortable work. ( All the most important commands should be there, other functionality is expected to be implemented using plugins).
  • Offer to save DB on quit if modified.
  • Git integration for DB saving.
  • Improve robustness (add exception handler at the main loop level, don't abort the application, show to user/log and continue).
  • Try to deal with code flow inconsistencies (e.g. within an instruction
    • low priority for intended usage) and data access inconsistencies (e.g. accessing individual bytes of previosly detected word - higher priority). (Improved in 1.4.)
  • See how to support other types of IDAPython plugins besides just processor modules.
  • Parse and use debugging information (e.g. DWARF) present in ELF (etc.) files.

FAQ
Q: What processors/architectures are supported?
A: ScratchABit doesn't support any processor architectures on its own, it is fully retargettable using IDAPython API plugins. Many plugins are available, writing a new plugin is easy. To let users test-drive ScratchABit, a very simple (!) X86 processor plugin is included in the distribution, using Pymsasid disassembler under the hood.
Q: I'm not on Linux, how can I run ScratchABit?
A: Install Linux in an emulator/VM on your system and rejoice.


Radare - The Reverse Engineering Framework


r2 is a rewrite from scratch of radare in order to provide a set of libraries and tools to work with binary files
This is the rewrite of radare (1.x branch) to provide a framework with a set of libraries and programs to work with binary data.

Radare project started as a forensics tool, an scriptable commandline hexadecimal editor able to open disk files, but later support for analyzing binaries, disassembling code, debugging programs, attaching to remote gdb servers, ..

radare2 is portable.

Architectures:
6502, 8051, arm, arc, avr, bf, tms320 (c54x, c55x, c55+), gameboy csr, dcpu16, dalvik, i8080, mips, m68k, mips, msil, snes, nios II, sh, sparc, rar, powerpc, i386, x86-64, H8/300, malbolge, T8200

File Formats:
bios, dex, elf, elf64, filesystem, java, fatmach0, mach0, mach0-64, MZ, PE, PE+, TE, COFF, plan9, bios, dyldcache, Gameboy and Nintendo DS ROMs

Operating Systems:
Android, GNU/Linux, [Net|Free|Open]BSD, iOS, OSX, QNX, w32, w64, Solaris, Haiku, FirefoxOS

Bindings:
Vala/Genie, Python (2, 3), NodeJS, LUA, Go, Perl, Guile, php5, newlisp, Ruby, Java, OCAM

Features:
  • Multi-architecture and multi-platform
    • GNU/Linux, Android, *BSD, OSX, iPhoneOS, Windows{32,64} and Solaris
    • i8080, 8051, x86{16,32,64}, avr, arc{4,compact}, arm{thumb,neon,aarch64}, c55x+, dalvik, ebc, gb, java, sparc, mips, nios2, powerpc, whitespace, brainfuck, malbolge, z80, psosvm, m68k, msil, sh, snes, gb, dcpu16, csr, arc
    • pe{32,64}, te, [fat]mach0{32,64}, elf{32,64}, bios/uefi, dex and java classes
  • Highly scriptable
    • Vala, Go, Python, Guile, Ruby, Perl, Lua, Java, JavaScript, sh, ..
    • batch mode and native plugins with full internal API access
    • native scripting based in mnemonic commands and macros
  • Hexadecimal editor
    • 64bit offset support with virtual addressing and section maps
    • Assemble and disassemble from/to many architectures
    • colorizes opcodes, bytes and debug register changes
    • print data in various formats (int, float, disasm, timestamp, ..)
    • search multiple patterns or keywords with binary mask support
    • checksumming and data analysis of byte blocks
  • IO is wrapped
    • support Files, disks, processes and streams
    • virtual addressing with sections and multiple file mapping
    • handles gdb:// and rap:// remote protocols
  • Filesystems support
    • allows to mount ext2, vfat, ntfs, and many others
    • support partition types (gpt, msdos, ..)
  • Debugger support
    • gdb remote and brainfuck debugger support
    • software and hardware breakpoints
    • tracing and logging facilities
  • Diffing between two functions or binaries
  • Code analysis at opcode, basicblock, function levels
    • embedded simple virtual machine to emulate code
    • keep track of code and data references
    • function calls and syscall decompilation
    • function description, comments and library signatures