NoWrite™ Design Notes
Bringing NoWrite to market has been a long, involved process. From the inception of this project considerable serious and insightful thinking has been used. The one overriding concept that was kept in mind was that the security and integrity of the Source drive was the most important aspect of the design. After all, any change in the Source drive can have serious consequences not only to your case but your reputation. Many design paths were considered, and many design paths were rejected. NoWrite uses Patented technology to protect the Source drive. Due to this, we are free to openly discuss some of the design elements.
NoWrite has a number of ways to protect the Source drive from inadvertent write attempts. The first, and possibly most important protection technique, is that NoWrite intercepts all communication from the Host computer intended for the Source drive, evaluates the commands, and passes only appropriate commands to the Source drive. There is no data path from the Host computer to the Source drive. To see why this is important, think for a moment about how any command is issued to a drive. Registers in the drive must be written by the host in order to pass it the parameters for the command. One of the registers is the command itself. When the command is received, the drive begins processing it.
If the command is one that will cause a change to any data object on the drive, a write blocker must prevent this command from being issued to the drive. There are a number of ways to do this, and we chose the one that offers the best protection; we do not allow the Source drive to see any commands from the Host. Ever, Period. Instead, NoWrite emulates a hard drive's interface electronics on the Host side and accepts all of the communications from the Host.
When all of the data for a command has been received, NoWrite has enough information to determine whether the command is one that it should process or one that the Source drive needs to process. Both the BIOS and Windows issue a lot of commands to the drive during the boot process. Other than some commands to read directory entries, many of the commands are not really necessary or simply redundant. These commands NoWrite can process on behalf of the drive. Obviously, a write command is not one that the Source drive should ever hear about.
A lot of effort went into reducing the number of commands that the Source drive sees. Basically, fewer changes on the data lines going to the Source drive are better for the drive. Since one of the goals of NoWrite is not only to protect the Source drive against changes, but also to protect the drive itself. With no commands, the drive happily spins along. If the signals going to the Source drive don't change, the Source drive has nothing to do and can't get itself into too much trouble. Every time the drive is required to do something, you increase the chance of the drive failing. With a possible exception of new drives purchased by the operator, you have no real knowledge of the history of the drives you review. They could have been abused or powered on 24 x 7 for years or just have a few operational hours. We consider every command that is sent to the drive to be important, and eliminate those commands that do not require the Source drive's attention.
Other commands that come in and are blocked by NoWrite include commands intended for the Slave drive. The way that Master and Slave work on an IDE drive is that all of the command registers are written simultaneously to both drives. The difference between a command for the Master and a command for the Slave is a single bit in one of the registers. Since NoWrite only passes along relevant commands to the Source drive, any commands intended for the Slave are rejected and the Source drive never hears about them. This is especially important when using Nowrite in the field for field previews. In the field you do not always work in optimum conditions.
If NoWrite determines that the command is a safe one to issue to the Source drive, NoWrite issues the command to the Source drive through its own IDE Host port. The results of the command are read by NoWrite and passed back to the Host computer. The Source drive does not communicate with the Host computer, only to NoWrite. This design leaves no direct path for the data to take from the Host computer to the Source drive. NoWrite determines what data should go between the two devices, if any. No glitch on the data lines or other anomalies from the host can cause a data change on the Source drive. “Glitches” can occur for any number of uncontrollable reasons. Line surges, host computer failures, or electromagnetic contamination from natural causes such as lightning can cause unforeseen line anomalies.
Our method of emulating the drive interface electronics to the Host and being a drive controller to the Source drive has another interesting side benefit. This process effectively resynchronizes the data. Had we taken another approach, there would be additional circuitry directly between the Host and Source drive. This circuitry would add delays in the critical path between the Host and the Source drive. This is another risk that we felt it best not to take.
In our method, for a command to the Source drive, NoWrite reads the results of the command into its own onboard memory. This includes commands that read sectors from the drive. We do not depend on the timing specification between a host controller and the drive to be loose enough to absorb additional time delays introduced by extra electronics. NoWrite presents correct and consistent timing to both the Source drive and the Host. By using this method, NoWrite helps maintain the validity of the data.
In order to keep the throughput high, NoWrite can read the next sector's data from the drive while the Host is reading the last sector from NoWrite. This is not to say that we value speed over Source drive safety. We consider speed to be a convenience, not a driving feature. This is one of the reasons that NoWrite only supports up to PIO Mode 4 and DMA Mode 2. (Let's call that combination Mode 4 for now.) The problem with going faster is that it makes the drive work harder and increases the number of commands that the drive must process. Remember, each command processed by a drive is one more chance for the drive to make an error. More importantly, each read command causes the drive heads to move, which increases the probability of a drive failure. This is not so much a problem with a new drive, but for a drive with unknown heritage, (most of the drives you process) we felt that it is best to be cautious.
Mode 4 is the fastest that a drive can go without going into the UDMA modes. The good thing about the UDMA modes is that they are fast. The bad thing is that they are prone to data failures with each transfer. The 80-conductor cable tries to stabilize the signals enough to get good data, but if you were to try running a benchmark with 5 different makes of 80 conductor IDE cables, you could easily get 5 dramatically different results. The reason is retries. Knowing that the UDMA modes were not nearly as stable as Mode 4, the designers added a feature to try and validate the integrity of the data. When an error is detected, the Host must try again to read the data. Each retry is another command to the Source drive.
Another Design feature used in NoWrite actually prevents the Host from issuing many commands, some of which could try and change data on the drive. This goes on the theory that the easiest command to Block is one that is never issued. To make this happen, NoWrite informs the host that certain commands are simply not supported. If the Host computer is paying attention, as most do, it will not try to issue an unsupported command. For those Hosts computers that are a little sloppier in their coding, NoWrite rejects the unwanted commands. Testing has shown that most Host computer systems work properly, and this technique reduces the data traffic. Due to this, NoWrite doesn't have to reject as many commands. This helps to maintain the stability of the Host computer system, as it doesn't have to contend with many rejected or failed commands.
A great deal of attention was paid in the design not only to the functional design and physical design of NoWrite, but to potential failure modes as well. As in, what happens if a component in NoWrite fails due to abuse or being “well traveled”. That is one of the advantages of not having a path for the data to take from the Host computer to the Source drive. There is no component that can fail in NoWrite that will leave a working data path between the two devices.
The main chip inside the NoWrite box is called an FPGA, or Field Programmable Gate Array. This is a fancy way of saying that it is a highly customizable chip. By loading it up with instructions, it becomes the circuit described by the instructions. Should this load process fail, no signals get in or out of the FPGA, so nothing can get to the drive.
The other big chip inside NoWrite is a 386 processor. It interprets commands from the Host, and communicates to both the Host and the Source drive through the emulators in the FPGA. What if the 386 were to fail? If it is a straight up failure, as in a dead chip, the 386 will be unable to help initialize the FPGA at a minimum. Without the 386, the FPGA doesn't do anything.
A potentially more serious form of failure would be "runaway code." This can happen in any computer system if a glitch in the RAM causes the processor to start executing code out of sequence. Usually the processor can't run in this state for long, as it has no way to get back to the correct code. Protection against this eventuality comes from the NoWrite program itself. NoWrite does not have code in its ROM that can cause a change in data on the drive. Even if the processor went nuts (technical term here), it could not stumble on code that would do anything bad to the Source drive. We simply have never taught NoWrite how to, well, write.
We also made a design decision that there should be a method to determine what the true capabilities and settings are for the Source drive. Without this information, there is no way to determine whether there has been an attempt to hide data on the drive. While NoWrite won't allow any commands that can make hidden data more accessible, knowing that data is hidden allows you to make a decision as to how best to recover it. Again, NoWrite allows you to view all user accessible data objects, just not change them.
This is a sampling of some of the features built into NoWrite to safely provide Absolute Write Blocking. The goal all along was to do the best job possible in protecting the Source drive and its data, and we certainly feel that we met this goal with NoWrite. Taking all of this into account, it is possible to come up with a Write Blocker Rating System for how well a Write Blocking system can protect a drive and its data.
Using this system, NoWrite would be a 10. Let's see how some other theoretical future versions of NoWrite would stand up to this Write Blocker Rating System. Why would we subject our designs to this rating system? Well, Why not? If we inform everyone up front about the features and drawbacks of any of our designs, they can choose the one that matches up to their comfort level. Not every Write Blocking job requires the highest level of protection. It is up to the user to decide what is right, and we'll provide the information to help with the decision, at least about our products. This way you are not “surprised” before, during or after you use our products.
If we were to make a Cheap & Fast version of NoWrite, the simplest design would be missing a few features that we consider important. For instance, it would be very easy for us to make such a device that has a direct data path between the Host and Source drive, and doesn't resynchronize the data. Sure it would go fast, but it would also be slightly more prone to additional retries at UDMA speeds. This version we'd have to rate at about a 6.
How about at the other extreme? Perhaps a more expensive design very similar to the current NoWrite, but with the ability to run at the higher UDMA speeds. This would get good marks on most of the criteria, but would lose a point or so for the potential retries. However, it would gain back a bit by taking advantage of NoWrite's memory buffers. If the data transfer between the drive and NoWrite was successful, retries requested by the Host would not necessarily have to be processed by the drive. With that, we might give this product a 9.
A FireWire or USB based device presents interesting problems. The first is that few people actually design their own FireWire chips. We are considering a chip from a major silicon vendor. While we have the source code to run the chip, we can't vouch for every last thing that goes on inside the chip. Nor do we have much of a clue as to its failure modes. There is also the question of the interfacing drivers between the operating system and the device, as the Windows drivers for these FireWire chips are usually provided by the chip vendor. Most of the FireWire to IDE conversion chips also like to run at UDMA speeds. Given all of these design 'features', this type of design only gets a 4 or 5, even though it can be awfully convenient in some circumstances.
For the ultimate in safety using FireWire or USB, an off the shelf FireWire or USB to IDE cable may be plugged into NoWrite, and this two part solution becomes a 10. These cables or external drive adapters can usually be found for less than $100 at just about any decent computer store.
For completeness, software write blocking should probably be discussed. If there is any level of the operating system where software can talk directly to the I/O ports that control the drive, there is the possibility of an intentional or accidental command getting to and changing the Source drive. Consider it discussed.
There are many ways to design a Write Blocking system. There are trade-offs associated with each design path. We feel that the design path chosen for NoWrite represents the best feature set for Absolute Write Protection, drive protection and preservation of the courts evidence, your reputation and case.