Time Bomb

[hollyquinn]

Hi, I'm fairly new to using VBA and Access. (I'm a .net programmer) I'm working with an Access database right now that supposedly has a time bomb written into the program so that it will cease to run on 01-01-2009. I have the task of trying to locate it. I was hoping that someone here might be able to give me some advice on this? I have a generalized idea of what kind of code I'm looking for, but I don't want to miss anything. Anyone have any advice for me? Good links to look at? Thanks in advance.

Holly

 

[chergh]

Change the date on a machine to that date and then open the database and see what happens, you might be looking for something that isn't really there.

 

[KenHigg]

Zip it and email me a copy and I'll take a look?

 

[WayneRyan]

Holly,

What does the Time Bomb do? I really would not suggest changing your
clock ahead to activate it. It might do something really, really bad.

The code can be activated by a startup macro or on a startup form's
OnOpen event. Triggering code to run can be a very subtle thing.

I'm with Ken, I'd have to see the DB.

Wayne

 

[hollyquinn]

Change the date on a machine to that date and then open the database and see what happens, you might be looking for something that isn't really there.

Very good idea! Didn't even think of it. Thanks!

I am assured now that it the time bomb does exist. I received an error message when trying to load the program that it had expired. Now, I just have to find out where it is. Any suggestions on where to start?

 

[hollyquinn]

Holly,

What does the Time Bomb do? I really would not suggest changing your
clock ahead to activate it. It might do something really, really bad.

The code can be activated by a startup macro or on a startup form's
OnOpen event. Triggering code to run can be a very subtle thing.

I'm with Ken, I'd have to see the DB.

Wayne

Ken and Wayne, I wish I could send it to you, unfortunately I can't, because it is a program that I am working on at a client site. The program did start to work again, after changing the clock back.

Wayne, you have given me a good idea of where to start looking though. Thanks for the info. Any other suggestions that anyone else has would be great.

 

[The_Doc_Man]

Time bombs can be in any of several places.

If this database has a "startup" form, the "class module" associated with that form is the first place I would look. Any general module might also have date-sensitive code. Any commonly-used form with a class module could also do it.

You can, of course, look for something that does date comparisons in an environment that is not obviously in the middle of record-oriented or recordset processing.

There is one more possibility. Look for any oddball comparisons in which something that looks like it came from the system clock (i.e. NOW() or DATE() functions) to be compared against a number in the general range of 39813 (give or take a few), which is the ordinal day number of 1 Jan 2009 under the Windows standard.

Also, if you see anything that looks like a GetParam function call comparing against a date, you might have a date in your registry that will cause your system to die after that date. If you find the code, you would be able to see the key in question.

If there is any vendor-supplied code for which your database has an external reference, that is another place where you could get bombed.

 

[gemma-the-husky]

make sure you backup your data every night, and have a "safe" copy of the program code - then if a trigger does trash something, you will be able to go back and rework it

some things you can do to check the code

a) see if theres an autoexec macro, if so see what that does, as this will fire on startup

b) find the first form that opens (tools/startup)

put a breakpoint in the formload/form open events and trace the code
see if there are any date tests anywhere - since you had issues runnnig the code with a forward clock date, it suggests there is something there

c) now a bomb could be set to trigger from something you do regularly, so it might get harder to find - so does this app use any dll's - see tools/references in a code module - are the references just standard MS libraries, or is there a strange one there - are there any other dll's called by the code.

d) finally do you know who programmed the code -this may be overkill, but consdider sending them a legal letter - put them under pressure to reveal what they have done - it probably isnt legal

 

[KenHigg]

Starting point (IMHO):
a. Always tinker with a backup
b. See if holding down the shift when it starts will get you pas the start up routine
c. Failing b, see if you can copy all of the objects into a new .mdb

Failing these post back and let us know where you stand...

 

[dkinley]

You didn't mention the type of database or where the data resides so just passing through and suggesting to check to see if it's an .mde or a .mdb. If .mde you're probably stuck with changing the date back to keep it going unless you have the original .mdb.

Also, if it's a .mde and it is not split (a front end and back end) then you are forever tied to it. If it is split then if you will probably be stuck rewriting a new database and import all the data into it.

There are services out there that can handle a .mde, although I can't attest to any of them because I have never used them. Good luck.

-dK

 

[pono1]

Is it a "time bomb" (something insidious) or just an expired license?

 

[hollyquinn]

Time bombs can be in any of several places.

If this database has a "startup" form, the "class module" associated with that form is the first place I would look. Any general module might also have date-sensitive code. Any commonly-used form with a class module could also do it.

You can, of course, look for something that does date comparisons in an environment that is not obviously in the middle of record-oriented or recordset processing.

There is one more possibility. Look for any oddball comparisons in which something that looks like it came from the system clock (i.e. NOW() or DATE() functions) to be compared against a number in the general range of 39813 (give or take a few), which is the ordinal day number of 1 Jan 2009 under the Windows standard.

Also, if you see anything that looks like a GetParam function call comparing against a date, you might have a date in your registry that will cause your system to die after that date. If you find the code, you would be able to see the key in question.

If there is any vendor-supplied code for which your database has an external reference, that is another place where you could get bombed.

I did find it, it was inside of a macro. Thanks to you and everyone else for your help.

Holly

 

[hollyquinn]

You didn't mention the type of database or where the data resides so just passing through and suggesting to check to see if it's an .mde or a .mdb. If .mde you're probably stuck with changing the date back to keep it going unless you have the original .mdb.

Also, if it's a .mde and it is not split (a front end and back end) then you are forever tied to it. If it is split then if you will probably be stuck rewriting a new database and import all the data into it.

There are services out there that can handle a .mde, although I can't attest to any of them because I have never used them. Good luck.

-dK

It is a .mdb, not a .mde. Thanks, I did find the problem.

 

[hollyquinn]

Is it a "time bomb" (something insidious) or just an expired license?

I was originally told that it was a time bomb, but it wasn't. It didn't cause the program to commit suicide, or anything like that. It was just an expiration date. I guess whoever created the program is no longer in business.

 

[KenHigg]

Just curious, could you put a copy of the macro in a new .mdb and zip and post it, I'd like to look at it...

 

[WayneRyan]

Holy,

If you post it, please don't let it expire for a couple of days, Ken can get
pretty busy

Wayne