The code uses a curl to [removed]
html source code of the link shows another obfuscated javascript code: http://pastebin.com/1WLYMp0E
EDIT: I removed the curl link to as it might be some unpatched exploit
I find it fun to reverse-engineer these sorts of things when I have the time; it's almost like a multilayered adventure game.
And Googling the URL there gets us to something familiar, which someone else has written up before:
http://tweetypage.com/wordpress-hacked/
The "IE9 Bugfix" and "IE 4 compatible" comments made me chuckle a little.
However, it looks like the page is somehow referer or IP-sensitive, since Google's cache of it goes to something intended to show popups while curling from my machine gets a fake Adobe Flash page with a nice binary to download - only 13.5KB (I only wish the real plugin was so small!) but packed and obfuscated. Nevertheless it's a pretty dismal obfuscation as I can see some strings like "qemu" and "vbox" which suggest it has VM detection. Google doesn't know its SHA-1 so there's no other public analysis of this one yet.
I don't have time right now but looks like this rabbit hole gets deeper and deeper...
I took the first function and decoded the first bytes of hex, which gave the infamous eval(gzinflate(base64_decode( function. Then I used http://www.whitefirdesign.com/tools/deobfuscate-php-hack-cod... to decode rest and got a group of variables with hex data that were being grouped together like this eval($xwq2ay . $xq9mar . $xb4jym . $xm0hy3); (full version available here - http://pastebin.com/7V951cRK
Decoding this hex gave me another set of preg_replace functions, which were doing the same thing pretty much. And then again the same, except two preg_replace were being called. Eventually I got something like this http://pastebin.com/JP1eukca
The hex stored in $a and $b are just a clever way of masking gzinflate(base64_decode( so I took the rest of the data, put it into the decoder and finally got to some proper code - http://pastebin.com/A0G290cE