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)!
"if size of any embedded file > 4GB"
why on heart would your embed file size be > 4GB ? unit_test are good but please
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.
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?
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.
Send your ideas to author of EVB, otherwise no prove of your bugs.
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. 🙂
Can you share TLS bug source code?
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.
Please update the software