L33t programming language
|
|
l33t is an esoteric programming language created by Stephen McGreal and Alex Mole. It is based loosely on Brainfuck and influenced by Beatnik. It's a tongue-in-cheek attempt to create a language which can be programmed using Leet Speak, for the script kiddies, trolls and crackers who find themselves amused by it. The language was deliberately designed to have the ability to self-modify and to have socket connectivity. This is so that the language can theoretically be used to write viruses or to crack into other people's machines, although the obfuscated nature of the language means that only a complete lunatic would attempt such a task. At the time of writing, neither the self-modification features or the connectivity have been used in a full l33t program.
| Contents |
Overview
Source is entered in l33t sP34k, and each word is evaluated as follows: Word are considered to be separated by spaces or carriage returns. The value of a word is obtained by adding the numerical digits within it together, e.g. l33t = 3 + 3 = 6. All other characters are valid but ignored. Words with no numeric characters (or in which the only numeric characters are “0”s) are evaluated to 0. It is possible to program in l33t just using numbers, i.e. not forming letters in l33t 5p34k. However, programmers who do this are considered “teh sUxX0r”, and the interpreter is well within its rights to format your hard drive for attempting this. Needless to say, l33t is case-insensitive, but extra kudos is awarded for random capitalisation ;o)
The language utilises a 64K block of memory, and 2 pointers - a memory pointer and an instruction pointer. The l33t interpreter tokenises all the words in the source to create a sequence of numerical opCodes (described below), and places them in order into the memory block, starting at byte 0. The instruction pointer starts at byte 0, and executes the command there to begin the program. Each opCode (except END) will move the instruction pointer, as described below. The memory pointer starts at the first byte after the instructions. Memory "wraps". Incrementing the memory pointer past 64K will cause it to run around to byte 0, and vice versa. The instruction pointer will behave in the same way.
It is legal to move the memory pointer into the area of memory occupied by the instructions, so code can be self modified at runtime. Similarly, the instruction pointer will keep incrementing or jumping until it encounters an END (see below), so code can be generated at runtime and subsequently executed. A program doesn't necessarily have to have an END command at the end of it. It can generate this at runtime, or run forever.
Opcodes
| Value | Opcode | Description |
|---|---|---|
| 0 | NOP | No Operation, except to increment the instruction pointer. |
| 1 | WRT | Writes the ASCII values of the byte under the memory pointer to the current connection (see CON). Increments the instruction pointer. |
| 2 | RD | Reads a character from the current connection (see CON) and writes it to the byte currently under the memory pointer. Increments the instruction pointer. |
| 3 | IF | Moves the instruction pointer forward to the command following the matching EIF, if the byte under the memory pointer is equal to zero. If the byte under the memory pointer does not equal zero, IF simply increments the instruction pointer. |
| 4 | EIF | Moves the instruction pointer backwards to the command following the matching IF, if the byte under the memory pointer is not equal to zero. If the byte under the memory pointer does equal zero, EIF simply increments the instruction pointer. |
| 5 | FWD | Move memory pointer forward by (next word+1) bytes. Adds 2 to the instruction pointer. |
| 6 | BAK | Move memory pointer backward by (next word+1) bytes. Adds 2 to the instruction pointer. |
| 7 | INC | Increment value of the byte under memory pointer by (next word+1). Adds 2 to the instruction pointer. |
| 8 | DEC | Decrement value of the byte under memory pointer by (next word+1). Adds 2 to the instruction pointer. |
| 9 | CON | Reads the 6 bytes starting with the memory pointer (the first 4 bytes specifying an IP in the format 127.0.0.1, and the last 2 bytes combining to make a 16-bit port number), and opens a connection if possible. If a connection can't be opened, l33t will return the error message:
"h0s7 5uXz0r5! c4N'7 c0Nn3<7 l0l0l0l0l l4m3R !!!". If all 6 bytes read 0, l33t uses the local machine's stdin and stdout (this is the default setting upon starting a l33t program). Increments the instruction pointer. Regardless of whether the connection was successful or not, the memory pointer will be left in the same place as it was. Only FWD and BAK move the memory pointer. The port number can be calculated by something along the lines of: portNumber = (byte5 << 8) + byte6 |
| 10 | END | Closes all open connections and ends the program. The value 10 won't end the program if it is used as data for OpCodes FWD, BAK, INC or DEC. |
Note that the words for the opCodes (NOP, WRT, etc) are just handy conventions for referring to the opCodes, and for explaining segments of l33t code as pseudo-code, nothing more. Writing INC in your source will do nothing (it will evaluate to 0, NOP); writing “pH34r” will do something (it will evaluate to 7, INC).
Quirks
A few points to be aware of:
- Any OpCodes evaluating to > 10 will produce an error message but carry on. Although this is legal syntax, it will print the standard l33t error code "j00 4r3 teh 5ux0r", and make your program somewhat embarrassing to run in public... No error will be produced if values > 10 are used as data for OpCodes FWD, BAK, INC & DEC.
- l33t will interpret ANY usages of 3 and 4 as brackets, even if they were intended as data! So although “pH34r m3!” will increment the current byte by 3 as expected, a subsequent call to EIF (if the current byte under the memory pointer is nonzero) will jump back to that “m3!”. If the memory pointer fails to find a matching "bracket" in the direction it is looking, the results are undefined: chances are the program will crash, and insult your stupidity.
- Memory byte values are unsigned, so they wrap: 255 + 1 = 0, and 0 - 1 = 255. Interpreters are advised, but not required to be able to handle the case where words in the l33t source evaluate to >255 and wrap accordingly. As this situation is very unlikely, results are undefined.
- The 64K memory limit is arbitrary, but a handy size for portability and minimalism. l33t interpreters may utilise different memory sizes, but 64K is considered to be the standard. In all cases, the memory and instruction pointers should be data types large enough to cope with accessing all locations within the memory block (i.e. a 16-bit unsigned integer in the case of a 64K memory block).
Examples
ASCII Dump
The following is the first ever functioning program written in l33t. It loops forever, printing all 255 ASCII characters, and takes the form of a short insulting rant about geeks:
ph34r my l3Et 5kIlLZ!!!!!! nErDs 41n't cool 3v3ry1!!! y0u b1g g33kS r teh g33kY sux0rs! PHE4R! LOLOLOLOLOLOL!!!
Hello, World!
The next, more complex program prints “H3LL0 W0RLD!!!” to the screen. For those who can’t read l33t sp34k, it takes the form of an essay on how to be l33t, drawing the conclusions that an appreciation of warez (pirated software), Quake clans, Star Wars, software cracking, writing computer viruses and trolling on message boards are all important components. Note the disclaimer.
// "Hello World" by Stephen McGreal. // Note that the views expressed in this source code do not necessarily // coincide with those of the author :o) Gr34t l33tN3$$? M3h... iT 41n't s0 7rIckY. l33t sP33k is U8er keWl 4nD eA5y wehn u 7hink 1t tHr0uGh. 1f u w4nn4be UB3R-l33t u d3f1n1t3lY w4nt in 0n a b4d4sS h4xX0r1ng s1tE!!! ;p w4r3Z c0ll3cT10n2 r 7eh l3Et3r! Qu4k3 cL4nS r 7eh bE5t tH1ng 1n teh 3nTIr3 w0rlD!!! g4m3s wh3r3 u g3t to 5h00t ppl r 70tAl1_y w1cK1d!! I'M teh fr4GM4stEr aN I'lL t0t41_1Ly wIpE teh phr34k1ng fL00r ***j3d1 5tYlE*** wItH y0uR h1dE!!!! L0L0L0L! t3lEphR4gG1nG l4m3rs wit mY m8tes r34lLy k1kK$ A$$ l33t hAxX0r$ CrE4t3 u8er- k3wL 5tUff lIkE n34t pR0gR4mm1nG lAnguidGe$... s0m3tIm3$ teh l4nGu4gES l00k jUst l1k3 rE41_ 0neS 7o mAkE ppl Th1nk th3y'r3 ju$t n0rMal lEE7 5pEEk but th3y're 5ecRetLy c0dE!!!! n080DY unDer5tAnD$ l33t SpEaK 4p4rT fr0m j3d1!!!!! 50mE kId 0n A me$$4gEb04rD m1ghT 8E a r0xX0r1nG hAxX0r wH0 w4nT2 t0 bR34k 5tuFf, 0r mAyb3 ju5t sh0w 7eh wAy5 l33t ppl cAn 8E m0re lIkE y0d4!!! hE i5 teh u8ER!!!! 1t m1ght 8E 5omE v1rus 0r a Pl4ySt4tI0n ch34t c0dE. 1t 3v3n MiTe jUs7 s4y "H3LL0 W0RLD!!!" u ju5t cAn'T gu3s5. tH3r3's n3v3r anY p0iNt l00KiNg sC3pT1c4l c0s th4t, be1_1Ev3 iT 0r n0t, 1s whAt th1s 1s!!!!! 5uxX0r5!!!L0L0L0L0L!!!!!!!
See also
External links
- Stephen McGreal's l33t homepage (http://electrodruid.zapto.org/l33t.htm) A l33t interpreter written in Python by Alex Mole
- Ruby l33t (http://propellors.net/l33t.php) A complete l33t interpreter written in Ruby
- C l33t (http://linuxfire.dhis.org/~alecs/code/l33t.c) A complete l33t interpreter written in C by Alecs Kingde:l33t
eo:l33t fr:l33t hu:l33t ja:l33t ko:l33t pl:l33t sv:l33t zh:l33t