2.png)
Haxxoring the elf format for 1k/4k stuff
category: code [glöplog]
...and let's remember that most compos(that I've seen at least) only give write permission to /tmp and as such it's the usual location to unpack the binary.
/dev/shm is also an option, as it's not written to disk
I don't know what's the local policy over thread necromancy, but...
A few days ago, I put up a tool to create small ELF32 binaries for FreeBSD and Linux.
This is a project that grew from the portability work on Lavos, but after the release I noticed there was room for improvement. As of today, there is also a documentation available.
I'd prefer if at least the parties that have shaped the result would take a look at the documentation. If for nothing else, then just to see there's nothing obvious wrong in attribution. Currently, this refers to Marq, Parcelshit, las, and the members of Hymy and YOLP.
The techniques presented could theoretically be extendable to any platform using 32-bit ELF. In particular, I believe Raspberry PI or Fuloong 2F 4ks using armel or mipsel should be (easily) possible. Big-endian platforms such as armeb, mipseb or ppc32 shouldn't be that hard either.
Anyway, bug reports and complaints are welcome. I've only really tested this in FreeBSD. The Linux tests have been done in a Linux jail, that is probably not quite good enough.
A few days ago, I put up a tool to create small ELF32 binaries for FreeBSD and Linux.
This is a project that grew from the portability work on Lavos, but after the release I noticed there was room for improvement. As of today, there is also a documentation available.
I'd prefer if at least the parties that have shaped the result would take a look at the documentation. If for nothing else, then just to see there's nothing obvious wrong in attribution. Currently, this refers to Marq, Parcelshit, las, and the members of Hymy and YOLP.
The techniques presented could theoretically be extendable to any platform using 32-bit ELF. In particular, I believe Raspberry PI or Fuloong 2F 4ks using armel or mipsel should be (easily) possible. Big-endian platforms such as armeb, mipseb or ppc32 shouldn't be that hard either.
Anyway, bug reports and complaints are welcome. I've only really tested this in FreeBSD. The Linux tests have been done in a Linux jail, that is probably not quite good enough.
Nice to see new progress with elf/4k hacking!
Nice. What sort of amounts of stuff have you been able to use this way? How much code for music player, how much shader code etc. I could be potentially interested in doing something for the Raspberry Pi, because it connects straight to a CRT monitor. I've done some initial shader tests, and they look just fabulous on the CRT.
yzi
I don't really have any numbers like this because the work here is just extended from earlier mechanisms we used for Lavos and Yog-Sothoth. Those intros have no clear fixed sizes for any parts, we just clumped everything together and then started removing bytes from wherever we could.
Usually Juippi takes about one kilobyte for the music. Shaders are one kilobyte, one kilobyte for control, and one for the systems programming. Updating the docmentation with the new final sizes, using manually crafted ELF headers frees about 300 compressed bytes. I'm looking forward to taking advantage of those.
(The sizes in Lavos are an exception, as it was collateralburger's first foray into introcoding. In that intro it's about 1k systems programming, 3k shaders, 3k control code, 1k font, 8k synth.)
Quote:
How much code for music player, how much shader code etc.
I don't really have any numbers like this because the work here is just extended from earlier mechanisms we used for Lavos and Yog-Sothoth. Those intros have no clear fixed sizes for any parts, we just clumped everything together and then started removing bytes from wherever we could.
Usually Juippi takes about one kilobyte for the music. Shaders are one kilobyte, one kilobyte for control, and one for the systems programming. Updating the docmentation with the new final sizes, using manually crafted ELF headers frees about 300 compressed bytes. I'm looking forward to taking advantage of those.
(The sizes in Lavos are an exception, as it was collateralburger's first foray into introcoding. In that intro it's about 1k systems programming, 3k shaders, 3k control code, 1k font, 8k synth.)
Added a prod of the former.
New in r83:
- Manually change origin/entry point for better compressable constant.
- Omit symbols '__progname' and 'environ' on Linux, they seem to not be needed.
New in r83:
- Manually change origin/entry point for better compressable constant.
- Omit symbols '__progname' and 'environ' on Linux, they seem to not be needed.