MIT Guide to Lock Picking – Chapter 1

The big secret of lock picking is that it’s easy. Anyone can learn how to pick locks.

The theory of lock picking is the theory of exploiting mechanical defects. There are a few basic concepts and definitions but the bulk of the material consists of tricks for opening locks with particular defects or characteristics. The organization of this manual reflects this structure. The first few chapters presents the vocabulary and basic information about locks and lock picking. There is no way to learn lock picking without practicing, so one chapter presents a set of carefully chosen exercises that will help you learn the skills of lock picking. The document ends with a catalog of the mechanical traits and defects found in locks and the techniques used to recognize and exploit them. The first appendix describes how to make lock picking tools. The other appendix presents some of the legal issues of lock picking.

The exercises are important. The only way to learn how to recognize and exploit the defects in a lock is to practice. This means practicing many times on the same lock as well as practicing on many different locks. Anyone can learn how to open desk and filing cabinet locks, but the ability to open most locks in under thirty seconds is a skill that requires practice.

Before getting into the details of locks and picking, it is worth pointing out that lock picking is just one way to bypass a lock, though it does cause less damage than brute force techniques. In fact, it may be easier to bypass the bolt mechanism than to bypass the lock. It may also easier to bypass some other part of the door or even avoid the door entirely. Rememer: There is always another way, usually a better one.

Back to Index >
Chapter 2 >

Guide to Lock Picking – MIT Hacking Community Opinion

Executive Summary:

The MIT Hacking community is saddened by the series of recent events which have made the “MIT Guide To Lockpicking” available electronically in a indiscriminate fashion. We would like to state, once again, that we believe such distribution is inappropriate. Since we clearly have no control over the guide’s dissemination, we would, at the least, like those distributing the guide to do the following:

  1. Add an integral section on [Hacking] Ethics
  2. Disassociate the MIT name from the distributed guide


We believe that the guide should be freely available to hackers who have a sense of ethics. Individuals have always been encouraged to only pass the information on to others who will use the information responsibly. Dissemination of the “MIT Guide” to the anonymous usenet and internet masses is irresponsible, at best. While most members of the internet community may use this information in ethical ways, some may not. Even if only a few people (a trivial percentage of the potential electronic readership) use the information in an unethical fashion, the damage can be considerable.

Many have, correctly, noted that there is no “magic” information contained in the “MIT Guide”. All the basic information is available from other texts. The MIT Guide distills the information relevant to lock picking and presents it clearly and succinctly. Electronic dissemination of this ~40 page text lowers the effort (and hence commitment) an individual must expend to gain a working knowledge of lockpicking. Widespread electronic availability of the document encourages everyone, regardless of their personal mores, to gain the skill.

The guide was originally written to pass on non-destructive methods of entry to members of the MIT Hacking community. At MIT “Roof and Tunnel Hacking” is a pastime where students explore the Institute where they live and work. For reasons of safety, liability, and privacy, the MIT administration isolates certain portions of the Institute from general traffic using various methods, including locks. Mastery over locks is, hence, a valuable asset to the dedicated roof and tunnel hacker.

Roof and tunnel hacking at MIT is concerned primarily with non-intrusive exploration. The goal is to discover and learn, not to steal, destroy, or invade anyone’s privacy. Unfortunately, the skills which one needs in hacking can be perverted to nefarious ends. Established MIT Hackers always make an effort to convey a proper sense of ethics to new hackers and to be discerning about the techniques they teach to new hackers. The “MIT Guide” has always been given to new hackers only after they demonstrated themselves to be responsible.

The “MIT Guide” was never intended to be distributed separate from the oral tradition and indoctrination associated with the MIT Hacking community. In hindsight, we can acknowledge, that it was a grievous oversight on the part of the author(s) of the “MIT Guide” that the document was written without attempting to integrate some of the ethics and context of MIT Hacking into the document itself. We agree that no amount of words will convey the same sense of hacking ethics as one acquires being a part of the MIT Hacking community. Nonetheless, we feel the distributed guide, stripped of its context–the MIT Hacking community, is very irresponsible and sadly lacking. We believe the very least that can be done is to attempt to include in this artifact some of the ethics which are part of the oral hacking education at MIT.

The MIT Hacking community does not support the guide’s distribution in electronic form for the reasons mentioned above. Further, it is quite clear from the actions taken by Ted T. Tool and others that the MIT Hacking community has no control over the guide’s dissemination. Consequently, we feel it is inappropriate for the guide to be labelled as an “MIT Guide”. At this point, the guide is neither being distributed by MIT nor with the blessing of the MIT Hacking community. We would like to ask Ted T. Tool [who left the MIT Hacking community several years ago] and anyone else distributing copies or derivatives of the original work, to disassociate the guide from MIT if they insist on continuing anonymous distribution. Such actions are counter to MIT Hacking ethics, and the MIT community would prefer not to imply that it condones such actions.

Words will not do justice to the MIT Hacking Ethics. Nonetheless, following is a brief list containing a few of the major principles to which the MIT Roof and Tunnel Hacking community adheres during its exploratory

  • Be SUBTLE — leave no evidence that you were ever there. (This is a general rule which applies to lots of circumstances — a few are enumerated explicitly in this list, but many principles follow from this simple edict)
  • Leave things as you found them (or better).
  • If you find something broken call F-IXIT (a local number for reporting problems with the buildings and grounds — Hackers often go places the normal institute workers do not frequent regularly and hence may see problems before the workers do).
  • Leave no damage.
  • Do not steal anything.
  • Brute force is the last resort of the incompetent.
  • Do not hack while under the influence of alcohol/drugs/etc.
  • Do not drop things (off a building w/out a ground crew).
  • Do not hack alone (just like swimming).

  • Exercise COMMON SENSE. (This is another general rule with very wide applicability — when exploring, you are often in places which were not intended for normal traffic. The people who built the area may not have assumed anyone would be there without special knowledge of the area Many of the assumptions you are used to making are not valid or applicable while hacking. It is very important that you stay alert and think clearly.)

Please, consider your actions carefully. If you feel you must continue to distribute the guide, we strongly advocate the addition of an integral section on ethics. As long as the MIT community has no controlover the contents or distribution of the guide, it is inappropriate to call it the MIT guide. Consequently, we ask that the name of the distributed guide be changed.

Chapter 1 >
Back to Index >

MIT Guide to Lock Picking – Table Of Contents


Copyright 1987, 1991 Theodore T. Tool. All rights reserved.

Permission to reproduce this document on a non-profit basis is granted provided that this copyright and distribution notice is included in full. The information in this booklet is provided for educational purposes only.

August 1991 revision.

The MIT Hackning community’s opinion.


Original Postscript source (gzipped 188 kB).
Original Postscript source (uncompressed 819 kB).
Original Postscript source converted to Adobe PDF(uncompressed 521 kB).

What The Heck is RAID 10?

Earlier this month, a company came along and asked for a RAID 10 array. Understanding that RAID 10 is a cooler sounding way of saying RAID 1+0, I understood it as a mirror set that is striped across another mirror set. Simple enough… Just concatenate a couple of mirrors, and you’ve got RAID 10.

Indeed, RAID 10 is simply one or more RAID 1 arrays (mirrored sets) striped together (RAID 0).

RAID 1 creates an exact copy (or mirror) of all of data on two or more disks, while RAID 0 splits data evenly across two or more disks with no parity information for redundancy. By combining the two into a RAID 10 array, you are able to take advantage of the faster write speed offered by RAID 0, while protecting your data against drive failures with mirroring.

This method of RAID is pretty costly, but useful if you find yourself in a situation where you need a lot of throughput combined with a lot of data protection.

How To Make Miso Soup

We have a wonderful Japanese restaurant near my home called Moritomo. We go there often for sushi, and I’ve always been amazed with the quality of their food, especially their miso soup.

I’ve tried a number of different recipes in an effort to make a soup that tastes similar to theirs, and after a dozen or so failures, I finally feel that I have come close. The trick, as it turns out, is adding just the right amount of bonito flakes to make the soup stock. This is my variation to a recipe that I found printed on the back of a block of shiro miso which I bought from an Asian food store in Burlington, VT.

  • Start with four cups of water in a sauce pan, and add two inches of kombu kelp. Bring this to a boil, and remove the kombu just as the water begins to boil.
  • Next, reduce heat to maintain a gentle boil and add 1/4 cup bonito flakes (lightly packed). Leave them in for 5 minuets
  • Prepare a colander lined with coffee filter material and run the soup stock through it to remove the bonito flakes. Add the stock back to the sauce pan. This is your soup stock. Known as dashi, it is the base stock for most Japanese soups and broths.
  • Add 3/4 cup soft tofu, cut into 3/8 inch squares, and three inches of wakame seaweed cut into 1/4 inch strips. Bring to a rolling boil for seven minuets to cook the tofu and wakame.
  • While the tofu and wakame are cooking, remove one cup of the soup stock, and place it into a bowl. Let it cool for one minuet and dissolve 3 and 1/2 tablespoons of shiro (white) miso, making sure that no little chunks remain.
  • Remove from heat, and allow to cool for two to three minuets.
  • Add the dissolved miso, garnish with chopped scallion rings and serve.


Macintosh Finder Copy to Samba Share Problem

With the last Samba upgrade, we started having problems copying files to our Samba share from the Mac OSX finder.When attempting the copy we received an error reading: “The operation cannot be completed because you do not have sufficient privileges for some of the items.”

There were no permissions issues, which was substantiated by our unhindered ability to do UNIX copies to the same share, and the smb.conf file had not changed. After searching the groups and finding nothing of use, I set up a test environment with all the same versions and settings, and replicated the error.

Because the Samba share is mounted over NFS on the server, and because the Mac Finder creates that annoying place holder file before actually copying the real file, I suspected that the problem had something to do with file locking. With this in mind, I systematically turned off all Samba locks one by one until I found the ones that worked.

Finder Copy Error

Finder Copy Error

IMPORTANT NOTE: The Samba share point in this environment is mounted over NFS on the server. The error did not occur when the Samba share point was on a filesystem local to the server.

Here is what our share looked like before making the changes:

read only = no
preserve case = yes
short preserve case = yes
csc policy = disable
share modes = no
level2 oplocks = no

Adding either of the two following directives resolved the problem:

locking = no
posix locking = no

Either one would have worked, but we ultimately decided to turn off posix locking because we wanted Samba to continue locking files for Windows connections, but stop locking them over NFS. Below is our share after making the change:

read only = no
preserve case = yes
short preserve case = yes
csc policy = disable
share modes = no
posix locking = no
level2 oplocks = no

The smb.conf man page has the following to say about posix locking:

posix locking
The smbd daemon maintains an database of file locks obtained by SMB clients. The default behavior is to map this internal database to POSIX locks. This means that file locks obtained by SMB clients are consistent with those seen by POSIX compliant applications accessing the files via a non-SMB method (e.g. NFS or local file access). You should never need to disable this parameter.

Default: posix locking = yes

The smb.conf man page has the following to say about locking:

This controls whether or not locking will be performed by the server in response to lock requests from the client.

If locking = no, all lock and unlock requests will appear to succeed and all lock queries will report that the file in question is available for locking.

If locking = yes, real locking will be performed by the server.

This option may be useful for read-only filesystems which may not need locking (such as CDROM drives), although setting this parameter of no is not really recommended even in this case.
Be careful about disabling locking either globally or in a specific service, as lack of locking may result in data corruption. You should never need to set this parameter.

No default

Hopefully this is helpful. If anyone has anything to add, please post a comment.

Solaris X86 Compatible RAID Controller

Every time I have to spec a solution using Solaris, I always have to answer a bunch of questions in meetings about why Sun is so costly compared to Dell servers. Usually the reason for the higher price is not the servers (especially with X86 sun), but rather the storage. Since Sun does not offer a system with a RAID card, you always have to purchase a high-end disk enclosure that is capable of performing the RAID functions unless you want the performance degradation that comes with software RAID.

The good news is that there is finally a really nice PCI RAID card that works with Solaris! The bad news is that it only works with X86 Solaris, and Sun only goes so far as to say that it is”reported to work“.

Anyhow, no matter. Here is the deal:

According to Sun Big Admin, the Mylex Accelaraid 150 is reported to work with Solaris 9 04/04 to Solaris 10 03/05 (read Solaris 9 and 10 X86). The firmware and bios on the card needs to be: BIOS Version 4.10-50; Firmware 4.08-37.

Pity that there still does not seem to be a RAID controller that works with SPARC hardware. If someone would come up with that, it would make my life as a Solaris administrator a whole lot easier.