Articles tagged #rust
A half-hour to learn Rust
In order to increase fluency in a programming language, one has to read a lot of it.
But how can you read a lot of it if you don’t know what it means?
In this article, instead of focusing on one or two concepts, I’ll try to go through as many Rust snippets as I can, and explain what the keywords and symbols they contain mean.
Ready? Go!
Variable bindings
Loading multiple ELF objects
Up until now, we’ve been loading a single ELF file, and there wasn’t much
structure to how we did it: everyhing just kinda happened in main, in no
particular order.
But now that shared libraries are in the picture, we have to load multiple ELF files, with search paths, and keep them around so we can resolve symbols, and apply relocations across different objects.
The simplest shared library
In our last article, we managed to load and execute a PIE (position-independent executable) compiled from the following code:
; in `samples/hello-pie.asm`
global _start
section .text
_start: mov rdi, 1 ; stdout fd
lea rsi, [rel msg]
mov rdx, 9 ; 8 chars + newline
mov rax, 1 ; write syscall
syscall
xor rdi, rdi ; return code 0
mov rax, 60 ; exit syscall
syscall
section .data
msg: db "hi there", 10
ELF relocations
The last article, Position-independent code, was a mess. But who could blame us? We looked at the world, and found it to be a chaotic and seemingly nonsensical place. So, in order to blend in, we had to let go of a little bit of sanity.
The time has come to reclaim it.
Short of faulty memory sticks, memory locations don’t magically turn from
0x0 into valid addresses. Someone is doing the turning, and we’re going to
find out who, if it takes the rest of the series.
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 thewritesystem call.entry_point, a C program that prints the address ofmainusingprintf- The
/bin/trueexecutable, probably also a C program (because it’s part of GNU coreutils), and which just exits with code 0.
We noticed that when running entry_point 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 had 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.
Crafting ICMP-bearing IPv4 packets with the help of bitvec
So. Serializing IPv4 packets. Easy? Well, not exactly.
IPv4 was annoying to parse, because we had 3-bit integers, and 13-bit integers, and who knows what else. Serializing it is going to be exactly the same.
Right now, we don’t have a way to serialize that.
Let’s take the version and ihl fields, both of which are supposed
to take 4 bits, together making a byte. We could serialize them like this:
Go back to the homepage.