DeXRAY 2.04 update

I was contacted about a problem DeXRAY had decrypting new Quarantine files produced by MBAM so I ended up updating the decryption routine to handle this case as well. When you decrypt files produced by MBAM you should now get two sets of decrypted files – each decrypted using a different method.

If you are lucky, you should be able to recover the files for analysis 🙂

You can download the latest version here.

The full list of supported or recognized file formats is listed below:

  • AhnLab (V3B)
  • ASquared (EQF)
  • Avast (Magic@0=’-chest- ‘)
  • Avira (QUA)
  • Baidu (QV)
  • BitDefender (BDQ)
  • BullGuard (Q)
  • CMC Antivirus (CMC)
  • Comodo <GUID> (not really; Quarantined files are not encrypted 🙂
  • ESafe (VIR)
  • ESET (NQF)
  • F-Prot (TMP) (Magic@0=’KSS’)
  • Kaspersky (KLQ)
  • Lavasoft AdAware (BDQ) /BitDefender files really/
  • Lumension LEMSS (lqf)
  • MalwareBytes Data files (DATA) – 2 versions
  • MalwareBytes Quarantine files (QUAR) – 2 versions
  • McAfee Quarantine files (BUP) /full support for OLE format/
  • Microsoft Forefront|Defender (Magic@0=0B AD|D3 45) – D3 45 C5 99 header handled
  • Panda <GUID> Zip files
  • Spybot – Search & Destroy 2 ‘recovery’
  • SUPERAntiSpyware (SDB)
  • Symantec ccSubSdk files: {GUID} files and submissions.idx
  • Symantec Quarantine Data files (QBD)
  • Symantec Quarantine files (VBN)
  • Symantec Quarantine Index files (QBI)
  • Symantec Quarantine files on MAC (quarantine.qtn)
  • TrendMicro (Magic@0=A9 AC BD A7 which is a ‘VSBX’ string ^ 0xFF)
  • QuickHeal <hash> files
  • Vipre (<GUID>_ENC2)
  • Zemana <hash> files+quarantine.db
  • Any binary file (using X-RAY scanning)

PROPagate follow-up – Some more Shattering Attack Potentials

We now know that one can use SetProp to execute a shellcode inside 32- and 64-bit applications as long as they use windows that are subclassed.

There are more possibilities.

While SetWindowLong/SetWindowLongPtr/SetClassLong/SetClassLongPtr are all protected and can be only used on windows belonging to the same process, the very old APIs SetWindowWord and SetClassWord … are not.

As usual, I tested it enumerating windows running a 32-bit application on a 64-bit system and setting properties to unpredictable values and observing what happens.

It turns out that again, pretty much all my Window applications crashed on Window 10. These 16 bits seem to be quite powerful…

I am not a vulnerability researcher, but I bet we can still do something interesting; I will continue poking around. The easy wins I see are similar to SetProp e.g. GWL_USERDATA may point to some virtual tables/pointers; the DWL_USER – as per Microsoft – ‘sets new extra information that is private to the application, such as handles or pointers’. Assuming that we may only modify 16 bit of e.g. some offset, redirecting it to some code cave or overwriting unused part of memory within close proximity of the original offset could allow for a successful exploit.