radare2 4.0 releases: unix-like reverse engineering framework and commandline tools
r2 is a rewrite from scratch of radare in order to provide a set of libraries and tools to work with binary files.
Radare project started as a forensics tool, a scriptable command line 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.
The main tool of the whole framework. It uses the core of the hexadecimal editor and debugger. radare2 allows you to open a number of input/output sources as if they were simple, plain files, including disks, network connections, kernel drivers, processes under debugging, and so on.
- 6502, 8051, CRIS, H8/300, LH5801, T8200, arc, arm, avr, bf, blackfin, xap, dalvik, dcpu16, gameboy, i386, i4004, i8080, m68k, malbolge, mips, msil, msp430, nios II, powerpc, rar, sh, snes, sparc, tms320 (c54x c55x c55+), V810, x86-64, zimg, risc-v.
- File Formats:
- ELF, Mach-O, Fatmach-O, PE, PE+, MZ, COFF, OMF, TE, XBE, BIOS/UEFI, Dyldcache, DEX, ART, CGC, Java class, Android boot image, Plan9 executable, ZIMG, MBN/SBL bootloader, ELF coredump, MDMP (Windows minidump), WASM (WebAssembly binary), Commodore VICE emulator, Game Boy (Advance), Nintendo DS ROMs and Nintendo 3DS FIRMs, various filesystems.
- Operating Systems:
- Windows (since XP), GNU/Linux, OS X, [Net|Free|Open]BSD, Android, iOS, OSX, QNX, Solaris, Haiku, FirefoxOS
- Vala/Genie, Python (2, 3), NodeJS, Lua, Go, Perl, Guile, php5, newlisp, Ruby, Java, OCaml, …
radare2 v4.0 has been released.
- Release v4.0.0 – Codename Krampack
- Fixed issues in windows thread switching by implementing thread attach for w32dbg =!pid
- Previously the function attempted to OpenProcess even though the main
- pid is already opened by __open and the fact that re-opening the main
- pid wouldn’t do anything. This way it attaches to new threads when
- called by r_debug_select.
- Modified w32_continue to update rio->pi.dwThreadId after switching to the requested thread ##debug
- Manually changing iop->pi.dwThreadId in io_w32dbg’s =!pid created a
- problematic scenario when w32_continue is called with the last event’s
- tid from dbg_wait. This solution makes sure iop->pi.dwThreadId keeps
- being updated after events on other threads arrive and that w32_continue
- actually uses the given tid.
- Modified w32_continue return values
- Fix build
Copyright (C) 2013 radare