Backdoor Primer

Introduction

Lots of good work has been done already with the crypto department backdoor. However, there may still be some people who are somewhat confused by how it works. There are also certainly further things we need to do with it, and so this guide is an attempt to get more people to the point where they can use it and, hopefully, break it too. The information presented is as accurate as possible at the time of writing, but may well be subject to change.

So, what is it? The backdoor is a "basic" interface that lets you connect to the crypto departments files. By entering different "configurations" (i.e. combinations of commands) into the 5-by-5 grid, you can navigate around these files and gain access to some of them.

So how does it work then? Well, there are 2 main things (for now - see "Further Research" below) to understand in order to use it properly. Firstly, how you place commands in the grid to get them to run properly, in the order you want. And secondly, how files are navigated to using the commands available.

Placing Commands

First up, a quick convention. In this document, I'll refer to grid squares in an X, Y fashion, starting in the top-left corner. Hence, the top-left corner is (1,1), the top-right corner is (5,1) and the bottom-left corner is (1,5).

Commands are processed one by one, moving through the grid as they do so, starting with the command highest up in the left-most column - i.e. a command in the top-left corner will be run before anything else, but if there isn't one there, the command in (1,2) will go first - moving downwards until a command is found. However, the path taken through the grid after that depends on what commands are used - each command goes in a different direction. For instance, usually a SWITCH command will then move in a south-east direction.

However, there are times when a command cannot move in the direction it would "like" to - either because it would go off the edge of the grid, or because it would go onto a square that has already been "processed", i.e. moved through. (Note, however, that this is not always the case, and further research needs to be done into this - see below.) When a command cannot go in a particular direction, it will usually try a second direction. If that one can't be moved to (for the same reasons) then a third, and a fourth, and so on until either it finds a new command to move to, or it runs out of directions to try. Note that not all commands will attempt to move in all 8 directions - e.g. some only move south-east, or fail.

Handy Tip: You can find out which grid space is the next in the sequence by using the RUN command. Normally, you can put RUN anywhere in the grid and if the grid is incomplete, it will give you an "Invalid Command Grid" error. However, this error changes if you place the RUN command in the square that's next in the path. For example, placing a MOUNT command (which moves south-east) in the top-left corner and then placing RUN at (2,2) changes the error to "No area has been accessed".

As far as I've been able to work out, the list of directions that each command tries to move to, in order, is roughly as follows (with some unconfirmed directions in brackets):

MOUNT:  SE  (this may be all - certainly doesn't go NW/N/NE)
ZONE:   W, ?, ... (Always tries to W first, but sometimes then tries N, and sometimes tries S.)
SWITCH: SE, ...
ROTATE: N, NE, E, SE, S
COPY:   S, ...
FLUSH:  S, ...
PWRITE: E, S, ...
POPEN:  E, S, ...
PREAD:  W, S, ...
CACHE:  No direction, execution ends
END:    E, ...

Where you see "...", things are very unconfirmed. However, the initial directions are enough to put together most combos that you want and should suffice to start with.

To run the commands in your grid, either drop the RUN command anywhere into the grid, or if there's one in there already, simply click on it.

Example:

If the grid looks like this...

  -- -- -- -- --
  MO CA -- -- --
  RO ZO -- -- --
  -- -- -- RU --
  -- -- -- -- --

...then the order in which things happen, and the direction each command moves in, is...

  Mount (-se-) Zone (-w-) Rotate (-can't go n, so goes ne-) Cache

N.B. The position of RUN is purely arbitrary. You should receive the message about "the Master", after which you can press the "Reboot Command Interface" button to reset everything. Also note that you can't see what commands you had in the grid once a file is output, so it's a good idea to remember/note it down somehow.

File Navigation

So now you can put commands together, how do you get to files? What's all this talk of "3 ZONEs" and "4 ROTATEs"?

The filesystem you're accessing via the interface is actually 3-dimensional in a sense. This means you can navigate to files by moving along 1 of these 3 axes. If you reach the end of an axis, you loop round to the start of it. The best way of picturing this, I find, is to look at the File Mapping tables, but I'll offer a different analogy below.

The 3 main commands used to navigate to a file are ZONE, SWITCH and ROTATE. You must use at least 1 ZONE command and 1 ROTATE command. Furthermore, in order to access files, you also need to use a MOUNT command somewhere. The order is mostly not important (e.g. ZONE-MOUNT is the same as MOUNT-ZONE), although see the notes below for more speculation on this.

If you're not comfortable with imagining things in 3D, then you can think of it like a series of bookcases. You have 4 bookcases, and you can move on to the next one in the sequence using a ZONE command. Each of these bookcases has 5 shelves, and you can move down (not up) to the next shelf using a SWITCH command - when you hit the floor, you just start again at the top bookshelf. Finally, each shelf has a number of books on it (which are the files), and you can move along (to the right, not the left) to the next book by using the ROTATE command - when you run out of books on a shelf, you just jump back to the beginning of the shelf. Also, when you switch to a new bookcase, you keep the position (in terms of shelf and book) you were in at the last one.

Lastly, it seems that we don't have "direct" access to files. But in order to show the file that we're currently on, you can use the CACHE command. This must be the last command in the sequence and, if the file is readable, it will be displayed when the commands are run. (If it's not readable, you'll see an error.)

Using POPEN and PREAD

We have discovered some extra files in the file system by using POPEN and PREAD before doing a CACHE command. The exact effects of these commands aren't clear (although they may be similar to functions of the same name in Linux, which invoke a new command shell...). However, the Klebold Plates file was found using this method.

Further research is being done in this area, but all help is gratefully welcomed ;)

Notes

I'm speculating that if you do a ROTATE before a MOUNT and a ZONE, then the system doesn't know how many files there are in the current "shelf", and so may not be able to move to the next file. Hence, Mount-Zone-Rotate-Rotate may be different to Rotate-Mount-Zone-Rotate. This is currently unconfirmed, but possibly worth noting/remembering.

Using END

If you try the configuration "END END END -- --" (on any line, with RUN anywhere) then you'll get the error message "All login sessions ended. File server inactive." It seems that, on the initial start up of the interface, you have been logged in through a series of 3 servers or accounts, each "inside" the previous one. By doing 3 ENDs, you log out of all of them. But by doing only 1 or 2, you get a different filesystem, or set of bookcases.

So far, no files have been found after doing only 1 END command. However, the audio files and some text files have been found after logging out twice - i.e. doing 2 ENDs. The files available change periodically - sometimes 2 at a time are available (using 2 ROTATEs), sometimes only 1. A list of these files and their access times is currently being compiled.

Other Commands

We're still not sure what these really do:

• COPY
• FLUSH
• PWRITE

Breaking the System

Caine has identified a couple of bugs in the system, although we only know what one of them is:

Infinite Loops

It is possible to cause the path of commands to loop back on itself, entering into a loop that never finishes. When this happens, the interface starts going all glitchy, and some random data - usually log files of conversation excerpts - is displayed.

At present, we're not sure why some combinations of commands loop, while others don't - this may or may not be useful in working out the other way Caine found of breaking the system, but is being documented a little bit anyway. It seems that some commands - or combinations of commands - don't bother to check if the next square in the path has already been processed or not.

Further Research

So what needs to be done now?

• As mentioned above, Caine broke the system a second time to produce something that looks like it's from a network configuration file. There must be another way to make the system crash.
• There are single characters that have been extracted by starting with one END command. How this works and if there are any more characters and if the characters fit together into something useful are all unanswered questions.
• Determining when the changing files appear is a nice-to-have, but all (I think) are documented on the Backdoor page, and so this isn't a priority.
• Working out what the other commands do may help to manipulate the system - e.g. if we can use PWRITE to change things...

Any questions, use the Talk page for this article, try the forum, or come ask in #syzygy on IRC.

-- Scribe