Articles tagged #assembly

Position-independent code

In the last article, we found where code was hiding in our samples/hello executable, by disassembling the whole file and then looking for syscalls.

Later on, we learned how to inspect which memory ranges are mapped for a given PID (process identifier). We saw that memory areas weren't all equal: they can be readable, writable, and/or executable.

Running an executable without exec

In part 1, we've looked at three executables:

  • sample, an assembly program that prints "hi there" using the write system call.
  • entry_point, a C program that prints the address of main using printf
  • The /bin/true executable, probably also a C program (because it's part of GNU coreutils), and which just exits with code 0.

We noticed that when running through GDB, it always printed the same address. But when we ran it directly, it printed a different address on every run.

What's in a Linux executable?

Executables have been fascinating to me ever since I discovered, as a kid, that they were just files. If you renamed a .exe to something else, you could open it in notepad! And if you renamed something else to a .exe, you'd get a neat error dialog.

Clearly, something was different about these files. Seen from notepad, they were mostly gibberish, but there to be order in that chaos. 12-year-old me knew that, although he didn't quite know how or where to dig to make sense of it all.

Consuming Ethernet frames with the nom crate

Now that we've found the best way to find the "default network interface"... what can we do with that interface?

Well, listen for network traffic of course!

Rust code
use rawsock::open_best_library;
use std::time::Instant;

fn main() -> Result<(), Error> {
    let lib = open_best_library()?;

    let iface_name = format!(r#"\Device\NPF_{}"# netinfodefault_nic_guid?
     iface = libiface_name?

    

    
     start = 
    iface |packet| 
        
            
            startelapsed
            packetlen
        
    ?
    

Reading files the hard way - Part 2 (x86 asm, linux kernel)

Looking at that latest mental model, it's.. a bit suspicious that every program ends up calling the same set of functions. It's almost like something different happens when calling those.

Are those even regular functions? Can we step through them with a debugger?

If we run our stdio-powered C program in gdb, and break on read, we can confirm that we indeed end up calling a function (which is called here, but oh well):

Go back to the homepage.