But like seriously. Best I'm seeing is copying files to disk, and executing them. Big downside of this is that it leaves a bunch of artifacts, and takes time. Ideally we could just JMP into where the next file starts or smth, hah.
-
-
Show this thread
-
Okay, bit anticlimactic but the most reasonable approach seems to be to store the embedded binary as base64 string inside the wrapper program. Then extract to /tmp to set permissions and run it. Simple, and should work!
Show this thread -
This then becomes an exercise in combining files right — because you probably want a tool that can generate these combined files for you. But that seems like a solvable problem! :D
Show this thread -
I'll most likely be able to knock out a demo in less than a day. Might do a fun side track on stream about this, if I can get the prerequisites working first. (E.g. working libcgroup locally; unshare and chroot are ok too
).Show this thread
End of conversation
New conversation -
-
-
One bin to find them
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
The Linux kernel has included support for squashfs for years, so maybe the entry point binary can be “mount the fs in the data section to /tmp/app/<uuid> and execute ./bin/main of it”? (Implementation left as an exercise for the reader)
-
aye, yeah squashfs might just be the best option. Much easier to debug than some random tmp file, probably. This is cool!
End of conversation
New conversation -
-
-
Trailing data as has been done by self extracting zip files is the norm.
-
!!! Do you have any more info on this? Self-extracting zip means it's a write to disk, right?
- 1 more reply
New conversation -
-
-
BINARIES FOR THE BINARY CAT
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.