hiding EXE file

[Ahmed]

Hello All,

I wonder if somebody knows how the following can be done. If we build
a VB application that uses a third party software(an EXE file) that
will be licensed to us, and the way things will be is that the VB
application launches the EXE file at some point. The problem is that
to do that, that file has to be on disk. Though we can delete that
file after processing is done, the file will be avaliable for the user
to copy/use without having the license. This EXE files needs a couple
of other auxiliary files that it writes to while running.

Now, can we do any of the following:

1- embed the software EXE file in the gui EXE we will build, and
"somehow" launch it without having it available to the user?

2- Use a RAM disk that gives no access to the user so that the gui
launch the EXE file in RAM and work from there.

Bottom line is that we have to make this in a way that gives the user
no access to the third part EXE file that will be licensed to us.

Any help is most appreciated,

Thanks,
Ahmed

 

[Simon]

Is it possible the supplier of the EXE can give you a version that can only
be run from your VB app?

Simon

 

[George Hester]

Have you tried just giving the System full rights on the file? No other NTFS permissions?

 

[Jonathan Wood]

You could include it as an EXE resource if it doesn't get so big to cause
any problems. I once simply appended one EXE to another and added a special
trailing "header" that contained the information about the appended file.
That worked fine but making it a true resource would probably be better.


I didn't quite understand where the file was coming from but another
approach you could consider is to give it a non-EXE name (such as
APPLIB.DAT) and even perform a simple encryption on it, which would be
decrypted just before execution.

 

[Pat]

I think I would ask the supplier of this software how to do it.
It seems strange that he would licence it to you for redistribution
and then not want you to redistribute it.

 

[Daniel Kaplan]

here are my thoughts, but they have limitations:

imbed the EXE as a resource in YOUR EXE.

at runtime, when you need the EXE, create a temporary directory off of the
path your EXE is runnign on.
take the resource and copy it to that new directory with some obscure name,
i.e. yerfap.da1
when your EXE is done with the EXE, simply delete the temp directory.

the flaws here are:

if it is a large EXE, it may slow down your app to do all the copying
if there is some type of crash in the 3rd party EXE, you may never get to
the DELETING part.
other crashes may leave it there for the user to find, obscure as it may be.


is it possible to ask the 3rd party EXE provider to make a custom build?
where it won't run unless one of your apps are ruuning? etc

 

[Ahmed]

Is it possible the supplier of the EXE can give you a version that can only
be run from your VB app?

Simon

Simon,
We asked about that, but it seems not possible, at least not soon enough for us.

 

[Ahmed]

Have you tried just giving the System full rights on the file? No other
NTFS permissions?

George,
Can you please elaborate?

 

[Ahmed]

You could include it as an EXE resource if it doesn't get so big to cause
any problems. I once simply appended one EXE to another and added a special
trailing "header" that contained the information about the appended file.
That worked fine but making it a true resource would probably be better.


I didn't quite understand where the file was coming from but another
approach you could consider is to give it a non-EXE name (such as
APPLIB.DAT) and even perform a simple encryption on it, which would be
decrypted just before execution.

--
Jonathan Wood
SoftCircuits
http://www.softcircuits.com
Available for consulting: http://www.softcircuits.com/jwood/resume.htm

Jonathan,
That was what we intended to do, but then the files stays decrypted on
disk during the execution time(which could be minutes). Once the EXE
is run, it cannot be changed on disk till the calculation ends. This
way the user can have access to the decrypted EXE.

If I included it in the VB EXE file, can I run it from within, i.e.
without having to save it on disk first?

 

[Ahmed]

I think I would ask the supplier of this software how to do it.
It seems strange that he would licence it to you for redistribution
and then not want you to redistribute it.

Pat,
They are currently working on some changes. My guess is that it may
take them long, and we wanted to get going with our application and be
able to send out demo versions soon.

 

[William P.N. Smith]

They are currently working on some changes.

Well, it seems they have these draconian restrictions "You may
redistribute this program and allow people to execute it, but you
can't allow them to have it on their computer or run it whenever they
want to, and you the licensee must design and implement these
restrictions, because DRM is hard, and we don't want to (or can't)
implement it ourselves."

I'd either tell them you've done it and leave it up to them to prove
it's not "sufficient", or push back on them and tell them you need
their DRM implementation to make it work properly.

[IMHO, any company that does the above has a way overinflated view of
the value of their software, and not nearly the technical expertise
they think they do...]

 

[George Hester]

On the machines where the executable lies try giving the executable NTFS Full permissions only for the system. If the machines are not using the NTFS file system then scratch this you won't even be able to try it. But if they are you select the executable right-click | Property | Security and set the permissions to have System Full permissions nobody else. You may have to uncheck propagate security settings from the parent folder to do this and only the Administrator can do it AND undo it.

 

[Ahmed]

You could include it as an EXE resource if it doesn't get so big to cause
any problems. I once simply appended one EXE to another and added a special
trailing "header" that contained the information about the appended file.
That worked fine but making it a true resource would probably be better.


I didn't quite understand where the file was coming from but another
approach you could consider is to give it a non-EXE name (such as
APPLIB.DAT) and even perform a simple encryption on it, which would be
decrypted just before execution.

--
Jonathan Wood
SoftCircuits
http://www.softcircuits.com
Available for consulting: http://www.softcircuits.com/jwood/resume.htm

Jonathan,
Thanks for your reply. Your idea sounds very good. Now, how should the
trainling header be? Is there a document/article you can direct me to
that explains such procedure. Here is the scenario I imagine. Our
gui.exe will be built in such a way that it calls the hidden EXE file
to perform the calculation. Can this call be done to the EXE file
while it is hidden at the end of the gui.exe file?, i.e. can we set
some pointer to the begining of the hidden EXE portion and run it as
if it were being called from disk?
Thanks so much in advance.
Ahmed

 

[Jonathan Wood]

Ahmed,

Thanks for your reply. Your idea sounds very good. Now, how should the
trainling header be? Is there a document/article you can direct me to
that explains such procedure. Here is the scenario I imagine. Our
gui.exe will be built in such a way that it calls the hidden EXE file
to perform the calculation. Can this call be done to the EXE file
while it is hidden at the end of the gui.exe file?, i.e. can we set
some pointer to the begining of the hidden EXE portion and run it as
if it were being called from disk?

No, I don't believe there is any way to execute the EXE without extracting
it and loading it normally.

The trailing header I came up with was simply a small structure that
contained an unusual value, which I could check to verify the file had been
appended, along with a few other bits of information such as how long the
appended file was.

Can't you give the file a temp name and place it in a temporary folder or
anything? Would the author be that concerned about what hackers can do?

As far as I'm concerned, if you need to run some code, then the only way to
make sure that code is unavailable to hackers is if that code is compiled
and *linked* into your EXE as part of a static library. If someone sold you
a separate EXE file but won't allow that file to exist on your target
computer, then either you've been ripped off, or you are attempting to use
software illegally.

 

[Ahmed]

Ahmed,


No, I don't believe there is any way to execute the EXE without extracting
it and loading it normally.

The trailing header I came up with was simply a small structure that
contained an unusual value, which I could check to verify the file had been
appended, along with a few other bits of information such as how long the
appended file was.

Can't you give the file a temp name and place it in a temporary folder or
anything? Would the author be that concerned about what hackers can do?

As far as I'm concerned, if you need to run some code, then the only way to
make sure that code is unavailable to hackers is if that code is compiled
and *linked* into your EXE as part of a static library. If someone sold you
a separate EXE file but won't allow that file to exist on your target
computer, then either you've been ripped off, or you are attempting to use
software illegally.

Jonathan,
Thanks for you explanation. It seems the only way is the tmp folder
one. I will suggest it to the vendor and see what they say. See, they
are still developing their product, and the way they have it now is
that u buy it to build ur own application on top of it, so there is no
problem as long as you donot try to sell ur application. What we want
to do is to use it to build our own app, but then sell it as well. I
guess the only way is to convince them with the tmp folder idea, or
wait till they come up with another version that would allow us to
resell our app without exposing theirs.
Thanks again.
Ahmed

 

[David Watson]

Hi Ahmed,

I know of a possible solution..

You can wrap the 3rd party exe in an encrypted 'copy protection shell'
so that it can only run on the users computer where your software is
licensed.
When your application calls the exe, it will first check to see if
there is a valid license on the users system. If not, it will not load
and can display a license screen with information advising theuser how
to proceed.
The exe itself is of no use to the end user and protected from
unauthorized distribution.
It's easy to do.

If you are interested, I can help you with this.

Best Regards,
David