Live data from Hacker News

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

github.com

11–20 of 23 posts

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

#11
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.

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

#12

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?

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.

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

#13
post #11

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.

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.

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

#14
post #13
post #11

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.

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.

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.

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

#15
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

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

#16

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

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.

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

#17
post #11

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.

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?

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

#19
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

It ends up being 50kB with minimal optimization and sports a lightweight X11 library (GUI) and JSON parser (configuration).

Post reply on HN