Breadbox

if you want to understand chip architectures, work through the elements of computing systems (aka nand to tetris). it walks you through implementing your own cpu, gate by gate, plus an operating system, compiler, and tetris game, in a way tested to successfully fit inside of a single-semester undergraduate class. their hardware designs are pretty weird (their hdl looks nothing like any hdl you can actually synthesize hardware from, their descriptions of how gates work are oversimplified, and their instruction set architecture is pretty similar to the eclipse that kidder was writing about but completely unlike any current design) but that isn't really important

after completing the work in that book and raising investment capital for your company, you can honestly call yourself a fullstack engineer

— arm —

the best architecture to write assembly for is the arm—the original one, not thumb, which is a bit of a pain—and arm is also only slightly more complex to build than the fake-ass architecture in nand2tetris, and quite a bit faster. if you already know any assembly language, including the nand2tetris one, the best introduction to arm might not actually be any current tutorial but rather the vlsi arm3 datasheet from 01990 https://www.chiark.greenend.org.uk/~theom/riscos/docs/ARM3-datasheet_ARM-Family-Data-Manual-VLSI.pdf which has a summary of the instruction set on p.1-7 (9/56) and a fully complete description on pp.3-12 to 3-43 (19/56 to 34/56)

as you probably know,…

Still not as good as "Einstein's Theory of Relativity in Words of Four Letters or Less". Excerpt follows:

A few more of us got it, then. But most of us just said, "What are you two on? Put down the bong and get real! This is way too wild to be true." But they just said, "Just try and see if it isn't true."

So we came up with ways to test old Al's idea, and each time Al hit the gold. His idea had the sun's rays a tiny bit more red than what Izzy said. They were. His idea put Mars a tiny bit off from how Izzy had Mars. It was.

The big one, the one that got told over and over, was the one with the dark-at-day time. You know, when the moon gets in the way of the sun. At that time you can get a real good look at a star when it's up next to the sun. (Next to it in the sky, that is. Not next to it for real. You know what I mean.) They went off and got a good look at a star that was very near the sun, and then they used a book to see just what spot that star was in. You see, the rays from the star pass so near the sun that they get bent, on the way to us. Old Al, his idea said just how much the rays get bent. With Izzy, the rays get bent, too, but only by half as much. So they took a look at the star, and they took at look at the big book, and ... well, I'll bet you can tell me as well as I can tell you just how far off that star was.

A-yup.

And then all of us, we all just sat back and said: "Whoa."

http://www.muppetlabs.com/~breadbox/txt/al.html

You'll learn a lot of this via debugging or reverse engineering. Do you REALLY know how your compiler, linker, and loader work? If you do, you'll understand everything they wrote about static variables, stack frames, etc.

The best exercise to start with is this one on creating the smallest ELF executable possible:

http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

And after that I'd do the same thing on Windows with a PE file.

Then try to break things. Try to write a C program that has a buffer overflow bug in it and exploit that to change the flow of program execution. Then exploit the same bug to open an xterm or calc.exe.

Getting really familiar with a good debugger will help you a lot with these things.

After you have a decent understanding of program loading and execution, you can dive into the more language lawyery things they're talking about so you can answer the questions about the nineteen different meanings of "static" like the hacker girl. With C, that's a worthwhile goal. With C++, good fucking luck.

A noob question here.

As it turns out, the first 8 pages on our hydra machines are void. This means that trying to read to or write from any address from 0 to 0xffff will result in a segmentation violation.

I have similar issue. I was following "A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux"[0]. And decided to put the start of .text section at virtual address 0x0:

; tiny.asm
BITS 32

org 0x0

;
; (the same as the one in the teensy elf tutorial)
;

It results in segmentation fault when ran as normal user. But fine when ran as super user. Changing the code to use address 0x10000 fix the problem.

My question: Is my issue because I create an elf that has .text section inside that void region? Is this void region documented somewhere? What purpose does it serve?

[0]: https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

The ELF loading logic in the Linux kernel is intentionally very simple, so it's more like a bare-bones subset of what the dynamic linker handles. matheusmoreira summarizes it well in a previous discussion [0]:

> Yeah it turns out the kernel doesn't care about sections at all. It only ever cares about the PT_LOAD segments in the program header table, which is essentially a table of arguments for the mmap system call. Sections are just dynamic linker metadata and are never covered by PT_LOAD segments.

The simplicity of the ELF loader in Linux can be exploited to make extremely small executables [1], since most of the data in the ELF header is stuff that the kernel doesn't care about.

[0] https://news.ycombinator.com/item?id=45706380#45709203

[1] https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

One of my favourite explorations of the ELF format is linked in the comments. Just how small can you make an ELF executable? [0]. Spoiler: 45 bytes, when you go far enough that standard assemblers start getting in the way. When the ELF header becomes part of the program itself.

> Of course, half of the values in this file violate some part of the ELF standard, and it's a wonder that Linux will even consent to sneeze on it, much less give it a process ID. This is not the sort of program to which one would normally be willing to confess authorship.

> On the other hand, every single byte in this executable file can be accounted for and justified. How many executables have you created lately that you can say that about?

[0] http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html