Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Technology

l0pht develops Sniffer Sniffer 97

Posted by CmdrTaco from the upping-the-ante dept.
An anonymous reader has written in to say that l0pht has released a sniffer detector called AntiSniff. You can use it to determine if someone is sniffing around your network. There's already rumors of sniffer-sniffer-proof-sniffer already for those of you who already knew what I knew I thought you knew I knew.
This discussion has been archived. No new comments can be posted.

l0pht develops Sniffer Sniffer More

l0pht develops Sniffer Sniffer

Comments Filter:

  • Old news... (Score:1)

    by Anonymous Coward
    This has been out for weeks. I think the motto needs to change to "Old news for nerds, stuff that mattered".
  • This was on bugtraq like a month ago...

    - A.P.
    --


    "One World, One Web, One Program" - Microsoft Promotional Ad

  • I did.
  • ...they've been around for a while, having that name before it was k3w1.

    If someone NEW tries using a name like that, then no slack.
  • In addition this tool is only good if the interface is active and has an ip address. If you're sniffing with a device that isn't bound to an address, then the "sniffer sniffer" isn't useful at all.

    -Peter
  • One simple technique: cards in promiscuous mode on the net are catching and processing every packet. Simple enough to throw out a packet with a destination address of 234.234.234.234 (or something similarly unique or bogus, and sniff out DNS lookups. The sniffer will often be logging 234.234.234.234 after doing a name lookup, and when the lookup packets go out, the source of the sniffer is identified.

    That's just one of many tricks; others involve talking to sniffer candidates to see how the cards respond to packets differently when in promiscuous mode.
  • It must only run on Win NT and Win95 and must be a small utility with a single defined purpose. We don't want no stinkin Linux software. On my LAN we accept that we're sniffed as a fact of life. That's the price of 10MB/s ATM in a time when companies make and lose $billions on the internet. Years ago this wasn't the case, but today you must pay.

  • Re:So what (Score:2)

    by jd ( 1658 )
    I agree. IPsec and SKIP make much more sense than trying to detect the sniffer. Detecting a detector is just another form of arms race. The problem with arms races is your arms fall off.
  • anti-sniff won't detect computers/devices on the network that don't emit any packet, but if someone has physical access to your network you have bigger problems than just sniffing.

    Anti-sniff was made mainly to try to detect sniffing on machines that are known to exist and must still listen on the network (like servers).

    It will send bogus IP and others weird things to check if it slow down the machine, as well as a few others tricks.

    Depending of the bandwidth to the machine, the speed of the machine and the intelligence of the sniffer that may not work.

    However it is a little extra in a sysadmin toolbox, it's not perfect but may help.

  • Ethereal is nice. Tcpdump is sorta the old standby. freshmeat [freshmeat.net] should have links to both.
  • Sniffit is another pretty good one.
  • I can't believe the number of posts claiming "This can't be done." Read the @&*$#@&( l0pht write-up. It's not perfect. It can be circumvented (in some cases), but it does actually detect some sniffers and it's pretty clever.

    I guess there aren't enough moderators to keep all of the "I don't know anything about this, and I can't think of how it could work, therefore it must not work" down to -1.

  • The Ethereal site is here. [zing.org] (I shan't say what the best sniffer is, as I'm not exactly a neutral observer.... :-))

    (Note also that Ethereal isn't Linux-only.)

  • If your system has a driver that lets you get at raw packets (the moral equivalent of raw DLPI access on Solaris, SOCK_PACKET or packet filter access on Linux, BPF access on BSD, etc.), the driver could provide a way to enable or disable promiscuous mode on cards that support it, read and write raw packets, etc..

    Unfortunately, NT either doesn't come with such a driver by default, or doesn't document it (NT Server comes, I think, with Network Monitor, which includes such a driver, although the version that comes with NT is claimed not to support promiscuous mode; you need the version that comes with System Management Server to get that).

    The Microsoft Developer Network stuff comes with sample driver and userland code to do that, at least on NT, and PCAUSA [pcausa.com] sells the Win32 NDIS Framework [pcausa.com], which includes a driver and a userland library to let you do that on W9x and WNT (complete with a BPF interpreter in the driver, so you can do BPF-style packet filtering when capturing).

    I've not used either of them, so I can't say one way or the other how well they work.

  • This would be a useful script to have. An entire dorm at Rice had to change their passwords (and check their computers) last year because one person's Linux box got cracked and had a packet sniffer running. (and because the hubs were at that time misconfigured; normally packet sniffing doesn't work here).
  • What are you trying do defeat? Sniffers are useless on switched ethernet so there is no need to run a sniffer detector there.


    The design of AntiSniff is to detect intruders running sniffers on your network.

    -weld

  • ... be on switched Ethernet.
  • Wrong. Switches do not guarantee security. It would be trivial to fake your MAC address in order to listen to somebody else's traffic, not to mention Ethernet broadcasts.
  • Appearently, you've never had a submission ignored for a while only to come up under another person's name a day (or days) later.
  • Couldn't you just send out ARP packets asking for the host-you-are-scanning's IP but to a MAC address other than the broadcast one (or it's) and see if it responds?

    Or has this been tried and found not to work?
  • Switched hubs render sniffers useless simply because every packet does not go to every NIC. Of course, encryption is a good idea anyway :)

  • hrm (Score:1)

    by True Dork ( 8000 )
    I certainly wasnt implying that relying on switches alone would completely secure anything. It does stop people from running a sniffer and then choosing what traffic they see from the whole subnet to grab. As far as faking the MAC address, would that not interrupt the communication to the other NIC? I've never tried faking a MAC address so I really dont know. Ethernet broadcasts arent generally sensitive information that I can think of. I know I said it before, but crypto is always the best way to go.
  • This is like the radar detector detectors police started using a few years ago.
  • I assume the reason it failed to detect it (based on other comments) is that each linux box is running its own caching nameserver, preventing any 'extra' traffic especially during the DNS tests, which is really what AntiSniff looks for.
  • Programs that detect network cards that are in promiscous mode aren't anything new. The detection isn't very reliable either. Often these programs show false alarms or miss the boat. In particular, the l0pht program failed to detect tcpdump on any machine I tried it on, and I tried running tcpdump from several linux boxen and tried AntiSniff on several windows machines. Hmm....
  • That's only one of three methods. The second takes advantage of a known protocol idiosyncracy of Linux.

    The third method takes response time data from hosts before and during a flood of packets with bogus MAC addresses. This is the core detection routine, and actually comprises three different timing attacks.

    There are multiple techniques to invalidate these tests; however, the intent of the tool is to detect *unauthorized* sniffing on a segment, and a number of the best anti-antisniffer techniques imply control of the surrounding network infrastructure...

    It's an arms race, but isn't it always? The tool has its place.

    -- Cerebus
  • well, I guess it goes kinda well with the following Slashdot article [slashdot.org], maybe? If you have an anti-sniffer sniffer, would it maybe stop a bunch of script kiddies who use plain old sniffers with default settings, I guess?

    Maybe?

    ...

  • AH! I was gonna say that.

    But yeah, after a certain point you'll hafta use exponents:

    trace-buster^3
    trace-buster^27
  • As discussed on Bugtraq.

    The technique used by this anti-sniffer is to check for machines lagging in replys due to the small amount of time it takes the sniffer to write everything on disk.

    It's fairly easy to modify the current sniffers to drop the promiscuous mode once they detect the huge amount of packets sent by the AntiSniffer

    My $.02
  • LOpht has probably been around longer than you've been 'doing computers', freak. Respect your elders.
  • I have actually detected people sniffing, and the logfiles produced are very helpful. Between this and L0phtCrack, you couldn't ask for a better (free) security suite.
  • I say thats a lame method. Network lag could eliminate this problem altogether. Especially since CPU's are getting faster and faster, and this program can only guess. I fear not.
  • If you saw this weeks ago, why the hell didn't you submit it? It's so easy to say "Boring, I saw this last week", but apparently the task of submitting a story is overwhelming to c00l folks like you.
  • I like Ethereal, check out Freshmeat for the link (I can't remember it right now).
  • Actually I think the Network General sniffer puts out a packet every once in a while to let everyone know that it's there (but don't take my word on it check a trace with the sniffer and see it there is a packet with a Network General MAC in it).

    I know that an ethernet aui connection can be wired so that it only receives. I don't think you can do that with a 10BaseT connection (link integrity won't work and may take the port down).
  • I can't get past the ./configure stage of Ethereal. It says that I need a net/bpf.h file. What file is this and what devel package do I install to get it?
  • libpcap wasn't installed. Sorry for the luser quality post.
  • If you go out and buy an actual sniffer device (expensive, but if you use it a lot, it's worth it), such as a network general sniffer or some such, then there's just no way to detect it. These don't send anything back down the TX line (unless you tell them to.. very handy to send out a custom packet or three for debugging), and put nothing at all on the network... This l0pht dealie is to detect computers with normal NIC's that have been put into promiscuous mode. It does this a bunch of ways, some are OS specific (older linux versions, most Windows versions due to poor network driver programming), and one is not.

    The one that is not relies on the fact that if you beat the hell out of a system in promiscuous mode, it'll slow down, badly. Basically, it pings the shit out of the system while adding a bunch of network traffic destined to somewhere else. Then it measures latency on the pings. If that latency stays about the same, then the system you are pinging is probably ignoring all that other traffic at the hardware layer. If it goes up by a good amount, then that extra traffic may be getting through, passing to the software, thus slowing the system down enough to detect.

    An actual sniffer device has none of these issues. Hell, a lot of them don't even HAVE an IP address. You stick it on the network, and hear pretty much what you want to hear. Transmit from any IP you want. It's just a matter of forming the packet correctly. If the system doesn't send out anything at all, there's no way to detect it, short of mucking about with resistances on the line or some EE stuff I know nothing of. :-)

    ---
  • I don't see how this is possible. From my experience, the Network General line of sniffers don't send ANYTHING out on the wire - they just listen to the packets going by and record them.

    Guess I'll have to check this out... :-)

  • D'OH! So I take it the new-fangled Windows NT- based Network General (Associates, whatever) sniffers are supceptible to this anti-sniffer sniffer?

    Then again, that wouldn't explain why the NT boxes have two interfaces - one for monitoring and one for transport...

    Eh, I liked the DOS version more than the NT version anyway.

  • AntiSniff detects the *lag* that is produced when packets pass *through* machines which are being sniffed. Any extra processing of packets moving through, such as logging or sniffing adds lag to the amount of lag the machine causes. AntiSniff detects the lag caused by storing sniffed packets.

  • AntiSniff on Bugtraq... Go to the source. (Score:3)

    by regs ( 18775 ) on Tuesday August 17, 1999 @06:09AM (#1742848) Homepage

    Some very interesting discussion about AntiSniff took place on the bugtraq mailing list; here are the relevant threads (and yes, there is already an AntiAntiSniff Sniffer :) :




    --
  • Can a television station detect electronically the number of viewers they have at any given time? Every standard television set and radio in the world is just like a dedicated packet sniffer. If I could connect a specialized box to your internal network, I could grab anything I want and it is not possible that you would be able to detect it unless you saw the box with your own eyes. I could come in and get it a week later and have a large number of passwords to mess with. The best sniffers have no need of a MAC or IP address.

    However, most crackers have to get into your network remotely. They usually find their way into a general-purpose machine. For practical reasons, it may not be possible for him/her to put the NIC into 100% receive-only mode. That is the kind of situation that AntiSniffer detects.

    As others have said, a switch can make sniffing more difficult. Not impossible, just more difficult. Remember that no computer can be 100% secure, unless of course it finds itself in the middle of a nuclear explosion. :)

    This /. article has been mildly irritating. We need more moderators.

  • No... (Score:1)

    by mplex ( 19482 )
    This is only one of the ways it detects it. The nslookups are a dead givaway though.
  • Absolutely hilarious subplot, watching the characters go from TraceBuster to TraceBusterBuster to TraceBusterBusterBuster! I can't believe more people haven't caught this on this thread.
  • get out your trace-buster-buster to bust the buster who's trying to bust your trace


    unless he has a trace-buster-buster-buster that is
  • Then don't read it and don't reply to it. Maybe people like myself haven't seen it.

    that's my contribution.
  • this program is inherently flawed....it makes the assumption that the computer doing the sniffing is also going to be doing nslookups on every ip that comes by..it would be a simple task to just sniff the data, and process it 6 hours later from another machine on the same network.
    just my worthless opinion.
  • As per the bugtraq discussion this isn't always possible.

    The Tx can be cut on AUI lines since it is not the same line as the keep alive, but on RJ45 Tx and keep alive are the same line so if you cut Tx, the device on the other end will stop sending you data.

    Another method that would work better (which was also on Bugtraq) was to sniff on one nic that had an unreachable address (eg 0.0.0.0) and have another nic in the sniffer machine to connect remotely with that has a valid IP. This hack practically requires a rewrite of the tcp driver tho so it would really one be feasable on an Open Source OS.
  • I was under the impression you couldn't go to promiscuous mode under 98/NT, but this article seems to indicate you can. Can someone point me on info on how to do this? Perhaps people hook into specific ethernet card drivers? Is there a general solution like linux?
  • I have used a number of sniffers and there is no way on earth that they can be detected remotely. All just capture packets - no more, no less.

    Of course if the sniffer was running as a process on an NT or Windows 95 machine, then it is possible that sniffed packets get passed up to the protocol stack, but I have not been daft enough to run such a sniffer.

    Looks like another means of making money out of ignorance.
  • Try and detect the DOS version of LANWatch. I used this a lot at a previous employer, running it on anything from a 286 luggable upwards. Since the packet driver just picked up packets, and no more (it had no IP address, IPX address or anything else), there was no way that anything else could detect this.

    It would also work on a token-ring network, but in this case there would be some MAC frames put on the ring.

    I will pay £1000 to anyone who could detect that such a LANWatch PC was scanning an Ethernet network.
  • I am afraid that you are mistaken. The Data General Sniffer (tm) running on top of DOS doesn't transmit any packets. It does not perform DNS lookups, respond to pings, arps, SYN, or anything. Likewise it does not introduce any latency into the network. All it does is sniff and analyze the data. It would be like trying to detect if someone put an oscilliscope probe onto a hub link. In other words, there is no way to detect it. Another technique is to use port mirroring on a switch. It isn't that hard to make a sniffer undetectable.

    In other words, Anti-Sniff cannot detect a sniffer box unless it's running the less-popular Windows version of Sniffer.

    At my last job at Adaptec we made the NIC cards used by Sniffer and my former boss worked in the Sniffer group at Data General. As a network developer I use a Sniffer all the time.

    Sniffer is a trademark of Data General.
  • I was just playing around with the new Windows based Sniffer software. What a load of crap. I'm trying to capture some DLC frames of my employer's trunking protocol and it won't give me hex dumps! Not only that, but it doesn't seem to work if I don't bind the adapter to a protocol which I don't want to do (our trunk doesn't like hosts on the trunk vlan). Give me the DOS version any day!

    As of a year ago about 90% of the Sniffer sales included the special NIC card since that version came with the DOS version in addition to the Windows version. The Windows version is just too limited and not as easy to use.

  • This program is bullshit. A number of hacker sniffing tools run over packet drivers, and as long as you don't do reverse-dns queries, you can scarf all the passwords you want. Of course, installing a packet driver takes physical access to the machine.

    All this will protect you against is sniffers being run by legitimate machines. It won't protect you against a rogue machine.
    -russ

  • Yea (Score:1)

    by Larry L ( 34315 )
    Well if you need another type of sniffer sniffer, try neped. the apostols had this thing a long time ago. instead of this approach they actually send out something which only promisc network stacks respond to. not the sneakiest approach, but it works.
  • So which is it? Are they "quasi-cracker" or "going corporate"? There's no pleasing some people.
  • Routers have enough other things to do than try and detect a machine sniffing. Cisco routers (75% of the internet) don't have any such capability directly built in.

    The l0pht anti-sniff program just does a couple of well known tricks to detect the response time of a normal machine hacked to be in promiscuous mode. A router could be used to do the same thing, just a bit more crudely, with less reliability (antisniff is pretty unreliable, I've been testing with it)

    Your router admin sounds like a know-it-all with no real knowledge. Ask for details, and if you get anything solid then email me. I'm always looking for new tricks :-)

    the AC

  • This always seems to be the conventional knee-
    jerk reaction to sniffer protection. Obviously,
    it is impossible to detect with software the
    presence of a "hardware" sniffer. People who
    insist on pointing this out repeatedly miss the
    point: the overwhelming vast majority of malicious
    sniffers are software, installed on general-
    purpose computers.

    A general technique to detect such sniffers would
    have a dramatic beneficial effect.

  • More wrong-headed "conventional wisdom". The two
    flaws in the logic that "switches solve sniffing":
    A.) switches aren't designed for security (even
    the ones with "security features"), and B.) there
    are things you can do at the network layer that
    affect the way the link layer works.

    There are switches that will revert into an
    "insecure" forwarding mode when room for
    forwarding tables runs out (if you think about
    this, you'll realize that there's basically no
    way any switch can prevent this attack, other
    than detecting it and locking down the offending
    port). There are switches that can be "fooled"
    by seeing a frame with an Ethernet address it
    believes to be on a different port (forwarding
    table updates happen instantaneously). There
    are tens of other little problems like this that
    can be exploited.

    More importantly, there are games you can play
    with IP that completely subvert switches; you can
    race ARP, for instance, and transparently forward
    captures packets. You can play games with dynamic
    routing. Look at the recent L0pht advisory on
    Router Discovery.

    For something to be useful as a security device,
    it needs to provide some degree of assurance that
    it is doing what you expect it to be doing.
    Switches, as "anti-sniffing" devices, fail this
    test --- there is no way for you to know, outside
    of expensive testing, not only of the switch but
    of your entire LAN environment, whether or not
    they are really providing any protection.
  • In the real world, IPsec isn't a practical
    solution to most security problems. When the
    entire Internet speaks IPsec, you will have
    a valid point. Until then, LAN snooping is a
    problem that is important to address.

    Even when IPsec is deployed widely, the only
    reasons sniffing will cease to be such an issue
    is that so few people will be doing it anymore.
    Right now, sniffer detection is a valuable means
    of detecting _intrusions_, and after-the-fact
    intrusion detection is obviously valuable when
    you can't assure attack detection.

  • This only works against a small number of broken
    stacks. When we (Secure Networks, Inc) discovered
    this technique several years ago, it only worked
    reliably against Linux and SunOS (Ivan Arce, the
    guy who came up with this idea, could tell you
    better). Since then, operating systems have gotten
    better about back-checking Ethernet addresses in
    their drivers.

    If you look at the AntiSniff material, this is one
    of the checks they perform, and its limitations
    are well-documented.
  • If the machine runs a general-purpose operating
    system and has "legitimate" network connectivity,
    the presence of a promiscuous-mode sniffer on the
    box will be detectable (not necessarilly by
    AntiSniff --- I'm not very familiar with how
    effective their implementation is) with latency
    analysis.
  • More wrong-headed "conventional" wisdom. The
    act of measuring network traffic on a general-
    purpose platform produces changes in that
    platform. These changes are detectable.

    Promiscuous mode sniffing alters the way the
    Ethernet drivers work, it changes the performance
    characteristics of the whole network system, and
    it causes the platform to react to events it
    wouldn't normally react to.

    Common sense tells us that unless there's no
    way to talk to the sniffing machine and thus no
    way to take measurements, running a naieve (read,
    not sniffer-sniffer-protected) sniffer is going
    to change SOMETHING on the box we can detect.

  • A.) The "company" you're talking about never
    published any research. They might as well have
    never done it.

    B.) Your idea of how the L0pht tool works has
    very little to do with what the tool actually
    does. The technique your "company" uses (which
    is well-known, though undocumented) is not the
    only (or even the most powerful) check done by
    the L0pht tool.

    C.) Physical sniffers are not the threat that
    this tool purports to defend against, nor are
    they a threat for the vast majority of networks
    (in which physical access to the network is not
    an issue).
  • L0pht predates "skript kiddies". The researchers
    at the L0pht are among the more respected in the
    whole security industry (speaking as one who spent
    a great deal of time in that industry). They're
    responsible for a good deal of pioneering work,
    and they have a reputation for doing things right.

    Which is what I believe they are doing here, by
    thoroughly documenting the way their tool works
    and what its limitations are. We can study their
    tool and determine through peer-review how
    effective it is. And, if we wanted to, we could
    use their research to build our own tools.

    Which is only fair, because they are also using
    publically available research to build their
    tool.
  • The article claims to be the first of its kind,
    despite the fact that I had a discussion with
    a guy 3 years ago whose company was doing
    _exactly_ this same thing.

    The theory is that if a machine is in promiscuous
    mode, certain IP communications are not responded to. (Sending an ICMP error to the machine and seeing if you get a reply is one such test.)

    So if your protocol stacks still respond normally, these tests don't work.

    The problem is that 1) after my conversation 3
    years ago, I managed to modify a public domain IP implementation that would sniff and not interrupt normal processing of packets, and 2) even if intruders are nice enough to use garbage stack implementations that respond like this, what if they are running a machine you don't know is there, and no protocol stack? No way to query the machine, no way to know it is sniffing.

    The point is that this company is grandstanding on a couple well-known behaviours of promiscuous machines. Don't believe them. They'll not improve your security.
  • What's the big deal? I've been doing this from my various UNIX boxes for years. And, I didn't need a half-assed (must be, since it's only for Windows) quasi-cracker utility to do it. I wonder how long it took them to copy the tcpdump source?

    But, since you brought it up, I would think an organization like l0pht would have thought of a better name for their product. Hmm, let's see, a product that detects others who are promiscuous. How about Celibacy? Or Puritan? Guess they're going corporate, huh?
  • How else can one detect a nic is promiscuous (sp?) mode? The Router guy at my school said that he could easily detect such things. Can anyone explain how? Is sniffing logged in the records of various network routers?

    He's a real jerk so he may just be embellishing the truth.

    -matt

  • Your router admin sounds like a know-it-all with no real knowledge.

    I agree. When i pressed him for more he copped out, mentioning security issues that prevented him from disclosing the info. I don't wanna do anything wrong. I just want to learn.

  • That's my word!

    I love that movie.

    Heart attack -> life buster
    pacemaker -> life buster buster
    microwave -> life buster buster

  • damnit! I meant

    microwave -> life buster buster buster

    weak. I'll stop now
  • I'd think that if you really needed the kind of security that makes network sniffing a no-no, you'd spend more time trying to strengthen the types of security you use for network traffic rather than trying to detect who's sniffing.

    Encrypted mail and such .... just make the data that could be sniffed useless in the hands of a sniffer, and you don't need a sniffer detector.

    Not that I'm any sort of security expert, but this sounds kind of like the Radar Gun Detector argument - if you're afraid of being pulled over in the first place, you have to work to change the speed limit, not try to evade the Radar Guns.
  • I knew that I knew before he thought that I knew.
    I don't know why we even bother...someone will always find a loop hole...
    Why is it that thier are never fixed before someone exploits it? You'd think that somewhere and sometime, one of the good guys would find the exploit first.

    Ah well...
  • Get a clue, if you used someone else's MAC then the switch would update it's FDB and any traffic to the user would be forwarded to you. That would cause the user to loose any connections that they had (IP/IPX/whatever) and that would definately cause them to think something is "up." I don't know of ANY vendor's switches that has room in their FDB to hold two ports for each MAC address. If you do I'd like to know.

    True, if you're in the same VLAN you would see all broadcast/multicast traffic (unless the switch was capable of IGMP then you wouldn't even get all the multicast traffic). But, my experience is that broadcast/multicast traffic is not too useful for snooping passwords and such (at least for TCP/IP/unix connections and that's all we care about, right?).

    Switches definately do not "guarantee security" but your method for snooping will not work. Even if you were able to get control of the conversation steering or port mirroring (or whatever your particular vendor calls it) capabilities of your switch there would be problems. First, you would have to be plugged into the same switch as the device you wanted to sniff. Second, you would probably only get half of the "conversation." A little know fact is that most switches are setup for auto-negotiation to 100BT full duplex. Most switches are unable to buffer frames while port mirroring. So if the device you are sniffing happens to be in full duplex mode and is sending a frame at the same time the switch is sending a frame to it you would only get one of the frames copied to your mirror port.

    Besides, auto-negotiation does not always work and when it doesn't the results are not too pleasant. It varies between combinations of various vendor's switches and various NIC cards. Some combinations work excellent, some are intermittent, and some fail all the time. The end result is that some network engineers choose to force speed and duplex in all cases just so that there is no possibility of problems.
  • Does this remind anyone of the movie "The Big Hit"

    "I have a call tracer blocker tracker blocker....."
  • Unfortunately The good guys are always too busy patting themselves on the back for their accomplishments.
  • This approach does not cover sniffers that do not run under an operating system. Mine certainly doesn't, and I gurantee that I never transmit anything!

Slashdot Top Deals

The biggest difference between time and space is that you can't reuse time. -- Merrick Furst

Close