.oO____Oo. T H E I N F I N I T Y C O N C E P T ``` ``` ` `` ` ``` ``` .oO____Oo. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~The Infinity Concept~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ . Issue #1 . . Summer 1995 . -=-=-=-=-=-=-=-=-=Brought to you by the members and associates of-=-=-=-=-=-= =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-the Guild=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- .Route [daemon9/Infinity]. .......Nihil.............. .......Carbonboy.......... .......Squidge............ .......jfp................ .......E-fx............... .......Mythrandir......... .......Delirium........... .......Alhambra........... .......MrZippy............ url's ------- ftp://ftp.netcom.com/pub/da/daemon9/*the Guild/ http://server.cs.jhu.edu/~jed/TheGuild/ ------------------------------------------------------------------------------ Summer 1995 [DefConIII] | The Infinity Concept | issue 1 ------------------------------------------------------------------------------ [Introduction] Welcome to the first issue of the Infinity Concept. This compendium of information has been compiled and brought to you by members of the Guild. Our aim in this and future issues is the dissemination of useful and accurate information. The Infinity Concept is here to provide you with the best in today's technologies. The articles themselves will usually have a hacking tint to them, as much of our diverse backgrounds tend to converge there, but don't be suprised to find an occasional wild-card... It is our goal to disseminate legitimate information in a discretionary, factual manner. However, should you spot an obvious (or not- so-obvious) error please feel free to make a note of it and let the author of the article know about it. We are ALL here to learn. Table of contents 1).Electronic Privacy............................Route 2).Windows NT Security...........................Nihil 3).Computer Security Threat Response.............Zippy 4).Semi-Conductor Refrence books...................JFP 5).How to help keep your privacy..............Deliryum 6).Obtaining information on other people....Mythrandir 7).Linux Packet Sniffing....................Mythrandir 8).Phone Explorations.......................Mythrandir .oO____Oo. This, the first issue of The Infinity Concept, is set forth into tumultous times. The Guild is still relatively new and we have not set any standard practices as yet. This just makes for a somewhat hecktic schedule and slight disorganization. This will change, however, and we will become a cohesive and solid unit as time goes on (esp. after DefConIII). Despite the rantings of a few misguided individuals, there is *NO* dissention in our ranks and the Guild is not an information leeching group. This electronic magazine is proof enough of that. The anti-Guild propaganda that was recently spread throughout .2600 is also a crock of shit. To further make things frantic, DefConIII is right around the corner. Several Guild members (including myself) will be there. In an effort to get ready to for the confrence, I have had to step up the schedule for this issue. Some members didn't have time to submit their articles, but pledge to next issue (Fall 1995?). The fact that the two founding members (Nihil and myself) have recently moved has not made things run any smoother, either... Despite all the forementioned hoops, it is my opinion that we have put together a solid compendium of useful knowledge. The areas of expertise of Guild members differ widely, and we have shown that here. I think the information hungry reader will find this an enjoyable, smart compilation. Feel free to drop me a note and let me know what you think. -Route, Guildmaster ______________________________________________________________ |Electronic Privacy - The Glory of Cryptography | |______________________________________________(the dark art)_| by Infinity --[Abstract]-- It seems you just can't trust *anybody* these days. The advent of the digital age has brought us wonderful advances in computing and communicating. However, it has also brought with it the need for increased awareness of *who* is out there, and just *who* may be watching you. E-mail is not safe. Anyone worth their weight in silicon can forge mail, and clever individuals can read *anyone's* mail... Your files are not safe. It's not much of a hack to browse through the directory structure of a computer, and forget about hidden files... Your off-line storage is not safe. Disks, tapes, CD-WORMS, Magno-optical disks, floptical, whatever the technology, there is no considerable effort involved in stealing off-line media and subsequently reading it. Enter cryptography. E-mail is now safe. No one reads your mail, except for the intended recipient. Your files are now safe. No one can touch them without your passphrase. Your disks are now safe. No one can read a file without your passphrase. You may wonder why people would want to get into your files... You are somebody important, you know something important, you have something important; you are nobody important, you know nothing important, you have nothing important. It doesn't matter: Some malicious crackers are nothing more than vandals, breaking into accounts and computers to cause damage and fuck around. If they happen upon some interesting mail or files, great. Some are more methodic; evil crackers that may target you or your organization, in hopes of monetary gain, social notoriety among peers, or a personal vendetta. (I won't even discuss the Federal Government. God knows they don't read people's mail.) For whatever reason, it happens. Better safe than sorry. This paper is intended to introduce you (in a relatively technical way) to cryptography. It is not for the feint at heart. If large numbers scare you, read no further. I assume a basic familiarity with the subject (and familiarity with the complexity classes of the running time of algorithms won't hurt). I tend to jump around from topic to topic, as it is the way I think, from one tangent to the next, but looking back, I believe there is enough cohesiveness to tie this whole thing together nicely. --[Symmetric key vs. Asymmetric key]-- There are two major types of cryptography (I won't even deal with ciphers that don't utilize keys) symmetric (secret-key) and asymmetric (public-key). In a symmetric system, one key is used for encryption and decryption (or the decryption key can be calculated from the encryption key). The message is encrypted with the secret-key and the process is reversed with the same key. Getting the sender and receiver to agree on a key without any potential attacker finding out is the major problem of the system. If the channels in which the messages are traveling are insecure (untrusted), how can the key be securely transmitted? If the key was snooped, all future messages could be decrypted by the attacker. This issue of key management is the major problem in secret-key systems. In 1976 a better method for key management was developed. Whitfield Diffie and Martin Hellman came up with a system involving two keys, both related mathematically. One key is kept private and the other is published publicly. A message encrypted by one is only decryptable by the other. This solves the age old problem of secure key management. Anyone can encrypt a message with the public-key, but only the intended recipient (with the corresponding private-key) can decrypt the message. Furthermore, authentication can be done in such a system. If the owner of a given private key encrypts (or cryptographically signs) a message with his key, only his corresponding public-key will decrypt (or verify the signature) of the message. If they do not match, either the message has been altered, or the key used is not the corresponding private-key. In either case, the message is discarded. The advantages of public-key over secret-key are obvious and great. The need for secure channels in which to transmit a private key is not necessary. In a secret-key system there is always a risk that an attacker could discover the secret-key through these insecure channels. The other great advantage of public-key systems is the authentication mechanism built into them. Authentication via secret-key systems is clumsy and can require a trusted third party (an arbitrator). One disadvantage (the only one?) of a public-key system is speed. Some secret-key systems are orders of magnitude faster than some public-key systems. This may not be too noticeable for small messages, but on large files, it quickly becomes undesirable. The solution to this? The hybrid- cryptosystem. Using both public-key and secret-key cryptography, the best of both worlds is achieved. The public-key system is used to encrypt a psudeorandomly generated secret key that was used to conventionally encrypt the message. This whole package can then be confidently sent across insecure channels. [Some words on PGP] This article will not focus on PGP, but as it is the premier hybrid system, I feel the need to mention it. PGP is one of those 'best of both worlds' cryptosystems. It uses a symmetric cipher for bulk encryption and an asymmetic cipher for key exchange. For digital signatures (authentication), a one-way hashing function is used (a one-way hash is simply a function that takes input and produces a unique fixed-size output that is not feasible to duplicate, except with the same input). PGP uses IDEA for bulk encryption (focused on, in depth below), RSA for key exchange (mentioned below), and MD5 for message digests. The keysizes currently used by PGP are 128-bits for the IDEA key, and 512-2048 for the RSA keys. [Some words on RANDOMNESS (as it pertains to cryptography)] Cryptography is big on randomness. Some systems (such as an engine for a one-time pad) need an n-length string of random bits, for an n-length message. True randomness is not something easily achieved. Computers are INCAPABLE of generating a random sequence of bits. The best a computer can do is a pseudo-random string. A pseudo-random bit generator is fine if it is cryptographically secure. To achieve this, the generator first of all needs to have a large enough period (the period of a function is defined as the point in which it begins to repeat. Sin is periodic at 2PI.) to be suitable for the cryptosystem's needs. Again using the one-time pad reference, if you have a message of length n, and the generator is periodic at some point m -----BEGIN PGP MESSAGE----- > Version: 2.6 > > hDwDqeLyyFpa0WsBAYCumTBz0ZUBL7wC8pMXS4mBS0m3Cf6PrPer+2A0EQXJZM46 > OvPnqNWz5QK3Lwyg9DeEqAPF5jH/anmgXQEE3RNhybQUcqnOSVGMO2f5hjltI73L > 8CRXhFzMCgjdCwTRf0Oq61j4RAptUviqhDq/r7J2FpY7GwpL5DxuJ+YrWNep69LK > Q/CkKxtwvv2f0taly4HCLCcqw59GQ5m++WnOwDQWKG7yUaXJuUG/mJdr/o+ia3y+ > QKyqOesHdSjWoXDpK7F2Cvxf2KpV3+vzbv+TriRyDV+zR/8womdJl6YAAAKtmWO2 > fy0sp/cqr/1ZGQKmfZWz5L0bh1e/sJXJq9PjvPc05ePxZ35XEoRTCqxbq2GPynkH > YSynfXZY//814TKmdQxPBvkc8Nbi0rc/GYyoAmItDui4mQISYskGkmLieoWDDlpP > E9tZlb/7Xa22QS53Or6DwU/y226WXQvrWq5OJ+8OhQyEnLWsEdfgFoe1l9aeweX5 > 0ao5lcp098Q4JFfQWoaU9D7kmKvg+AVT44Pv16/nPvihAoC2O14xg7t1U8032ybs > 4FLpvxyqoF7+oDV/QNw4Evk1ZnxE5+PH2sOf1qCJdljVSd3wGSfUQaDPRx5RH0XC > SAgYMsIRaytpdoq521tHUZt2BIg7Ii89TfUBrnkenBFAqdZAf+JR1PSB4yaV3YtG > PCS4lNQkmWx+ItjP0zsHVcAR0TiBcpV0gMY+tx0h40CTkDi2vHiVyswSJr4halsW > SIixrdi6B0i3f7v7xlOpFI2khza1c/dH8nrF1uPLECeAZ8TQq53ZlyN472KYuTVZ > 8y5NqyXd672dYEtzsOlUa9YwFKKyGisyDhZmE5wSOg2Pjopvl0WkuZSR/kdxrX/N > hFdfXRy1Kgkr+vz9abumhcWS5lYCCfVLk/CIgRqHO09nlEJCTb1T/U788Gptr3/d > 3dj8C/LECdY7fIdkmTgYhXmfv7fQxLWln29Yux0cEpRq2ud8rjYVSuEaTUO9dF4n > 9oFRsPdbb0TOxaMVFm2hnELzeKAk/poInfEZkN2ZnusxJ4aM1HkBRva+CAMhQHdT > XMisoNawWEDPwiwu91owIrBevPJNvX155jUTwKNj0UPBwS6TfS5gXl9g+LoBnMWQ > nbMMMYVXbJVsAeVOlzTSBftpbglx1k7ocDaAJTZ3OCjf0FcKJsa+4Hybc713611c > WSHV5esfY9k/yw== > =nLfz > -----END PGP MESSAGE----- A successful decryption resulted in: > Although I realize blacknet was a hoax of some sort, I'm curious as > to the reasons behind it and I would like to know the motives of the > person who did it, malicious to make fun of cypher punks or simply > poking fun at cyberspace in general. > I'm interested in forming a similar net, not for the buying and > selling of information, but for the fun of doing it, who knows what might > come about in a network somewhat limited and away from the internet, but > based on pgp without people flaming, and without the netloons like > dwetler and sternlight, (I have my doubts about dwetler's actual motives > in spamming the mailers) > SO, hopefully they key I encrypt it to is the actual one, and if not > hopefully whoever is intercepting this is as interested in creating > what I am, why else be eaves dropping?? > Looking forward to hearing from whoever out there, and > I hope you're competent enough with unix to extract my pgp key > from my .plan > > > -- > Finger yusuf921@raven.csrv.uidaho.edu for PGP public key 2.6ui > GJ/GP -d+ H+ g? au0 a- w+++ v+(?)(*) C++++ U++1/2 N++++ M-- -po+ Y+++ > - t++ 5-- j++ R b+++ D+ B--- e+(*) u** h* r+++ y? > > > The next step was to create a revocation certificate and send that off to the PGP key servers. After all, the key has undoubtedly been compromised. The moral of this story is that 384-bit keys can be broken by a small team of people working in secret and with modest resources. Lest anyone object that a MasPar is not a modest resource, we'd re-iterate that it did only 50% of the work; that we took only three months and that we used only 50 or so quite ordinary workstations. We believe that we could have used at least twice as many machines for at least twice as long without anyone noticing. The currently minimum recommended key size, 512 bits, is safe from the likes of us for the time being, but we should be able to break them within five years or so. Organizations with more than "modest resources" can almost certainly break 512-bit keys in secret right now. Alec Muffett alec.muffett@uk.sun.com Paul Leyland pcl@oucs.ox.ac.uk Arjen Lenstra lenstra@bellcore.com Jim Gillogly jim@acm.org and, of course, BlackNet 8-) P.S. The 384-bit BlackNet secret key is: > -----BEGIN PGP MESSAGE----- > Version: 2.6.2i > > lQDAAy/ty1QAAAEBgM98haqmu+pqkoqkr95iMmBTNgb+iL54kUJCoBSOrT0Rqsmz > KHcVaQ+p4vLIWlrRawAFEQABfAw0gFVVGhzZF63Nc8HJin4jAy2WgIOsvST5ne1Y > CbfyDIZ6siTHUAos8wMBQZ6Q8QDA2b6tiYqrGu6E1+F0DGPSk9MGif5/LKFrAMDz > 8HXIK1zrEFEDq9/5dUXO2rk1tH+mkAEAv0EE9e5EJn+quL3/YvAg6bKOlM7HgVKq > JEDDtCBCbGFja05ldDxub3doZXJlQGN5YmVyc3BhY2UubmlsPg== > =/BEI > -----END PGP MESSAGE----- -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBL+6HEzt/x7zOdmsfAQGRpQP9FZluArrT5+zsG/R6y/MF7O3d7ArEkVe2 rUQgP7W2NxudAFHTNaL9mqLBDVNW/3PqWIhvHMtrSgG+ZAFBH5bP03tizfOFr+SL eO1JQgYFey7Wh5J/YCuE0VTlYMZ7bhnoiGIvTYZgxIzVWAYyGmlWKRDjfKz/Pks8 qavbPg6qbPo= =s12J -----END PGP SIGNATURE----- -- Paul Leyland | Hanging on in quiet desperation is Oxford University Computing Services | the English way. 13 Banbury Road, Oxford, OX2 6NN, UK | The time is gone, the song is over. Tel: +44-1865-273200 Fax: 273275 | Thought I'd something more to say. Finger pcl@sable.ox.ac.uk for PGP key | -------------------------------------END INCLUDED TEXT------------------------- [Why a (proper) ONE-TIME PAD is unbreakable] A one-time pad is the only provably perfect cryptosystem. A one-time pad is a simple symmetric cryptosystem. If a message of length n needs to be encrypted, a pseudo-random sequence of bits of length n is generated. The message is then XORed with the pad. The pad must be generated by a cryptographically secure PRNG (pseudo-random number generator) and can only be used once per communication, and must be transmitted securely. If this protocol is followed, you have perfect secrecy. Since the ciphertext yields *no* possible information about the plaintext, with the possible exception of it's length, no cryptanalysis can be performed on the ciphertext. A given ciphertext is equally likely to be any possible plaintext of equal size, and there is no way of knowing which of the decryptions is valid. You could spend an eternity trying all the possible solutions, and never be sure which is the proper meaning of the original message. --[The IDEA algorithm]-- The International Data Encryption Algorithm, designed by Xuejia Lai and James Massey, was originally called PES (Proposed Encryption Standard). It was demonstrated to be vulnerable to a differential cryptanalysis attack in 1990 and had to be strengthened. The result of the strengthening was called IPES (Improved Proposed Encryption Standard), and, in 1992 the name was changed to IDEA. IDEA is a symmetric cipher with a 128-bit key, that operates on 64-bit blocks of data, divided into 4 16-bit sub-blocks, for eight rounds. IDEA mangles data by mixing operations from three algebraic groups: XOR, addition modulo 2E16, and multiplication modulo 2E16+1. These operations are encased within the algorithm itself, and involve no external permutations (unlike DES's E-box). The operations operate on the 16-bit sub-blocks of data, so IDEA is efficient on slower 16-bit processors. Like most symmetric ciphers, IDEA uses confusion and diffusion to obscure the redundancies that naturally occur in a plaintext message (esp. if that message is English text): Confusion is where relations between the plaintext and ciphertext is obscured. This makes cryptanalysis of the ciphertext more difficult, as there are fewer redundancies to exploit. Substitution is one method of confusion (remember the Caesar Cipher?). Diffusion is where the redundancy of a plaintext message is spread out through the ciphertext. This dissipation of the plaintext message further frustrates attempts to locate redundancies. Transposition is one method of diffusion. [IDEA in 14 easy steps] Below is a basic overview of one round of IDEA (This information originally appeared in Bruce Schneier's book, Applied Cryptography). A 64-bit data block is divided into 4 16-bit sub-blocks (X1-X4). These four blocks become the input to the first round of the algorithm. In each round, the four sub-blocks are XORed, added, and multiplied with one another and with 6 16-bit sub-blocks of key material. Between each round, the second and third sub-blocks are swapped. In each round, this is what happens: 1. Multiply X1 and the first key sub-block. 2. Add X2 and the second key sub-block. 3. Add X3 and the third key sub-block. 4. Multiply X4 and the fourth key sub-block. 5. XOR the results of step 1 and step 3. 6. XOR the results of step 2 and step 4. 7. Multiply the results of step 5 with the fifth key sub-block. 8. Add the results of step 6 and step 7. 9. Multiply the results of step 8 with the sixth key sub-block. 10. Add the results of step 7 and step 9. 11. XOR the results of step 1 and step 9. 12. XOR the results of step 3 and step 9. 13. XOR the results of step 2 and step 10. 14. XOR the results of step 4 and step 10. The output of the round is the four sub-blocks that are results of steps 11, 12, 13, and 14. The input to the next round is the two inner blocks of the previous round, reversed. After the 8th round, the first four steps are repeated, and the four sub-blocks are re-attached to form the final ciphertext block. [Key sub-block creation] The algorithm uses 52 key sub-blocks (6 for each of the eight rounds, and 4 more for the final output). The 128-bit master key is divided in 8 16-bit sub-keys. These are the first 8 sub-keys used by the algorithm (6 for the first round, 2 for the second). The master key is then rotated (bitwise) 25-bits to the left, and divided again into eight sub-keys. The first four are used in round two; the last four are used in the third round. The master key is again rotated 25-bits to the left and divided into 8 sub-keys, and so on until the end of the algorithm. [Decryption] IDEA, being a symmetric cipher, goes through the same process for decryption, as it does for encryption. The only difference is that the key sub-blocks are reversed and slightly different. The decryption key sub-blocks are either additive or multiplicative inverses of the encryption key sub-blocks. The decryption keys are more computationally intensive to compute than the encryption keys, and that time is negligible. (sort of.. see below). [Security of IDEA] IDEA is a new algorithm; too new for any concrete proofs of security one way or the other. It is conceivable that the NSA or some such group has come up with a better method than brute-force, but it is unlikely they have, or at least, unlikely that the public sector would know about it if they had. IDEA *looks* very secure. So far, the best method publicly known for breaking IDEA, is by a brute-force search of it's keyspace. As I stated before, a brute-force attack is absolutely infeasable. It gets worse. Generating encryption sub-keys is much faster than generating decryption sub-keys. When a brute-force attack is waged against a ciphertext block, this time adds up, as each new attempt requires a new decryption key. The time to compute all the additive and multiplicative inverses can double or triple the necessary time and/or resources needed to launch such an attack. [Weak keys] A weak key is a key that compromises the security of a cryptosystem in one fashion or another, making some attacks easier. (DES has 4 weak keys, and 12 semi-weak keys.) The IDEA weak keys are weak in the sense that if used, an attacker can exploit them in a chosen-plaintext attack. (A chosen plaintext attack is where an attacker has access to the plaintext and ciphertext for several messages, and can choose the encrypted plaintext. This allows the attacker to exploit chosen parts of a message, and possibly glean more information about the key.) A weak key example: 0000,0000,0x00,0000,0000,000x,xxxx,x000 'x' can be any number. The chance of accidentally generating one of these keys is 2E-96. Not too likely. --[Source]-- IDEA is patented, but is usable without restriction for noncommercial use. Please note the keying function below is *not secure*. It uses a simplified key, in that it takes up to 8 characters and casts each one into a 16-bit word, by shifting it left 8 bits, and OR'ing it with the previous character (0 for the first character), making 8 16-bit subblocks of the key, which is no where near as complex a key as possible. I would recommend either writing a better keying function, or finding a secure 128-bit hash to use. In any event, the code is really here to learn from. You cannnot be sure whether or not it has been altered from the original code (I cannot be sure, as it had no signature to check the integrity). If you want more or less guaranteed security, use PGP's conventional encryption function. ---------------------------------BEGIN INCLUDED TEXT--------------------------- /* idea.h */ #ifndef _IDEA_DOT_H #define _IDEA_DOT_H #include #include #include #include #include #include #define IDEAKEYSIZE 16 #define IDEABLOCKSIZE 8 #define word16 unsigned int #define word32 unsigned long int #define ROUNDS 8 #define KEYLEN (6*ROUNDS+4) #define tempfilename "tempfile.”nc" int end_of_file,noisy,overwrite; /*global vars*/ #define low16(x) ((x) & 0xffff) typedef unsigned int uint16; typedef word16 IDEAkey[KEYLEN]; /*IDEA Algorithm functions */ void en_key_idea(word16 userkey[8],IDEAkey Z); void de_key_idea(IDEAkey Z, IDEAkey DK); void cipher_idea(word16 in[4],word16 out[4],IDEAkey Z); uint16 inv(uint16 x); uint16 mul(uint16 a,uint16 b); /*file handling functions*/ char read_char_from_file(FILE *fp); word16 read_word16_from_file(FILE *fp); void write_char_to_file(char data,FILE *fp); void write_word16_to_file(word16 data,FILE *fp); void cipher_file(FILE *in,FILE *out,word16 *key); void decipher_file(FILE *in,FILE *out,word16 *key); void swap_files_and_clean_up(char *file); #endif /* End idea.h */ /*IDEA.C v2.2 c source code for IDEA block cipher. IDEA (International Data Encryption Algorithm), formerly known as IPES (Improved Proposed Encryption Standard). Algorithm developed by Xuejia Lai and James L. Massey, of ETH Zurich. This implementation modified and derived from original C code developed by Xuejia Lai. Zero-based indexing added, names changed from IPES to IDEA. CFB functions added. Random Number routines added. Optimized for speed 21 Oct 92 by Colin Plumb This code assumes that each pair of 8-bit bytes comprising a 16-bit word in the key and in the cipher block are externally represented with the Most Significant Byte (MSB) first, regardless of internal native byte order of the target cpu. modified for use with PC files by Colin Maroney 4/1/94*/ /* USAGE: pass a key made up of 8 16-bit numbers (word16) in an array ("word16 key[8];"), an input FILE * and an output temporary FILE * to either encode_file() or decode_file(). where the key comes from is up to you. then call swap_files_and_clean_up() with the original file's name as the argument, to replace the original file with the encoded data (stored in the temporary file). you can remname the tempfile to be used in idea.h noisy is an integer which tells encrypting/decrypting functions to echo a "." every 256 writes, so the user can see that something is happening. set it to 0 for quiet running. please note that for really good security the original file is overwritten before being erased if you use the w switch. otherwise it outputs a file ".enc" the main() used here as illustration reads the filename from the command line arguments, as well as a command "e" or "d" to tell it whether to encrypt or decrypt, and a key. the older versions had an interface for when a command line was not use. lack of editing features made this buggy, so i axed it. */ #include "idea.h" static uint16 inv(uint16 x){ uint16 t0,t1; uint16 q,y; if(x<=1)return x; t1=(uint16)(0x10001l/x); y=(uint16)(0x10001l%x); if (y==1)return low16(1-t1); t0=1; do{ q=x/y; x=x%y; t0+=q*t1; if (x==1)return t0; q=y/x; y=y%x; t1+=q*t0; }while (y!=1); return low16(1-t1); } static void en_key_idea(word16 *userkey, word16 *Z){ int i,j; /* shifts */ for (j=0;j<8;j++)Z[j]=*userkey++; for (i=0;j> 7)); Z+=i&8; i&=7; } } static void de_key_idea(IDEAkey Z,IDEAkey DK){ int j; uint16 t1,t2,t3; IDEAkey T; word16 *p=T+KEYLEN; t1=inv(*Z++); t2=-*Z++; t3=-*Z++; *--p=inv(*Z++); *--p=t3; *--p=t2; *--p=t1; for (j=1;j>16); return b-a+(b0)write_char_to_file(((char)(output[y]>>8)),out); if(length-->0)write_char_to_file(((char)(output[y]&255)),out); } } } void swap_files_and_clean_up(char *file){ long fsize,count; FILE *fp; char temp[100]; if(overwrite){ if ((fp=fopen(file,"r+b"))==NULL)printf("\nError overwriting old file, security compromised.\n"); else{ fseek(fp,0l,SEEK_END); fsize=ftell(fp); fseek(fp,0l,SEEK_SET); for (count=0;count\n",file); printf("encoded data remains in temporary file <%s>\n",tempfilename); exit(-1); } } else{ strcpy(temp,file); file=strtok(temp,"."); strcat(file,".enc"); } if ((rename(tempfilename,file))!=0){ printf("\nERROR renaming temporary file <%s>!!\n",tempfilename); printf("Data is safely processed and stored in that file.\n"); exit(-1); } } /*-----------------------------------------------*/ #define KBYTES 1024 void getuserkeyfromargv(word16 *key,char *arg){ int x; for (x=0;x>8)); } if(strlen(arg)>8)printf("\nONLY first *8* characters of key used!!!\n"); if(x<8)while(x<8)key[x++]=0; } main(int argc, char **argv){ word16 userkey[8]; char filename[100]; FILE *fp,*temp; int to_or_from; noisy=1; overwrite=0; if (argc!=4){ printf("\nUsage: idea filename.ext [e|d[w]] key\n"); printf(" e=encode d=decode w=overwrite file\n"); printf(" NOTE: Key must be no longer than 8 characters long!!!\n"); exit(-1); } else{ strncpy(filename,argv[1],99); filename[99]='\0'; if (argv[2][0]=='e') to_or_from=1; else if(argv[2][0]=='d') to_or_from=0; else{ printf("\nUsage: idea filename.ext [e|d[w]] key\n"); printf(" e=encrypt d=decrypt w=overwrite file\n"); printf(" NOTE: Key must be no longer than 8 characters long!!!\n"); exit(-1); } if (argv[2][1]=='w') overwrite=1; getuserkeyfromargv(userkey,argv[3]); } if ((fp=fopen(filename,"r+b"))==NULL){ printf("\nError opening File %s\n",filename); exit (-1); } if((temp=fopen(tempfilename,"w+b"))==NULL){ printf("\nError opening temporary file\n"); exit(-1); } if (to_or_from==1){ printf("\nEncoding file %s ",filename); cipher_file(fp,temp,userkey); } else{ printf("\nDecoding file %s ",filename); decipher_file(fp,temp,userkey); } fclose (fp); fclose(temp); swap_files_and_clean_up(filename); return 0; } ---------------------------------END INCLUDED TEXT----------------------------- --[How to implement cryptography securely]-- You can be using the most secure algorithm available, and be using it improperly, and sacrifice all the security it has to offer. This section includes some general things to be wary of, to have optimum success with whatever algorithm you are using. [Passphrase/word picking] First things first. Why bother using all of the worlds computers in a parallel brute force search or prime factorization, when a poorly chosen password is the only obstacle (if you deadbolt your door, don't leave the hinges off). Poor passwords are the number one way in which ALL of computer security is compromised.... THINGS YOUR PASSWORD SHOULD *NOT* BE: -In any dictionary. -A real word. -Anything that can be deduced from knowing you. -And for GOD'S sake NOT written down. THINGS YOUR PASSWORD *SHOULD* BE: -The full length allowable by the implementation. -Of mixed case, numerics and special characters. -Something you learn to type quickly w/o looking at the keyboard. -Something you DO NOT forget. [Dangers of a multi-user system] Using cryptography on a multi-user system can be dangerous. There are multitudes of attacks possible, with the feasibility and implementation depending on the particular OS. There are so many possible attacks: key logging, memory space snooping, swap-file reading, trojan horses, etc... Granted some of these attacks are sophisticated. I supposed your level of paranoia depends on what you are seeking to hide, but, my advice is to never underestimate the sophistication of your enemy. My further advice is NOT to use cryptography on an untrusted multi-user system. [Van-Eck devices] All electronic equipment emits electrical and electromagnetic radiation. Van-Eck devices are devices that intercept this radiation from computer equipment and are able to reassemble the data displayed therein. Van Eck devices can be very hard to detect, as they can be installed out of site from the target. Van Eck devices can be built for around $300.00 from parts available at Radio Shack. The implications of this are obvious and potentially severe. Unfortunately, apart from outfitting your equipment with TEMPEST certified products (or shielding the rooms with lead), there isn't much you can do about this threat, except be wary of just who is driving a van in your neighborhood with limo'd out windows and parked in front of your house... [Packet-Sniffing] Packet-sniffing is another 'invisible threat'. Packet sniffers are very hard to detect, because most are passive, not altering or producing data, just recording what zips on by. Some implementations of crypto products will send some sort of initialization value or even a key (or password) across the wire in the clear. I'd avoid using them. (Unfortunately, one of the most commonly networked OS's, Unix, is vulnerable to this attack. It sends login names and passwords in the clear both upon logging in and in ftp and telnet sessions. Of course, there are alternatives, such as Kerberos or a revised ftp or telnet client [and daemon].) --[In closing]-- In this world of tinsel locks, privacy is a dangerous illusion. As the world inexoribly heads towards a completely computer controlled society we will need some level of assurance that our secrets remain secret. Cryptogrpahy can provide this assurance. It is my humble opinion (and not much of a revalation) that cryptography will become much more commonplace in the years to come. As far as today goes, cryptography is largely a misunderstood artform. When some people think of cryptography they think of super-spys and large governments. The people that DO know about modern day cryptography, often implement it incorrectly, sacraficing it's security. The few that do know need to teach the masses that don't know. It is important to show them *why* to use it, not just how. It is also important to keep cryptography legal and thriving. If the power of unbreakable ciphers is put in the hands of the few government officials and outlawed for the masses, it would be a tragedy. More than a tragedy, it would be a violation of our intrinsic right to privacy. I don't remember where I read it: When cryptography is outlawed, only outlaws will have cryptography. He who controls the information will control the world. In the uneducated words of one late actor: "...You won't get in...It's encrypted..." --[Credit where credit is due]-- This paper could not have been possible without the following: - Bruce Schneier for his GODSEND book _APPLIED_CRYPTOGRAPHY_, which I find myself constantly reading. - Bruce Schneier for answering my questions. - The gracious community of SCI.CRYPT for answering my questions. - Paul Fahn of RSA Laboratories for the SCI.CRYPT FAQ. - Introduction to Algorithms, a very, very large and very theory- oriented book. - Paul Rubin, Adam Back, and several others for their help. - Alec Muffet, Paul Leyland, Arjen Lenstra, and Jim Gillogly for factoring the Blacknet key and showing us just how important large keys are. - Some inate hunger for knowledge I developed somewhere along the line... .oO____Oo. ______________________________________________________________ |Windows NT Security | |_____________________________________________________________| by the Nihilist 1.1 The Subject of Trust Within any network security model, the subject of trust is always an area of great complexity. The Windows NT security model centers around the concept of a domain, in which a single sign-on is necessary to access any resources (file services, print services, and program execution) where permissions have been granted. A domain model, such as the one used in Windows NT, offers ease of use for both users and for general administration but also offers many possible avenues of exploit for those inclined. The model is made more complex when the concept of a trusted domain is introduced. A trusted domain is another domain with which an explicit connection is made through a trust relationship. In Windows NT a trust relationship is one way *and* non-transitive. In order to have two domains trust each other, there must be two trust relationships established, one from domain A to domain B and another trust from B to A. Once a trust relationship is created, permissions must be explicitly granted in the trusting domain if users from the trusted domain are to have access to resources in it. The idea of non-transitive trust is that if domain A trusts domain B and domain B trusts domain C then domain A does not trust domain C. Windows NT inherently handles the mechanisms of trust and permissions securely by using ACLs (Access Control Lists), process and user Ids, and cryptographically signed tokens. Nowhere in authentication are clear text passwords used, except with FTP, telnet and a few other UNIX like utilities (the r commands and telnet are only clients on NT[1], so the security of the serving host would be the one compromised unless the passwords are the same on both systems). But these mechanisms do not, by any means, guarantee a secure environment without careful administration and guidelines. Invariably, there are nuances to the security mechanisms in all operating systems and network operating systems, Windows NT is no different. In the case of trust relationships, there is a significant peculiarity to be aware of. Once a trust relationship is established, it should be able to be broken by either domain, the trusting or the trusted, at any time. What really happens (in versions 3.1 and 3.5) is that either or both sides can sever the trust connection but it will remain in effect until the Primary Domain Controller (PDC) in either domain is rebooted. The ramifications of this would only come into play if an administrator or user in the trusting domain made data or resources available expecting that members of the formerly trusted domain did not have access. Another case maybe that it was expected that the data in a share would not be updated, but a user of the trusted domain, unaware, made changes because she/he could. The way to prevent a situation like this from happening is to remove the permissions from the resource, opposed to relying on the breaking of trust. A more insidious bug I uncovered is the ability to view and *possibly* change or create user information in the trusting domain. Normally the trusting domain has access to user names and groups from the trusted domain in order to grant permissions to resources, but the trusted domain does not have access to the trusting domain's user database. I created a trust relationship between a Windows NT 3.1 Advanced Server domain, the trusting domain, and a Windows NT 3.5 Server domain, the trusted domain. Immediately after establishing the trust, I opened the User Manager in the trusted domain and attempted to view the user database of the trusting domain. I was able to view *all* the information regarding user accounts, groups, and the domain's security policy which includes minimum password length, password aging, logon hours, tries before lockout, and user rights. At the time I was unable to attempt adding or modifying a user account. None the less, revealing this information is enough of a breach of security by itself. Remember, knowledge is power. I have not had the resources available to me to thoroughly test the extent of this bug, but I do know that any further attempts to view the user information were denied. For this bug to be exploited, one must be in the Administrators group of a domain controller or in the Domain Admin group of the trusted domain and possibly do a little social engineering. To this point, I have discussed trust in the NT sense of the word, but if one applies a more philosophical view of trust to Windows NT they will see it extends much deeper into the networking model. The concept of single sign-on in a network requires an authority, or trusted, service to validate access to resources across multiple hosts. What this implies is that if someone can crack or circumvent the trusted validation mechanisms then that individual has a free reign as far as the trust extends. The scope of a breach of this nature would include the local domain and it would extend to any trusting domains where permission has been granted to resources. When users logon to Windows NT, a security access token, which contains the user's security ID, group security IDs, user name, group names, and user rights, is created by the system from information stored in the security account manager database (similar to the UNIX /etc/passwd database, but contains much more information and is encrypted. The default location of the database is %SystemRoot%\system32\config\SAM). All processes created by the user, or run on the users behalf (impersonation), have the user's security access token attached. When a process tries to access a protected object, the Security Reference Monitor (the only access validation code in the system, which I believe is embedded in the kernel) checks the user's security token against the object's DACL and grants or denies access based on the local system's policies and standard validation routines. The SAM database is always open by a process, therefore it can not be copied or deleted regardless of the user's security level[2]. It maybe possible for a system level program to gain access to or delete the database, but the old UNIX problem of snatching password files seems to be eliminated. Therefore, the areas that seem most likely to be exploited revolve around security access tokens and the logic in the Security Reference Monitor. If processes do not set or reset tokens correctly or the Security Reference Monitor deals with obscure situations illogically, then holes like the trust bug mentioned earlier could be opened. The significance of these holes is magnified because they possibly affect multiple servers. 1.2 Do I have permission? Windows NT has probably shut the door on the less technical cracker, but poor administration could open the door back up. By default, the directory and file permissions leave the system software unnecessarily open to all, a situation that begs to be exploited through trojan horses. Also, some of the management utilities will allow any user to view information about the system like user names, group names, and application and system logs. I prefer to not give out any information about my systems other than what is necessary to accomplish the intended work. I suggest setting file permissions by hand in the %SystemRoot% and system32 directories. The entire system32 directory can be made read only to the everyone group to prevent trojan horses and tampering, and the management utilities can be made only accessible to the administrators group and any other group or user responsible for accounts and management. Also, it should never be necessary to share the system32 directory[3]. If a user can delete files from the system32 directory, it is very easy to obscure the audit logs by simply removing three files: MSAuditE.dll, MSObjs.dll, and IOLogMsg.dll. These three files supply the text of the audit entries, and without them the entries become very cryptic (but with some work one can still figure out what happened, or else just replace the files). The %SystemRoot%\system32\config directory is a prime target since it contains the system databases and audit logs. The default permissions are well thought out, but there is a precautionary measure that can be taken to insure that even if there is a complete security breach the audit logs can not be erased. The Registry can be modified to write the logs to a WORM (Write Once Read Many) device, if one is available. I recommend this type of configuration for RAS hosts and Internet gateways or any other host that needs robust auditing. In the following example, the Registry has been modified to write the security log to a WORM drive mapped to drive X: Key Name: SYSTEM\CurrentControlSet\Services\EventLog\Security Class Name: Last Write Time: 6/15/95 - 8:58 AM Value 0 Name: File Type: REG_EXPAND_SZ Data: X:\Log\SecEvent.Evt 1.3 TCP/IP and Security Running TCP/IP in a Windows NT environment does not *by it self* open any security holes (it is my protocol of choice), but some of the services and applications that have become standard in the UNIX environment do. FTP and Telnet are two prime examples of services that will send passwords un-encrypted on the wire. With such services it is really the server that is compromised, because this is where the revealed password can be used to gain access. At this point, up to and including build 1057 (version 3.51) of Windows NT, it can only be a server for FTP, with the exceptions mentioned previously. The recommended configuration for a FTP server under NT is to *only* allow anonymous access, this way no passwords for the NT machine will be divulged. The real danger comes in a heterogeneous environment where users synchronize passwords on their NT accounts and on some other system, such as a UNIX box, and use unsecure services like Telnet and FTP. A local attacker can sniff packets at the ethernet or IP level to capture the passwords, and a remote attacker can possibly spoof a local router or host and have the IP packets sent to a remote machine to be captured and analyzed. The best defense is to educate users on secure password practices and create utilities to try and test for bad habits. If operating in a pure NT environment, refrain from using UNIX style services and use the standard NT networking services. With the NT services you are protected from the standard and not so standard password and IP spoofing attacks. Even if an attacker spoofs a connection, they still have to deal with the signed tokens servers and processes check. There is one danger of information leakage with TCP/IP. If the host is multihomed, any application that binds to a port on one interface expecting to only send data on that network will be in for a big surprise. There is *no* guarantee that packets will only be sent on the interface the port is bound to. If one NIC is on a private network and the other is on a public network, there could be problems[5]. This issue is apparently fixed in the build 1057 bits. 1.4 Closing Comments Build 1057 of Windows NT has cleaned up a lot of the internals, and since I have only had access to it for three days[4], I have not tested it out *yet*. My words to live by are still: don't trust your users, don't think C2 means secure, and don't think that nobody can get in. Have fun! Footnotes 1 There are third parties that supply telnet and r command daemons, but the security issues involved with the current versions of the software are tremendous (the documentation warns of this in some cases). It is possible for an individual who is using the server locally to see what is being executed remotely and enter commands to be executed as the remote user. This prompts me to recommend against their use unless security is of NO concern. Microsoft supplies an unsupported client/server remote command execution utility (rcmdsvc.exe and rcmd.exe) with the Resource Kit that does not send passwords in the clear, but I can not speak as to whether it is actually secure. 2 It could be possible to kill the process which has the database open. This might leave the file wide open since the group everyone has full control. 3 It is possible to replace files in the system32 (or any other directory) by doing a "copy trojan.exe \\target_machine\c$\%SYSTEMROOT%\system32\AT.EXE" if the permissions are not set correctly. 4 Ah, but now I have access to thousands of them! and source! very LARGE. 5 I believe this will only manifest itself if the host thinks the destination can be reached through the other interface. Probably rare, but I have seen it happen. .oO____Oo. _____________________________________________________________ | Computer Security Threat Response | |______________________________________(is your system safe?)_| by MrZippy ---[ 1.0 ]--- INTRODUCTION If you forgot the password on your home computer, you'd be happy to find that all you have to do is pull a jumper and the password is cleared out. However, no system administrator wants access to his/her system to be that easy. In order to stay ahead of those desiring to break into their systems, sysadmins need a way to stay on top of security risks to their systems. Several computer security orginazations were formed in order to centralize reports of security threats and fixes for them. There have been numerous discussions about the impact of making this type of information available to the public, but it is my (and many other people's) opinion that publishing security loopholes can only make systems more secure. If someone does manage to gain entry to a system through a well-documented loophole, then it must be considered the sysadmin's fault for not taking action to close the hole. So, how does a sysadmin (or anyone else, for that matter) become informed of a possible security threat? There are many security-related orginazitions that publish information on potential problems. The three major players are CERT, FIRST, and [8LGM]. This article is intended to give you an overview about what these groups are about. The URL of each orginazation is provided so you may further explore them. ---[ 1.1 ]--- CERT [Computer Emergency Response Team] CERT is probably the most well-known of all computer security organizations. Based at the Carnegie Mellon University, they provide 24-hour technical assistance for responding to computer security incidents, product vulnerability assistance, technical documents, and seminars. The most visible of CERT's activities are it's *CERT Advisories*. These advisories are posted to a mailing list and Usenet news groups, and are archived at CERT's FTP site. The advisories are usually NOT highly technical, and provide only an overview of a potential threat rather than a detailed description of exactly how to exploit the threat. In their words, "A CERT advisory provides information on how to obtain a patch or details of a work around for a known computer security problem. " CERT advisories are extremely useful to sysadmins, because they outline how to fix a problem and where to obtain the resources to do it. . They are less useful to someone wishing to exploit the security hole because of the lack of technical information. In addition to publishing Advisories, CERT maintains a FTP site containing all sorts of informative materials. Archives of all CERT Advisories are stored here, as well as an archive of security-related Usenet articles. You can find RFC 1244 (the Site Security Handbook), RFC 1281 (the Guidelines for the Secure Operation of the Internet), and the Department of Defense's "Orange Book." Also kept at the site are security- related papers, technical tips for securing a system, and a small collection of security tools. ---[ 1.2 ]--- 8LGM [8-Legged Groove Machine] 8LGM is similar to CERT in that they also publish security Advisories. They actively report any vulnerabilities they find directly to the vendors that are affected. The Advisories that 8LGM publishes are made known to the relevant organizations (such as CERT), but are generally much more detailed than a CERT Advisory. 8LGM maintains not only a list of Advisories, but also a full write-up on how to exploit the security bug. The exploits are only posted after a patch or fix has been found. Most of these exploit files contain working shell scripts which demonstrate the exact problem and how easy it is to utilize it. This is provided to assist sysadmins in closing the hole and preventing any possible future exploit of the same bug. The exploit files are only available through 8LGM's email file server. People requesting exploit files are warned that their names may be published if 8LGM feels it necessary. Since the exploit files are not made available until a patch to the bug is available, it's unlikely that the information can be used in a harmful way unless a sysadmin is unaware of the problem in the first place. I find the 8LGM archive interesting because it is able to answer questions about EXACTLY how a particular loophole was utilized. You can gain a better understanding of the extent someone will go to gain access to a system, and also gain a greater sense of appreciation for the security advisory organizations. It quickly becomes apparent how easily a system can be compromised. ---[ 1.3 ]--- FIRST [Forum of Incident Response and Security Teams] FIRST is made up of members of Computer Response Teams from around the world, including government agencies, Universities, and commercial organizations. It's main purpose is to share information between it's members. FIRST is not a public organization - the information shared between members is generally not for release to the public. In fact, FIRST members must sign a non-disclosure agreement before being admitted. Members may write their own advisories, (like CERT does), but the text of communications between FIRST members stays secret. Not much else is known about FIRST. Since they do not publish their own advisories, they do not maintain a public archive. The information they have made available mainly discusses it's goals, but shows no examples of how or if they have achieved them. FIRST states that any of it's members may be contacted with security problems, and that member will assist you with a solution. Currently, the following organizations are members of FIRST: ------------------------------------------------------------ Air Force (US) Micro Bit Virus Center (Germany) ANS (US) Motorola (US) Apple Computer (US) NASA Ames (US) Assist (US) Nasirc (US) Auscert (Australia) Navcrt (US) Bellcore (US) Navy (US) Boeing (US) Nist (US) BSI (Germany) Nordunet (Denmark) CCTA (UK) Penn State (US) CERT Purdue University (US) CERT-IT (Itally) Rentar (France) CIAC-Doe (US) SBA (US) Cisco (US) Sun Microsystems (US) DDN (US) Surfnet (Netherlands) DEC (US) Switch (Switzerland) Defense Research Agency (UK) TRW (US) DFN-CERT (Germany) UK Agencies (UK) Dow (US) Unisys (US) EDS (US) US Sprint (US) GE (US) Veteran's Health Admin (US) Goddard (US) Westinghouse (US) Goldman (US) HP (US) J. P. Morgan (US) MCI (US) ------------------------------------------------------------ After reviewing the types of organizations involved in FIRST, it is very possible that major breakthroughs in computer security are originated here. Notice, though, that the only organization which actually releases information to the public is CERT. This makes you wonder what FIRST members know that they're not sharing with the rest of the world. ---[ 1.4 ]--- CONCLUSION Hopefully, this has made you more aware of a few of the resources available to sysadmins and non-admins alike. The reason that any of the organizations mentioned in this article make this type of information available to the public is to educate them. The more who know about the risks involved in running a computer system, the more secure they will be. Unless the information provided is completely disregarded by those running the systems, it is rare that the knowledge gained from these advisories can be used in a harmful manner. .oO____Oo. UNTAPPED RESOURCES: SEMICONDUCTOR REFERENCE BOOKS AND MANUFACTURERS ==================================================================== By J. Frank Parnell Many hackers would like to build their own electronic projects, but feel the knowledge required to do so is beyond them. This, in fact, is untrue. This article will hopefully help those people. The information talked about in this article is oriented to people with a basic knowledge of electronics. If you don't know a resistor from a capacitor then you should pick up "Getting Started In Electronics" (part # 276-5003) from Radio Shack. It's only $2.99 and can help give you a basic understanding of electronics and electronic circuits. Part 1 - Semiconductor Reference Books -------------------------------------- Most hackers know a computer user is only as good as the reference material they have available (or have memorized). Well, the same holds true for electronics. There is one difference though--most electronics related reference material may be obtained free of charge. What are they? ============== Semiconductor reference books (also known as databooks) contain a wealth of information. They are meant to help engineers and technicians design and construct circuits in an easy and straightforward manner. There are books for resistors, books for capacitors, books for transistors, books for integrated circuits, etc. The most useful of these books are the integrated circuit (IC) databooks. These IC databooks come in many flavors (power, digital, linear, etc.), and from many sources (National, Motorola, Texas Instruments, etc.). At the end of this article is a list of semiconductor manufacturers for your reference. First, I will explain a bit about the different types of books. Linear Analog circuits (amplifiers, voltage regulators, radio and TV circuits). Logic (TTL) Digital circuits (logic chips mostly. AND gates, multiplexers, data bus drivers). Microprocessor Like the name says, microprocessors. Memory Again, like it says, "memory." Power Usually things like high power transistor switches and high output audio drivers. Interface Line drivers, RS-232 interface chips, etc. Data conversion/ Analog to digital converters and such. acquisition These are the most common types of books. There are others also, but these books will be the ones you encounter most often. Why would I want them? ====================== So you're asking yourself, "Why in the heck would I want to find out the technical details of chips and stuff." Well, let me tell you. Along with all the technical specifications in these books there are also "typical applications." These are schematics, and sometimes circuit board designs, of common electronic circuits used in everyday consumer equipment. The engineers at these companies, some of the brightest people around, have sat down and designed almost every conceivable use of each chip their company manufactures. They have done such a good job that people with just a rudimentary knowledge of electronics can take this info and build themselves perfectly functioning electronics circuits. "Engineering by databooks" is very common in all types of industries. It takes less time, costs less money, etc. Why re-invent the wheel? Some examples of "typical applications" are: Radio control circuits Controlling something remotely, or getting a signal from a remote place when something happens. DTMF generators Generating your own DTMF tones for telephone communications. Ultrasonic transceivers Wireless communications. You could make a wireless burglar alarm. Speech synthesizers Verbal communications (e.g. you think somebody might recognize your voice). Audio amplifiers Listening to faint conversations. The list goes on and on. Almost anything you can think of has already been designed by the engineers that work at these IC companies, although they won't be called things like "red box." Instead they will be called something generic (like DTMF tone generators). Almost everything I have built was already designed in a databook. There are some exceptions, like radios. Complex (or semi-complex) things are laid out in functional blocks. A radio will have an RF receiver, a tuner and an output amplifier. So, you just have to hook each of these separate circuits together to end up with your final circuit. [This is actually a poor example, but you get the picture.] Where can I get these books? ============================ Perhaps the most reliable place to get these books is direct from the IC manufacturers. They have these technical reference books printed up by the thousands just for people like you and me. Sometimes, if you get the right person, they will send you a complete set of all their books. Another place to find them is at electronics suppliers. They get tons of databooks from the IC manufacturers. In fact, they often get so many that they have to throw some of them out. Several years ago all of these suppliers would hand these books out free. A friend and I would go around to the different suppliers in the area and load up on databooks. In just a few hours, we would have a truck load. The practice of just handing them out is getting increasingly scarce nowadays. The suppliers feel it's another way to make money and so they are starting to charge for them. But not all suppliers do this, so look around and ask. The easiest way to find the suppliers is to look in the yellow pages under: Electronic equipment wholesale & manufacturers Electronic supplies wholesale & manufacturers or something similar. You can also find them by calling the chip manufacturers and asking them for local suppliers in your area. The last easy place you can find these books is at electronic trade shows. Most major cities have them every year or two. They will usually be in some big convention center or arena (the same place they would have home shows, boat shows, lawn and garden shows, etc.) You will probably have to do some digging to find out when they are scheduled. The chip manufacturers will set up booths to show off their latest products, and often times they will have some sort of "goody" to entice people to stop by their booths. These goodies might be key rings, sample parts, or candy but often they are databooks. If they don't have databooks at the show, or if they are all gone, you can ask the company representative at the show to send some to you. He will take your name and address and send them out in a few weeks. How does one get these books? ============================= It will be easiest to get these reference books if you work for a high-tech company or you are in college (or some type of school). Depending on which situation you are in, you can try one of the following: If you are with a company, as opposed to school, then your best route would be going to an IC manufacturer. When you get books from them they will usually pay the shipping. To get the books you need to talk with somebody in the sales department. A typical conversation might go like this: IC mfg. "Hello, blahblahblah IC company." You "Hi, could I have sales please." IC mfg. "Just a minute." IC mfg. "Hello, this is Joe Salesman, can I help you?" You "Hi Joe, this is John Q. Public with Electro-cool company. The databooks we have for your company are several years old and I was wondering if you could send me out a new set?" IC mfg. "Okay. Can I have your shipping address?" You "Sure, it's blahblahblah, and could you mark the package 'attention John Q. Public'?" Sometimes the salesperson will say that they have to charge for the books. If this happens, just say you are not interested. Then call back in a few days and try to talk with a different person. If you are in school, then your best route would probably be a local electronics supplier. But you can try either one regardless of your situation. When you get databooks from a local supplier you will probably have to pay for shipping yourself, so your best bet is to just go to their place and pick up the books. Again, you want to talk with somebody in sales. A typical conversation might go like this: Supplier "Hello, blahblahblah electronics supplier." You "Hi, could I have sales please?" Supplier "Just a minute." Supplier "Hello, this is Joe Salesman. Can I help you?" You "Hi Joe, this is John Q. Public at Bigshot University. I'm working with the electronics lab, and we would like to update our reference books. Do you guys have any IC databooks?" Supplier "Yes we do. We have blahblahblah and so&so." You "Would it be possible for me to come down and get a few databooks for our lab?" Supplier "Certainly. Our address is blahblahblah." You "All right. I will come down tomorrow. Thanks a bunch." Now, if these guys want to charge for the books, then you need not call back because you will get the same response from everybody there. Just tell them you are not interested. If you are getting the databooks from an electronics convention, then just act professional and dress nicely, because you will be judged by your appearance. The sales people there are specifically picked to be the "suckup" type that wants to please, so you should have no problem. Why do they give them away? =========================== You might be saying to yourself, "This sounds to good to be true, there must be a catch or something." Well, yes and no. Today, integrated circuits are so complex that if you did not have these reference books to help you along you would be lost. There is no way in the world you could figure out how to use an IC just by looking at it. You need to have these technical books to do anything. This being the case, the manufacturers of these chips would not be able to sell even one of their chips if an engineer (or technician) could not figure out how to use them. This is why these books are given away. It all has to do with marketing their products. Now the catch, they won't just give them to Joe Blow on the street. They must feel there is a potential "sell" somewhere in the future. In other words, there is a marketing strategy behind it. So most of the time they will only give them to people at schools (universities, colleges, technical schools, high schools, etc.) or people in high tech industries (software, hardware, consumer electronics, research facilities, etc.). The people in these industries and institutions are much more likely to buy these products than your average Joe on the street (who would not know how to use these reference books let alone buy any of these products). Since most hackers will actually be buying these products, there should not be a problem. Part 2 - Semiconductor Manufacturers ------------------------------------ Semiconductor manufacturers can provide you with more than just databooks. They can also provide you with technical expertise and even free parts. They provide all of this in the name of sales. Since these things help people use their products, they are more than happy to do this. Getting technical help ====================== IC manufacturers usually have an entire department of engineers to help their customers when they are having trouble using their chips. They can walk you through how a circuit works, fax you updated schematics, give you ideas on other ways to use their chips, etc. Say you are trying to make a DTMF decoder and you got all the info from the databook, and you put it together just right and it still doesn't work. You can call these guys up and ask them for help. This time when calling, you will want to talk with an application engineer instead of a salesperson. A typical conversation might go like this: IC mfg. "Hello, blahblahblah IC company." You "Hello. I'd like to speak to an application engineer, please." IC mfg. "Just a minute." IC mfg. "Hi, this is Joe Engineer, can I help you?" You "Hi Joe, this is John Q. Public with Electro-cool company. I have been working with your ABC123 DTMF decoder chip and I am having a few problems. Can you help me?" IC mfg. "Sure, what kind of problems are you having?" You "Well, I hooked up the circuit the way your databook said to and it isn't decoding..." IC mfg. "OK. Have you checked blahblahblah?" etc... These engineers are really a godsend. They will go out of their way to help you. I have actually had some engineers draw up complete schematics and fax them to me. Getting free parts ================== Another thing IC manufacturers will do is provide you with free parts. OK, say you are the entrepreneurial type, and you have designed some kind of cool electronic gizmo that you want to sell to "2600" readers, but you are not sure if your design will actually work or not. You can call the IC manufacturers and ask them to send you a sample part. You will need to talk with customer support to get sample parts. A typical conversation might go like this: IC mfg. "Hello, blahblahblah IC company." You "Hi. Can I have customer support?" IC mfg. "Just a minute." IC mfg. "Hi, this is Joe Supportperson. Can I help you?" You "Hi Joe, this is John Q. Public with Electro-cool company. I am doing a little research project with DTMF decoders and I was hoping you could send me a sample ABC123 chip so I can verify if the project is viable or not. I just need one to verify the circuit design." IC mfg. "Sure, where would you like it sent?" You "Send it to Electro-cool company at blahblahblah. And could you mark it 'attention John Q. Public'?" IC mfg. "No problem. You should have it in a couple of days." Some other situations in which you could get sample parts is if you need just one chip and you can't find anybody to sell you just one, or if you can't find the chip from any supplier, anywhere. Just call the manufacturer and ask them for a sample. Most likely they will help you. This practice of sampling parts is very common in the electronics industry. Again, it all has to do with marketing, sales, and customer satisfaction. A final note about dealing with semiconductor manufacturers =========================================================== Many times when you call and ask for specific departments the receptionist will ask "for what product, sir"? Just tell them "ICs." Also, when you ask for sample parts you may be asked a few questions about how many you might purchase in the future. Because I work in a research department I tell them "I have no idea. It depends on the project making it out of the research stage." Also, remember to be courteous--these people are helping you. Additional References ===================== Semiconductor suppliers ----------------------- The following companies will sell electronic parts to anybody (i.e. you don't need to be working for a high-tech company or going to school). You can call these companies and get their catalogs, free. As well as describing the products they sell, these catalogs have some useful information in them. Digi-Key Corporation 701 Brooks Ave. South, P.O. Box 677 Thief River Falls, MN 56701-0677 USA TELEPHONE: 800-344-4539 FAX: 218-681-3380 FAX OTHER: 800-344-4539 Mouser Electronics 24-T Hwy. 287 N., P.O. Box 719 Mansfield, TX 76063 USA TELEPHONE: 817-483-4422 FAX: 817-483-0931 FAX OTHER: 800-346-6873 TELEX II4 510-601-0375 TWX Semiconductor manufacturers --------------------------- Here is a list of some of the more common semiconductor manufacturers. Advanced Micro Devices, Inc. One AMD Place, P.O. Box 3453 Sunnyvale, CA 94088-3453 USA TELEPHONE: 408-732-2400 Intel Corp. 3065-T Bowers Ave. Santa Clara, CA 95052-8121 USA TELEPHONE: 408-765-8080 OTHER: 800-548-4725 Motorola, Inc., Semiconductor Products Sector 3102-T N. 56th St. Phoenix, AZ 85018 USA TELEPHONE: 602-952-3248 FAX: 602-952-6100 FAX National Semiconductor Corp. 2900 Semiconductor Dr., P.O. Box 58090 Santa Clara, CA 95052-8090 USA TELEPHONE: 408-721-5000 FAX: 408-739-9803 OTHER: 800-272-9959 910-339-9240 TWX NEC Electronics Inc. 401-T Ellis St., P.O. Box 7241 Mountain View, CA 94039 USA TELEPHONE: 415-960-6000 FAX: 800-729-9288 FAX OTHER: 800-632-3531 SGS-Thomson Microelectronics Inc. 1310-T Electronics Dr. Carrollton, TX 75006 USA TELEPHONE: 214-466-6000 FAX: 214-466-6572 FAX Siemens Components Inc., Integrated Circuit Div. 10950 N. Tantan Ave. Cupertino, CA 95014 USA TELEPHONE: 408-777-4500 FAX: 408-777-4977 FAX OTHER: 800-338-2777 Texas Instruments, Inc. P.O. Box 255012, M.S. 57 Dallas, TX 75265-5012 USA TELEPHONE: 214-995-2011 FAX: 214-995-4360 FAX OTHER: 800-336-5236 Ways how to help keep your privacy by Deliryum Privacy. Its something that all of us should strive to obtain. Not because we feel we have something to hide, but becuase we have something to protect. The world in which we live today is not exactly a friendly place to be anymore. Crime is all around us; Though no longer are the lines so very well drawn as to who are the criminals and who are your friends as they may have been in past times. Our neighbors, police, even our very government could possiblly turn out to be our worse enemies. Is this just idle paranoia or something quite sinister and *very* real? Take a long hard look at the world today folks and that question should be easy to answer. Below are various things you can do to help maintain your privacy. Although there are no garrantees of *total* privacy, these procedures will certainly help secure your privacy to a greater degree than most. Do your best to stay away from trouble with the law. They like information about people and will do practically anything to get it. Keep your record as clean as possible. If you do get in trouble with them do not say anything. You are under no obligation to talk to them. Make sure your attorney is present if you do however. If you say nothing that will incriminate you or others then that will make it that much harder on them to screw you over. This cannot be stressed enough! Believe it, live it, follow it. Never tell strangers where you work. Always give fake info on this. Tell them that you are self employed, aren't employed, etc etc... If you are paid by check, DON'T deposit the paycheck into a bank account that has any bearing upon you. Such as one that has your name as the owner of said account.. :) The best measure as to cashing the check would be to go to the bank whose name is printed upon the check. Never make a regular schedule of cashing your checks as this might allow a cashier/other bank employee the ability to recognise you as you would be a "regular". Habits of such would be one of the first things a person might check out to get information on you. Also, on the subject of jobs, you should watch what info you give about yourself to other workers. Also in dealing with strangers and people that you really don't know on a very personal level in general be wary of what you say pertaining to yourself. The less you tell of yourself, the harder you make it on potential "snoops". The popular phrase from the X-files show of "trust no one" is the key mindset here. In your finacial dealings, try to stick to cash. Cash leaves no paper trail and is practically impossible to trace in itself. If you can't use cash as in the case of mail order use money orders as they are hard to trace whereas checks are quite traceable. In the case of mail order items, always have them sent to a "drop site". This should not be a post office box either. This rule should apply to all mail in general for that matter. Also on that subject, when sending US mail never put your address on the outside of the letter. When dealing with US mail use a typewriter/printer to make out the letter. Handwriting can be traced back to you should a test be preformed upon samples. After typing the letter out make a copy of it via a copy machine and mail the copy. Destroy the original. This will make it next to impossible to trace the letter back to a particular machine. When using E-mail always encrypt any sensitive information. Please refer to Daemon9's article once again if you have not in this issue of IC. Do your best to keep secret the names of your friends/family. Also, always tell your friends/family NEVER EVER EVER to give out information concerning you. This being phone numbers, addresses, etc etc etc... Make sure you are quite adamanate about this! Keep your home in such a manner that it would not draw un-needed attention. In this I mean don't throw large parties that would get the notice of your pesky ass neighbors. Keep your music low. Keep your yard clean and well mowed. Keep yourself in a likewise manner. By this I mean do not behave in a way that is "unacceptable" to the community at large. This will draw attention to yourself from others as they will think you are "strange". I know this may be a stretch for most of you (myself included in this.. heh ). Also, do not be "unfriendly" to people, but make sure you are not overly friendly either. To do so either way will bring attention to yourself. To keep them from taking an interest in you, so to speak, act like them, talk like them, be like them. Like they say... when in Rome... do like the Romans... :) When going to a doctor or such try not to use your real name if you possibly can. By this I mean, if you can afford it (that meaning that you can pay in cash for the services provided) give a fake name and address on any forms you are given. Fake id should be a definate must in these cases as they are most likely going to request some form of id or another. This advice should go for pharacists as well if you are needing to have medicine filled. Do not affiliate your self in groups or clubs. Such being *any* politically active group, Kiwanas club, PTA, Militias (heh), etc etc etc... Keep to yourself on your views concerning "controversial" subjects to yourself. Siding with such groups will most certainly draw attention to yourself by someone. Avoid being fingerprinted. Many jobs ask that thier employees be fingerprinted for id purposes... Don't allow this to be done on you. Several times a year tv ads will come out about how a person should be finger printed with the fbi so if they end up missing the fbi can help search for the missing person, etc etc.. well while that might be a big help in finding a lost loved one it also helps to kill your personal privacy as that will be entered in the NCIC. In other words, don't let them print ya. :) In the case of legal trouble when they are ganna print ya whether you like it or not have your lawyer file for expungement of your records after your trial/payment of fees. Its ganna cost ya (believe me.. it will), but expungment will order by the courts that all records pertaining to your case be destroyed. In other words, as far as the law is concerning.. the crime was never took place. A clean record is a good thing too... heh To start off you should stop attending church. For the most part, church ppl are some of the nosiest people around. It seems like they want to know everthing about you and will gossip like crazy about you. If you are that devoutly religeous and value that over your privacy you should change the church that you currently attend and use another name at the new church. Also, speaking of which you should give false information about yourself concerning everything related your attendance of that church. In other words, if you are asked where you live give a fake address. Basically bullshit info to anything relating to "you" at that particular church. if you give to the offering box give in cash. Do not use a check. A paper trail is quite easy to trace. If you are asked by someone (neighbor, whomever) of the name of the church you attend you should give the name of another church than the faith of the one that you attend or just tell them that you do not attend at all. Do NOT let them talk you into going to thier church. Once again I stress you should really stop attending church as this will enhance your privacy. Avoid getting yourself into a "routine". Most of us fall victim to this. We do things a certain way and manner. Such as driving to and from work. We normally alway take the same route. Vary the ways in which you do things. Habits mark us and thus can be used against us. When making phone calls, NEVER dial 1-800 numbers or any other number that has ANI capabilites from your house... ie.. 911 (well, only if you have to from your phone), 1-900's, etc etc... They will have the number you are at if you do. Also, concerning your phone bill ask the phone company what you can do to make your line more private. Block out caller id, have an unlisted number, have it where your information is flagged where it can't be given out to the LD companies such as at&t and the like, etc etc... Also request that a passcode be put on your bill with them and have that passcode be used for *ALL* trans- actions concerning your account with them. Such as phone canceling, changing of status of the line, etc etc... Finally, when disposing of "sensitive" information make sure you rend it so it cannot be recovered. In the case of electronic data, one should encrypt it with such a program as PGP, wipe (not erase) it, and then possibly (if its VERY sensitive) run a defrag on your harddrive as well. This should make it impossible for a recovery. In the case of "physical" items, such as US mail, documents, disks, etc...shreading is a good idea followed by burning the remains and then scattering them. Remeber police agencies need no warrent to search your trash. Keep this in mind. Paranoia is a good thing. While there is no sure fire way to completly remaining anonymous short of completly revamping your identity, the above measures will greatly enhance the level of your personal privacy. Well, this about does it for me. Take care folks and always watch your backs. You never know who may be back there waiting with the proverbial knife... :) Deliryum .oO____Oo. _+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_ + Mythrandir's Greetings and such + _+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_+_ A special hi and hello to all those who have touched my life: Dexter - If this ever finds its way to you, GO to my family's house and get my phone number and use that wonderful tool called the phone. As you said, We have much to talk about. ReDragon - The man who made me feel special when he said things like, Mythrandir is the first person to come on #hack in a long time that was a complete and utter idiot. (perhaps the word wasn't idiot), and JUST THE OTHER DAY I WAS THINKING TO MYSELF WTF HAPPENED TO MYTHRANDR. Now, how can you not love this guy? Zem - The guy who was working right along with me, when I rediscovered computer hacking. It was a fine night of delving into the network around us. Also, the creator of probably the most unique application the guild will ever receive. Tim - Me TIM at DEFCON. All I have to say is, thanks Tim! You've done so much good, and you don't even realize it. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- = Obtaining Information on Other People = - By, - = Mythrandir = -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Recently, I was given a copy of a post to alt.privacy which dealt with the acquiring of knowledge through public records. I found the subject very interesting so I decided to look into it. As luck would have it I found two interesting books on the subject in the reference section at a bookstore down at my college. I read through these two books, and found that obtaining information on another individual was very easy. The two books I purchased were Researching Public Records by Vincent Parco and published by Citadel Press under the Learning Annex books series. The ISBN is 0-8065-1522-8 The book cost me $8.95. Private Investigating Made Easy by Kelly E. Riddle and published by Historical Publications. The ISBN is 1-881825-05-1 The book cost me $12.95. This article documents the general information that I gained while reading these books. If you wish more detail and pointers to resources, I recommend picking these books up. First off, it is entirely legal to use public records for investigation of another individual. However, you must obtain a liscense in order to investigate for money. If you are trying to obtain information on a person, you should first detail exactly what you know and what you are trying to find out. The basic information that you should try to collect (and the more you have the easier your search will be) is.. Name (full name) - When doing searches be sure to search on all possible variations of a name. If a persons name is Timothy X. you should also search under Tim X. Birth Date - This is needed to access some records. Social Security Number - Again some records are searched by this number. Address - This is mostly useful in order to find a person Phone Number - Useful to have so you can call, and obtain more information through social engineering. Or you can just have a nice chat with the person you are trying to obtain information about. Description - Helpful in determining who a person is if you do not have a lot of the above information. Occupation - Also useful in finding a person as well as determining the financial position of your subject. Of course there are many other things that you can find out about a person, but the above are very useful in tracking down someone and after that you can do what you will. So how do you obtain this information? Well, it is very easy. Two of the best places to start are the Board of Elections and the good ole DMV. In order to do a search at the board of elections you need to have a list of names that you are searching for. A birth date or approximate birthdate can also be helpful. The board of elections holds voter registration records that you can access. These records will allow you to verify a persons name, when they were born, a general description, their current address, how long they have lived there, immigration status, and politcal party. It is also possible for you to obtain their phone number if they recorded it in an optional field. As you can see this one stop is very useful for obtaining plenty of information. There is of course one hitch, they must have registered to vote. So the board of elections doesn't turn up anything. Well, chances are the subject drives. So off to the DMV you go. In order to do a search at the DMV you need a full name, birthdate, and possibly a drivers liscense number (but not always). Also, you need to call the appropriate DMV for which state you are searching. The DMV holds drivers registration information. This will get you the persons full name, birth date, their driving record, date liscense issued and when it expires, and any restrictions the subject has on driving. Also, if you are searching by liscense plate you can obtain the full name of the owner of a vehicle (not necessarily the driver), the vehicle identification number, year and model of the vehicle, insurance company, registration and expiration, lien holder, and the color of the vehicle. All useful information as well. Well, at this point you have probably already ammased quite a bit of information. But suppose you are trying to find a person, and they are not living at the address that is listed on their drivers liscense. At this point you should head on over to the post office and fill out a freedom of information act form requesting the forwarding address of an individual. You need the persons name and last place of residence. This will usually work if someone filled out a mail forwarding card when they moved. However, it is possible for the subject to request that the information not be given out by paying a small fee. (So for future reference, if you move, ask about this option and pay the few dollars for your privacy) Other places to obtain information is the County Courthouse where you can obtain Criminal recordes, civil records (divorces, debts..) , birth records, marriage liscenses, death records, and many other pieces of information. One useful search is to see if the subject owns any businesses. A little investigation into these areas should yield tremendous results. If you have any questions about searching records or need any help please feel free to contact me at jwthomp@uiuc.edu Best of luck, Mythrandir P.S. I intentionally did not go into full detail with this, but felt it was better to just lay down the basics to allow people to explore this. I am certain that you will find all of your endeavors fruitful and very interesting. .oO____Oo. ---------------------------------------------------- + Linux Network Sniffing + ---------------------------------------------------- The following file that I have included is a basic network sniffer that will run on linux boxes. It is very easy to port it over to other platforms as all you have to do is rewrite the network code section. inet.h - contains all of the includes for the networking code to work. globals.h - contains one global definition.. Perhaps later I'll add another. packet.h - contains the definitions for the packets. Currently only tcp/ip is supported. struct PACKET will hold one packet struct CONNECTION defines a unique connection pair find.h & .c - contain the code for a very simple pattern matching algorithm. sniff.c - contains the bulk of the sniffer code sniff.h - contains the definitions for sniff.c. init - initializes the network interface. This will need to be modified if this is ported to a new platform. Get_Packet - grabs a packet from the network This will also have to be modified if a port is attempted. Convert_Packet - converts the raw char string buffer into a struct PACKET. This should be modified in the future to check for what type of packet it is.. i.e. tcp/ip, tcp/udp, IPX.. Set_Connection - Defines the values for a unique connection pair into struct CONNECTION Write_Data - Merely outputs the data portion of a PACKET onto the screen Display_Connections - Displays a list of unique connections from an array of CONNECTIONS.. Not very eligant. Data_Length - Returns the length of the data portion of a PACKET main.c - Contains the main loop, that utilizes this code. In its present form it captures all packets that traverse lo (loopback) and display them on the screen... If you would like to watch another interface change the name string to another interface, such as eth0.. I have modified this program to act as a password sniffer, but have not included it as it is still far to rough looking (yes even in comparison to this). I will however, release it as soon as I am happy with it. I also plan to release an updated version of this sniffer that will check for packet type and print out the appropriate type. Even though this code is rough, it should be very easy for someone to rip apart and play with. I am interested to hear of anything anyone does with it, and as always am more than willing to help out or to answer questions. - Mythrandir The following is a shell archive of the code. Create a directory and place this in it as sniff.shar Then type sh sniff.shar and it will self extract. #!/bin/sh # shar: Shell Archiver (v1.22) # # Run the following text with /bin/sh to create: # OUT # README # find.c # find.h # globals.h # inet.h # main.c # packet.h # sniff.c # sniff.h # sed 's/^X//' << 'SHAR_EOF' > OUT && SHAR_EOF chmod 0644 OUT || echo "restore of OUT fails" sed 's/^X//' << 'SHAR_EOF' > README && XTo compile on a Linux box type Xgcc -o Sniff find.c main.c sniff.c X XEnjoy, X XMythrandir SHAR_EOF chmod 0644 README || echo "restore of README fails" sed 's/^X//' << 'SHAR_EOF' > find.c && X#include X Xint Find(char * String, char * Match, int length2) X{ Xint length; Xint i, k; Xchar buf[100]; X Xlength = strlen(Match); X Xif(length2 < length) X return 0; X Xfor(i = 0; i < (length2 - length); i++) X { X for(k = 0; k < length; k++) X buf[k] = String[k + i]; X if(!strncmp(buf,Match,length)) X return 1; X } X Xreturn 0; X} SHAR_EOF chmod 0644 find.c || echo "restore of find.c fails" sed 's/^X//' << 'SHAR_EOF' > find.h && Xint Find(char * String, char * Match, int); SHAR_EOF chmod 0644 find.h || echo "restore of find.h fails" sed 's/^X//' << 'SHAR_EOF' > globals.h && X#define PACKET_LENGTH 500 X X X SHAR_EOF chmod 0644 globals.h || echo "restore of globals.h fails" sed 's/^X//' << 'SHAR_EOF' > inet.h && X#ifndef INET X#define INET X X#include X#include X#include X#include X X#include X#include X#include X#include X#include X X#include X#include X#include X#include X X Xchar *pname; X X#endif SHAR_EOF chmod 0644 inet.h || echo "restore of inet.h fails" sed 's/^X//' << 'SHAR_EOF' > main.c && X#include "sniff.h" X#include "inet.h" X#include "find.h" X X#include X Xvoid main() X{ XFILE * fd; Xint i,j; Xint choice; Xchar name[2]; Xchar buf[500]; Xstruct PACKET *Out; Xstruct CONNECTION List[256]; Xchar View[256][50]; Xchar Data[256][50]; Xstruct CONNECTION Check[1]; Xint toggle = 0; Xint count = 0; /* Stores the number of unique connections */ X Xstrncpy(name, "lo\0", 3); X Xinit(name); X Xwhile(1) X { X X /* X * Get the next packet to fly by the network X */ X Get_Packet(buf); X X /* X * Convert the buffer into a Packet type structure X */ X Out = Convert_Packet(buf); X X /* X * Display all of the packet information X */ X Display_Packet(Out); X X /* X * If the program detects login in the text it will then check X * if the connection is unique X */ X if(Unique(List, Out, count) == -1) X { X printf("Found a Unique connection\n"); X count = count + 1; X Display_Connections(List, count); X } X X } X} SHAR_EOF chmod 0644 main.c || echo "restore of main.c fails" sed 's/^X//' << 'SHAR_EOF' > packet.h && X#include "globals.h" X X X X Xstruct iphdr { X unsigned char version; X unsigned char tos; X unsigned char tot_len[2]; X unsigned char id[2]; X unsigned char frag_off[2]; X unsigned char ttl; X unsigned char protocol; X unsigned char check[2]; X unsigned char saddr[4]; X unsigned char daddr[4]; X }; X Xstruct tcphdr { X unsigned char source[2]; X unsigned char dest[2]; X unsigned char seq[4]; X unsigned char ack_seq[4]; X unsigned char flags[2]; X unsigned char window[2]; X unsigned char check[2]; X unsigned char urg_ptr[2]; X }; X X/* X * A structure which contains all of the parts of a packet X */ X Xstruct PACKET { X struct iphdr IP; X struct tcphdr TCP; X char DATA[PACKET_LENGTH]; X }; X Xstruct CONNECTION { X unsigned char protocol; X unsigned char saddr[4]; X unsigned char daddr[4]; X unsigned char source[2]; X unsigned char dest[2]; X unsigned char seq[4]; X unsigned char ack_seq[4]; X }; X X SHAR_EOF chmod 0644 packet.h || echo "restore of packet.h fails" sed 's/^X//' << 'SHAR_EOF' > sniff.c && X#include X#include X#include X X#include "inet.h" X#include "sniff.h" X#include "globals.h" X X/* Globals */ X X X Xint Sock; Xstruct ifreq oldifr, ifr; X Xvoid init(char * DEV) X{ X XSock = socket(AF_INET, SOCK_PACKET, htons(ETH_P_ALL)); X X/* X * Stores device name to access in ifr and oldifr X */ Xstrcpy(ifr.ifr_name, DEV); Xstrcpy(oldifr.ifr_name, DEV); X X/* X * Stores the cards current setting into ifr and oldifr X */ Xif(ioctl(Sock, SIOCGIFFLAGS, &ifr) < 0) X { X printf("Unable to get %s flags.\n", DEV); X exit(1); X } X Xif(ioctl(Sock, SIOCGIFFLAGS, &oldifr) < 0) X { X printf("Unable to get %s flags.\n", DEV); X exit(1); X } X X/* X * Sets ifr's flags to include Promiscuous Mode X */ Xifr.ifr_flags |= IFF_PROMISC; X X/* X * Sets devices flags to that of ifr's X */ Xif(ioctl(Sock, SIOCSIFFLAGS, &ifr) < 0) X { X printf("Unable to set %s flags.\n", DEV); X exit(1); X } Xprintf("%s device has been successfully configured.\n", DEV); X} X Xvoid Get_Packet(char buf[PACKET_LENGTH]) X{ Xint length; Xstruct sockaddr saddr; Xint sizeaddr; X Xlength = recvfrom(Sock, buf, PACKET_LENGTH, 0, &saddr, &sizeaddr); X X X} X Xstruct PACKET * Convert_Packet(char buf[PACKET_LENGTH]) X{ Xint i; Xchar tmp[PACKET_LENGTH]; Xstruct PACKET Holder; X X/* X * Copy over ip information X */ Xfor(i = 14; i < 34; i++) X tmp[i - 14] = buf[i]; X/* X * Copy tmp to iphdr structure X */ Xbcopy(tmp, &Holder.IP, 20); X X/* X * Copy over tcp information X */ Xfor(i = 34; i < 54; i++) X tmp[i - 34] = buf[i]; Xbcopy(tmp, &Holder.TCP, 20); X Xfor(i = 54; i < PACKET_LENGTH; i++) X tmp[i - 54] = buf[i]; Xbcopy(tmp, &Holder.DATA, (PACKET_LENGTH - 54)); X Xreturn &Holder; X} X Xvoid Display_Packet(struct PACKET * Out) X{ Xint i,k; /* loop variables */ Xint dlength; X X X X/* X * Display ip Information X */ Xprintf("Header Length: %d Service Type: %d", X Out->IP.version & 0x000f, Out->IP.tos & 0x00ff); Xprintf(" Total Length: %d\n", X (Out->IP.tot_len[0] & 0x00ff) * 256 + (Out->IP.tot_len[1] & 0x00ff)); Xprintf("Id: %d FragFlags: %d\n", X (Out->IP.id[0] & 0x00ff) * 256 + (Out->IP.id[1] & 0x00ff), X (Out->IP.frag_off[0] & 0x00ff) * 256 + (Out->IP.frag_off[1] & 0x00ff)); Xprintf("TTL: %d Protocol: %d HeaderChecksum: %d\n", X Out->IP.ttl & 0x00ff, Out->IP.protocol & 0x00ff, X (Out->IP.check[0] & 0x00ff) * 256 + (Out->IP.check[1] & 0x00ff)); Xprintf("Source Address: %d.%d.%d.%d Destination Address: %d.%d.%d.%d\n", X Out->IP.saddr[0] & 0x00ff, Out->IP.saddr[1] & 0x00ff, X Out->IP.saddr[2] & 0x00ff, Out->IP.saddr[3] & 0x00ff, X Out->IP.daddr[0] & 0x00ff, Out->IP.daddr[1] & 0x00ff, X Out->IP.daddr[2] & 0x00ff, Out->IP.daddr[3] & 0x00ff); X X/* X * Display tcp information X */ X Xprintf("Source Port: %d Destination Port: %d\n", X ((Out->TCP.source[0] & 0x00ff) * 256) + (Out->TCP.source[1] & 0x00ff), X ((Out->TCP.dest[0] & 0x00ff) * 256) + (Out->TCP.dest[1] & 0x00ff)); Xprintf("Sequence Number: %ld Acknowledgement Number: %ld\n", X (Out->TCP.seq[0] & 0x00ff) * 65536 + (Out->TCP.seq[1] & 0x00ff) * 4096 X + (Out->TCP.seq[2] & 0x00ff) * 256 + (Out->TCP.seq[3] & 0x00ff), X (Out->TCP.ack_seq[0] & 0x00ff) * 65536 + (Out->TCP.ack_seq[1] & 0x00ff) * 4096 X + (Out->TCP.ack_seq[2] & 0x00ff) * 256 + (Out->TCP.ack_seq[3] & 0x00ff)); Xprintf("TCP Header length: %d Checksum: %d Urgent Pointer: %d\n", X (Out->TCP.flags[0] & 0x00f0) >> 4, (Out->TCP.check[0] & 0x00ff) * 256 + X (Out->TCP.check[1] & 0x00ff), (Out->TCP.urg_ptr[0] & 0x0ff) * 256 + X (Out->TCP.urg_ptr[1] & 0x00ff)); X X/* X * Display data information X */ X X/* X * Data length = Total length - IP header length - TCP Header length X */ Xdlength = (Out->IP.tot_len[0] & 0x00ff) * 256 + (Out->IP.tot_len[1] & 0x00ff) X - (Out->IP.version & 0x000f) * 4 - ((Out->TCP.flags[0] & 0x00f0) >> 4) * 4; X Xprintf("Data Length: %d\n", dlength); Xif((Out->IP.tot_len[0] & 0x00ff) > PACKET_LENGTH) X dlength = PACKET_LENGTH - (Out->IP.version & 0x00ff) * 4 - X ((Out->TCP.flags[0] & 0x00ff) >> 4) * 4; Xprintf("-------------------------------------------------------------\n"); Xfor(i = 0 + (((Out->TCP.flags[0] & 0x00f0) >> 4) - 5) * 4; X i < (dlength + (((Out->TCP.flags[0] & 0x00f0) >> 4) - 5) * 4); X i += 16) X { X if((dlength + (((Out->TCP.flags[0] & 0x00f0) >> 4) - 5) * 4) - i >= 16) X for(k = 0; k < 16; k++) X if((Out->DATA[i + k] & 0x00ff) < 16) X printf("0%x", Out->DATA[i + k] & 0x00ff); X else X printf("%x", Out->DATA[i + k] & 0x00ff); X else X for(k = 0; k < (dlength + (((Out->TCP.flags[0] & 0x00f0) >> 4) - 5) * 4) - i; k++) X if((Out->DATA[i + k] & 0x00ff) < 16) X printf("0%x", Out->DATA[i + k] & 0x00ff); X else X printf("%x", Out->DATA[i + k] & 0x00ff); X printf(" "); X if((dlength + (((Out->TCP.flags[0] & 0x00f0) >> 4) - 5) * 4) - i >= 16) X for(k = 0; k < 16; k++) X if((Out->DATA[i + k] & 0x00ff) > 39) X printf("%c", Out->DATA[i + k]); X else X printf("."); X else X for(k = 0; k < (dlength + (((Out->TCP.flags[0] & 0x00f0) >> 4) - 5) * 4) - i; k++) X if((Out->DATA[i + k] & 0x00ff) > 39) X printf("%c", Out->DATA[i + k]); X else X printf("."); X printf("\n"); X } Xprintf("-------------------------------------------------------------\n"); X} X Xint Unique(struct CONNECTION List[256], struct PACKET * Out, int count) X{ Xint i,j; /* Loop counters */ Xint flag = -1; Xint num; /* Number where non uniqueness occurs */ X X/* X * Scan through list of connections and see if Out differs. X */ Xfor(i = 0; i < count; i++) X { X /* X * Checks if this is a non-unique connection X */ X if((Out->IP.protocol & 0x00ff) == (List[i].protocol & 0x00ff)) X if((Out->IP.saddr[0] & 0x00ff) == (List[i].saddr[0] & 0x00ff)) X if((Out->IP.saddr[1] & 0x00ff) == (List[i].saddr[1] & 0x00ff)) X if((Out->IP.saddr[2] & 0x00ff) == (List[i].saddr[2] & 0x00ff)) X if((Out->IP.saddr[3] & 0x00ff) == (List[i].saddr[3] & 0x00ff)) X if((Out->IP.daddr[0] & 0x00ff) == (List[i].daddr[0] & 0x00ff)) X if((Out->IP.daddr[1] & 0x00ff) == (List[i].daddr[1] & 0x00ff)) X if((Out->IP.daddr[2] & 0x00ff) == (List[i].daddr[2] & 0x00ff)) X if((Out->IP.daddr[3] & 0x00ff) == (List[i].daddr[3] & 0x00ff)) X if((Out->TCP.source[0] & 0x00ff) == (List[i].source[0] & 0x00ff)) X if((Out->TCP.source[1] & 0x00ff) == (List[i].source[1] & 0x00ff)) X if((Out->TCP.dest[0] & 0x00ff) == (List[i].dest[0] & 0x00ff)) X if((Out->TCP.dest[1] & 0x00ff) == (List[i].dest[1] & 0x00ff)) X flag = i; X } X Xif (flag == -1) X { X List[count].protocol = Out->IP.protocol; X List[count].saddr[0] = Out->IP.saddr[0]; X List[count].saddr[1] = Out->IP.saddr[1]; X List[count].saddr[2] = Out->IP.saddr[2]; X List[count].saddr[3] = Out->IP.saddr[3]; X List[count].daddr[0] = Out->IP.daddr[0]; X List[count].daddr[1] = Out->IP.daddr[1]; X List[count].daddr[2] = Out->IP.daddr[2]; X List[count].daddr[3] = Out->IP.daddr[3]; X List[count].source[0] = Out->TCP.source[0]; X List[count].source[1] = Out->TCP.source[1]; X List[count].dest[0] = Out->TCP.dest[0]; X List[count].dest[1] = Out->TCP.dest[1]; X List[count].seq[0] = Out->TCP.seq[0]; X List[count].seq[1] = Out->TCP.seq[1]; X List[count].seq[2] = Out->TCP.seq[2]; X List[count].seq[3] = Out->TCP.seq[3]; X List[count].ack_seq[0] = Out->TCP.ack_seq[0]; X List[count].ack_seq[1] = Out->TCP.ack_seq[1]; X List[count].ack_seq[2] = Out->TCP.ack_seq[2]; X List[count].ack_seq[3] = Out->TCP.ack_seq[3]; X } X Xreturn flag; X} X X/* X * Display unique connections X */ X Xvoid Display_Connections(struct CONNECTION List[256], int count) X{ Xint i; X Xfor(i = 0; i < count; i++) X { X printf("#%d, P: %d, ", i, List[i].protocol & 0x00ff); X printf("SA: %d.%d.%d.%d, DA: %d.%d.%d.%d, ", X List[i].saddr[0] & 0x00ff, List[i].saddr[1] & 0x00ff, X List[i].saddr[2] & 0x00ff, List[i].saddr[3] & 0x00ff, X List[i].daddr[0] & 0x00ff, List[i].daddr[1] & 0x00ff, X List[i].daddr[2] & 0x00ff, List[i].daddr[3] & 0x00ff); X printf("SP: %d, DP: %d\n", X (List[i].source[0] & 0x00ff) * 256 + (List[i].source[1] & 0x00ff), X (List[i].dest[0] & 0x00ff) * 256 + (List[i].dest[1] & 0x00ff)); X } Xprintf("---------------------------------------------------------\n"); X} X Xvoid Set_Connection(struct PACKET * Out, struct CONNECTION List[256]) X { X List[0].protocol = Out->IP.protocol; X List[0].saddr[0] = Out->IP.saddr[0]; X List[0].saddr[1] = Out->IP.saddr[1]; X List[0].saddr[2] = Out->IP.saddr[2]; X List[0].saddr[3] = Out->IP.saddr[3]; X List[0].daddr[0] = Out->IP.daddr[0]; X List[0].daddr[1] = Out->IP.daddr[1]; X List[0].daddr[2] = Out->IP.daddr[2]; X List[0].daddr[3] = Out->IP.daddr[3]; X List[0].source[0] = Out->TCP.source[0]; X List[0].source[1] = Out->TCP.source[1]; X List[0].dest[0] = Out->TCP.dest[0]; X List[0].dest[1] = Out->TCP.dest[1]; X List[0].seq[0] = Out->TCP.seq[0]; X List[0].seq[1] = Out->TCP.seq[1]; X List[0].seq[2] = Out->TCP.seq[2]; X List[0].seq[3] = Out->TCP.seq[3]; X List[0].ack_seq[0] = Out->TCP.ack_seq[0]; X List[0].ack_seq[1] = Out->TCP.ack_seq[1]; X List[0].ack_seq[2] = Out->TCP.ack_seq[2]; X List[0].ack_seq[3] = Out->TCP.ack_seq[3]; X } X Xint Data_Length(struct PACKET *Out) X{ Xreturn (Out->IP.tot_len[0] & 0x00ff) * 256 + (Out->IP.tot_len[1] & 0x00ff) X - (Out->IP.version & 0x000f) * 4 - ((Out->TCP.flags[0] & 0x00f0) >> 4) X * 4; X} X Xvoid Write_Data(struct PACKET * Out) X{ Xint dlength; Xint i, k; X X/* X * Data length = Total length - IP header length - TCP Header length X */ Xdlength = (Out->IP.tot_len[0] & 0x00ff) * 256 + (Out->IP.tot_len[1] & 0x00ff) X - (Out->IP.version & 0x000f) * 4 - ((Out->TCP.flags[0] & 0x00f0) >> 4) * 4; Xfor(i = 0 + (((Out->TCP.flags[0] & 0x00f0) >> 4) - 5) * 4; X i < (dlength + (((Out->TCP.flags[0] & 0x00f0) >> 4) - 5) * 4); X i += 16) X { X if((dlength + (((Out->TCP.flags[0] & 0x00f0) >> 4) - 5) * 4) - i >= 16) X for(k = 0; k < 16; k++) X if((Out->DATA[i + k] & 0x00ff) > 39) X printf("%c", Out->DATA[i + k]); X else X printf("."); X else X for(k = 0; k < (dlength + (((Out->TCP.flags[0] & 0x00f0) >> 4) - 5) * 4) - i; k++) X if((Out->DATA[i + k] & 0x00ff) > 39) X printf("%c", Out->DATA[i + k]); X else X printf("."); X } X} X X SHAR_EOF chmod 0644 sniff.c || echo "restore of sniff.c fails" sed 's/^X//' << 'SHAR_EOF' > sniff.h && X#include "packet.h" X X/* X * Header file for sniff functions X */ X Xvoid init(char *); X Xvoid Get_Packet(char buf[PACKET_LENGTH]); X Xstruct PACKET * Convert_Packet(char *); X Xvoid Display_Packet(struct PACKET *); X Xint Unique(struct CONNECTION *, struct PACKET *, int); X Xvoid Set_Connection(struct PACKET *, struct CONNECTION *); X Xvoid Write_Data(struct PACKET *); X Xvoid Display_Connections(struct CONNECTION *, int); X Xint Data_Length(struct PACKET *); X SHAR_EOF chmod 0644 sniff.h || echo "restore of sniff.h fails" exit 0 .oO____Oo. ----------------------------------------------------- - Mythrandir's Phone explorations - ----------------------------------------------------- A short time ago I began to realize that I had no idea how the phone system worked. Now most people could care less about this. But I can never understand people like that. Well I went out and printed out the old LOD/H tech journals and poured through the information they had on the telephone system. I also found an excellent little book called Ready-to-Build Telephone enhancements by Delton T. Horn ISBN:0-8306-4359-1 The other surprising resource that I found was from good ole AT&T herself.. http://www.att.com/TALKINGPOWER/ (I believe it is) is a series of documents written by the people who make the giant backup batteries for the phone system. While there are several pages on how they create them, there are several other excellent pages which very clearly explain the basic operations of the phone system. So simple in fact, that they have inspired me to build a very small but workable telephone system myself (switching and all) just to learn about it some more. So, the following are a few interesting circuits that I have found during my exploits that I thought I would share with you. ---------------- - Basic Info - ---------------- **WIRES** The four standard wires in a phone line are as follows (In order to see these, rip off the jacket on one of your phone cords) red - This is the tip wire. green - This is the ring wire. The tip and the ring form the loop between your house and the CO (central office). yellow - This wire carries the ringer signal. However, in most home phone systems this wire is shorted to the green wire. So if you want to disable the ringer without black - Usually unused, but sometimes used in multiline systems. I don't know the specific use as I have yet to tinker with anything but my home line. Though I would guess that it is used in conferencing type systems and such. **TONES** The phone company uses dual tones for all of its services. The reason for this as it is incredibly unlikely for a dual tone to be created naturally. So what is a dual tone? Why simply two different tones signaled at once. Name Frequency Duration Dial Tone 350Hz & 440Hz Continuous Busy Signal 480Hz & 620Hz .5sec on, .5 sec off.. and so on Ring Back 440Hz & 480Hz 2sec on, 4 sec off PBX 440Hz & 480Hz 1sec on, 3 sec off Off Hook 1400Hz & 2060Hz & .1sec on, .1sec off (yes this is 2450Hz & 2600Hz annoying) No such number 200Hz & 400Hz Continous sweep at 1Hz **Dual Tone MultiFrequency(DTMF) TONES** Column1 Column2 Column3 Column4 1209Hz 1336Hz 1336Hz 1477Hz Row1 697Hz 1 2 3 A Row2 770Hz 4 5 6 B Row3 852Hz 7 8 9 C Row4 941Hz * 0 # D ABCD are often used by the military for priority overides. e.g. Flash ------------ - Circuits - ------------ This first one is from LOD/H Volume 1 Issue 1, in an article entitled Outside Loop Distribution Plant. The circuit allows you to create a test set. It has two modes, one is normal line operation, and the other is a "listen" mode. The schematic is as follows: Ring >-------------------------------------> To test phone Tip >-------| SPST Switch |---------------> To test phone | | |--/\/\/\/\----| | Resistor | |----|(--------| Capacitor The capacitor should roughly be a .22uF 200 WVDC Mylar capacitor. I got away with two .10 micro farads in parallel. (cap's in || are additive) The resistor should be a 10kOhm 1/2W resistor. For me this did not work. I had to throw two 10k's in || and drop the resistance to 5kOhm in order to be able to listen into the line. Otherwise I was unable to get any audio. >--- should be alligator clips that can connect to posts. Also you make them wires leading out of a phone jack as well. In any case, the simply need to be able to connect to the ring and tip of a line in whatever manner is needed by you. The SPST Switch is used to break the tip connection to the test phone. If the switch is closed then the current will flow straight through the wire and bypass the resistor and capacitor. This will cause the phone to act like a normal phone. If the switch is open the Capacitor will charge and block the DC voltage on the line. This will keep the phone companies switch from detecting an off hook from current flow. However, since the audio signal sent across the wire is an AC signal, you will still be able to here it. This is because the capacitor does not block AC signals. (If you are not sure why, please read up on it in a basic electronics circuitry book). The other circuit that interested me is a DTMF dialer. I am only using a small portion of it for myself. I merely added the ABCD buttons to my phone, as well as the test set above. I used a one piece flip phone that is very convenient as it has no base and is easy to carry around. The parts you will need are as follows IC1 MK5085 DTMF generator IC2 LM380 Audio amplifier KB a 16 Button Pad. You can use a twelve as well, but you will not have ABCD then.. CR 3.58MHz crystal C1 10uF 25V electrolytic capacitor C2 .01uF cap C3 47uF 25V electrolytic capacitor R1 10kOhm 1/4W 5% tolerance resistor R2 1kOhm 1/4W 5% R3 1kOhm 1/4W 5% R4 100Ohm Pot SP 8Ohm Speaker. +9V | ------------- |---------------------------|3 8 7 1 | | |-------------------------|4 10| | | |-----------------------|5 | | | | ----------------------|9 IC1 | | | | | | | --------- | | |1 2 3 A|--------------------|14 | | KB |--------------------|13 | | |--------------------|12 | |* 0 # D|--------------------|11 6 16 | --------- ------------- | | gnd | R2 | R3 C2 --/\/\/\/\-|-/\/\/\/\-|(-- | | | | gnd ------------ | | +12V ------| | | | |\| |---/\/\/\--|+ \ C3 | R4 |IC2 >--)|--| |-----------|- / |< SP |/| | | | gnd gnd In order to you use only one power source for both +12v and +9v just construct a voltage divder. Send +12 to the OpAmp and +12 to the diveder which will have a +9V output. 22kOhm 68kOhm +12V(in)---/\/\/\/\---/\/\/\/\--gnd | | Out (+9V)