So far, we've combed through the basics - expr and a module - analysis.
In this article, I'll give an overview of the i and p modules:
i: displaying information about the binary(the program being debugged).p: printing memory and data, such as the hexdump, the disassembly, and the strings.So far, we've combed through the basic usage of r2, see basics and expr.
In this article, I'll give an overview of the a module that supports analysis.
After installing the radare2 toolset, we've come on board.
Let's set sail with some important and frequently used commands.
First raw, then ripe. Well begun is half done.
radare: UNIX-like reverse engineering framework and command-line toolset.
The Radare2 project is a set of small command-line utilities that can be used together or independently.
You can debug a program from the command line using GDB or even more powerful tools such as Radare2, IDA Pro and Binary Ninja.
Every loadable or allocatable output section has two addresses. The first is the VMA, or virtual memory address. This is the address the section will have when the output file is run. The second is the LMA, or load memory address. This is the address at which the section will be loaded.
In most cases, the two addresses will be the same, because wherever the program is loaded into memory, that is where it will be executed. So what's the actual difference between the VMA and the LMA? Under what circumstances does VMA != LMA?
Core dump: In computing, a core dump, memory dump, crash dump, storage dump, system dump, or ABEND dump consists of the recorded state of the working memory of a computer program at a specific time, generally when the program has crashed or otherwise terminated abnormally. In practice, other key pieces of program state are usually dumped at the same time, including the processor registers, which may include the program counter and stack pointer, memory management information, and other processor and operating system flags and information.
Core File Generation (Debugging with GDB): A core file or core dump is a file that records the memory image of a running process and its process status (register values etc.). Its primary use is post-mortem debugging of a program that crashed while it ran outside a debugger. A program that crashes automatically produces a core file, unless this feature is disabled by the user.
Previously, we've dynamically analysed how shared dynamic symbols such as puts are resolved and relocated at runtime using gdb-pwndbg.
On this post, we'll do much the same work, but change our dynamic analysis tool to the popular open-source SRE toolkit r2(aka radare2).
It is also a thorough and comprehensive debugging exercise, demonstrating the power and versatility of the r2 toolset.
Previously we've statically analysed the layout and ingredients of the DYN PIE ELF a.out. In particular, we've focused on dynamic sections/symbols and relocation entries.
In this article, we'll do some dynamic analysis, taking a closer look at how shared dynamic symbols such as puts are resolved and relocated at runtime.
It is also a thorough and comprehensive pwndbg debugging exercise, showcasing the use of the advanced features of GDB.
So far we've been through the default gcc compilation process and had a look at the product of our C demo program a.out with GNU binutils.
It links dynamically by default, a dynamic linker (aka interpreter) is used to resolve the final dependencies on dynamic libraries when the executable is loaded into memory to run.
Previously, we've gone through the basic concepts of static linking and dynamic linking. In this article I'll have a look at how the shared dynamic symbol such as puts is designated at link time in the DYN PIE ELF.