As I plow the digital seas, I often come across a piece of programming flotsam worthy of investigation. Most of it is obfuscated C, which is delightful. The obfuscated code that outputs something wonderful is most entertaining. But every so often I stumble upon something perplexing like the following code:
\n<\/p>\n
\r\n#include <stdio.h>\r\n\r\nint typedef[[]]$;\r\n\r\nint main($[[]]$)\r\n{\r\n [[]]$:&&$&&$&&puts(\"hello world\");\r\n\r\n return 0;\r\n}<\/pre>\nSeriously?<\/p>\n
For starters, at Line 3, should typedef<\/em> be the first item? What is int typedef<\/em>? And then what is the typedef<\/em> defining?<\/p>\nThe code can build, but not under any circumstances, which I’ll get into shortly. Here is the output:<\/p>\n
hello world<\/pre>\nSo, nothing fancy is going on other than code clutter that somehow doesn’t affect the puts()<\/em> function — though it looks like it does.<\/p>\nFirst, this code does not build under clang<\/em>:<\/p>\n0718.c:3:13: error: expected expression\r\nint typedef[[]]$;\r\n ^\r\n0718.c:5:12: error: expected expression\r\nint main($[[]]$)\r\n ^\r\n0718.c:5:15: error: expected ')'\r\nint main($[[]]$)\r\n ^\r\n0718.c:5:9: note: to match this '('\r\nint main($[[]]$)\r\n ^\r\n0718.c:5:11: warning: omitting the parameter name in a function definition is a C2x extension [-Wc2x-extensions]\r\nint main($[[]]$)\r\n ^\r\n0718.c:7:2: error: expected expression\r\n [[]]$:&&$&&$&&puts(\"hello world\");\r\n ^\r\n1 warning and 4 errors generated.<\/pre>\nThe weird code builds under gcc<\/em> with three warnings:<\/p>\n2026_07_18-Lesson.c:5:5: warning: \u2018main\u2019 takes only zero or two arguments [-Wmain]\r\n 5 | int main($[[]]$)\r\n | ^~~~\r\n2026_07_18-Lesson.c: In function \u2018main\u2019:\r\n2026_07_18-Lesson.c:7:15: warning: the address of \u2018$\u2019 will always evaluate as \u2018true\u2019 [-Waddress]\r\n 7 | [[]]$:&&$&&$&&puts(\"hello world\");\r\n | ^~\r\n2026_07_18-Lesson.c:7:21: warning: value computed is not used [-Wunused-value]\r\n 7 | [[]]$:&&$&&$&&puts(\"hello world\");\r\n |<\/pre>\nAll these warnings and errors make sense, until you accept the second item worth mentioning:<\/p>\n
This code adheres to the C23 standard. Using the -std=c23<\/code> switch works for both clang<\/em> and gcc<\/em>.<\/p>\nTo untie the knots, start with the typedef<\/em>:<\/p>\nint typedef[[]]$;<\/code><\/p>\nThe result of this statement is that the dollar sign is declared as an integer identifier: $<\/code> == int<\/em>. Remember that the $ character isn’t used as an operator in C. But what’s happening here involves two tricky things.<\/p>\nThe first is that [[]]<\/code> is used as attribute syntax in the C23 standard. In a way, it works like an empty set of parentheses, so it’s ignored in the code (under C23).<\/p>\nThe second thing happening is a quirk in the gcc<\/em> compiler that accepts this type of backwards typedef<\/em> definition. This exploit allows typedef<\/em> to replace int<\/em> as an identifier, though the result isn’t used elsewhere in the code. So, after all the dust settles, the $<\/code> identifier now means int<\/em><\/p>\nThe main()<\/em> function uses this as its argument: $[[]]$<\/code><\/p>\nIn this obfuscation, the [[]]<\/code> thing is ignored, so the declaration is $<\/code> of the type $<\/em>. As main()<\/em> has arguments by default, what’s captured here is the argc<\/em> value, or integer count of items present at the command line, which is always a positive, non-zero value. The value is used in Line 7, which is also hideous:<\/p>\n[[]]$:&&$&&$&&puts(\"hello world\");<\/code><\/p>\nThe [[]]<\/code> thing is ignored in C23 as an empty attribute.<\/p>\n$:<\/code> is a label named $<\/code>, which is the argument count from the main()<\/em> function. As the label isn’t referenced, I think it’s just here for decoration and obfuscation.<\/p>\nThe next few characters are parsed like this:<\/p>\n
&&$ && $ &&<\/code><\/p>\nThe &&$<\/code> is a gcc<\/em> extension to obtain the address of a label, $<\/code>.The result is an integer, not a pointer.<\/p>\nThe &&<\/code> is a logical AND. It’s compared with $<\/code>, which is the value of the main()<\/em> function’s argument.<\/p>\nThe final &&<\/code>; evaluates the return value of the puts()<\/em> function, which is non-negative. The entire expression evaluates as TRUE, though nothing acts upon this result.<\/p>\nWeird.<\/p>\n
Bottom line: This code is obnoxiously obfuscated. It takes advantage of C23 as well as peculiarities with the gcc<\/em> compiler. I avoid obfuscation in my code as much as possible, but I do take delight in unweaving puzzles such as this example.<\/p>\n","protected":false},"excerpt":{"rendered":"Time to unravel some C language obfuscation I found on the Interwebs. Continue reading