Batch vs Interactive

by StankDawg

Computer systems use two basic kinds of processing: batch and interactive.  Each type has its own advantages and disadvantages, and each type can be used in different ways.  By the end of this analysis, you should have a better understand of these differences and a better understanding of how they are used.

Interactive processing is what most of us are used to.  It is exactly what it sounds like, where you are "interacting" with the computer.  When you play a game of Quake2, you are running the Quake program (or job) interactively.  Typing an article in Microsoft Word, as I am doing right now, is also interactive processing.  All of the processing done by the program is done immediately, and the results are seen instantly in front of you.  Most users who work in a PC environment are almost always working interactively.

Batch processing is a little different from interactive processing.  The programs (or jobs) are not performed immediately, but instead, put onto a queue to execute later.  The best example of this in a PC environment is when you submit something to print.  You computer does not begin to print immediately (no matter how fast it is).  Instead, it gets submitted to a queue (monitored by print manager).  If it is the first or only item on the queue, then it will be printed immediately, but it actually is a batch job.

Yes, understanding that may be simple.  It is probably just review for most readers.  The question is how to use each one effectively.  It may seem insignificant, but the using the proper type of processing may keep you from being caught on a system that you are not supposed to be on.  Of course, where we "should' and "shouldn't" be is a relative concept.

All system have a way of monitoring jobs.  On Windows 95/98/NT systems, it is the Task Manager.  On the AS/400, it is the WRKACTJOB screen.  An ES/9000 may use an Interactive Output Facility (IOF) to monitor jobs.  Every system has some way of doing this.  In heavy metal systems, there are many reasons for monitoring its jobs.  Usually, each type of job has its own resource pool (which is sometimes broken up again within each type of job) and at certain times of the day, and certain days of the year, they may be dramatically different.  Their use, capacity, and saturation fluctuate constantly.

Why is this important?  It is important because since every system is different, you must know how the target system handles jobs in order to avoid detection.  A system that belongs to a phone company, for example, will more than likely have an enormous amount of interactive jobs, relating to live phone calls.  A system that has a large amount of dial-in users would also have a high volume of interactive jobs.  You should pay close attention to the locations where these jobs run, and make sure that your interactive job looks similar to the others.  Try to match the naming conventions of the other users.  You want your job to be indistinguishable from the others.  If you do that, you can work for hours without ever being discovered.

Conversely, you want to avoid maintaining interactive jobs on systems that are not set up for that purpose.  Universities and businesses usually fit into that description.  They utilize their systems mostly for maintaining and processing internal jobs and information.  An outside user would stick out like a sore thumb on these systems.  If this is the case, you want to connect for short periods of time only.  Find what you want and take it offline to evaluate it.  Plan your sessions to be quick and innocent looking, and if you must do something that is CPU intensive (such as a search), try to submit it interactively.  Use standard naming conventions, and make the job fit in with the others.  Also, there is another danger here that you must be very careful of.  Your chances of having a job halt (or crash) are much greater.  Computer operators and/or system administrators constantly monitor most heavy metal systems, and when a job halts, they begin to investigate.  If a job halts on you, take care of it immediately!  Kill (or cancel) the job before anyone notices it, or you will give yourself away.

Finally, I must mention that these two extreme examples are not always as cut and dry in the real world.  What I mean is that in the real world, a system performs many different functions, and mixes both types of processing.  During the day, a system may be running mostly interactive jobs, while at night, daily batch procedures may take over the system.  You have to pay attention to what the trends for each individual system are, and use your judgment on how to take advantage of these trends.  A sloppy hacker will always get caught.

I will leave you with a few last tips to keep in mind.  If you pay attention, and study your environment, you can usually avoid detection.

On interactive heavy systems, one trend to look for is time zone differences.  West Coast to East Coast might leave you hanging on a system where everyone has already signed off and gone home at 5:00 while it still may be 2:00 where you are.

Some things you may want to do are exclusive to a certain type of processing (printing).

Don't use too much CPU time and don't boost job priority.  It makes your job look suspicious and draws attention to it.

When submitting batch jobs, log off to avoid being detected on your interactive job.  There is no point in creating two targets for you to be discovered.

A Lot of things can be run either interactively or via batch.  Just because one is standard, or the default, use your judgment to decide which is best for your goals.  Think outside the lines.

Be careful crossing state/country lines.  Laws fluctuate greatly from location to location.  Make sure that when you cross the line into "dangerous" hacking, you know the consequences.

Return to $2600 Index