Thursday 15 December 2011

Get Out Of jail Free

Okay, all of that is fine if you've broken in by discovering someone's username and password but what if the only access you've found to a machine is that of a command account or information setup? Then you have to see what can be done to break out of this jail of a program and get down to the level of the operating
system. Probably this will be difficult to do. It will be less so if you've done any serious programming in the past.

As a programmer, you know what kind of bugs and errors crop up, and what kinds of things to look for to make them appear. If you're stuck in an account that runs an info program, let's say, you will want to try every unconventional, unexpected thing you can think of, in the hopes that you'll find something the programmer
didn't think to guard against. Then hopefully you'll get an error in . essage and crash out to the OS prompt.

Things to try:
Give bad, inappropriate, unrequested, or extremely long input to prompts, especially alphabetic answers to numeric questions. Or when asked to supply a number, that will be analyzed by a function, try an incredibly small or large one. Try responding with break signals, either Control-Z, Control-C, or possibly Control-
P. Try executing "Find" commands that will search out of bounds of available resources, or that will look beyond the alphabet. See if it's possible to set up programs for nonexistent hardware or memory capabilities.

If there is any sort of text editing facility, such as a program to send mail to sysops, do what you can to compose a batch file, and see if it's possible to send your message as a command that must be executed. Also with text editors, try to compose excessively long letters. If the editor has special text revision functions,
write up a huge paragraph then cut and paste a copy underneath it. Then cut and paste those two paragraphs underneath, etc., until the program either crashes or doesn't allow you to continue. If the latter, see what happens when you try saving or sending the whole mess.

You may be in a program that is made to look like a simple operating system or control program, essentially a menu with the list of options either unavailable, or callable with a HELP command. Thus, you're given a prompt and asked to enter a command. Some application commands allow appending to them the name of a file on which you intend to work. For instance, to edit STORY.DOC with a word processor, you might type the cornmand "WORD PROC STORY.DOC,` to run the word processor with STORY.DOC already loaded in it. On an on-line system, try to crash a program that allows such execution by giving it too much data, ("WORDPROC STORY.DOC FILEONE FILETWO...") or by giving it inappropriate data. Some
examples:

WORD PROC WORD PROC WORD - PROC \directoryname WORD - PROC
nonexistent-filename
WORD-PROC /etc/date [or other command]

The "inappropriate data" tactic has been used successfully in the recent past.

Another bug that's been exploited is excess command stacking. Command stacking is the placing of multiple commands on one line. Commands may be separated with spaces, semicolons, slashes, or a number of other punctuation symbols. The parser which interprets the stacked commands may break down if too many
commands are given it. The line editor may not allow you to enter so many lines that this occurs, but through programming tricks you can probably get an unwieldy stack of commands sent as though from the keyboard.

If there is a language or compiler available, then it should be possible to POKE some values into places that would be better left unprodded. Alternatively, you might find yourself able to compile code into specific areas of memory, overwriting the code which is impeding your progress. Or your code might cause the program
to jump to a new location, where further instructions can be carried out.

Finally, see if you can load a program into a mail writer or other editor, or into a superzap program, and alter it so that when it rum, it will crash.

Bugs in software are most likely to occur if the software in question:
• Is new (i.e., version one or thereabouts, or being Beta tested).
• Was hastily slapped together to make some fast money or to comply with the advertisements or demands.
• Has remained the same for years despite hardware or other changes.
• Is being renovated.
• Is not commercially available.

When you're hopping around on the networks you encounter, stop and read the notes that accompany new versions of old software. These will generally list, not just the improvements made, but sometimes the reasons for the improvements (i.e., if there was an exploitable bug in the earlier version). By the time you read the upgrade note, most sites will probably have already upgraded to the new version, but given the tremendous number of computers running today, more than a few won't have heard that a new version of their software has been released.