The most common form of all contaminated software is the logic bomb. Logic bombs are pieces of logic that lie dormant until triggered by some internal or external event. This code can be incorporated into z/OS modules or embedded in application programs. You can trigger a bomb by a date (a time bomb), which is the most common method, or by some combination of input data (an event bomb). The same program can contain both types of bombs.
Time bombs can be found in a system routine that is frequently executed and performs day or time checking. Because commercial data processing depends on billing cycles, month‑end closings, fiscal year processing, and so on, time bombs placed in date‑oriented logic are assured that they are periodically executed.
Input data can trigger event bombs. Usually, event bombs execute when a certain transaction is submitted or withheld from the system. For example, an event bomb’s design can require that a transaction be submitted periodically to prevent it from executing. Once the designer leaves the company or is otherwise unable to supply the transaction, the bomb is triggered.
Another example is a bomb triggered by the number of employees on the payroll file. In this case, the bomb lies dormant in a small company until that company grows. As soon as the number of employees reaches the trigger number, the computer experiences problems.
The design of a logic bomb determines what happens when it explodes. Logic bombs can stop programs from running, erase master files, destroy backup tapes, and mimic hardware failures by corrupting random bytes of data. You cannot recover data that is lost due to a logic bomb if your virus‑free backup tapes are reused before you detect the bomb.
Ironically, the commercial software industry is the primary developer of logic bombs. Software publishers, in an attempt to prevent unauthorized copying of their software, can incorporate logic bombs. Before a program executes, its logic bomb performs tests to determine if a program is running on its original diskette or a copied diskette. This can involve checking for nonstandard disk formats, I/O errors in certain disk locations, or laser holes burned into the diskette.
| Copyright © 2009 CA. All rights reserved. | Tell Technical Publications how we can improve this information |