Digital Workshop

Hi

Resource Managing is a new area for me. I have a pub that uses a DLL, loading it and calling functions (xyz.dll). I would like to hide the DLL and make it unavailable to users for any other use. One possible solution would be to include it as a resource in the pub, and have this resource included in the published .ILM file (publishing as a standalone EXE). From my reading of the help guide, resources (images, audio, video, etc.) are included by default in the .ILM file which Opus upon publishing apparently further bundles into the EXE.

The DLL is loaded by scripting and the current load function call path is


Doing some experimenting, I seem to be able to add the xyz.dll as an additional resource (either by single file or inside of its own directory) by using the additionl resources tab of the publication properties. Then it appears in the Resource Manager, where I can choose a location tab and select the setting that will include this resource inside the published .ILM file.

However, I can't figure out how to re-write/reset the correct path name in the load script so that the runtime pub can load the DLL and call its functions, since it is no longer in the SYSTEM_PUBLICATION_DIR but instead inside of the .ILM file.

So, I'm stuck trying to figure this out and would appreciate any help. I wonder if this is even possible.

Kind Regards,

Hi Stephen,

Regarding the path, ...have you tried assigning an Alias name to add'l resources?

As for 'hiding' the DLL, I'd be curious to know that too.

What little testing I've done with the sqlite.dll, it DOES show up to user when installed on a system under Program Files (used Opus installer setup, and I had added it both under Add'l Reso. and in the Publishing process). Not yet tried making the ILM file.

As far as hiding the dll; you can change the file extension to anything you like.
ie
foo.dll will still work if you change the filename to foo.txt, then load it with
var MyDLL = LoadDLL("foo.txt" );.

Paul

Thanks, Larry and Paul for your replies.

The ultimate goal is to bundle the DLL in such a way (for example, embedded inside the ILM) that it remains accessible to load and function calls for the pub, but cannot be accessed in any other way by any user for any other use. I suspect this is similar to the goal of gamers who use a DLL or OCX or other component in a game and want to secure and protect it from use by other programs.

I have checked out many of the third-party anti-crack, bundling, compression, winlicensing programs that are used to bundle and protect DLL's, their EXE's and a variety of resource files. For whatever reason not one will work with an Opus generated EXE.

The DLL can be bundled easily enough along with the pub's EXE in an installer, but following installation, the DLL can still be separately found.

So, the only remaining option would be to bundle the DLL in the ILM, and yet still be accessible in runtime (like a pub's image, sound or video resources), if this is possible.

This still would not work if the DLL ends up visible, otherwise accessible in a program directory or any other place.

If the DLL is embedded in the ILM (like any other jpeg, etc.), I wonder how it's pathname can be identified and used in a script?

Larry: the use of alias names may be a clue to this?

Any ideas how?

Kind Regards,

Stephen


It's done under Publication Properties >>> Additional Resources. There's a Button there if I recall. [Edit: part of the dialog when Add/Edit there)

Opus is set-up to use that Alias in Scripts... instead of referencing the filename and path. Check the Help files under Add'l Reso?

- - - - - -
Another way I can think of is a 95% solution, if that. Encrypt the DLL, perhaps as a .txt file as Paul suggests. Ship the encrypted file only. Then at runtime, Read/unencrypt it to an active file... down in some obscure directory. And of course, do exit maintenance to destroy the file.

Hi Larry

I had seen the alias input area of that dialog box. I am not sure how to use it. I read the help guide entries and followed the instructions. I did try setting "abcd" as the alias for the DLL, having entered the real pathname for the DLL in the box to create the alias. Unfortunately, when I published a sample pub, using "abcd" in the load DLL function and tried it, the DLL was not successfully loaded.

I'm just not sure how to use the script alias properly to substitute it for the DLL pathname currently written (see code above).

Any suggestions would be appreciated.

Kind Regards,

I've not used it myself.
Apparently, when referring to an alias within opusscript, it goes inside quotes? "aliasname"
And the path in Add'l Reso.... single '/' or double '//'? I presume 'single' there, since Opus allows you to Browse to the file. (may have to change filter to *.* All-Files, to find DLLs)

Other than that, I'm just not that familiar with how Opus configures things in Publishing. Maybe I'll head over to Michelin and see if they have a roadmap on that. Or find a "Pub crawl" guide.

Hi Larry

I can experiment some more, try different versions of the alias and script. However, I'm not sure that Opus will recognize DLL as a file type for adding as a resource. If I recall, I was only able to select it when I chose to view "all files" rather than the "supported" file types that could be chosen in the dialog box.

There is one program, EnigmaProtector (http://www.enigmaprotector.com/en/home.html), which with the help of its developer (he provided great support: even wrote a small extra utility to create compatibility!) can be used to bundle the pub EXE and DLL as a single EXE, thereby protecting the DLL.

So, one way or another...But including the DLL inside the ILM would be the smoothest option if only I can figure out how to write the pathname and successfully load the DLL, call its functions with that path.

Kind Regards,

Hi Larry

I'm not sure how to make this work. I did notice that the additional resources dialog mentions "supported" file types which does not include DLL. I was able to choose "all files" in the dilaog to add the DLL, but it may not work because it's unsupported.

I can experiment.

Meanwhile, a developer of a protector software wrote a little utility to improve compatibility of his software EnigmaProtector: http://www.enigmaprotector.com/en/home.html), and with some tweaking, it works: outputs a single EXE with the DLL embedded inside. The protector software is awesome, reasonable, and his support responsive and highly capable! So, there is another potential solution.

I would still like to see if the DLL can be embedded inside the ILM, and if a pathname can be added to the script to load it, call functions.

Kind Regards,

That's what I'm saying... do add a DLL file type by going beyond supported filetypes. ( I interpret "supported" here as a legacy situation... at the time, those are what DW envisioned made sense. DLL use is a recent addition.)

The other option is as Paul said. Rename the file extension to .txt, or even .INI, .bak, .tmp ( although I'd use the latter two with caution.... as some windows backup and imaging applications allow users to exclude those from backups )

BTW, I did notice a few months ago that files I added via Add'l Reso, were NOT included when published. Other posts pointed me to a step in Publishing to "Add Files" (or directories) in that process. I have no idea how that affects your plan to do an ILM.
viewtopic.php?t=2684&highlight=publish+create

[Edit: I edited to clean up the post/wording... and think that got this out of sequence from Stephen's post about same time]

Stephen,

Are you placing the DLL directly in the "system publication directory"? Or do you have an intermediate Folder?

I doubt the following applies when choosing the option to create a Single-data-file. But worth noting since we're discussing.

I learned thru trial and error, that when using the "Distribution Wizard" that I can (i.e., I must) manually append the 'xyz_Resources' folder or 'myImages' folder -- to the 'default' Target Folder. (and same applies in standard Publish process, when using "Create setup exec..." option)



I guess the point here it that it takes some care to keep the file locations consistent with the paths you specify in scripts.

Hi Larry

Yes, the critical issue may be getting the correct path to the DLL, if you are asking Opus to publish it in the ILM.

I did some more experimenting, with no success: I placed the DLL in the Resource Directory, since, according to help guide information, the Resource Directory's content are included in the ILM as their default location. I created a script alias for the DLL when still located in the Resource Directory, hoping that upon publication and being launched, the runtime would seek the script alias' DLL file in the Resource Directory inside the ILM. No joy. Test failed.

I wish I knew if (1) the DLL is ending up in the ILM after publication and (2) what the correct pathname to it in that location would be. I don't have a clue how to name the path to the published ILM, or if a DLL inside of the ILM can even be loaded and its functions called in runtime. Maybe, all of this will end up on the Wishlist.

Kind Regards,

I use .x32 Xtras in Director, which are just DLL's.
Some of them are commercial; the developers of these Xtras protect their products by requiring a serial string to be sent with any call to the Xtra.
This stops any unauthorized use.
Maybe whoever makes the DLL in question could think about adding this functionality.
Just curious about this DLL -- it isn't a common practice to hide them.

Paul

Hi Paul

This proprietary DLL was customized for me and does have a password string to protect it.

I was simply trying to see if it can be included inside an Opus EXE, within the ILM, as a resource that can be loaded/called.

No mystery: since some of my projects invite the user to enter health data (medical conditions running in their family), I'm always trying to create the most secure programs to help assure privacy of sensitive data.

Kind Regards,

missed a bit... what are DLL's