Solved Autoexec export (1 Viewer)

ZEEq

Member
Local time
Today, 18:51
Joined
Sep 26, 2022
Messages
93
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
 

isladogs

MVP / VIP
Local time
Today, 13:51
Joined
Jan 14, 2017
Messages
18,130
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
However, no Access database can ever be 100% secure
 

tvanstiphout

Active member
Local time
Today, 06:51
Joined
Jan 22, 2016
Messages
158
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

Member
Local time
Today, 18:51
Joined
Sep 26, 2022
Messages
93
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
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

Member
Local time
Today, 18:51
Joined
Sep 26, 2022
Messages
93
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

MVP / VIP
Local time
Today, 13:51
Joined
Jan 14, 2017
Messages
18,130
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
 
Last edited:

Josef P.

Well-known member
Local time
Today, 14:51
Joined
Feb 2, 2023
Messages
760
@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

Member
Local time
Today, 18:51
Joined
Sep 26, 2022
Messages
93
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.
 

Josef P.

Well-known member
Local time
Today, 14:51
Joined
Feb 2, 2023
Messages
760
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? :)
 
Last edited:

Gasman

Enthusiastic Amateur
Local time
Today, 13:51
Joined
Sep 21, 2011
Messages
13,881
Add a property to the DB? Check for that property?
 

isladogs

MVP / VIP
Local time
Today, 13:51
Joined
Jan 14, 2017
Messages
18,130
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

MVP / VIP
Local time
Today, 13:51
Joined
Jan 14, 2017
Messages
18,130
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

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

MVP / VIP
Local time
Today, 13:51
Joined
Jan 14, 2017
Messages
18,130
@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

Rich (BB code):
 '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:


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

Rich (BB code):
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
 
Last edited:

ZEEq

Member
Local time
Today, 18:51
Joined
Sep 26, 2022
Messages
93
@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

Rich (BB code):
 '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:


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

Rich (BB code):
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
 

Users who are viewing this thread

Top Bottom