Introduction to the ELF Format Part II : Understanding Program Headers

Welcome back folks! In the previous post I covered pretty much the most trivial parts of the ELF file format. In this post we are actually going to work with one of the most interesting mechanisms in the file - the program headers!  I skipped some parts of the ELF header in the previous post and decided to cover them here specifically because they inform on the Program Headers anyway. Lets get started!
Introduction : What are Program Headers?
I mentioned in part 1 that the ELF format performs two tasks. A recipe for how to sublimate dead files into living processes and adds the bells and whistles needed to make the file look pretty to gdb, the dynamic loader and a bunch of other tools. Program Headers (among other functions) are more often for telling the memory loader where to put stuff. It also has some house keeping functions.

We'll get into how these memory loading powers and formats work a little later for now its just important to keep in mind a good idea of what to expect …

Introduction to the ELF Format : The ELF Header (Part I)

ELF Files are charged with using their magic to perform two holy tasks in the linux universe. The first being to tell the kernel where to place stuff in memory from the ELF file on disk as well as providing ways to invoke the dynamic loaders functions and maybe even help out with some debugging information. Essentially speaking its telling the kernel where to put it in memory and also the plethora of tools that interpret the file where all the data structures are that hold useful information for making sense of the file. Anyway that's as far as I've figured it out - the actual break down is a little less simple.

I'll demonstrate why this is so here and over the next series of posts in the classic "Learn things by breaking them" style.
ELF Header and Identification fields The first thing that appears in an ELF file is of course the header, which is like most things in file formats just a list of offsets in the file. Its purpose is to indicate essentially what kin…

Object-Orientated Ontology and the Computer Hacker

I'm busy burning through Graham Harman's Object Orientated Ontology and reflecting on it in different ways as informing on the phenomenology of computer hacking. This name for the concept "Object Orientated Ontology" needs some breaking down, and building up before we are ready to plug it into the hacking world. "You can prove it top-down and bottom-up" - Reg Dodds.

Object orientation in the programming language sense is a way of encapsulating a list of attributes by reference to a given atomic ultimately number-name. So it basically gives us the ability to stuff concepts of a certain kind into a black box that doesn't require our scrutiny at every second (potentially damaging the accuracy of engineering). We as a result have instead of a "real" or direct representation of that object in memory, we get what is essentially a number with which to refer to it.

In the sense of Harmon's work the "object" in  the term "Object Ori…

Reversing a bare bones Raspberry Pi Kernel : Branching To the Kernel

I lost the first version of this post because of problem in blogger's auto-save function.

Anyway so if you want to get your own raspberry pi os kernel going, I share some cool posts on that in here and expand on them by unpacking some of the assembler code essentially reverse engineering it or "unrolling" the os. 
Setting up your Development Environment I think the explanation of the 'Roll your own Rapsberry Pi Os' at pretty much sorts this out I can at least do the favor of confirming that this persons advice definitely does the job so check it out.  The post also discusses the background of why we need certain files in the project for instance like the linker scripts and kernel.c files. As a short summary here's the basic work flow:

1 - Write a linker script This is to make sure the compiler can recombined the boot.S and kernel.c parts 2 - Write a boot.S This file is to initialize the run time for your kernel and branch into i…

[Reverse Engineering Primer] Unpacking cramfs firmware file systems

Reverse engineering firmware from the point of view of an attacker involves levering as much as possible what is accessible from the physical board. Of course the classic question this strives to answer is, if someone gets hold of my board what could go wrong? Reverse engineering some devices in the wild often exposes security keys, default passwords and other forms of security failures that can expose an unfair escalation of privilege or perhaps also allow a complete take over of the device right down to boot loader level - all of this sometimes also possibly learned by analyzing the firmware.

I'm going to talk about some of the more basic skill in getting toward exposing the code and other sensitive artifacts used by the device. Before you can find remote code execs and admin auth by pass vulns you need to get to grips with firmware image formats and embedded file systems.

Setting up the environment 
Before getting super in depth and writing our own file format parsers, machine …