Opening a Locked Database

[Tezcatlipoca]

I have started working for a company that uses a split Access database (front end / back end). The people who actually work with the database use MDE files, which connect to the back end MDB tables elsewhere.

Also in our possession is the MDB source code.

Recently, all the users databases stopped running. When run, they popup with a message saying they're out of date. Normally this wouldn't be a problem, but the source mode MDB master is doing it too. Holding down shift doesn't work, so it looks like this has been disabled.

We've also tried changing the system clock date, but starting the database then just tells us we've tried to change our system clock to get around the lock and still shuts itself down.

Ordinary cracking programs are uselsss, since this isn't a password; the database starts up then immediately shuts itself down.

The person who originally wrote this database is uncontactable, and, whilst I could use the source code to prepare new versions for people, not being able to even access the source code prevents me doing anything.

Any ideas?

 

[DCrake]

It sounds like your predecessor (Author) has protected his/her interests by putting in a time out date. I have a applet that may help. I was not the author of this but have made some modifications to it. It essentially documents an mdb by copying all the forms, modules, queries, etc to txt files which can then be uploaded into a blank mdb. Effectively re creating the mdb. I will fish it out today and put it in the sample database section.

This may give you an insight to what they have done and how to overcome it. Not knowing how well they have protected the mdb I cannot guarrantee it will work, but it's worth a try.

David

 

[gemma-the-husky]

[edited

sorry - read this again, and i realise you cant get INTO the database at all

its probably vary hard to find, but check these folders
a) dbs folder
b) dbs backend folder
c) also look for any file dated as the installation date of the app

see if there is a file or hidden file, that may contain a cut-off date. it gets hard, because the contents may well be encrypted in some way

this stuff could even be buried somewhere in the registry

less likely, but there may be some field in a control table in the backend storing such authorisation stuff. open this directly with a new dbs - and see if there is anything there.

normally bombs like this would only activate if licences are out of date - is there any dispute with the dbs provider


one other thought - get a new pc, set the date back to an earlier date, and put the mdb on it - then try to run the mdb. this might help identify how the protection works

and another thought - create a new dbs - and try to import what you think may be the startup form (or indeed all the forms) and the code modules - then you might be able to examine the code - assuming the dbs uses access security, you should be able to connect to the .mdw to do this. As long as there is no startup form specified, no code will run on launch.

finally try everythingaccess.com (or other codebreakers) - they may well be able to help

end of edit]




look at startup properties and see which form opens first. (or there may be an aotoexec macro)

you could examine this, and trace programme code.

This will locate the piece of code that is causing the crash.

It will only be a problem if the code block includes destructive stuff - maybe deleting records/files that you didnt know about.

Its a bit moot if you can't get hold of the programmer, but I'm sure it is probably illegal to put bombs like this into code.

 

[Tezcatlipoca]

Update on this. We have managed to contact the programmer, who tells us that this has happened because of standard version checking routines in the database that prevent old versions sitting alongside new versions and causing instability. Apparantly when they were working for us, each new version would have a new timer embedded to prevent the use of older versions when newer ones were available. They tell us that when they left the business they handed over a final version with no checks at all (which we apparantly didn't distribute). I've found and checked that version, and it runs absolutely fine so I can restore the database for the users. The source code, though, is still locked up.

To be fair, the programmer has tried to help us by email, and said the source shouldn't have version checking on it and has promised to look for an old copy of the source and will supply it if found. They have confirmed to me in an email that the routines are apparantly all written in Visual Basic modules, which I know gets encrypted when it's turned into an MDE and cannot be pulled out again.

Apparantly the database has a form that autochecks the version, set in the Startup folder of the application, then, if all is fine, it jumps into the welcome form.

I should point out that part of this problem is that the whole system has been written as modal popups, so the database window doesn't actually ever open up; it's all just popup forms. This means I cannot get into Access proper, or carry out any of the usual tasks associated with it.

If they can't find an old copy of the source code to help us, which is likely given the amount of time that has passed since they left, is there another way to get this data out? I will try your method later, DCrake, but will it also pull out modules and VB, or just basic forms and queries?

 

[DCrake]

The documenter pulls out all the source code and vba from your forms. please find attached a sample of a form that has been saved as a text file.

As you can see if you scroll down to the bottom of the file you can see all the vba that sits behind the contols.

Note this demo only works on Mdb's not MDE's


If you want to post me the mdb I will see what I can recover for you.

David