Something wrong with VirtualBox in EP 7.90 x32

[Tim Vau]

Hey,

I'll try to prepare "public" example with a problem but in the Enigma Protector v7.90 is exists a bug with VirtualBox-ed program files like .jar with running under JavaRuntime, for example, maybe with some other types also. At this time I can't upload an example because easy "Hello World!" program is running properly in 7.90.

Log Name: Application
Source: Application Error
Date: XXXXXXXXX
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: XXXXXXXXX
Description:
Faulting application name: javaw.exe, version: x.x.x.x
Faulting module name: ntdll.dll, version: 6.1.7601.24384
Exception code: 0xc00000fd
Fault offset: 0x0004eb14
Faulting process id: 0x107c
Faulting application path: xxxxxxxxxx\bin\javaw.exe
Faulting module path: C:\Windows\SysWOW64\ntdll.dll

If I protect the program in 7.80 (7.70, 7.60, 7.50, etc) - all is fine (jar and java.exe inside VirtualBox).
If I load -jar file directly from a disk in 7.90 - all is fine, but if under VirtualBox - the application crashes.

[aiden]

Hi Tim,

thanks for the post. It is pretty hard to tell what could be wrong here especially if you say with a simple Hello World its working properly. The only thing i could advice you to do here is to send an E-Mail directly to Vladimir. Use support@enigmaprotector.com. I assume you did not upload the files where it fails here because you dont want them public - wich makes sense ofc when you choose Enigma Protector in the first place to protect them. The best support can be given if you send:

• Your .enigma Project file

• Your unprotected files

• The protected file(that crashes)

• A quick overview about your System Host or VM, OS and wich Language you run on your System.

This way it can be analyzed the best and most efficient way why this issue occurs. Please note Vladimir does strictly keep everything private and will respect all intellectual property. Just make sure to transfer them securely, meaning dont upload them to any thirdparty hoster without a password as they might get indexed by Google. Best ist to directly send them via E-Mail and if they are too big to send and there is no way around sending them through a hoster, i would suggest you choose something like Dropbox, compress it to a rar file with a password and share the password in the Mail. Afterwards you can then remove these .rar from the Dropbox as well.

-Aiden

[Tim Vau]

I uploaded it here (link in attachment):

bug-report.zip

(27.51 KiB) Downloaded 234 times

You need to unpack and copy the "DEBUG" folder to the path "D:\" and download the necessary components from the links inside the BUG-REPORT.txt file.
From my observations, among other things, the OEP virtualization option clearly conflicts (Classic or RISC doesn't matter).

Also here is an additional report about custom resources recording floating bug.

[Enigma]

OK, I see. First of all, the structure of the files protection is incorrect, it is possible, but not correct. Please try to avoid BatToExe converters (any one, not any specific, just all of them), that's wrong to use this kind of software for protection.

Why is it wrong? Let me explain, how the protection + Virtual Box + BatToExe converter works. When you convert a bat file to exe, what happens at low level when you run such file? Runs the first process, it is a process of exe file you converted. This exe runs a new process - cmd.exe, this is required in order to run the bat file. In your bat file the file javaw.exe runs, so cmd.exe runs 3rd process - javaw.exe. This happens hidden for end user, but clear for protection. Imagine, to make sure this 3rd process javaw.exe could read virtual files you've added to Virtual Box, protection has to inject Virtual Box into cmd.exe process, then into javaw.exe process. So good so far, but if these processes have different architectures, protection would be rather tricky to inject Virtual Box between all these processes. Process may have different privileges and limitations, something could happen wrong.
If you are going this way, the following options at Virtual Box - Options panel are mandatory:

vb.png (24.15 KiB) Viewed 9573 times

What would be the correct way?
Very simple! Take javaw.exe, put jar file in Virtual Box, use option Miscellaneous - Command Line to append necessary parameters, like these "-jar HelloWorld2.jar", protect it, nothing more. No virtual box process sharing options are required. No cmd.exe will be run. No additional processes will be run.

As for protection of entry point, that's separate issue, we will check it out.

[Enigma]

Could you please also change the content of the bat file and provide us converted exe?
Change the following line: "..\zulu24.32.13-ca-fx-jre24.0.2-win_x64\bin\javaw.exe" -jar HelloWorld2.jar
Java is being installed on the computer and register globally in paths, so this line should be just "javaw.exe -jar HelloWorld2.jar" no path is required.

[Tim Vau]

You'r right that I shouldn't use the 64-bit version of Java to run 32-bit programs. The latest version for x32 is:
zulu17.60.17-ca-fx-jre17.0.16-win_i686

And there I reproduced some differencies between 7.80 and 7.90 versions of EP mostly on Windows 7 SP1 with disabled OEP virtualization.
I use recommended options for VirtualBox.

At this time I'm not sure what the problem only in OEP virtualization. Custom code virtualization also needed to be checked for own custom loader.
But for VirtualBox'ed files looks like version 7.80 more stable than 7.90.

Here is addition to the java loader bugreport:

bug-report-2.zip

(27.51 KiB) Downloaded 213 times

Java is being installed on the computer and register globally in paths, so this line should be just "javaw.exe -jar HelloWorld2.jar" no path is required.

Sure, I will do it next time.

[Tim Vau]

Here is 3'rd addition for the java loader bugreport:

bug-report-3.zip

(27.51 KiB) Downloaded 251 times

Now the path is global for a loader:
javaw.exe -jar HelloWorld2.jar

I have tested it with zulu21.44.17-ca-fx-jre21.0.8-win_x64.msi
Same errors. I think for version 24 will be also same errors.

[Alex.Rischer]

Absolutely the same situation with jar and java.exe inside VirtualBox.
Everything worked for many years without any glitches, from about 2017 until the release of version 7.90.
I had a lot of problems with my clients. Everything went back to normal when I rebuilt all the files on version 7.80.

[Enigma]

Absolutely the same situation with jar and java.exe inside VirtualBox.
Everything worked for many years without any glitches, from about 2017 until the release of version 7.90.
I had a lot of problems with my clients. Everything went back to normal when I rebuilt all the files on version 7.80.

Alex, can you please send us some small sample at support@enigmaprotector.com?

Example of Tim is a bit difficult to investigate, since it depends on a batch file converted to exe. Hope your sample would be more suitable to be investigated.

[Alex.Rischer]

The problem is, you won't be able to run it. It's part of a complex automotive diagnostic system. You'll need a separate computer, a car, and a multiplexer. And several hours of me explaining how and what to do. But the fact is the fact. I had huge, huge problems that took me almost 2 months to fix after 7.90.