I’m no crypto expert, but after comparing this RC4-like function with other RC4-based algorithms, it looks like this could be a CipherSaber implementation. Below is a pretty-printed part of the function (comment were added by me):
As already mentioned, the CipherSaber algorithm is based on the stream cipher algorithm RC4. RC4 encrypts its content by xor’ing using a keystream which is derived by a secret key. In CipherSaber, this key is created by appending an initialization vector (IV) to the actual key (as show in the image above).
Now, when the first stage of this script is executed, a 53 bytes secret key is randomly generated and stored in an internal variable called ‘oil’.
Next, the secret key is encrypted using RSA and a public key that is hard coded in the script. The output is converted to a hex-string and used as a parameter for the URL leading to the next stage. The next stages are loaded by calling the appendChild()-function for the document object, and thus preserving the current state of RC4.
On the server side, the hex-string will be decrypted and therefor have access to the randomly generated secret key of CipherSaber. The server then returns a CipherSaber-encrypted script, using the hex-string itself as the IV.
The results of the version check is reported back to the server by RSA-encrypting it, and using the resulting hex-string as a part of the next-stage URL. Again, the next stage is loaded by calling the appendChild()-function.
Not surprisingly, the server returns an encrypted chunk of code that needs to be decrypted using CipherSaber. This code contains suitable exploit code based on the version information gathered from the previous stage. Finally, if the exploit is successful, an URL parameter is generated by RSA-encrypting a few exploit-parameters, which leads to the malware payload itself.
For a graphical overview of the stages involved, click on the image below:
However, these scripts has to be readable to browsers – which means anyone can read them, one way or another :)