7 ms·

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

65 points by meribold 6mo ago

emanuele-em 6mo ago
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?
- zahlman 5mo ago
  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.
- sjdv1982 5mo ago
  Haha this is great! What about adding a Make rule to auto-generate the one-liner install from the binary?
- billforsternz 5mo ago
  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.
captn3m0 5mo ago
I have a use for this: A somewhat portable one-liner to go in my waybar/sway/i3 configs!
vparseval 5mo ago
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.
darioterror 5mo ago
[dead]
Eric_Xua 5mo ago
Love this kind of tiny, over‑engineered hack—totally impractical, but pure Show HN energy.
userbinator 5mo ago
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.
- meribold 5mo ago
  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/8ef5a4ce58ae73c489d2475874b45672ca66f93a https://github.com/meribold/btry/commit/8ef5a4ce58ae73c489d2...
bregma 5mo ago
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.
- noam_k 5mo ago
  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.
  - meribold 5mo ago
    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.
- benj111 5mo ago
  I'd agree it's not standards compliant. But if it's accepted as an ELF by Linux, in what way is it not an ELF? Or to flip it round. If Linux accepts something as an ELF that isn't, then it isn't an ELF loader. Would you describe a web browser that doesn't score 100% on a rendering test as not a browser?
  - auguzanellato 5mo ago
    The analogy would be more like a browser that somehow manages to render utterly broken HTML (yes, they actually do)
anonymous67453 5mo ago
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
- meribold 5mo ago
  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.
- meribold 5mo ago
  I fixed the most likely culprit now (excessively large p_memsz value). It cost a few bytes; the new executable size is 307 bytes.
qcoudeyr 5mo ago
This commit (https://github.com/meribold/btry/commit/75cba2be52cc8fbdc72b7661cac70fe84033aff3 https://github.com/meribold/btry/commit/75cba2be52cc8fbdc72b...) worked for me !
- meribold 5mo ago
  The new latest version (commit 806789e4d454b, 307 bytes) should also work. It no longer sets p_memsz to something unreasonably large, which was most likely the issue with the 301-byte and 298-byte versions from a few days ago.
bArray 5mo ago
I had a similar problem for a Thinkpad, except there is more than one cell at different capacities that are switched between. The existing battery manager would not tell me which battery was actually being used, and whether there was still a secondary battery waiting to be discharged. I wrote a very quick hacky program for X11 that stays always visible that will display the information for any number of batteries: https://gitlab.com/danbarry16/bat_mon https://gitlab.com/danbarry16/bat_mon It ends up being 50kB with minimal optimization and sports a lightweight X11 library (GUI) and JSON parser (configuration).
mehdistronghold 5mo ago
Really cool ! I like to see these kind of post here

65 points by meribold 6mo ago

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?

zahlman 5mo ago
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.
sjdv1982 5mo ago
Haha this is great! What about adding a Make rule to auto-generate the one-liner install from the binary?
billforsternz 5mo ago
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.

captn3m0 5mo ago

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

vparseval 5mo ago

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.

darioterror 5mo ago

[dead]

Eric_Xua 5mo ago

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

userbinator 5mo ago

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.

meribold 5mo ago
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/8ef5a4ce58ae73c489d2475874b45672ca66f93a https://github.com/meribold/btry/commit/8ef5a4ce58ae73c489d2...

bregma 5mo ago

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.

noam_k 5mo ago
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.
- meribold 5mo ago
  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.
benj111 5mo ago
I'd agree it's not standards compliant. But if it's accepted as an ELF by Linux, in what way is it not an ELF? Or to flip it round. If Linux accepts something as an ELF that isn't, then it isn't an ELF loader. Would you describe a web browser that doesn't score 100% on a rendering test as not a browser?
- auguzanellato 5mo ago
  The analogy would be more like a browser that somehow manages to render utterly broken HTML (yes, they actually do)

anonymous67453 5mo ago

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

meribold 5mo ago
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.
meribold 5mo ago
I fixed the most likely culprit now (excessively large p_memsz value). It cost a few bytes; the new executable size is 307 bytes.

qcoudeyr 5mo ago

This commit (https://github.com/meribold/btry/commit/75cba2be52cc8fbdc72b7661cac70fe84033aff3 https://github.com/meribold/btry/commit/75cba2be52cc8fbdc72b...) worked for me !

meribold 5mo ago
The new latest version (commit 806789e4d454b, 307 bytes) should also work. It no longer sets p_memsz to something unreasonably large, which was most likely the issue with the 301-byte and 298-byte versions from a few days ago.

bArray 5mo ago

I had a similar problem for a Thinkpad, except there is more than one cell at different capacities that are switched between. The existing battery manager would not tell me which battery was actually being used, and whether there was still a secondary battery waiting to be discharged. I wrote a very quick hacky program for X11 that stays always visible that will display the information for any number of batteries: https://gitlab.com/danbarry16/bat_mon https://gitlab.com/danbarry16/bat_mon It ends up being 50kB with minimal optimization and sports a lightweight X11 library (GUI) and JSON parser (configuration).

mehdistronghold 5mo ago

Really cool ! I like to see these kind of post here