CSCS1730 UNIX/Linux Fundamentals

PROJECT: THE PUZZLEBOX (pbx0)

OBJECTIVE

Use your observational skills, ability to track and utilize details, problem solving abilities, and investigative prowess to unravel the puzzle box, which will attempt to throw obstructions in your path to deter you from success.

PROCESS

Do note, the productive way to go about this project involves taking the following steps:

  • starting early
  • reading the project page
  • asking questions regarding things you do not know, are not clear on, or are confused about
  • experimenting and exploring the your files, using tools familiar and new to try and unravel the puzzle.

If you start too late, and do not ask questions, and do not have enough time and don't know what is going on, you are not doing the project correctly.

TASK

You are to unravel the puzzle, getting to the instructions inside. Be wary of deceptions and obstacles trying to throw you off track.

To start off, there is a starter puzzle, ascii.512 that must be solved and acted upon first before you can get to your actual puzzle.

Once you work through the starter puzzle, you can proceed to your actual puzzlebox puzzle.

You are seeking the creation of two files, that you will submit:

  • results - the final instructions correctly unscrambled
  • pbx0steps - a list of the steps taken to accomplish the core task

NO GRABIT

As part of this activity is to test your ability to navigate around the filesystem and manipulate files on your own, there is no grabit configured for this project.

Navigate to the UNIX PUBLIC DIRECTORY yourself and manually copy your project files back into your repository.

TOOLBOX

In addition to tools you may already be familiar with from previous projects, you may also want to check out:

  • ar(1)
  • basenc(1)
  • cpio(1)
  • file(1)
  • lzma(1)
  • sort(1)
  • tr(1)

You are NOT to make use of, as part of your puzzle solution, any steps that involve interactive tools (such as nano), nor utilize sed, ed, or awk in your solutions.

NOTE

While you may need to install any needed packages on your pi to perform tasks related to this project, do keep in mind that for the actual solving of the puzzlebox:

  • you do NOT need to call upon sudo / root access in any way (solutions containing such steps will be considered to not be following the spirit of the project)
  • all actionable steps taken are to be done using non-interactive tools. There is zero need to make use of an interactive tool like nano. Solutions that make central use of interactive tools will be considered to not be following the spirit of the project.

While you as a user investigating things may end up using various tools to see what is going on, your resultant steps file is to only be representative of the core automated/non-interactive task the computer is performing (with value-added comments giving pertinent clued-in information as a result of your observations and investigations).

BACKGROUND

The type of a file can be extremely important when determining what application is used to open it.

As discussed on a few occasions already, conventional UNIX filesystems do not have any special treatment for file extensions. It is therefore said that UNIX ignores them; that means we can use more characters as valid symbols in filenames.

On systems that have engrained support for filename extensions (say, a DOT followed by 3 characters), that actually limits our ability to name files.

In UNIX, it is not uncommon to find files named archive.tar.gz, and since UNIX ignores extensions, this is a perfectly legitimate filename… and it is also quite informative (we are clued in on potential actions taken on this file, as well as what tools to make use of).

Most of the time a file is named correctly, for instance a file ending in .c can be assumed to be the source code of a C program, or .gz to be a gzipped file. These are not extensions, they are traditional naming conventions (just as we tend to call those petrol-powered metal boxes with 4 rubberized wheels a "car"… we CAN call it something else, but that may cause bumps in otherwise smooth communications).

With the dircolors(1) utility colorizing specific files, it is further assuming that files which end in .mpg are really MPEG files and colors them accordingly, and the same for .zip files, etc.

In other operating systems, a file's extension determines what application is used to open the particular file. If a file that ends in .mp3 is really a .png file, the default MP3 player is going to have difficulties.

Sometimes files are not always named properly, either due to a web browser mangling an extension or for whatever reason. When a file is more than meets the eye, we must rely on the various tools available to use to determine what in fact it is.

THE FILE UTILITY

In UNIX there is a nifty little utility called file that attempts to determine the actual type of a file by checking a series of properties. From the file(1) man page:

There are three sets of tests, performed in this order:

  • filesystem tests,
  • magic number tests,
  • and language tests.

The first test that succeeds causes the file type to be printed.

A filesystem test checks to see if the file is non-ordinary (such as a socket, symbolic link, or other special file).

The magic number test is a check of files conforming to existing fixed formats, typically by examining the file at the binary level. If using a hex editor, you will find that .gz files should always start with the same sequence of hexadecimal values.

Finally, if the file is determined to be a simple ASCII file, it will attempt to analyze whether or not it conforms to some language (ie C source code vs. an HTML document).

Note that file is not always perfect, but for most cases will get the job done. Try checking files in your home directory or elsewhere on the system and see the results. Should file not be able to give you a clear answer, you must still result to your other skills and mental faculties– test and debug the situation.

Refer to the file(1) manual page or your references for more information.

PROJECT

For this project, files are located in the pbx0/ subdirectory of the UNIX Public Directory.

There is a directory by the name of your user, which contains a file. Please copy this into some custom project folder in your home directory.

Using your debugging, observation, and analytical skills, unravel the puzzle until you have an ordered, plain text, english readable file (called results) with directions on how to submit the project.

In many puzzles, one's visual comprehension of the scenario plays a vital role. Where something doesn't necessarily meet the eye, or is not behaving as you would expect- just try reading any messages or output. Sometimes the clues are right under your nose.

As is the case many investigations, just observing how things behave can lead to recognition of an object's true state, or the recognition of a pattern, which can be used to solve the task at hand.

VERIFICATION

The results file, when correctly unscrambled and assembled, can be verified by generating its md5sum hash.

This hash should match the hash stored inside the MANIFEST file located in the project directory (in the public directory).

FILECHK

You can also use the filechk tool to verify the accuracy of your results:

lab46:~/src/SEMESTER/unix/pbx0$ filechk unix pbx0

SUBMISSION

In addition to the files produced during the completion of this project, I would also like for you to create a detailed step-by-step text file called pbx0steps which includes the valid command-lines that will document for me the steps you took from project commencement through completion. You will submit this file at the end in accordance with the instructions.

To successfully complete this project, you must follow the directions located in a readable file at the conclusion of this project. Until you encounter it, you are not yet finished (hint).

You should get some sort of confirmation indicating successful submission (actually, two) if all went according to plan. If not, check for typos and or locational mismatches.

SUBMIT TOOL USAGE

Let's say you have completed work on the project, and are ready to submit, you would do the following:

lab46:~/src/SEMESTER/unix/pbx0$ submit unix pbx0 file1 file2 file3 ... fileN

A less abstract instantiation of the above (to help you transition):

lab46:~/src/SEMESTER/unix/pbx0$ submit unix pbx0 results pbx0steps
Submitting unix project "pbx0":
    -> results(OK)
    -> pbx0steps(OK)

SUCCESSFULLY SUBMITTED

You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.

I'll be looking for the following:

RUBRIC

104:pbx0:final tally of results (104/104)
*:pbx0:submitted results file via submit tool [13/13]
*:pbx0:submitted pbx0steps file via submit tool [13/13]
*:pbx0:results md5sum matches project MANIFEST [13/13]
*:pbx0:results is correctly unscrambled and assembled [13/13]
*:pbx0:pbx0steps contains valid set of instructions [13/13]
*:pbx0:pbx0steps any commentary after hash mark [13/13]
*:pbx0:emailed results via instructions [13/13]
*:pbx0:matching subject line as per instructions [13/13]

Additionally:

  • Solutions not abiding by spirit of project will be subject to a 50% overall deduction
  • Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
  • Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction
  • Solutions not organized and easy to read are subject to a 25% overall deduction