Yes, but if they have their crypto stuff together, it might not gain you much.
Someone here mentioned the encrypted versions of the files are the original size + a little extra. To me that indicates that they use a public key (of which the private component does not reside on your computer, and never has, but which you can buy). The public key is used to encrypt a key for a symmetric algorithm (AES, DES, ...), which encrypts the data, and the RSA-encrypted version of that symmetric key is then prepended as a header of some sorts.
So using a debugger you'd be able to see the public key, which I suppose is infected-useraccount-specific. It's not useful for decryption, you'll need its private counterpart.
You'll also see the symmetric key, of which a new (random) one should be instantiated for each file that is being encrypted. Should, but might not... if they slipped up, the latter might be reused (for your user account). In which case you can win, if you can observe it encrypting a new file — you'd be able to decrypt the other files too.
They'd have to be quite stupid to slip up like this, but it happens.
Update: Reading a reverse engineering report¹ it appears that it indeed works as described above. And yes, they didn't slip up; a new symmetric key is generated for each individual file.
Problem is, the prompt doesn't appear until the encryption has ended, the key has been sent to the servers (it's kind of complicated, it apparently tries to find servers on its own, I wonder if it can be fooled) and that key has been locally destroyed.
So, by the time the user is notified that there is malware on their PC, it's too late. People who know to detect viruses while they're running don't run attachments in the first place.
According to the KernelMode thread¹ the keypair is generated on the server. The public key is retrieved from it, but its private counterpart will never be on your machine. No key is sent to the server.
