Skip to content

Blog#

VMA & LMA

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?

Ubuntu Apport Core Dump

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.

  • in elf
  • 21 min read

reloc puts@plt via GOT - r2 debug

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.

  • in elf
  • 27 min read

reloc puts@plt via GOT - pwndbg

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.

  • in elf
  • 25 min read

puts@plt/rela/got - static analysis

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.

  • in elf
  • 8 min read

REL ELF Walkthrough

Previously we've compiled our C demo program with gcc -c command.

gcc -c compile or assemble the source files, but do not link. The linking stage simply is not done. The ultimate output is in the form of an object file for each source file.

In this article, I'll practice using GNU binutils to take a close look at the 0701.o product.