Building Executable with Molebox

[Sng1]

I create a exe with molebox encryption package. Since up till now exe was executed on a server in which VFP was installed , so there was no problem. But now When I am distributing it as zip for desktop version where VFP is not installed, exe simply doesn't execute.

 

[Mike Lewis]

Regardless of the use of Molebox, you can't simply distribute a VFP executable and expect it to run. The EXE needs certain support files in order to run.

The easiest way to deal with this is to use an installation package to create a Setup program. The Setup program is a single, user-friendly program which the user runs to install your EXE and all its support files. You can create this program using InstallShield, which is included in your VFP package. Or you can use a third-party tool, such as Inno Setup, which is popular among VFP developers. Both of those should be compatible with Molebox, but Molebox is by no means essential for this task.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Sng1]

If I don't molebox my exe and simply copy exe along with supporting files, it works without any installations. I am using molebox so that my exe doesn't get reverse engineered easily.

 

[Gerrit Broekhuis]

Hi Sng1,

If it works without Molebox, there must be something wrong with something inside your Molebox setup.
Have you checked

https://sudachen.github.io/Molebox/

?

If you succeed in solving your problem, please post your solution back here, others may be interested in this as well.

Regards, Gerrit

 

[Mike Lewis]

In that case, I suggest you drop Molebox. There is no question of being able to reverse engineer your EXE easily - especially if you tick the "Encrypted" box in the Project Info dialogue (from the Project menu). And also do not tick "Debug info".

Even if someone could retrieve your source code from the EXE, it is highly unlikely they would be able to do anything useful with it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Sng1]

Hi Gerrit
I have already read that and tested in every possible way which I could do but it didn't work.

Mike
My problem is that if any user is able to view the source code and he gets logic so that he cracks exe and extends trial versions days, he can then use/distribute pirated version.

 

[Mike Lewis]

You really don't need to worry about anyone cracking the source code.

Just try this yourself. Tick the "Encrypted" option, then build the EXE. Open the EXE in a hex editor. Scroll down through the entire file. You will not see anything at all that resembles your source code.

But even if the hacker was able to view the source code, they would have to go to a huge amount of trouble to figure out the logic. Surely you could obfuscate your trial version check to make that even more difficult.

Keep in mind too that, even if they knew how to defeat the trial version check, they wouldn't necessarily be able to edit the EXE in such a way as to make that possible.

And finally, is your application really so expensive that anyone would go to so much trouble to avoid paying beyond the trial period? As for pirated copies, would anyone really want to use one, with no support, not upgrades, no documentation?

You know your application and your users better than I do. But I'm sure your fears are exaggerated.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[TamarGranor]

To Mike's arguments, I'll add the question of whether anyone who would use a pirated version would ever actually buy the legal version. That is, even if you get pirated, does it actually cost you money?

Tamar

 

[Sng1]

I think I got the source of problem but not the solution . I made a simple exe with messagebox and added runtime dll in molebox and then packed the package . When I create a pack module along with all runtime using configuration as "Register on Pack" , it fails. It gives message as failed to process standard OCX registration, trying alternative is not OCX yet or does not registered properly. Error : virtual register fetching error.

And when exe is run in the destination computer where vfp is not instaled , it gives error as "Failed to read registry files".

 

[Chris Miller]

Maybe because of the manifest embedded in VFP9 executables.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
          manifestVersion="1.0">
  <assemblyIdentity
    version="1.0.0.0"
    type="win32"
    name="Microsoft.VisualFoxPro"
    processorArchitecture="x86"
/>
  <description>Visual FoxPro</description>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level="asInvoker" />
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity
        type="win32"
        name="Microsoft.Windows.Common-Controls"
        version="6.0.0.0"
        language="*"
        processorArchitecture="x86"
        publicKeyToken="6595b64144ccf1df"
        />
    </dependentAssembly>
  </dependency>
</assembly>

This is embedded into the exe and Molebox likely tries to register Microsoft.Windows.Common-Controls or read info about it from the registry. If you remove the whole dependency section this could work.

Also, what runtimes do you add, you're aware of all the DLLs a VFP executable needs? Including C++ runtime and GDIplus?

Chriss

 

[Sng1]

I have exe in which I have included 1 program file with messagebox and dll I have included are GDIPLUS.DLL,MSVCP71.DLL,MSVCR71.DLL,VFP9R.DLL,VFP9RENU.DLL
And then I have compiled the package with molebox

 

[Chris Miller]

What about the habit of VFP to create a Foxuser.dbf?

Chriss

 

[Sng1]

As Mike and Tamar suggested , I am making encrypted exe with vfp and distributing to users.

 

[Mike Lewis]

I am making encrypted exe with vfp and distributing to users.

Good. That is the obvious solution.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

I actually still like the idea behind Molebox, though it adds a layer of virtualizing. In the description of Molebox it actually only virtualises hard drive and registry, so it seems to hook into any registry access to reroute it, likely using Windows own technique to reroute registry access used by UAC. And files are unpacked to a virtual hard drive, but not on the real hard drive which is it's mean to protect access to the executable file.

The downside of Molebox to me is the latest build is from 2017, requirements to compile sources are VS 2010, so it's an inactive project and it may fail on incopatibilities.

Your first hint about a Molebox created exe working with external runtime files suggests to me, that the VFP bootstrapping code of finding the runtimes and initializing them doesn't work with the virtual filesystem and thus needs the runtimes as separate files on the host filesystem. Also C++ runtime version 10, I guess. As Molebox.exe itself needs that runtime.

It would be a good idea to try dependency walker on the encrypted molebox exe to see what it needs.

Chriss

 

[tomk3]

Hello,

for protection and compressing (we include dlls, pictures,.. in the exe)
I can recommend refox, also its not free.

http://www.refox.net/

Regards
tom

 

[Sng1]

Molebox created Exe doesn't run on host computer even after providing external runtime file.

Chriss do you mean runtimes required for Molebox. But in the computer where VFP is already installed moleboxed exe works fine. What I think is while making molebox exe and choosing option 'register when pack' generates error and so virtual registry file which might be read is not made and there problem arise. I am not sure how to solve it. Just I can do is either include runtime dll in package or exclude it and provide additionally. But neither of the two are working

 

[Chris Miller]

What of my other suggestions did you try?

VFP only looks in the registry at start to find the VFP runtime, but if it's in the same folder not finding it doesn't matter, so have you tried without registry virtualisation?

Chriss

 

[Sng1]

Yes that was the starting point with which I had tested - "without registry virtualization" and providing external runtime. In this case problem which I feel is that moleboxed exe is not recognized as VFP executable , so even if external files are present, when exe is run , it checks for some virtual registry file. For this I had made a shell vfp exe which in turn calls moleboxed exe and provided external runtime. So when I run shell exe it calls moleboxed exe but that exe doesn't run and in the same folder one file is generated in which there were so many commands and in the middle it was written 'failed to read virtual registry file'

 

[ggreen61]

I too have ReFox which I purchased and upgraded over the years (all the way up to the version for VFP9). Back around 2008, I had developed a number of VFP tools which I had "protected" with ReFox. I had placed the "protected" versions on the web for others to download. One user (which I don't remember) sent me an email with one of the tools completely decompiled back into the forms, classes, programs, etc. with all source code to prove that ReFox can't prevent decompiling (the person would not explain how it was done). So, ReFox is not completely able to protect the executable from being decompiled; however, most will not be able to do the decompile.