Bugs in Enigma Virtual Box

kao

While working on a new version of my static EnigmaVB unpacker, I tried to generate test files to cover most of the Enigma Virtual Box features. In the process, I ran into quite a few bugs in Enigma Virtual Box v7.40.

So, here's a short list:

Registry virtualization

1. Importing REG file with wrapped lines:

"RootFolder"=hex:01,00,00,00,00,00,00,00,01,00,00,00,04,00,00,00,01,00,00,00,\
  64,00,00,00

Data get truncated at the end of first line.

2. Importing REG file with entry type REG_NONE:

"WMP11.AssocFile.3G2"=hex(0):

It gets virtualized as a string value "hex(0):"

File virtualization

1. If size of any embedded file > 4GB: creates invalid x86 executable;
2. If total size of all embedded files > 4GB: creates invalid x86 executable;
3. If size of main EXE > 2 GB: creates executable that seems to be valid but won't run;
..and that's only for x86 executables. I wonder how many more issue will surface when I start testing x64 executables. 😉

TLS callbacks

Since Enigma Virtual Box uses TLS callbacks to initialize its hooks and handlers, it will (accidentally?) break any executable that also uses TLS callbacks. However, it preserves TLS StartAddressOfRawData, EndAddressOfRawData and AddressofIndex fields. Very weird.. 🙂

Have fun (and remember to test your software properly)!

9 thoughts on “Bugs in Enigma Virtual Box

  1. "if size of any embedded file > 4GB"
    why on heart would your embed file size be > 4GB ? unit_test are good but please

    1. Short answer - for example, game data files or video files.

      Long answer - you can't imagine how many different edge cases users have reported to me. So, when making my own test files, I'm pushing the limits of the packer. If it showed me a message box saying "Hey dummy, don't try to pack 4GB datafiles, it makes no fricking sense", I would totally understand. But if it accepts my files and produces boxed executable, I expect this executable to be valid and runnable.

  2. If you take a look at the structure of the packed exe file you understand that it is just impossible to create file of more than 4GB of size, this is not a bug of EVB this is limitation of PE section of exe file.

    TLS callbacks are being called by packed program anyway, even if you do not see these callbacks anymore in TLS directory.

    And what is strange to keep StartAddressOfRawData, EndAddressOfRawData and AddressofIndex? This data is used to initialize some global tls variables in program, what is weird there?

    1. Ad.1: Already gave response to XenocodeRCE. If packer produces a packed file, I expect it to be valid. If it gave an error message instead, I wouldn't complain.

      Ad.2 & 3: TLS callbacks are not called by packed program. They called by Windows PE loader when creating new process. EnigmaVB screws this up.
      Here's a tiny example file I made during my tests: https://www.mediafire.com/?pja635uzujlcw2h. As you can see, boxed file doesn't work the same as original. If that's not a bug, I don't know what is.

    1. I am under no obligation to send anything to anyone. Just like you are under no obligation to read my blog if you don't like it. 🙂

    1. I gave the example binaries in a comment above: https://lifeinhex.com/bugs-in-enigma-virtual-box/#comment-982 It was hand-made in a hex editor, so there is no source code. 🙂 But you're welcome to disassemble empty1.exe and see for yourself.

      If you want to implement TLS callback in C, see http://www.rohitab.com/discuss/topic/40811-detect-debugger-with-tls-callback/, https://gist.github.com/merces/1336cd4739cb1368efed or just Google for TLS callback source code.

Leave a Reply

  • Be nice to me and everyone else.
  • If you are reporting a problem in my tool, please upload the file which causes the problem.
    I can`t help you without seeing the file.
  • Links in comments are visible only to me. Other visitors cannot see them.

3  +   =  4