Breadbox

My favorite language for implementing short Hello World programs in is HQ9+ [1]. Joking aside, this page [2] used to be a great tutorial on writing small ELF binaries, but I'm not sure whether it will still work in 64-bit land. It proved very helpful for writing a 4K intro back in 1999. [1] https://esolangs.org/wiki/HQ9%2B [2] https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

I would also recommend the legendary Teensy Files: https://www.muppetlabs.com/~breadbox/software/tiny/ They sparked my interest in ELF and freestanding programs.

Also see this blog post, which compares "Hello World" programs in different languages by overhead: https://drewdevault.com/2020/01/04/Slow.html Follow-up: https://drewdevault.com/2020/01/08/Re-Slow.html This legendary blogpost makes the smallest Linux program (the program simply exits with status 42): https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html You can also find the smallest "Hello World" program on that website.

If you are curious about how small a ELF binary file can be, you might like the following amusing article: https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

Love the muppetlabs posts. See also this series on ELF binaries, and a really small (the smallest?) ELF executable. http://www.muppetlabs.com/~breadbox/software/tiny/

But wait there's more: http://www.muppetlabs.com/~breadbox/txt/mopb-app.html Lovely examples, great writeup. Using kernel modules "cuz i want to do something stupid now" is a treat. this is a great tutorial for it.

It's definitely the case that some of the ELF header fields can be repurposed to store additional data, the following articles all address that optimization: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html https://www.pimzero.com/2020/04/19/golf_so.html https://rpis.ec/blog/plaidctf-golfso/ There are also a few instructions in the article that are size-suboptimal (e.g. "movl $4, %eax" is 5 bytes (b804000000), while the equivalent "xor %eax, %eax; movb $4, %al" is only 4 bytes (31c0b004)).

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

And if you liked that http://www.hugi.scene.org/compo/compoold.htm And something I found useful https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html It really is quite amazing how small you can make things when you try. Then you realise you're wasting most of a disc sector, and the thing you have is unportable and unmaintainable. But still, being able to look at a binary and know what every byte does, being unconstrained by the rules of a language is liberating.

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

This is code golf. I mention that because apparently some people are missing the point, which is purely to get the smallest size. This isn't directly applicable to most work you might do, but like many exercises that explore the extremes, useful knowledge can be learned from the attempt. In a similar vein, there's a classic article on creating a tiny ELF executable.[1] 1: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

My favourite page on ELF executables of all time: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html, "A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (or, 'Size Is Everything')"

What might you recommend to someone who wants to to learn more about these subjects? For example, http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html is extremely interesting, but a lot of it is over my head. I guess at the end of the day there's no real alternative to "just dive into the source code for a while" with these sorts of things - hence the importance of having "decades of experience" under your belt - but I'm curious if there's anywhere in particular that you might recommend as a startpoint.

It's interesting to compare with DOS, where a do-nothing program is a single byte: C3 A Hello World is roughly 20 bytes, the bulk of it being the string itself: 95 BA 07 01 CD 21 C3 48 65 6C 6C 6F 20 77 6F 72 6C 64 21 24 The ELF in the article, which is 130 by my count, could be reduced to 45 with some tricks: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html Also worth looking at is what the demoscene has done with binaries of 128 bytes or less: http://www.pouet.net/prodlist.php?type%5B%5D=32b&type%5B%5D=64b&am…

> and if we wanted to have some fun, we could lower that number by quite a bit still One of my earliest introductions to the ELF format was "A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux" (http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html), which I still highly recommend.

A nice treatise on a well-charted ocean. Another great article along these lines for those interested in assembly and execution environments and so on .. is of course the famous muppetlabs exploration to build the smallest linux executable: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

Very similar to several posts that have come up before: https://news.ycombinator.com/item?id=5508981 and https://news.ycombinator.com/item?id=3158862 as well as things mentioned therein: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html which is a 45 byte executable (it doesn't say Hello World), and http://asm.sourceforge.net/intro/hello.html. All the same, very cool, this is a great experiment for anyone to work on :)

Another great read, if you haven't already, is Brian Raiter's "Albert Einstein's Theory of Relativity: In Words of Four Letters or Less" is also a great read. http://www.muppetlabs.com/~breadbox/txt/al.html

The classic resource for this (does the same sort of tricks, taken to an extreme: code overlaid with tables, tables overlaid with other tables, etc.): http://www.muppetlabs.com/~breadbox/software/tiny/ (62-byte hello world among other things)

Thats brilliant. It reminds me of the size matters article I read a couple of years ago, the most difficult title to google too http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

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_A… 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.

I didn't know there was a sequel! Looks like there's also a part 3 that covers teensy dynamic linking: https://www.muppetlabs.com/~breadbox/software/tiny/somewhat.html

Reminds me of this blog post where someone was trying to reverse-engineer a hand-rolled encryption protocol in a crossword app by colorizing the output and looking for patterns. https://www.muppetlabs.com/~breadbox/txt/acre.html

The famous "A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux" tutorial has some good answers for you. https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html In short: Compilers don't help l, but with a good macro assembler it is quite convenient. Maybe the author used custom tooling but the assembler route is the easiest if you only need this once or a couple of times. To the second question, reverse engineering software like IDA Pro or Binary Ninja are not only made for strange and broken binaries but often used for binaries with deliberate anti-reversing measures. They are as good as it gets when it comes to not choking on unusual binaries. EDIT: Forgot to mention Ghidra.

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

The appendix to this is also good, and goes over things like getting linker scripts to create binaries using objdump and writing C wrappers for syscalls: https://www.muppetlabs.com/~breadbox/txt/mopb-app.html

If you found this article interesting, you might also enjoy "My Own Private Binary: An Idiosyncratic Introduction to Linux Kernel Modules"[0] and the previous discussion[1] of it on HN. [0]: https://www.muppetlabs.com/~breadbox/txt/mopb.html [1]: https://news.ycombinator.com/item?id=29291804

Linking a similar, very popular past example of this: Teensy: https://www.muppetlabs.com/~breadbox/software/tiny/teensy.html