alt.hn

4/6/2026 at 8:14:16 PM

Show HN: A (marginally) useful x86-64 ELF executable in 301 bytes

by meribold

4/9/2026 at 10:40:58 AM

Dell 5440

    $ git clone https://github.com/meribold/btry
    ...
    $ make
    as -mx86-used-note=no btry.s -o btry.o
    objcopy -O binary btry.o btry
    chmod +x btry

    $ ./btry 
    Segmentation fault         ./btry

    $ strace -f ./btry 
    execve("./btry", ["./btry"], 0x7ffc1a562078 /* 57 vars */) = -1 ENOMEM (Cannot allocate memory)

    $ file btry
    btry: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, corrupted section header size

by anonymous67453

4/9/2026 at 10:47:57 AM

Looks like I may have stretched what values are acceptable for p_filesz/p_memsz too far. What's your kernel version? (I tested it on 6.8.0 and 4.4.0.) Perhaps the 316-byte version at commit 451827cfd5399074 (before that particular hack was introduced) would work.

by meribold

4/9/2026 at 4:23:25 AM

Love it! It's entirely inapplicable and useless to me but it embodies the spirit of Show HN and what the spirit of programming in the 80s and 90s was.

by vparseval

4/9/2026 at 4:12:36 AM

I have a use for this: A somewhat portable one-liner to go in my waybar/sway/i3 configs!

by captn3m0

4/6/2026 at 9:16:02 PM

301 bytes! The base64 one-liner install is a nice flex. Accepting an infinite loop when energy_full doesn't exist is peak code golf, perfectly reasonable when every byte counts. Is there a writeup on the assembly somewhere?

by emanuele-em

4/9/2026 at 10:09:40 AM

I would prefer avoiding the infinite loop and printing a message to help the user understand what went wrong. I'm sure you could do that with an extra 100 bytes or so. Just my opinion of course.

by billforsternz

4/9/2026 at 4:52:02 AM

The xz step doesn't seem to be doing very much, though. It seems the decoded data is currently 278 bytes versus a 298-byte decompressed result.

by zahlman

4/9/2026 at 6:04:00 AM

Haha this is great!

What about adding a Make rule to auto-generate the one-liner install from the binary?

by sjdv1982

4/9/2026 at 6:43:51 AM

It doesn't even look like particularly optimised Asm (could immediately spot a few savings, despite how horrible GAS syntax is to read...), but is definitely not "compiler slop"[1] either, which shows just how inefficient the majority of programs actually are. Of course even the ELF header takes up a significant amount of space, but this reminds me of how PC magazines would print short listings of utilities like this, often a few dozen up to a few hundred bytes at most --- in DOS .COM format, which is headerless and thus pure machine instructions.

[1] In the late 80s and early 90s, the battle between those writing handwritten Asm and those using compiled HLLs has many similarities to AI-generated vs non-AI code today.

by userbinator

4/9/2026 at 8:02:17 AM

If the savings are about `mov $1, %edi` and `mov $10, %ecx`, those 32-bit immediate values line up with the higher bytes of p_filesz and p_memsz in the program header, which have to be zero [1]. If not, what are the savings? :)

[1]: https://github.com/meribold/btry/commit/8ef5a4ce58ae73c489d2...

by meribold

4/9/2026 at 9:55:25 AM

As always with these admirable hacks, I feel compelled to point out these are not really ELF executables but just small files you can trick the x86_64 Linux kernel into loading.

I mean they're very clever and legit and kudos to the people who develop these exploits, but they're not ELF.

by bregma

4/9/2026 at 10:30:55 AM

Is it really not ELF? The file starts with the \x7FELF magic, but I'm not by my laptop to see what `file btry` outputs.

by noam_k

4/9/2026 at 10:39:48 AM

GP is likely referring to how fields in the ELF and program header are abused for instructions and data in a way that happens to not break things on Linux.

by meribold

4/9/2026 at 5:47:56 AM

Love this kind of tiny, over‑engineered hack—totally impractical, but pure Show HN energy.

by Eric_Xua

4/9/2026 at 4:46:42 AM

[dead]

by darioterror