DeXRAY – Decrypting VBN files, Part 2

A few months back I posted about DeXRAY –  a generic script/file carver that tries to decrypt various Quarantine files + PE files hidden inside other files under a simple layer of a single-byte xor encryption.

Some time later, in one of my other posts I mentioned that newer VBN files used by Symantec Quarantine use a different encryption scheme; instead of using well-known xor with a 0x5A key, they now use 0xA5 key.

Turns out that I was right about it, but only partially as there is a twist to it – not only these files are encrypted, but they are also divided into chunks separated by a 5 byte ‘chunk divider’ in a form of 0xF6 0x?? 0x?? 0xFF 0xFF. So, to reconstruct the encrypted Quarantine files, one needs to decrypt them with 0xA5 first and then remove the chunk dividers.

Simple, isn’t?

I updated DeXRAY.pl to handle this (quick & dirty patch, but it should work). If you find some VBN files that don’t get decrypted at all or get corrupted after decryption, please let me know.

I bet Symantec guys added this to prevent accidental detection of Quarantine files by theirs and other AV companies’ scanners; the way I think it goes is that many AV companies use X-rays technique during scans (that is, they may find malware even if it is encrypted with a single byte xor) and they could potentially/accidentally decrypt and detect the Quarantine file during scans. That could potentially lead to some ‘funny’ results (recursive detection, etc.); introducing ‘chunk divider’ breaks the file format of the encrypted file and AV scans no longer can ‘understand’ the corrupted file structure (especially if it is an encrypted PE file).

Download a new version from here:  DeXRAY.pl

 

Update

It’s been a while since I wrote anything here. This is due to me being on holidays and moving to a new place right after coming back. I finally settled down in a new apartment and looking forward to play with some new ideas.

So, here is a short update:

  • I fixed a silly bug in HAPI – I mixed up CR & LF characters in the output and it looked awkward to say the least, not to mention potential parsing issues; Thx to Pedro L. for spotting this and notifying me
  • HAPI may occasionally print some strings that look like non-API, e.g. ‘version’; this is not a bug, but a feature 😉 it turns out that there is such an API exported by one of the Microsoft DLLs ; since I don’t want to miss any API, I made a trade off and include all of them; still… I use some little heuristics to prevent printing many of them, but some of them will sometimes go through; so, please always verify the output manually; and for the curious – some Microsoft programmers decided to name certain APIs using one, or two characters; I dunno why do you do stuff like this, but there are legitimate system DLLs exporting functions named ‘u’, ‘vo’, etc.
  • Discovered recently that Symantec’s VBN files can be encrypted not only with 0x5A, but also 0xA5; these files are still handled by DeXRAY since it relies on a XRAYS technique that searches and extracts encrypted executables without needing to know a specific key; but if you parse VBN files yourself, knowing that 0xA5 is being used may help you to save some time