Copy Link
Add to Bookmark
Report
The Infinity Concept Issue 01
.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<n, you have
a problem. If the sequence of numbers repeats at some point, you have
completely sacrificed the strength of your cipher. To be thought of as
cryptographically secure, a generator must not only pass statistical tests for
randomness, but it also must be unpredictable. It must be totally infeasible
to predict the next bit given all the previous bits, and the way in which they
were generated.
--[Why it works (why it's safe)]--
It's not presently possible to mathematically prove that any cipher
is unbreakable (except a one-time pad--see below). But, we can be reasonably
sure that provably strong ciphers are safe from penetration, given a large
enough keysize, and secure enough algorithm.
[Strength of Secret-key systems]
The strength of any secret-key system (assuming an ideal cipher with
an impenetrably strong algorithm) resides in the key length. That is, the
number of different possible keys that the cipher could use to encrypt a
message. This is usually a large number. A very large number. (To get an idea,
see the chart below..)
CIPHER KEY-LENGTH IN BASE 10...
DES 56-bits 7.2E16
LOKI 64-bits 1.8E19
NEWDES 120-bits 1.3E36
IDEA 128-bits 340,282,366,920,938,463,463,374,607,431,768,211,456
In order to retrieve the key, on average, half the key-space will need
to be searched. In the case of DES, if a computer could try 1,000,000 keys
per second (generating the key, decrypting the message and testing to see if
you were successful), it would likely take 2,000 years to recover the correct
key. LOKI keyspace would take almost 600,000 years to find a hit, and an
IDEA key would take 10E25 years (the universe is only 10E10 years old) to
search for a match (if the same computer could try 1,000,000,000 keys, and
you had 1,000,000,000 of them, it would only take 10E13 years). For more
info on the security of IDEA, see below.
So why not create a cipher with a 16,384-bit key? (My calculator can't
even compute the size of it's keyspace.) The caveat is this: Remember that
the algorithm must be perfectly secure so that there is no alternative to
brute force. Cryptography is subtle art (thank you Bruce Schneier for that
wonderful quote). It is not a simple task to create an algorithm that is
perfectly secure, and in many cases, increasing the key size will detract from
the overall security. A keyspace of 128-bits is not likely to be searched in
polynomial time without some RADICALLY new technology.
[Strength of Public-key systems]
The security of public-key systems resides in so-called 'trap door'
functions: Mathematical problems that are relatively easy to calculate in one
direction, but infeasible to calculate the inverse of. Such problems as:
discrete logarithms in a finite field (it's complexity is not known, but is
thought to lie between P and NP-hard), knapsack problems (an NP-complete
problem), and, the most famous, RSA which gets it's security from the
difficulty in factoring large numbers (a super-polynomial time problem).
[MH]
The Merkle-Hellman public-key system gets it's security from the
knapsack problem (actually, this algorithm has been broken, but it is still a
good example of a trap-door function). In a nutshell:
The knapsack problem is best described with the thief analogy: A thief
robbing a safe finds it filled with N types of items of varying size (and
value), but only has a knapsack of capacity M<N to carry the items. The
problem is to find a combination of items to maximize the total value of what
he chooses. The problem is solvable for relatively small input values, but
seems to grow exponentially with the number of items in the safe.
The MH system encodes a message as a solution to a series of knapsack
problems. A block of plaintext equal in length to the number of items would
select the items, and ciphertext would be sum (a binary 1 in the plaintext
indicates inclusion, while a 0 is indicates exclusion of the item in question):
PLAINTEXT
BLOCK (in
binary) 1 0 0 1 1 1 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1
KNAPSACK:
BLOCK 1 7 9 20 30 43 60 1 7 9 20 30 43 60 1 7 9 20 30 43 60
RESULTING
CIPHERTEXT
BLOCK: (1+20+30+43) (0) (1+7+9+20+30+43+60)
94 0 170
The security comes from the non-superincreasing knapsack (which is the
public key). A superincreasing knapsack is one where every term in the series
is greater then the sum of the all previous terms. A superincreasing knapsack
is relatively trivial to solve. With non-superincreasing knapsacks, the only
way to figure which items were included in the knapsack, is to test ALL
possible solutions, until the correct one is found. This is NOT an easy
problem. The fastest solution's complexity grows exponentially, scaling with
the number of items in the knapsack. With a knapsack of sufficient size (200
or more items) and sufficient item complexity, solving it on a computer that
can try 1,000,000 possible solutions a second, it would likely take 10E46
years. The universe is only 10E11 years old...
In MH, the private-key is the series of weighted items for a
superincreasing knapsack problem. The public-key is a series of weighted
items for a non-superincreasing knapsack problem with the same solution.
In any event, the MH public-key system was broken by Adi Shamir
(of RSA fame) and (?) Zippel by finding a way to construct the superincreasing
knapsack from the non-superincreasing one.
[RSA]
The RSA Public-key system is the most popular and well known
public-key system. It is widely believed that RSA gets it's security from the
difficulty in factoring large numbers (it's possible that another method for
breaking RSA may be discovered, but it hasn't surfaced yet).
The math of RSA is simple:
Take two large primes, p and q.
Find the product n of pq (which is the public modulus).
Randomly choose a number e, such that: e<n and e is relatively
prime to (p-1)(q-1).
Use Euclid's algorithm to compute d [which is the inverse
mod(p-1)(q-1) or ed = 1 mod (p-1)(q-1)].
e is the public exponent, and d is the private one.
The public-key is (n,e) and private key is d.
p and q must be destroyed.
The security comes from the difficulty in factoring the public modulus
n. Prime factorization of large numbers is not an easy problem (it has not
been proven that factoring *must* be as difficult as it is, but no one has
discovered an easier way to go about it). The fastest algorithms are of the
super-polynomial complexity class. While not easy, factoring technology has
jumped LEAPS and BOUNDS in the past few years. In 1977 Ron Rivest (of RSA
fame) said that factoring a 125-digit number would take 40 quadrillion years.
In 1994 a 129-digit number was factored. In June of 1995 the 116-digit
Blacknet key was factored. The table below shows time estimates for factoring
several keysizes using the general number field sieve (GNFS) (a MIPS-year is
a 1,000,000 instruction per second computer running for one year, or 3E13
instructions).
Key size in bits MIPS-years required to factor
512 3E5
768 2E8
1024 3E11
1280 1E14
1536 3E16
2048 3E20
A related algorithm, the special number field sieve (SNFS) is faster
still then the GNFS. The SNFS is actually more efficient on special number
types that are not too often used in cryptography, but the SNFS is relevant
to a factoring discussion. The SNFS has faster times accordingly.
Key size in bits MIPS-years required to factor
512 <200
768 1E5
1024 3E7
1280 3E99
1536 2E11
2048 4E14
If you are thinking that a 1024-bit key is unconditionally safe, here
are some assumptions from the mathematicians who factored RSA-129:
We believe that we could acquire 100 thousand machines without
superhuman or unethical efforts. That is, we would not set
free an Internet worm or virus to find resources for us. Many
organizations have several thousand machines each on the net.
Making use of their facilities would require skillful
diplomacy, but should not be impossible. Assuming the 5 mips
average power, and one year elapsed time, it is not too
unreasonable to embark on a project which would require half
a million mips years.
Frightening indeed.
[What key size should I choose?]
To determine a desirable keysize, you need to assertain the security
you need vs. the lifetime of the key. I am assuming (as most people using
cryptography would) that you want maximum security. Since no realistic
predictions of factoring speed can be realistically made beyond a few years,
the keysize chosen should be a factor (no pun intended) of this. Today you
need a 1024-bit number to get the level of security you got from a 512-bit
number in the early 1980s. If you want your key (and data) to remain secure
for 20 years, and you do not plan to (or cannot) change it, 1024 bits is likely
too short. Choose an implementation that allows for a larger keysize.
Something about 2048-bits just makes me feel good...
Below is the announcement posted by Paul Leyland about the successful
PGP public-key modulus prime factorization. (If you try to check the
signature integrity, you may notice it doesn't check. I went a little hay
-wire with the spell checker...)
---------------------------------BEGIN INCLUDED TEXT---------------------------
-----BEGIN PGP SIGNED MESSAGE-----
We announce the first known hostile attack on a PGP public key.
In 1993, Tim May created BlackNet as a proof-of-concept implementation
of an information trading business with cryptographically protected
anonymity of the traders. He created a 1024-bit key, and invited
potential traders to encrypt their sales pitch and a public key for a
reply with the BlackNet key, posting the result in one or more Usenet
newsgroups. BlackNet would then reply in the same manner. The original
proposal went only to a few people and May acknowledged his authorship
shortly afterwards, when his pedagogical point had been made. It was
soon posted to the Cypherpunks list, and from there to Usenet. Six
months afterwards in February 1994, a 384-bit key was created in the
BlackNet name, and the BlackNet message was spammed to hundreds of
newsgroups by the new key owner, L. Detweiler.
At least one message was posted encrypted in the 384-bit key. The
encryptor, either by design or by unwitting use of PGP's encrypttoself
option, also encrypted the message to his own key, exposing his identity
to anyone who cared to look him up on the key servers and use finger.
Factoring 384-bit integers is not too difficult these days. We wanted
to see whether it could be done surreptitiously. Jim Gillogly picked
the 384-bit BlackNet key as a suitable target, partly because of its
apparent interest and partly because he had saved a copy of the reply.
Paul Leyland took the key to pieces. The public exponent was found to
be 17 and the public modulus:
3193508200533105601431099148202479609827976414818808019973596061739243\
9454375249389462927646908605384634672078311787
To factor this 116-digit integer, we used the same technology as the
RSA-129 project which completed last year. That computation was so
large that it was necessary for it to be done in a blaze of publicity in
order to attract enough resources. Ours, we estimated, would take about
400 mips-years, less than a tenth of the earlier one. Arjen Lenstra and
Paul Leyland have been factoring integers for years, Lenstra with a
MasPar at Bellcore and Leyland with a dozen or so workstations at Oxford
University. Alec Muffett has been contributing to factorizations for
almost a year, using forty or so machines outside working hours at Sun
Microsystems UK. Jim Gillogly threw a couple of machines into the pot,
for a total peak power of around 1300 mips, plus the MasPar. The
computation began on March 21st on the workstations and continued until
June 23rd. Lenstra slipped in three weeks runtime on the MasPar between
other factorizations; he also performed the matrix elimination and
emailed the factors (PGP-encrypted) to Leyland. About 50% of the
computation was done by the MasPar.
The factors, as can easily be checked, are:
5339087830436043471661182603767776462059952694953696338283
and
5981374163444491764200506406323036446616491946408786956289
Over in Oxford, a doctored PGP was created. It could generate only
one secret key, that from two primes hard-coded into it. The key was
generated and tested on the following message:
> -----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<nowhere@cyberspace.nil> 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 <pcl@sable.ox.ac.uk> | 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 <stdio.h>
#include <time.h>
#include <process.h>
#include <io.h>
#include <string.h>
#include <conio.h>
#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
<colin@nsq.gts.org> 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 "<filename>.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<KEYLEN;j++){
i++;
Z[i+7]=((Z[i&7] << 9) | (Z[i+1 & 7] >> 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<ROUNDS;j++){
t1=*Z++;
*--p=*Z++;
*--p=t1;
t1=inv(*Z++);
t2=-*Z++;
t3=-*Z++;
*--p=inv(*Z++);
*--p=t2;
*--p=t3;
*--p=t1;
}
t1=*Z++;
*--p=*Z++;
*--p=t1;
t1=inv(*Z++);
t2=-*Z++;
t3=-*Z++;
*--p=inv(*Z++);
*--p=t3;
*--p=t2;
*--p=t1;
/*copy and destroy temp copy*/
for(j=0,p=T;j<KEYLEN;j++){
*DK++=*p;
*p++=0;
}
}
uint16 mul(uint16 a, uint16 b){
word32 p;
if(a){
if(b){
p=(word32)a*b;
b=(uint16)(low16(p));
a=(uint16)(p>>16);
return b-a+(b<a);
}
else return 1-a;
}
else return 1-b;
}
#define MUL(x,y) (x=mul(low16(x),y))
#define CONST
static void cipher_idea(word16 in[4],word16 out[4],register CONST IDEAkey Z){
register uint16 x1,x2,x3,x4,t1,t2;
int r=ROUNDS;
x1=*in++; x2=*in++;
x3=*in++; x4=*in;
do{
MUL(x1,*Z++);
x2+=*Z++;
x3+=*Z++;
MUL(x4,*Z++);
t2=x1^x3;
MUL(t2,*Z++);
t1=t2+(x2^x4);
MUL(t1,*Z++);
t2=t1+t2;
x1^=t1;
x4^=t2;
t2^=x2;
x2=x3^t1;
x3=t2;
}while(--r);
MUL(x1,*Z++);
*out++=x1;
*out++=(x3+*Z++);
*out++=(x2+*Z++);
MUL(x4,*Z);
*out=x4;
}
char read_char_from_file(FILE *fp){
char temp=0;
if((fread(&temp,sizeof(char),1,fp))!=1)end_of_file=1;
return(temp);
}
word16 read_word16_from_file(FILE *fp){
word16 temp=0;
if((fread(&temp,sizeof(word16),1,fp))!=1)end_of_file=1;
return(temp);
}
void write_char_to_file(char data,FILE *fp){
if((fwrite(&data,sizeof(char),1,fp))!=1){
printf("Fatal Error writing output file!!!\n");
exit(-1);
}
}
void write_word16_to_file(word16 data,FILE *fp){
if((fwrite(&data,sizeof(word16),1,fp))!=1){
printf("Fatal Error writing output file!!!\n");
exit(-1);
}
}
void cipher_file(FILE *in,FILE *out,word16 *key){
word16 input[4],output[4];
IDEAkey Z;
int x,y;
int count=0;
long length;
int temp;
en_key_idea(key,Z);
end_of_file=0;
length=filelength(fileno(in));
fwrite(&length,sizeof(long),1,out);
while(!end_of_file){
x=0;
while (x<4){
input[x]=((word16)(read_char_from_file(in)<<8));
if (!end_of_file){
temp=read_char_from_file(in);
if (temp<0)temp+=256;
input[x]=input[x]|temp;
x++;
}
if(end_of_file){
while (x<4) input[x++]=0;
break;
}
}
cipher_idea(input,output,Z);
for (y=0;y<x;y++){
if(noisy)if(count++%256==0) printf(".");
write_word16_to_file(output[y],out);
}
}
}
void decipher_file(FILE *in,FILE *out,word16 *key){
word16 input[4],output[4];
int x,y;
IDEAkey Z,DK;
int count=0;
long length=0;
en_key_idea(key,Z);
de_key_idea(Z,DK);
end_of_file=0;
fread(&length,sizeof(long),1,in);
while (!end_of_file){
x=0;
while(x<4){
input[x]=read_word16_from_file(in);
if(end_of_file)break;
x++;
}
cipher_idea(input,output,DK);
for (y=0;y<x;y++){
if(noisy)if(count++%256==0) printf(".");
if(length-->0)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<fsize;count++)fputc('0',fp);
fclose(fp);
}
if ((remove(file))!=0){
printf("\nERROR removing old file <%s>\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<strlen(arg) && x<8;x++){
if (x==0) key[x]=arg[x]<<8;
else key[x]=((arg[x]<<8)|(key[x-1]>>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: <NO CLASS>
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
passwor
ds 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]
<http://www.sei.cmu.edu:80/SEI/programs/cert.html>
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]
<http://www.8lgm.org/>
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]
<http://www.first.org/first/>
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 <string.h>
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 <stdio.h>
X#include <string.h>
X#include <unistd.h>
X#include <stdlib.h>
X
X#include <sys/ioctl.h>
X#include <sys/types.h>
X#include <sys/socket.h>
X#include <netinet/in.h>
X#include <arpa/inet.h>
X
X#include <linux/inet.h>
X#include <linux/in.h>
X#include <linux/types.h>
X#include <linux/socket.h>
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 <string.h>
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 <linux/if_ether.h>
X#include <linux/if.h>
X#include <string.h>
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.
**T
ONES**
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)
