Solved Autoexec export

[ZEEq]

Hello to all respected members i have a question regarding autoexec macro i split database and created autoexec to set few startup properties and open login form but issue is autoexec macro can be exported from another database into frontend how can i protect frontend ? please guide me

 

[ebs17]

TransferDatabase Method [Access 2003 VBA Language Reference]

learn.microsoft.com

 

[isladogs]

Just to clarify ... as @ebs17 seems to have interpreted your post differently.
I believe you want to prevent macros such as autoexec being imported into your database as these could allow users to bypass any security you have added to your FE

Unfortunately, its not easy to do so and you will need to apply several security features to make it much more difficult.
Have a look at my article which contains many of the things to help achieve this

Improve Access Security 2

This article explains how to apply various security measures to make your databases as secure as possible. An example app is used to illustrate the possible methods available

www.isladogs.co.uk

However, no Access database can ever be 100% secure

 

[tvanstiphout]

Hello to all respected members i have a question regarding autoexec macro i split database and created autoexec to set few startup properties and open login form but issue is autoexec macro can be exported from another database into frontend how can i protect frontend ? please guide me

What I do is have AutoExec with only 1 line:
RunCode "Startup()"

Then in a standard module I implement the Startup function and set properties and check permissions in VBA. If not OK, DoCmd.Quit.
This VBA code gets compiled with the ACCDE so gives some level of protection.

To prevent hacking, I might in Startup open a hidden form that ticks a timer, and at random intervals I re-run the permissions check, and will DoCmd.Quit if needed.
Not perfect security, but good enough in most cases. If you need Fort Knox level security, Access is not your platform.

 

[ZEEq]

Just to clarify ... as @ebs17 seems to have interpreted your post differently.
I believe you want to prevent macros such as autoexec being imported into your database as these could allow users to bypass any security you have added to your FE

Unfortunately, its not easy to do so and you will need to apply several security features to make it much more difficult.
Have a look at my article which contains many of the things to help achieve this

Improve Access Security 2

This article explains how to apply various security measures to make your databases as secure as possible. An example app is used to illustrate the possible methods available

www.isladogs.co.uk

However, no Access database can ever be 100% secure

thanks @isladogs i learnt a lot from your security topics and implemented your solutions just dont know how to handle this scenario export of new autoexec from another database into my frontend

 

[ZEEq]

What I do is have AutoExec with only 1 line:
RunCode "Startup()"

Then in a standard module I implement the Startup function and set properties and check permissions in VBA. If not OK, DoCmd.Quit.
This VBA code gets compiled with the ACCDE so gives some level of protection.

To prevent hacking, I might in Startup open a hidden form that ticks a timer, and at random intervals I re-run the permissions check, and will DoCmd.Quit if needed.
Not perfect security, but good enough in most cases. If you need Fort Knox level security, Access is not your platform.

thanks @tvanstiphout doing pretty much like you explained except hidden form is this a good solution to use startup form as login form and remove autoexec from my frontend?

 

[isladogs]

I think it unlikely that anyone would do this but perhaps the simplest solution is to lock down your app as much as possible and have your own autoexec macro even if it is empty. Anyone transferring another autoexec which would bypass security would find it was renamed as autoexec1 so it wouldn't run automatically. If you make it impossible to access the nav pane it will be hard (though not impossible) to rename it.

EDIT: Sorry - ignore this - it doesn't work as stated as the Destination name is specified as one of the DoCmd.TransferDatabase arguments

 

[Josef P.]

@Colin: if you can insert an Autoexec macro, you can also delete an existing macro.

To secure it, you would need an option in Access that prevents remote control from the outside.

 

[ZEEq]

I think it unlikely that anyone would do this but perhaps the simplest solution is to lock down your app as much as possible and have your own autoexec macro even if it is empty. Anyone transferring another autoexec which would bypass security would find it was renamed as autoexec1 so it wouldn't run automatically. If you make it impossible to access the nav pane it will be hard (though not impossible) to rename it.

I created an autoexec macro in the frontend. Then, I created a new macro in a new database and used "Open StudentForm" in the new autoexec. after that I exported it to my frontend, and the new autoexec replaced my existing autoexec.

 

[ZEEq]

@Colin: if you can insert an Autoexec macro, you can also delete an existing macro.

To secure it, you would need an option in Access that prevents remote control from the outside.

thanks @Josef P. can u explain this process

 

[Josef P.]

thanks @Josef P. can u explain this process

Unfortunately not, because this option does not exist.

Just an idea: at the "proper" start of the application, a variable or similar is set that is checked in each form when it is opened. If the correct value is not set, the form refuses the service and closes again.
The only question then is: what does this bring in terms of safety?

 

[Gasman]

Add a property to the DB? Check for that property?

 

[isladogs]

Hi Josef
Yes I know that but deliberately avoided mentioning it. TBH anyone knowledgeable enough to know how to delete objects from a locked down database will be able to bypass typical security anyway

 

[isladogs]

thanks @Josef P. can u explain this process

As Josef stated, it is close to impossible to prevent automation from other running Office apps. That is a standard feature in all Office programs which run VBA. You can successfully block automation if your app is closed but not when it is already running.
However, it is possible to make that much more difficult.
For example, you can use a timer event to check for other specified apps that are also running. If any of those are found, your app could then be automatically closed.
I've used both of those techniques in one of my security challenges

Encrypted Split No Strings

This example app shows how an Access database can be made reasonably secure against hackers whilst still allowing full functionality to authorised users.

www.isladogs.co.uk

On its own, that wouldn't be foolproof but in combination with other measures it would be very difficult to hack.
Doing this will of course severely limit what other uses can do and wouldn't be popular.

But is all of this really necessary? What are you trying to protect and from whom?

 

[isladogs]

@ZEEq
Although I think its not particularly important in terms of overall security, I think I have a simpler solution that will work for you without going through what I described in post #14. I've tested it & it worked for me.

Make sure your app does not contain an autoexec macro.
Use a startup form with code in the Form_Load event to check for the presence of an autoexec macro (that has been imported by someone).
If it exists, delete it before it has a chance to run

 'check & delete autoexec macro if it exists
    If DCount("*", "MSysObjects", "Name = 'Autoexec' AND Type = -32766") > 0 Then DoCmd.DeleteObject acMacro, "Autoexec"

This works because, contrary to popular belief, the startup form loads BEFORE the autoexec macro. See my article:

Debunking Myths about the Autoexec Macro

This article debunks several widely believed fallacies about the autoexec macro used at startup

www.isladogs.co.uk

If you already have your own autoexec macro that you want to keep, first make a copy and call it e.g. autoexex (or something non-obvious for obfuscation). Then modify the above code to first delete the existing (possibly imported) autoexec macro, then copy autoexex and rename as autoexec. That way you'll know the correct autoexec macro will run

Private Sub Form_Load()

     'check & delete autoexec macro if it exists (as it may have been imported overwring the original)
    If DCount("*", "MSysObjects", "Name = 'Autoexec' AND Type = -32766") > 0 Then DoCmd.DeleteObject acMacro, "Autoexec"
    
    'Now copy the autoexex macro and rename as Autoexec to ensure the correct macro always runs
    DoCmd.CopyObject , "Autoexec", acMacro, "autoexex"
End Sub

A bit tortuous but it will work.
I've now added this info to the article linked in post #3 including a new version of the example app with the above code

 

[ZEEq]

@ZEEq
Although I think its not particularly important in terms of overall security, I think I have a simpler solution that will work for you without going through what I described in post #14. I've tested it & it worked for me.

Make sure your app does not contain an autoexec macro.
Use a startup form with code in the Form_Load event to check for the presence of an autoexec macro (that has been imported by someone).
If it exists, delete it before it has a chance to run

 'check & delete autoexec macro if it exists
    If DCount("*", "MSysObjects", "Name = 'Autoexec' AND Type = -32766") > 0 Then DoCmd.DeleteObject acMacro, "Autoexec"

This works because, contrary to popular belief, the startup form loads BEFORE the autoexec macro. See my article:

Debunking Myths about the Autoexec Macro

This article debunks several widely believed fallacies about the autoexec macro used at startup

www.isladogs.co.uk

If you already have your own autoexec macro that you want to keep, first make a copy and call it e.g. autoexex (or something non-obvious for obfuscation). Then modify the above code to first delete the existing (possibly imported) autoexec macro, then copy autoexex and rename as autoexec. That way you'll know the correct autoexec macro will run

Private Sub Form_Load()

     'check & delete autoexec macro if it exists (as it may have been imported overwring the original)
    If DCount("*", "MSysObjects", "Name = 'Autoexec' AND Type = -32766") > 0 Then DoCmd.DeleteObject acMacro, "Autoexec"
   
    'Now copy the autoexex macro and rename as Autoexec to ensure the correct macro always runs
    DoCmd.CopyObject , "Autoexec", acMacro, "autoexex"
End Sub

A bit tortuous but it will work.
For info I'm adding this info to the article linked in post #3. I will upload a new version in the next day or so

followed your suggestion thanks @isladogs

 

[isladogs]

You're welcome.