Lately, I've been
wasting spending time doing code golf at the (very informal) Anarchy Golf server.
I don't claim to be any sort of expert on the topic, but here are some recent entries I've made, explained.
For those not
in the know, the goal in code golf is to write the shortest possible program in language X that accomplishes a task Y.
The golf server has a set of test inputs, and your program needs to produce output matching the corresponding reference outputs in order to be accepted.
This is a gamified extension of the x86 opcode mnemonic generator. Playing should, hopefully, be self-explanatory.
Have you ever wondered how Intel comes up with such high-quality mnemonics as
VPCLMULHQLQDQ, and many more besides?
Well, wonder no more!
Here is an entirely automatic generator for you to make as many new opcodes as you please.
Quite some time ago (late 2011) I got sufficiently bored to poke and prod the firmware of a ZTE ZXDSL 931WIIA brand VDSL2 device, primarily to find out if it had a usable telnet interface and/or a convenient way to run arbitrary code. I always meant to write up a description of what was hiding under this particular rock, but never got around to. Well, here we (belatedly) are.
Most things in the following are likely to be — more or less — particular to the exact model and firmware version (
ZXDSL931WIIA_ElisaV2.8.2a_Z40_FI) I have.
The model is probably discontinued by now, but perhaps the illustrated principles may be helpful for someone.
If you still have one, don't try any of this at home if you're very attached to the device.
Finally, the approach taken is a very "manual" one (GNU binutils, dd, etc.), and more intelligent tools could well make it simpler.
tl;dr? There is a telnet interface (in this version), with hardcoded ZTE "debugging" username:password pairs, allowing for full root shell access.
You know how, when you link an ELF executable dynamically, all the names of the dynamically linked symbols end up being included in the executable? That's, like, several bytes — maybe even dozens — of bloat. (And there's no Windows DLL style import-by-ordinal functionality.) Turns out, however, that it's possible to refer to the symbols by their hash values instead. That's a fixed cost of four bytes per symbol, compared to 8 (symbol table entry) + strlen(name) + 1 for regular dynamic linking. (Of course there's also some amount of bytes wasted in the stub that does the hash resolving.)