MS Office Activation (1 Viewer)

[aziz rasul]

If someone has a copy of my MS Access db but does not have an activated version of MS Access, is there any VBA code that would be able to 'read' the 'Activation Required' value on the Files|Account page?

 

[theDBguy]

Just curious, why do you ask?

 

[aziz rasul]

I want to sell a run-time version of an Access db and I want, on opening the db, whether the user has a legit copy or activated copy as certain routines will not work.

 

[theDBguy]

I want to sell a run-time version of an Access db and I want, on opening the db, whether the user has a legit copy or activated copy as certain routines will not work.

Hmm, interesting concern. Normally, you wouldn't care what they have. If you want to make sure they use a specific copy, you could deploy your app with the free runtime version. However, I have no idea how to determine if the user has a legit or non-legit copy of Access. Maybe it's available in the Registry.

 

[isladogs]

I want to sell a run-time version of an Access db and I want, on opening the db, whether the user has a legit copy or activated copy as certain routines will not work.

Are you sure? Runtime is just a cut down version of Access.
AFAIK, anything that works in runtime should work fine in the full version of Access.
Can you give an example of something that won't work?

 

[aziz rasul]

So for example, if I want to alter an Excel file and keep the Excel object invisible, this will work on a legit copy. However if the copy isn't legit, then the Microsoft Office Activation Wizard dialog box appears and since the Excel object is invisible, this tops the code from working. So if at the outset, my db can 'detect' that the user does not have a legit copy, then I can simply fire up a message box to that effect. Hope that makes sense.

 

[theDBguy]

So for example, if I want to alter an Excel file and keep the Excel object invisible, this will work on a legit copy. However if the copy isn't legit, then the Microsoft Office Activation Wizard dialog box appears and since the Excel object is invisible, this tops the code from working. So if at the outset, my db can 'detect' that the user does not have a legit copy, then I can simply fire up a message box to that effect. Hope that makes sense.

Hi, not sure if this applies, but we usually just use an error handler for something like that. For example, if you create an object, but it fails, then you trap the error and show a message to the user.

 

[aziz rasul]

That's just the problem, there is no error. The code just hangs as the 'Microsoft Office Activation Wizard' dialog box is open but invisible and needs to be closed. Hence the only way I know something is wrong is when the code effectively stops and hangs and I then need to go to the TM to release the db. If I knew in advance that the end user does not have a legit copy, then I can either go down the road to say my software won't work on an unactivated copy OR simply make the Excel object visible so that the user simply closes the 'Microsoft Office Activation Wizard' dialog box and the code carries on it's merry way.

If the end user buys my software, then it's not really my concern whether he\she has a legit copy or not. That's for them to worry about. I just need my db to know whether it's legit or not so that my code can then make a decision in which direction the code should take.

 

[isladogs]

The problem you have is that MS deliberately obscure where such information is held.
If the location was obvious it would be easier to hack!

If the activation info is in the registry, I would expect it not to be at all obvious.
I have read that it is stored in the various files in c:\windows\system32\spp.
The subfolder c:\windows\system32\spp\tokens\pkeyconfig contains files marked as XML Digital Licence which may be what you need.
However good luck making sense of the file contents!

However, I would just warn clients when they purchase the software or, if necessary, show a message warning users about the issue when they run code to modify the Excel file data

 

[theDBguy]

That's just the problem, there is no error. The code just hangs as the 'Microsoft Office Activation Wizard' dialog box is open but invisible and needs to be closed. Hence the only way I know something is wrong is when the code effectively stops and hangs and I then need to go to the TM to release the db. If I knew in advance that the end user does not have a legit copy, then I can either go down the road to say my software won't work on an unactivated copy OR simply make the Excel object visible so that the user simply closes the 'Microsoft Office Activation Wizard' dialog box and the code carries on it's merry way.

If the end user buys my software, then it's not really my concern whether he\she has a legit copy or not. That's for them to worry about. I just need my db to know whether it's legit or not so that my code can then make a decision in which direction the code should take.

Unfortunately, I have no idea how to do that. I thought you were originally only concerned about the user having legit copy of Access.

 

[aziz rasul]

Apologies, I should have been more clear in my first post.

I did have a look to see if there was a registry called 'Activation Required', but no such key. I guess you are right isladogs, I wouldn't expect it to be that easy. I did look at the file in c:\windows\system32\spp\tokens\pkeyconfig and it made no sense. All gobbledygook. LOL.

 

[AccessBlaster]

It could be hidden on a piece of hardware.

 

[arnelgp]

i disagree, not All the functionality of a full msa can be
found in the runtime.
there are many discussion about this.

 

[isladogs]

@arnelgp
Not sure who you are disagreeing with. It’s already been stated that runtime is a cut down version of Access

 

[aziz rasul]

arnelgp, I have had a customary look at the db (testExpiry.accdb) you posted from a different thread and it works well. However what's stopping a purchaser from sharing the details with someone else and sending them a copy of your db. So in effect you would only need one person to purchase the db and they then pass it on to others with the correct credentials.

If however the 3 MB serial numbers were in a module and you convert the db to a accde then accdr file, only those 3 machines can use the purchased db. Does that make sense? I know it would be cumbersome as I would have to manually do this for every customer.

 

[CJ_London]

if however the 3 MB serial numbers were in a module and you convert the db to a accde then accdr file, only those 3 machines can use the purchased db.

like passwords, anything that is a text value stored in a .accde can be discovered by someone who knows what they are doing.

accdr is just a file name, users can rename back to accde (or accdb if not compiled). It is really for the benefit of developers making sure their app works as expected with runtime.

 

[aziz rasul]

Would an expert be able to retrieve the code from a accde file? I didn't think that was possible?

 

[isladogs]

If an Accde file isn't encrypted with a password then it is easy to retrieve information from it.
Provided it is encrypted, then your code should be safe from almost everyone.
However if the password is removed you're back to square one.

In addition, there is a company called EverythingAccess run by Wayne Phillips that offers a service to retrieve ACCDB files from ACCDE.
However they are a legitimate company and require proof of ownership before they undertake the recovery.
The process is also quite expensive.

BTW adding a password in the VBE to protect VBA code is almost completely useless. The password can be bypassed if you know how

 

[CJ_London]

To be clear I was referring to a password or other 'code' that is stored as text e.g.

const var ="ABC"

or

dim var as string
var="ABC"

not the whole vba code, for that you would need the services of Wayne Phillips as Colin suggests.

And the problem with encrypting the front end is your customer needs to know the password to get in anyway.

 

[aziz rasul]

Well I understand obtaining the password is pretty easy from 3rd party software, but good to have anyway, belts and braces.
As far as EverythingAccess is concerned, if there is enough copyright information and contact details on each part of the code, hopefully Wayne Philips would see that and ask the originators of the software first before pursuing any decoding. So all in all, placing the serial numbers in a module is at least one of the safest ways to ensure your code is relatively secure and people cannot simply pass on their purchase of a piece of software to anyone one for free use. After all, what would be the point of spending many months developing something.

Unfortunately no system of security can be 100% secure even for a MS Access db even though you can hide the code using an accde file. I'm surprised that Microsoft hasn't introduced such a feature in MS Excel.