Checkpoint Commander - User Guide

Devices and Navigation

Author: Will Dickson, CCS
Editor: John Dickson, CCS
Version: 1.4.0
Date: 06 August 2007

Devices in General

In Checkpoint Commander parlance a device is a container for a collection of files. Checkpoint Commander knows about several different kinds of device, and treats them all in the same way (give or take).

Disk devices

The files on local disks are stored in one or more disk devices. Unix has a unified root filesystem which appears as a single disk device; Windows has a system of drive letters, each of which appears as a separate disk device. Disk devices are opened automatically as soon as Checkpoint Commander starts, and cannot be closed. On Windows, some drive letters may represent either removable-media disk drives, or Windows (SMB) network shares. These come and go automatically from the Checkpoint Commander device list, as the drive becomes accessible or inaccessible.

Checkpoint Commander archives

Archive devices

A Checkpoint Commander archive is a special (but common) kind of Checkpoint persistent object store. It's a kind of filesystem or "disk drive" which sits inside an ordinary disk file, is only accessible via Checkpoint and Checkpoint Commander, and can be encrypted. One of Checkpoint Commander's major raisons d'etre is to allow you to organise your files, and transfer them into archives for safekeeping. Unlike zips or many other archiving formats, Checkpoint Commander archives are also fully random-access.

Archive cryptography

Checkpoint Commander uses the 256-bit CBC (Cipher Block Chaining) AES algorithm [109] to encrypt archives, with HMAC-SHA1 [105], [110] to verify that the archive has not been tampered with. There are no known weaknesses in these algorithms. There are no "back doors" in Checkpoint Commander: if you forget your password, then you lose your data. AES is fast, so on a reasonably modern PC using encryption is unlikely to feel noticeably slower than not. The principal weakness is likely to be your password - passwords which humans can remember are often small enough or predictable enough that a "dictionary attack" method can discover them. Checkpoint Commander Plus provides a solution to this problem.

We would like to record the historical contribution made by the Blowfish cipher algorithm [103], and the RIPEMD-160 hash function [106]. These were used during the development of Checkpoint 4 and Checkpoint 5: without them, it's highly unlikely that Checkpoint would exist today in its present form.

[NOTE] Recent cryptanalytic work has found collisions in "raw" SHA-1; this is a concern. However, SHA-1 is still considered to be secure when used in the HMAC construction, and its successor hashes are a lot slower. We continue to monitor the situation, but this remains the best tradeoff today.

Filenames in Archives

Checkpoint Commander archives are very tolerant about filenames - you can use pretty much any character you please. However, some native filesystems are much less tolerant.

The troublemakers vary depending on your OS, and as the whole point of writing Checkpoint and Checkpoint Commander in Java is to make the software platform independent, it's better not to wreck the portability of your data by using non-portable filenames in your archives. For maximum portability, steer clear of the following:

  • backslash (except on Windows native filesystems such as NTFS or FAT, obviously)
  • forward slash (on systems which don't use it as a separator)
  • colon
  • asterisk
  • query
  • double quote
  • angle brackets
  • vertical pipe

If you use any of the above characters in an archive filename, and copy or move the file onto a native filesystem, Checkpoint Commander will "escape" the character so that it doesn't cause problems. This also happens if you attempt to open the file with either a helper app or the CPC browser interface (see Plugins and helper applications).

Archives over networks: Beware!

Many systems support some kind of "network" file system. With these, you can access storage on another host, over the network, as though it was storage on your local host. For example, Windows has the "Map network drive" function in Explorer; Windows (SMB) networking shares appear as though they were local drive letters.

Provided you avoid the filenaming problems described above, Checkpoint Commander can be used as a simple, but very powerful tool for backing up data across such a network. However, if you have a Checkpoint Commander archive which is shared in this way - whether it's in local shared space on your host, or you're accessing it over a share from some other host - it is vital that only one instance of Checkpoint Commander has the archive open at any given time. Failure to observe this may cause archive corruption and data loss. This is because our locking mechanism (which allows multiple programs to access an archive safely at the same time) does not work over a network.

You should also be aware of the security issues present with this type of working - network traffic is not encrypted, and can be intercepted and copied by anybody on your LAN. Wireless LANs are even worse: if the WLAN is not secured properly, a cracker in a car in the street outside your office can do the same. The most commonly deployed WLAN confidentiality system is WEP, which is insecure. The newer WPA system is a lot better, however.

All that said, we do have to admit that this method of working can be extremely convenient. Therefore, while this is not recommended, it can be used safely if appropriate precautions are taken. If you indulge in this mode of operation, you accept responsibility for the consequences.

[NOTE] Our separate product, Catcher, will provide a fully secure, safe alternative to this mode of operation. Coming soon.

JAR / ZIP devices

As a convenience, Checkpoint Commander can open Zip-compressed archive files, provided they are not encrypted with a password. Java ARchive (JAR) files actually conform to this format, as do a number of next-generation formats (for example, the SXx formats used by StarOffice / OpenOffice 6, or the .zargo format used by the Pseidon UML tool). However, since this format does not support random-access - to delete or update one file from the zip, you must re-write the entire thing - these devices are read-only. Migrate to a Checkpoint Commander archive for a superior replacement!

Result-set devices

Result sets are a special kind of device. Rather than containing files, they contain references to files which are stored on other devices. They get a page of their own; for more information, see Result sets and XSPF.


Navigating around your files

To navigate through your files, double-click on a device-list entry in one of the panels to open that device. Double-click on subfolder entries as required to get where you want. You can tell subfolders apart from files because they all either end in a backslash (currently, Win9x / WinNT disk devices only) or a forward slash (everything else), and come before ordinary files in the folder listing. The first entry in any folder listing is ../ or ..\; this moves you up to the parent folder.

Checkpoint Commander remembers the current folder for each device; if you haven't been there before in this session, this is the root (topmost / outermost) folder of the device. If you have a device open in a certain subfolder in one panel, and you then open the same device in the other panel, Checkpoint Commander will put you straight into that same folder.

As an alternative, you can use the Change folder option on the Do> menu to type in folder paths directly; this can be easier. To go straight to the device list, type $ on its own. Otherwise, this should work in exactly same way as it does on a command-line ("shell" / "DOS box" / etc. depending on your background and / or platform). To be a little more specific:

  • If you type an absolute path, including a device specifier, Checkpoint Commander will go there. The device specifier for a disk device is the normal prefix you use on a command line: for example, d: for a Windows drive. The device specifier for any other device is whatever appears on the device list, without the "decoration" - curly brackets or what-have-you - which go around it. Example: d:\subfolder1\subfolder2
  • Otherwise, if you type a device specifier on its own, Checkpoint Commander will go to the current folder of the device. This isn't possible for the unix disk filesystem, since the "device specifier" is the same as the absolute path of the root folder. Example: d:
  • Otherwise, if you type a device specifier followed by some relative path, Checkpoint Commander will go to that path relative to the current folder of that device. Again, this isn't possible for for the unix disk filesystem. Example: d:folder2.
  • Otherwise, the path is treated as being relative to the current folder on this device.

The use of .. to go up a folder in the usual way is OK. However, a relative path specified in this way cannot traverse through the device list.

If you use the change-folder function to move from one device to another, or straight to the device list, the current-folder setting on the device you move from is not affected.

Accessing files

Once you've found your file, Checkpoint Commander provides two mechanisms which allow you to open it. This has a chapter to itself, Plug-ins and helper applications.

If a filename is so long that it won't all fit in the panel width, or a path is so long that it won't fit into the panel heading (without being truncated), then you can see the full name or path by hovering the mouse pointer over the name for a second or so. The full name or path will appear in a "tool-tip".

Selecting files

  • Ordinary (left) clicking on a file in a panel will select the entry you click, and unselect anything else. However, in various circumstances (see below) you'll need to select multiple files in a panel. To do this, use Ctrl+click to toggle (unselected-to-selected and vice-versa) individual files or subfolders. To select a range, using the most recent selection as an "anchor", move to the other end of the range from the anchor, and Shift+click; Shift+drag doesn't work. This won't unselect.
  • As an alternative to using the mouse, you can use the up and down arrows to select, with shift to select a range; there's no equivalent to Ctrl+click sparse select.
  • When you select a file which is a GIF, PNG or JPEG image, Checkpoint Commander will attempt to preview it; the preview will animate animated GIFs. There are some obscure JPEG variants which the previewer can't manage: if you run into one of these, use a dedicated image-processing app to convert it to a more mainstream one.

    [NOTE] The colours in PNGs sometimes go awry for some reason (Win32, Java 1.4.1). This appears to be a problem with Java; we have not had reports in Java 5, so hopefully it's now been fixed. There are also thoughts that it may be a problem with PNGs created with older versions of software.

  • Use Ctrl+A to select everything.
  • You can't make multiple selections in the device list.
  • To give the focus to a panel without upsetting its selection state, either click on the panel heading, or use Alt+left-arrow / Alt+right-arrow on the keyboard.
  • When making selections for a recursive operation (see below), the parent-folder .. entry is ignored by the recursion, even if selected. This is a safety feature; a little thought should convince you that any other behaviour could lead to some really catastrophic accidents!

Opening new devices

To open a Checkpoint Commander archive or a JAR / ZIP file, use the special device-opener "plug-in" for the archive or JAR / ZIP file. This is covered under Plug-ins and helper applications.

You can use the "Do" menu to open an empty result set (which you can then customise; see below).

[NOTE] While JARs and ZIPs have conventional extensions, and Checkpoint Commander does use these, it does not enforce them - you can specify any file, and Checkpoint Commander will do its best to open it as whatever you say. Clearly this won't work if the file isn't what you said.


After you've selected your files (see "selecting files" above), you can do things to them.

This only applies to result sets, and deletes the reference without affecting the underlying file.
Copies the selection from the panel with the focus (this panel has a mauve panel heading) to the other.
Copies the selection as before, but then wipes the source file.
Wipes the source file. Normally, files are only deleted: this just puts a "this space to rent" sign on the file's filesystem entry, but does not touch the contents. These can then be recovered with forensic or even ordinary file-recovery software. Wipe overwrites the content with selectable thoroughness. See below.

More about wiping

Checkpoint Commander offers several degrees of thoroughness for wiping disk files. These all trade security for execution speed; the securest mode is the slowest. Where time is a factor, it may be better to settle for a less secure mode, to ensure that all your data is wiped at least somewhat in the time available.

Some kinds of media are better than others. A single-pass wipe on a modern, high-capacity hard drive (e.g. >= 40GB) offers considerably greater protection than the same wipe on older, low-density media: modern hard drives have to do some fairly advanced signal processing just to get data out ordinarily. In particular, 3.5" floppy disks are horrible (5.25" are even worse, but happily now confined largely to museums), and your best bet may well be to rip the (round) magnetic disc out of its (oblong) plastic container and incinerate the thing. Accelerant: the tool of choice for the discerning security consultant!

Checkpoint Commander offers the following wiping modes.

Delete only
This just hangs out the this-space-to-rent sign as described above, and leaves the data intact.
A single wipe with pseudorandom numbers. It's quick but not brilliantly secure: good forensic software may be able to recover the data.
A three-pass schedule, as specified by the US government for removal of sensitive but unclassified material: zeroes, followed by ones, followed by pseudorandom numbers. This offers a reasonable compromise between speed and security for general-purpose use. However, it might be argued that the body in question would not recommend a standard that they themselves could not defeat. We conjecture that forensic methods based on dismantling the hard disk and using a magnetic force microscope on it might recover, or partially recover, material wiped with this schedule. Your call.
The FIPS schedule plus six more passes with pseudorandom numbers. This is probably the best choice for a high-security wipe on a modern hard disk.
A painfully slow wiping schedule [102] designed to defeat magnetic force microscopy, even on very old, low-density media which make these attacks easier. On such media, (especially floppy disks), seriously consider incinerating the disk instead. On modern, high-capacity hard disks (say >=40GB) this schedule will not do much for you that the much quicker Schneier schedule won't, and is not recommended.

We should caution, however, that since Checkpoint Commander is a cross-platform product, there are some potentially serious "side-channel" leaks which it can't protect against. In particular:


Almost all modern machines have a "virtual memory" system. When the system doesn't have enough RAM for all of the needs of all of the processes it's running (the author's Windows 2000 workstation had upwards of 15 processes running even when just sitting there, apparently doing nothing), it finds processes that aren't doing anything just then, and copies some of the memory allocated to those processes onto hard disk. This gives it more RAM to allocate to processes that need it. This is called "swapping". When a process whose memory has been "swapped out" in this way needs it back, the system finds another process which isn't busy and swaps that out, and so on. When a system is heavily loaded, it spends most of its time swapping and everything slows to a crawl. This behaviour is called "thrashing".

The problem for our purposes is that if the piece of memory containing your data gets swapped out, a copy of it may remain, unencrypted, in the "swap space" on the hard disk. To minimise the probability of this happening, avoid working on a heavily loaded machine: shut down any unnecessary applications and system-tray utilities (Windows), and make sure your system has copious amounts of memory. We recommend at least 256MB for present-day standard systems (512MB for WindowsXP). It makes a big difference to performance as well.

Remnants in RAM
If your host doesn't get switched off from one year to the next (as is increasingly common even for PC's), then your data may stay in memory until that bit of memory gets used for something else. This can be fixed by power-cycling the machine (leave it off for 10 seconds or so to be sure).
RAM burn-in
If the data stays in the same place in memory for more than a few minutes, the pattern of electric fields that represent it causes changes in the RAM cells' dielectric that reflect the pattern. This may allow the pattern to be read back by putting the memory module into a special test configuration using specialist hardware. If you're really this worried, power-cycle your machine as soon as you've finished working with sensitive data.
Metadata, and the filename in particular
Checkpoint Commander tries to expunge this, but might be foiled by the underlying filesystem.
Many modern filesystems feature a journalling mechanism which protects the filesystem from the effects of improper shutdowns, where the in-memory disk caches are not synchronised correctly with data actually on the disk. Non-journalled filesystems can suffer from filesystem corruption in these situations, potentially causing data loss. Unfortunately, a side-effect of journalling can be that the file data moves around on the disk; thus the wiping data doesn't get written to where it's needed. If you're worried about this, consider a non-journalled filesystem type such as FAT. (Of course, now you have to worry about hard system crashes and power failures instead. Such is life.) [NOTE: On Linux, the ext3 filesystem, running in its default journalling mode ("data=ordered"), is believed to be friendly to data wiping. For this, and various other reasons, we recommend this filesystem and this mode of operation for general-purpose use.]

The paper by Gutmann [102] has more information on all of these issues.

To be honest, the only two of these you probably need to be concerned about are swapping and journalling effects. If in doubt, buy some more RAM! Alternatively, a best-of-breed, platform-specific sanitising package may to be able to do a better job; however, there's a fair amount of weak software out there. Sanitisation is like cryptography - it's extremely difficult to test.

Ultimately, you might need to consider the tradeoff between the cost of destroying (and hence, having to replace and repopulate) the physical media in question, and whatever consequences might result from unauthorised disclosure or recovery of whatever data which was on the disk.


When one of the files selected for one of the operations described above is actually a subfolder, that subfolder and its contents are processed recursively. In other words, the operation is performed on all files within the subfolder, and then every subfolder of that folder is processed in the same way, and so on.

It's possible to modify this behaviour by using the smart recursion function, from the Options menu. From this dialog, you can select a series of regular expressions (see under "opening result sets with the search function", above), which are used to select the files on which the operations should be performed. Excluder expressions ("but not files matching...") take precedence over includer expressions. If no expressions are supplied in either category, all files are processed.

Smart recursion

Smart recursion

If the "Apply to folders as well" box is checked, the recursion only descends into subfolders whose names pass the same set of filters which you've set up for files. Otherwise, the recursion descends through all subfolders.

[NOTE] For this purpose, subfolder names come with the "badge of rank" slash or backslash character on the end, as displayed in the panel.

When setting up a smart recursion, do remember that the filter set does not apply to the folder which is visible in the panel when you initiate the operation.

Authored in CXD using Checkpoint Information Engineering Workbench   Copyright © Caversham Computer Services Ltd.