Setting up the Application so that only an Executable of a Specific Version Number is Allowed 5

the older executable may have the same name as the current one but overwrites the current (legitimate) one

Click to expand...

Don't understand. How can an older file overwrite a newer one?

And if that does happen, you could never tun the "legitimate" file, so how can that program do a check on the version number?

I'm guessing that what you really want is for your program to somehow find out what the latest version number should be - perhaps by reading it from some external source - and decline to run if that number does not match its own version number. If that's right, it should be easy, but perhaps you could clarify your question before we go any further.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

I do something like this to manage executable versions against database versions - so old executables cannot
access updated databases. I wonder if that is what the OP is talking about?

In my scenario, the executable opens the db compares it's version with the db version, in a table whose structure never changes, and
decides whether the executable is allowed to continue, maybe in readonly mode or updates the structure...

That way if the version is a non structural update, slightly older versions can run, but much older ones cannot.

e.g. exe ver 1.7 against db ver 1.8 is ok, but exe ver 1.7 against db ver 2.0 is not
and if exe ver is 2.1 against db ver 1.9, the exe updates the structure of the db through 2.0 and into 2.1


Regards

Griff
Keep [Smile]ing

An executable, tpay24.exe, can have different versions. What I meant is that if someone copies an older version in the application folder it would overwrite the current one of the same name.

Mike,

What I want to find out is what the latest version number should be - perhaps by reading it from some external source - and decline to run if that number does not match its own version number. (just as what you are expressing)

How can you check the version number of the executable that is currently running. The version number of the latest version is recorded in a control file in the application.

Griff has a good point about needing an external source for the necessary version number. An exe checking its own version number it has encoded in its own verification code will always pass itself.

Introducing this is not really possible unless you do it from version 1. The only way I see is to let too old versions without such verification fail, for example by renaming an important table. A too old exe then will crash. I don't see a way to enforce this gracefully without an error popping up. And I won't take that lightly, if you talk about an application you ship to many customers, any hard system error message reduces the trust into an application.

But from then onwards, the mechanism as Griff describes it will be fine. I'd also take in the possibility for executables to only need to match in the major version. Obviously, if you make a db change that's mandatory for all users, that automatically makes this update a major update.

The only weak point then is faking exe version or changing the version in the DB, that should be cared for by permissions, of course. A dbf containing the db version made read only means the executable with a newer version than db version could upgrade the db but not the version of it, which is a problem. Well, you then would not do the DB update from within the exe but administratively within a company. For the scenario of a product shipped to end users, you can't administer the database that way, though.

Also, file permissions are not the strongest safeguard, as users could change them.

This means, in any serious scenario you get into the territory of cryptographic safety mechanisms. Signing the necessary version number with a private key, the signature can be checked by an executable knowing the public key of the private/public key pair. And it can know the public key without breaching the security of that, by definition of such asymmetric cryptographic mechanisms. That way you also won't need read-only protection, a user trying to manipulate something will be caught by a wrong signature and he'd be incapable of producing a new valid signature.

There's still a problem with this, as an older version together with an older valid signature still is valid. The problem scope is now smaller though, a user could only override both db version and exe to older versions. That'll only give him an advantage if an old version enables him to do something the new version doesn't allow. For example by a flaw of the old version. I had to struggle with exactly that scenario, once. An old version had a built-in adminstrative backdoor that I gave to thje admin of a company, and he didn't keep it secret. In the end, I could only finally make old versions unusable by introducing a new table-structure and -naming the versions with the backdoor would not be able to use.

Chriss

Carol, you ask how to check the version number of the executable that is currently running. You already know the answer to that. You use AGEFILEVERSION(). You pass the name of the executable as the second parameter. You then find the version number returned in the 4th element of the array (specified in the first parameter).

For this to work, you must specify the correct version number when you build your executable. To do so, click the Build button in the project window, then click the Version button. Enter the version number in the box(es) at the top of the dialogue.

Alternatively, you can simply maintain a variable within the program which always contains the latest version number. Just update the vzriable before you do the build. That might or might not be easier than using the Version dialogue. Either way, it is up to you to remember to do it each time.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

I keep a version and sub version in my applications, in the main program
just before the modification log... so I can track when changes were requested


Regards

Griff
Keep [Smile]ing

Carol, I wonder about your concern. Is it really about manipulative users? Or do you just need to identify an update problem, like a failure to overwrite an older exe version with the current one, that should lead to a fix of the exe with the current version?

The simplest way to ensure that is to use an xcopy or robocopy of newer files run before starting an EXE, which means a very usual start mechanism.

Then the only other ingredient for forcing this start procedure is that a direct start of the EXE should always stop running. That could be done by defining a parameter in the main prg and checking it to be a specific value that's used as parameter by the startup procedure. That way an EXE pinned to the taskbar wouldn't work anymore. Which is both good and bad. On one side it prohibits users sticking to a version this way, as they don't start the startup routine but the finally running EXE directly, so that never gets updated. On the other side enabling the user to pin a running application has become a normal und useful Windows feature Windows users like to use for applications frequently used.

So you could take all this one step further and say an EXE starrted without a magic start parameter will not just quit and refuse to run, but it will start an update routine that eventually will start the correct current version with the magic startup parameter. That way also a pinned exe would work and update when necessary. The initial start will just lead to a restart.

Indeed I see I already addressed the pinned application issue in thread184-1809371. It's not the direct answer to your question, Carol, but it might give you a hint on why some users don't have the current EXE version running. If the proposed start of your application is by a start.bat/start.cmd file, then this is circumvented by users pinning the application when it runs. and they don't update, therefore.

Chriss

Carol, we're not hearing back from you, probably you're just busy.

I can only add to all suggestions, that group policies I thought I already mentioned, can be used in Windows, in general, to allow or disallow many things, besides others you can use a group policy that only allows signed executables to run. Then you still don't solve that only one exact version can run, this would not just need to be signed, that would need to have one specific known signature. And so even if you could set this policy with the restriction to exactly one signature, that means updates would require this to update, too.

Besides, group policies could only be a solution within an organization or company, not with the scenario of single end users with their literally personal computer, they are not governed by an administration having control over a domain and things like group policies.

Chriss

Hi Forum,

I use the expression x = AGETFILEVERSION(arrVersion, "vpay202410.exe") to determine whether an upgrade is due, whether an outdated executable is being used, and whether the name of the executable has been changed, as Mike had suggested. Thanks for the suggestions.

You are aware, if you assume manipulative users, the file version is something that can be manipulated?

Chriss

Carol,

Just curious. How does a user's exe know it is NOT the current version?

Does it check some new version number you place on the server and exe to compare (I've done it that way)?

If not, how would the exe know by itself what the latest version is?

Just curious.

Steve

Steve,

CarolX said:

by reading it from some external source

Click to expand...

That must be external, internally an EXE can only know it's own version number and also could know when it was created. So it can know how old it is. But that will of course never tell it whether there is a newer version or not. So that has to be from some external source by definition.

And it can be somewhere the application can easily read from, but the user can't change, like a web URL storing that.

Nevertheless, once you get the message - say "you can only run version 2.5.4" and you use a resource editor to edit your old exe version 1.9.3 to version 2.5.4 the old exe would pass such a test. It's sufficient to be able to edit one of the version numnbers to pass a comparison.

And, you know, the more it pays for anyone to overcome a hurdle, the more he'll also dig into possibilities to trick a system.

Chriss

Chris said:

...the more he'll also dig into possibilities to trick a system.

Click to expand...

So true! Some even had the nerve to call me for support. You can imagine my response.

Steve

That's probably working in enough cases such people don't hesitate to try it. Especially if support is outsourced and my be convinced to provide the necessary help, new license key or whatever.

Anyway, Carol, you see why I asked. If it's not that and you just deal with the mystery of why some users in your company have an outdated version of a company software distributed by such a batch update and start process, that would be a very probable reason. And that can be solved with a more reliable update process as I sketched it.

Still the best thing I can think of is verification of an executable by a signature. And more generally speaking by the same mechanisms that are used to detect software piracy, eg in the realm of software protection and licensing.

Chriss

Just to add another general approach. If the op can place the new version on the user's machine, the old exe can compares exe dates and go from there. If it can't find the newer exe, continue, else compare file dates and act appropriately.
Steve

If the op can place the new version on the user's machine, the old exe can compares exe dates and go from there. If it can't find the newer exe, continue, else compare file dates and act appropriately.

Click to expand...

Steve, that's pretty well exactly what I have done in several of my projects.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

Hi Mike,

As Chris implied, there can be several ways to trick a system. Many of my users wouldn't even know how to copy a file (one even after 20 years), much less change the source code. Even so, I encrypt the compare dates so they are not easy to change.

In one of my old apps I used checksums against random records of the user's data. So once they enter data, it becomes difficult for them to give away, sell or pirate the program if the pirate's data doesn't match. (I did allow for the user to change data.)

So much for paranoia.

Steve

Hmm bunch of old gits comparing notes.

Me as well

Regards

Griff
Keep [Smile]ing

I have to say that, when I've implemented this type of executable updating, it has never occurred to me to worry about these security issues. I would never have expected a rogue user to try to trick the system into using an old version, mainly because they would have no reason to do so. As far as I know, that has never been a problem.

I could see it might be an issue if you distribute a limited-time trial version of an executable, but I have never had to do that.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads