Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
It's funny. Laugh.

Distributed.net Captures Laptop Thieves. 102

Posted by Roblimo from the cracking-crypto-keys-helps-stop-crime dept.
Octal writes "According to this story, there is a little-known advantage to running a distributed.net client from your start-up script. On two separate occasions, laptops have been stolen, and then returned, by tracing the IPs of rc5des clients that criminals forgot to remove."
This discussion has been archived. No new comments can be posted.

Distributed.net Captures Laptop Thieves. More

Distributed.net Captures Laptop Thieves.

Comments Filter:

  • Similar story (Score:2)

    by Anonymous Coward
    This reminds me of a program I wrote back in the days of Win3.1 (92 or 93) ... The program ran in the autoexec.bat and printed out the following message (or close):

    Microsoft GPS Computer Locater v2.xx
    Initializing GPS . . .
    Connecting . . .
    Transmitting computer location . . . . .
    Location transmitted to database.

    The dots were timed out randomly, and for the version info I just copied something from a real Microsxxx driver, so it looked pretty real to those who didn't know better (like most of the people in my office). Obviously this would never get back a stolen computer, but thinking of the reaction of anyone who stole the computer and saw this when they turned it on was enough.

    M

  • Anyone running distrubted.net software on a laptop most likely installed it themselves, and is fully aware that it sends information back over the network.

    Choosing to do something it totally different then software that does something you're not even aware of without your consent. THAT is a privacy violation.
  • I think the real answer to this, however, is that they impliment some checking on the server end to verify the results so people can hack their client all they want.
    If the challenge has a simple answer, and the task of verifying the answer is trivial compared to actually finding it, then they can verify the results as you suggest. However, in the case of exhaustive keyspace searches, the answer isn't simply "I have found the key" (which can be verified) but rather "I have searched that part of the keyspace you gave me and I have either found the key, or I can tell you for sure that the key isn't there".

    There is no way you can "verify" that latter answer without actually redoing the entire work yourself, in which case there would be no point in asking others to lend you their CPU time in the first place. Even though you know the key yourself, you can only detect the liar if he claims having searched the part of the keyspace it is in and still not found it. All the other sections of the keyspace would remain in doubt, and the challenge would be useless as a measure of how hard it is to search the entire keyspace.

    Now, could someone come up with a way to verify by looking at the data submitted that the computer is still safely in the hands of the owner, then we would get another benefit from the d.net project (as well as getting this thread barely back on topic).

  • You need to check only a small percent (i.e. probably less than 0.1%) of these values anyway, since anyone trying to fake his keyblocks will want to do crank out much more false keyblocks like those pranks before.
    This begins to sound like a reasonable approach, but consider carefully the implications of your statistical approximations here. Even if the bad guys are detected due to one of your random samples showing fake results, how are you going to determine what other submitted blocks should be invalidated?

    Relying on the fact that the bad guys have used only a single ID works only as long as the risk of getting caught this way is minimal. As soon as you start labelling all reports by the same submitter as faked, they will start obtaining multiple ID's to the point where your attempts at detecting them will be meaningless, much like you can't eliminate spam by listing the e-mail addresses of all the spammers.

    There will simply be more rogue keyspace searchers than keyspace blocks per searcher (or more spammers than spams per spammer), and your 0.1% sample will detect only about 0.1% of the rogue keyspace blocks submitted. This will still leave the integrity of 99.9% of the submitted blocks in doubt.

    However, if you are somehow able to check a randomly chosen piece of data in each keyblock submitted, then you stand a pretty good chance of detecting blocks where more than half the data has been faked. Is that good enough for the application at hand?

    You won't save any money by having someone search your premises for that missing $100 bill, and then hire someone for $100 to follow him around and make sure he doesn't sneak the money away and pretend not having found it.

  • wrong....see the other comments or read my summarY:

    Distributed.net stuff is installed by choice, and any users of the clients are fully aware WHAT and HOW OFTEN personal data is transferred over the net.

    Comare that to softwares and P-IIIs that blindly report who you are, and what you're doing back to their masters. This is done without users' knowledge, and without giving users the option to opt-out of the data transfer. hardly fair, and hardly the same thing.

  • Re:No (Score:1)

    by Smack ( 977 )
    I have a laptop for work that's plugged in 90% of the time. The reason I don't have a desktop is so I can use it at home (plugged in) as well. So for me, it's not dumb at all.
  • My boss just asked me to install rc5des on all of the machines here. I've got no choice but to boost my keyrates...
  • >They wouldn't have to crack your Linux password, >they would just have to boot off a Linux
    >boot floppy,


    Maybe on yours, but mine is configured to boot only from the hard drive, and changing *this* requires a password stored in flash memory (or whatever it is). Eliminating *that* can be done, but iirc, it's going to take special equipment (remove chip from board & flash) or a dealer.

  • If my system gets stolen, they'll try booting up, see some wierd screen that doesn't say Win95, give up, and format the hard drive.
  • The irony here isn't lost on me, but what is so wrong with this idea provided that it is done in a transparent manner? The Internet does provide an excellent tool for finding computers in this way, and I think a security system based on this principle would sell - and rightly so. I don't think this kind of system would nescessarily be a challenge to personal freedom provided it is done properly.

    --

  • Wow! The found the thieves because the stolen laptops had an application that contained a unique UID, and sent periodic network announcements to a centralised body.

    Gosh, if everyone had one of those on their computer, computer crime would be greatly reduced! And if it was built into the OS or even the firmware, it would be hard for thieves to remove.

    So, let's petition Intel and AMD and MS to get together so that all new computers report in a unique ID to a central body over the network whenever they have a live net connection.

    Yeah! That'd be great..

    giggle :-)
  • It seems to me that this would be an ENORMOUS performance impact on the clients as they are. People keep shouting for them to code it "right", and do it only in the True Method of All Things Coded: OpenSource, but what they don't realize is that in order to beef it up cryptographically to ensure that results are indeed calculated and not forged, you'd have to take an incredible performance hit.

    Now would you honestly prefer that D.net progress be *halved* as a result of them turning to the Good Side of the Force? C'mon..

    I completely agree with D.net's reasoning and their decision to remain closed for now.
  • I'm not "bashing" OpenSource. I simply feel that there are certain times when keeping your source code closed and proprietary is perfectly justifiable. This is one such case.

    And yes, performance will be *drastically* reduced. Perhaps not halved, but at least on the order of 20% or more.

    All of these calculations have been optimized to an obscene degree. It's all done down to the assembly code level. Taking and storing mid-calculation data and performing a checksum/cryptographic hash/whatever on it will be an *enormous* performance hit, relative to the highly optimized calculation loop that's being performed on the data.

    Now I have no actual numbers to base this on, but I believe the D.net crew said almost as much (with a number in the same range) on their web site, or in some message someplace. Check out their FAQ or something for details. They explain why they remain OpenSource, and I think their explanation is perfectly adequate.

  • Re:No (Score:3)

    by Fastolfe ( 1470 ) on Thursday August 26, 1999 @05:55AM (#1724663)
    You're totally right. All closed source software is inherently EVIL, and all companies who release closed-source software are themselves spawns of satan.

    Who cares if we have to make all of our software cryptographically secure if we want to be able to trust their output? Who cares if this security HALVES the performance of CPU-critical tasks like D.net? OpenSource is always good, and if making programs cryptographically secure is the only way for OpenSource programs to give us trustable, reliable results, then by golly that's the way it must be done, because OpenSource is the True Path. OpenSource is the Light. Programming to pay bills is the path of the Dark. Fear the Dark. Oppress the Dark. Closed-source programming is the path of Evil. All evil must be destroyed.
  • By opening the source, people like those Russian guys can fiddle with it and

    Not necessarily. It should work this way: when the client checks all the keys in a block, it saves the results of the intermediate calculations, and hashes all of them via a semi-secure hash function (md5, sha1). You just have to be careful that these intermediate values are hard or impossible to get without the real computations; for example let them be the last bit of the supposedly decrypted text (which then looks invalid).

    Then, occasionally, you check some of these values by hand (or, the horror, by sending the same task to another individual :) and if there's a mismatch, you know one of them is lying about his performance.

    You need to check only a small percent (i.e. probably less than 0.1%) of these values anyway, since anyone trying to fake his keyblocks will want to do crank out much more false keyblocks like those pranks before.

    The only question is where to store these additional values, as it might take a significant amount of storage to administrate the keyspace anyway, but I think it even sufficient to store a few bits (at most 32) of this hash to be able to catch the bad guys.

    Now I can only hope the distributed.net guys read this :)

  • Now would you honestly prefer that D.net progress be *halved* as a result of them turning to the Good Side of the Force? C'mon..

    Who said halved??? I just devised a method which provides a way to prove that a given block is incorrectly submitted as done. Inexpensive even in the storage point of view (just a few more bits for each block to store, where the submitter ID is already stored); and there's no need to check all of the results, just the suspicious ones. Done correctly, just slows the progress down possibly even microscopically. The "cryptographic" method to compute these bits is actually very fast too, MD5 doesn't take too long for a few bits per N blocks at the clients. And might be even unneeded as the final bits of computations are probably hard to get anyway...

    Oh, and let me ignore your opensource bashing.. Why do you think people can't abuse the closed source version too? This simply seems to be a way where you can be safer than that, even with open source clients...

  • Well, I think the only "reasonable" (ehrm) incentive to "fake" results is having a large keys/sec value, and if you have multiple id's, you won't have that :)

    I think by carefully looking at log results they would be able to get most of the bad guys anyway. IP address, submitter id, submitter team; some of them must repeat frequently if you use a fake client...

    But having just sending a few bits of result (i.e. 32 bits for each keyblocks, each meaning the xor of the last bits of the particular cleartexts from the 1/32 of the keyblock) is basically what you and I am saying too, I like "my" way because by storing less bits you can store more proofs to check later if someone looks suspicious, whereas for a random check it's more wise to send more bits (the more to chose from, the more sure you can be faster by checking it).

  • Re:RC5 (Score:1)

    by Imabug ( 2259 )
    "when" is exactly the point of the d.net rc5 and DES efforts. the first DES contest took d.net what, a year or so to crack? the second fell in a few months, and the third DES contest completed in less than a day. the point is to show how long des/rc5 can stand up to brute force attacks.

    imabug

  • Re:RC5 (Score:1)

    by Imabug ( 2259 )
    I suppose cracking times can help show how vulnerable an encryption scheme is to brute force attacks. Whether it's a dedicated machine doing it (like EFF's Deep Crack) or a bunch of computers working part time on it (like with d.net), if the method can't stand up for very long to a brute force attack, are you going to use it? DES III fell in less than a day. Granted the key was found in the first 1/4 of the keyspace, but that still means less than a week to crack DES just by brute force.

    Calculating how fast a keyspace can be searched is easy. The d.net effort is *showing* how fast it can be done. I think when DES III fell, everyone involved was shocked at just how fast it took, even though they could calculate the top keyrate, how fast it would take to ramp up to that keyrate, how many participants it would take, etc. it turned out to be a very graphic presentation on how weak DES is now. That's what the contest is about I think.

    But d.net is about more than just cracking encryption. it's about the power of distributed computing. cracking just happens to be a good illustration of DC.

  • Re:No (Score:1)

    by Imabug ( 2259 )
    >BTW: 1) d.net client source is still closed. d.net is an insult to the Open Source community and we should have nothing to do with it.

    i don't recall d.net ever having claimed to be open source, so how can it insult something it isn't?

    imabug
  • A bunch of lameoids in here are claiming that tracking via distributed.net is just as low and dirty as tracking via the Microsoft document ID. Get a grip, people!

    The distributed.net client takes active effort to set up. The Microsoft tracker is enabled by default, and takes active effort to disable. That distinction makes all the difference in the world.

  • Didn't some (older?) SGI boxes require an IP connection to boot ? I think I heard that, havent seen it myself though...

    It could be a nice feature to have in firmware. Connect to the vendors' ``bootup registration'' server, send a unique id of the hardware along with some information (like IP/subnet/routing).

    The story I heard about the SGIs was, that it was an anti-theft measure.
    However, I wouldn't count on having Award or any of the other PC bioses hold an IP stack anytime soon though...

    If someone wrote a daemon (regd) that was run right after the network came up, which did this registration, there could be a good chance that any asshole thief would at least boot the machine once before he wiped the drives.

    Do I smell a project here ? :)

  • No (Score:1)

    by Mawbid ( 3993 )
    Everyone who runs the d.net client on their machine should understand the implications. The d.net client doesn't claim to be an installation program and then secretly transmit information to d.net servers without the user's consent. If it did that, then slashdot readers would be duly outraged.

    BTW: 1) d.net client source is still closed. d.net is an insult to the Open Source community and we should have nothing to do with it. 2) I think running something like this on a laptop is dumb -- save your battery instead.
    --

  • Re:No (Score:1)

    by Mawbid ( 3993 )
    Because the reported reason for not opening up the source is that with access to the source, morons would create bogus clients that pretend to be crunching keys at an enormous rate just for the thrill of seeing their handle at the top of the stats. I don't doubt that for a second. What I DO doubt is the contrapositive, that if the source is kept closed, the re won't be any hacked clients. And I have good reason to. Remember that Russian guy [rc5.aha.ru]?

    What d.net obscurity-apologists are saying is that this problem can't be solved openly, and THAT is an insult to open source. If you believe them, you'd better run out and buy a proprietary encryption package because pgp isn't safely closed like the d.net client.

    I don't understand how so many of the people who champion for open source and see the benefits in all other areas can turn around and root for security through obscurity just because it's d.net.
    --

  • The idea that anyone would steal a computer and then operate said computer on a public network without reformatting the drive or otherwise replacing all identifying parameters... well, I don't know whether to laugh or cry.

    Serves them right, of course. It just goes to show that good wins because evil is generally stupid.
    ---------------------
    the SlashDot spellchecker:
  • I used to follow the ICQ newsgroups and I had
    tried helping someone do this exact thing. They
    said their computer was stolen but a friend
    had seen the account logged in after it was stolen and even had a copy of her contact file
    that contained that last IP.

    I didn't know if that IP was accurate. But I
    explained about locating the ISP and contacting
    them. I detailed what had to be done, whether it
    was to traceroute by themselves, or ask Mirabilis to help them trace the logins of that account. Actually, I think I had asked Mirabilis for login
    information but the answer was that they did not
    have any logging in place so they couldn't help.

    I didn't hear anything for a couple of weeks and
    by then I had stopped following those newsgroups.
    I had forgotten all about this till now.

    At least this is how I remember it...it was around first quarter 1998 I think.

    Andy

  • You just want to start the client up as a specific user on bootup, right? That doesn't necessarily imply a login.

    Probably what you want to do is stick something like su -c "rc5clientthingy --option blah" rc5user < /dev/null 2>&1 > /dev/null & in one of your init scripts. Bonus points if you set up a full-blown SYSV script for it (a la /etc/rc.d/init.d).

    You probably want this to start in runlevel 2, 3 or 4, as those are the "network-enabled" ones. (if you're using standard runlevel configurations)


    Berlin-- http://www.berlin-consortium.org [berlin-consoritum.org]
  • Blah. So what? With local console access I could break into any x86 machine I've ever seen. Sometimes it taks a lot of effort, but if the machine is stolen and I have the time to open it I can get into it. No x86 box I've ever seen stores passwords anywhere other then CMOS, that is erasable via a jumper on the motherboard or removing the battery for a while. Even in the off chance it were FLASH, just call arround a bit. There are always chips available. Not to mention most Flashable BIOS units have a special key combo you can use to initialize the FLASH sequence, used in case you try to update your FLASH and it doesn't work right and kills your box. It just loads the flash image from floppy.

    As for getting into Linux, how do you boot? LILO probably, most people running Linux use it. At the prompt just type "linux single" sometime and see what it does. ;) Of course the image name could be different, hit tab. ;) I believe there is even a key combo to get the lilo prompt if it's set to not show it.

    Or I could just take out the HD and put another one in. Most systems are set to autodetect the HDs on bootup, and will change the config automaticly without needing BIOS config.

    Of course, the point of this message is that nothing is secure if the attacker has physical access to it. Crackers have broken hardware security many times in the past, and probably will continue to. Most dongles are crackable, Playstation, DVD Region codes, Computers, Networks, and probably a ton of other stuff I haven't thought of.

  • You know, tracking computers after they've been stolen is really simple. You don't even need a internet connection. There are companies out there selling anti-cartheft chips that are basically minature transmitters. When the vehicle is stolen, you call up the company, and they activate the chip via a satellite downlink, and then it's a simple matter of tracking down the signal.

    Similar technology could easily be implemented for computers without all the privacy hoopla surrounding software or the "UID" stuff intel would have you believe is really there for your own good.

    --

  • The SB1200 doesn't store the MAC address. Even if it did, all you need to do is open your browser and click on this link [192.168.100.1], which will reset your modem to it's factory defaults. This is also useful when the modem periodically fouls up and garbles all your configuration information (usually resulting in a "serial port error" whenever you try to connect).



    --
  • Hey there...

    I've been wondering about how to get my rc5des client logged in automatically on bootup for a while, and this seemed like the perfect opportunity to ask.

    I searched all the HOWTO's for similar information (how to log in a user on bootup) but evidently I did not find the information I needed.

    My girlfriend often uses my laptop and can't be bothered to remember to switch to a virtual console and log in rc5. So how can I make rc5 login and begin work on bootup?

    Security isn't *much* of an issue here, I've got a separate rc5 user, running in a restricted bash environment.

    Any pointers to documentation? Or free clues?

    Muchos Gracias!

  • Several reasons:

    - You install distributed.net expressly to send stuff back. Distributed.net tells you explicitly that it is doing so.

    - Distributed.net only sends things back that are related to its mission.

    - You install Microsoft Office to do word processing, create spreadsheets or run a database. None of these missions require an ongoing information exchange with Microsoft.

    - Microsoft includes this information in their .doc format without informing you, and without giving you a chance to opt out.

    - Microsoft is a large company that many people distrust becuase of similar fiascos in the past. As a result, our comfort level with giving them information is likely to be lower than with distributed.

    D

    ----
  • Some of the IBM laptops have passwords on the motherboard and hard drive that can't be erased. If you forget the password, IBM can't help you. The motherboard and/or hard drive must be replaced. This makes the laptop useless to a thief.
  • Not really. My experience in tracing people on the 'Net has shown me that most ISP's will hand over a lot of info without a warrant or any identification. As an example... Several months ago I had some script kiddie trying to bring down our companies web server by using a DOS attack. While the kid didn't have a chance in h*ll of actually crashing the server, it was annoying. So, I traced his IP, identified myself to to his ISP over the phone, and explained the problem. I was promptly given the users name, address, and telephone number. You shoulda heard his mom go off on him when I called :)

    That's not a solitary incident either. I've requested this type of info, for legitimate reasons, several times in the past and I've never had an ISP tell me no. The closest thing I've ever had to "verification" was an ISP that asked for my telephone number, and called me back. Identifying people is easy if you know how to ask properly..
  • I disagree. The way I see it, is that it's very simmilar to slashdot logging your IP address when you connect. Pretty much everything on the internet will log your IP address when you connnect to it. Also, rc5 is completely optional, it's not like windows logging your IP everytime you connect to the internet without your knowledge or concent.

  • Re:No (Score:2)

    by dirty ( 13560 )
    I do understand their reasoning for keeping it closed though. The way the current system is setup it's very open to people writing hacked clients to skew the results. Right now, it would require someone with some technical expertise to write said client. If they open sourced it, any idiot with a little C knowledge could write a hacked client. It's security through obscurity, but it's still some security. I think the real answer to this, however, is that they impliment some checking on the server end to verify the results so people can hack their client all they want.
  • I think most non-intel systems have power on passwords that are stored in PROM. These things don't need a battery to survive, and if you forget it you better hope you have a PROM programmer ready.

  • Hmm.. I'm thinking I should put rc5 back on my notebook :) but then again I never take it anywhere, and the fools that steal it would have to a) crack my linux root password, or b) format & install something new, so it would be useless to me :\ oh well.

    Time to implant the homing beacon.



    -- dc.
  • They wouldn't have to crack your Linux password, they would just have to boot off a Linux boot floppy, mount your partition and edit your /etc/passwd or /etc/shadow to delete your password altogether.

    I personally use a BIOS password, but then I'm sure there's a jumper I could short inside the damn thing to get rid of it. What we need is encrypted file systems, non-overidable BIOS passwords and the like, (but then what do we do when we really forget the password???)
  • If you remove the motherboards battery, then the password would dissapear. Thats my guess.

  • When someone steals your cell phone, and then they answer the phone before the number is changed.

    Anyway, this could be a good way to sell distributed.net to companies. I know big corps would trade their extra cpu cycles for the safety of their most expensive machines. Oh, well. Just a thought

    geach

  • not sure if this will be the same as on your machine, but under redhat 5.2 --

    log in as root (of course), goto /etc/rc.d, and joe (or whatever) the rc.local file.

    add this line at the end:

    /PATH/rc5des -quiet

    where /PATH/ is where you've placed RC5...

    this script (rc.local) is run after the system boots up, but before logging in, that way any programs here will run regardless of whether you logged in to the machine or not..

    hope this helps.

  • I actually did that to my computer by accident.

    I had been locked out because my little sister had set the BIOS password and forgot about it. However, I didn't have a PROM programmer in hand. What I DID have was an incompatible BIOS.

    So, I took the other BIOS, plugged it in and turned it on. Needless to say, it didn't like my CMOS settings, so it rewrote them. I plugged in my original BIOS, it didn't like my CMOS settings either and it rewrote them. Then, I had a clean default BIOS.

    Warning: I'm not responsible if you fry your system doing this.

  • The real problem with cryptographically securing the program is you then have to trust that program or another on their system to correctly do the crypto. F.ex if you send every block back to d.net with a hash of the d.net client and a signature a hacked client could just use a precomputed hash of the non-hacked client, and happily send off a signed block that looked correct. After all the client has to know the proper key to sign with or it can't sign in a non-hacked form. You end up with more software on the untrusted computer that you have to rely on to function in a trusted manner. If you can't trust that the client will not be hacked how can you trust that the over-watch code won't be hacked either!
  • I can't believe how stupid these thieves were. Who in thier right mind would connect a stolen computer to a local net/the internet without first formating the HD? You have no idea what's on there. What type of viruses it has? What is shared? What programs it run?

    With the way that most websites use cookies, I'm sure there are any number of websites that the thieves could have visited that would have been able to give the owners the same data. Then there are programs likes netscape which can send all your information back to netscape with every click of the mouse if your not careful.

    Bottom line, they were very stupid thieves.

    I wonder what OS these laptops where running? Must have been Win9x...

    Quack
  • Which "them" is that? HNN, mindsec, d.net, Microsoft?
  • i am rather new to linux so there may be better and mor sexy ways of doing it but when i want something to start at bootup i just add it to the bottom of /etc/rc.d/rc.local

    however my problem is when i try to start redir this way it doesnt take... and i have to do it manually. however i rarely reboot so no biggie :)

    -fixe
  • I'm running the dhid daemon (www.dhis.org) on my laptop, so that no matter where I connect to the 'net, I would have the same domain name. I guess it would work just as well if it were stolen from me.
  • And you, in your humble and obviosly 'insulted' opinion, that D.net should open their source so every little script kiddie can hack the code so they do a gigakey/sec, just to be cool? This is a serious contest, and crap like that would both ruin it's value and detract from the point of the endevor - to prove that RC5 isn't strong enuf.

    By opening the source, people like those Russian guys can fiddle with it and skew results.

    We know people can't be trusted to do whats right, so why do something that is inviting attack?

    Before you attack d.net and say it's an insult to open source, pause to think. Everything in the world shouldn't be open source. Some things need to be closed to protect people from themselves. (and other, more stupid people).
  • You are presuming that thieves are computer techs.



    You are also presuming that the buyer of a hot computer would know how to install the Operating System.



    You are also presuming that the person has the install media.



    Non techie types don't think of this stuff. The thief usually sells it for cash quickly either to a fence who resells or to a waiting customer.



    In the past, I've seen laptops come into the shop for upgrades or to replace that ubiquitous lost battery charger that are obviously stolen or to wipe and reinstall.
  • i usually clean the windows before using them.
    ;-)
  • OpenBIOS [openbios.org] will have network support. This is to easily allow network booting without using a PROM on the NIC.

    It could be easily added in when we have something workable. Unfortunately, that won't be for a while yet.
  • Won't that run the client as root? That doesn't sound like a great idea. I like the sound of the earlier 'su' solution.
  • It would have been that much more ironic had the laptop been running the SETI client - While searching for extra-terrestrial intelligence, a computer reveals terrestrial stupidity. Not that it takes a computer to do that...
  • I remember reading about someone recovering his PC the same way coz the lamebrain who had bought it from the thieves just plugged it in, connected to the net and ICQ connected to ICQ server. The owner discovered his ICQ account was active, tracerouted back, and called the ISP.
    Can anyone find a link to that story?
    ---
  • I have a marquee screensaver announcing "This computer is protected by NETLOCK. The owner will immediately be informed of any interference with this computer via THE INTERNET" in super-bold red type.

    And then I leave it switched on when I'm away. I'm relying on burglars' ignorance, since I don't leave my modem plugged in, but it's worked so far :)

  • > Well, I think the only "reasonable" (ehrm) incentive to "fake" results
    > is having a large keys/sec value, and if you have multiple id's, you
    > won't have that :)
    You guys are lacking imagination. If I were to hack the d.net
    client, I'd keep the key rate the same. I'd just make sure that if
    I found The Key, it'd tell me first, not distributed. Then I get
    all the prize money and I can donate money to charities
    that I think do more good than, say, ones de facto dedicated to
    ensuring rich people don't have to pay for their software.
  • The PIII ID code could not be removed. And, furthermore, it could be activated without the user's knowlege.
    The PIII ID code doesn't broadcast itself, you know. It just exists, much like any other ID that might be available on a machine. It requires you to run some software on your local machine to send the code to someone else, and so, it no more or less private than a software-generated ID.

    In other words, trusting your software not to send your hardware ID code is no different than trusting your software not to send a crytographically uniquie ID that was generated for your machine. Having a PIII doesn't make your machine any less (or more) private than having any other microprocessor-based machine.

    The only valid issues I've ever seen raised about the PIII's ID code were concerns over some ill-conceived applications that did not properly consider security and/or privacy. However, such issues should be dealt with separately from the existance of the ID (which is not in and of itself a bad thing), since it is possible to do these same bad things without resorting to the use a microprocessor's ID code.

    It really surprises me how much FUD is still floating about on this topic, most of which does not appear to have any basis in reality.

  • what is the function of the ID?
    I've always thought that Intel's real reason for the ID was to aid in the tracking of stolen chips. If there are other good uses for the ID, I haven't thought of them.
    The ID can not be removed by the user (unlike software ID methods) and CAN be activated without user consent.
    It is comments like this that led me to ask if you thought the ID gets broadcast all by itself. It matters not if the ID is present or removed, activated or not, unless some software sends the ID. And if you can't trust your software to not send your hardware ID, you can't trust it to not send a crytographically unique ID that it created just for you (which can often be used to achieve the same effect). Yes, disabling the ID can stop malicious software from getting access to the hardware ID (if you choose to actually run the malicious software on your machine), but it can't stop the malicious software from achieving the same results through other means.

    Thus, your comments on the easy foiling of software methods also applies to the sending of a hardware ID since it requires software to do the sending.

  • Hey, this is off-topic, but I'm just wondering it you still have a copy of that program you wrote (simple, or hard, it may be, but I can't program myself or I'd try)... I want it so I can do the same thing to people on my compy! (esp. since, if they get past LILO, that'll be a real shocker! ha!)

    If you have it, email me at my address.. and thanks!
  • Encrypted backups?
  • The Pentium III ID code can easily be changed. Unplug the Pentium III chip.

    That's not changing code, that's replacing hardware. Why should I have to go through the expense and effort to change out hardware to avoid invasion of my privacy?

    Much the same as the Unique, tracable, Ethernet MAC address that many of you have installed in your machine (if you have an Ethernet card installed) is removable.

    Its easier than that. You can change the ID on your Ethernet card without removing it. But why should you HAVE to?

    MAC addresses exist to facillitate various aspects of networking. You give up annonymity in return for working technology. Why does the PIII ID exist? What bennefit does it offer to users/consumers?

    You do bring up an interesting point, however. Why should advertisers count on cookies to trace eyeballs? Why not snag the MAC address? Granted... this can be changed, but Joe User is unlikely to be aware of it or how to do it.

  • The PIII ID code doesn't broadcast itself, you know.

    I'm unaware of ANYONE claiming the PIII ID broadcasts itself.

    The three points I brought up still stand: what is the function of the ID? The ID can not be removed by the user (unlike so ftware ID methods) and CAN be activated without user concent. And finally, the ID was to be shipped activated by default.

    The only valid issues I've ever seen raised about the PIII's ID code were concerns over some ill-conceived applications that did not properly consider security and/or privacy. However, such issues should be dealt with separately from the existance of the ID (which is not in and of itself a bad thing), since it is possible to do these same bad things without resorting to the use a microprocessor's ID code.

    I would argue that the two issues have a much closer relationship. The fact that this identification technology was being announced in the same breath of ill-conceived applications is very telling. The whole idea behind the ID was to provide those very types of services! Ill-conceived indeed.

    Software identification concepts have also been tried. Cookies. Some users are accepting of them. Many are not - features to disable cookies went from third-party add-ons to rolled in features on major browsers. Once again, a software based technology is easy to foil once it is identified. The hard-coded ID number is impossible to remove.

    I do agree on one point. The fear over the PIII ID was overly hyped. The media seemed to harp on it for an overly extended period of time. I'm sure the general populous ended up fearing the PIII ID without any real clear idea of WHY they should.

  • I've always thought that Intel's real reason for the ID was to aid in the tracking of stolen chips. If there are other good uses for the ID, I haven't thought of them.

    Hmmm. That's actually a good possibility. Though, I'm not sure how big of an issue that actually is.

    Though, I'm of the opinion that the big problem for Intel is counterfeit chips; processors that have been remarked as higher speed chips. While they've put some hardware in place to make overclocking much more difficult - I think embedding a model number would have been better. Of course... this leads to the big "Is there really a difference between X MHz and Y MHz chips" question/conspiracy theory.

    Thus, your comments on the easy foiling of software methods also applies to the sending of a hardware ID since it requires software to do the sending.

    OK. I can see where you misunderstood my own understanding of the issue concerning how that ID can be used. And, indeed, a solely software based scheme could effectively do the same thing. And in both cases, it would require the interaction of a user to disable. But allow me to point out two distinctions between a hardware and software ID.

    The ability to remove the ID is important. If I find a software ID and delete it - its gone. For that software to work again, it will have to generate another ID. It makes it harder to continue to identify me. With a hard-coded ID, once the identifying process is running again, I can be linked with the same identity as before.

    A second point is how to set up the identification scheme. A software based scheme would require access to more resources. Not only will you have to get the person to execute the code, but you'll need to store that ID somewhere on the host machine. Of course, a minor point is also having to generate more complex (and larger) code to not only read the ID, but generate and store (possibly hide) the ID. With a hardware ID, its a simple matter of reading a register. I would suspect java-enabled marketing banners could do that with ease. Since there's no writing or control of additional resources, the code will be small and unlikely to attract notice... or leave evidence of its actions.

  • can you remember PIII hardware identification? This is the same thing.

    On the surface, this might appear to be the same kind of thing. But there's a pretty big difference on serveral points.

    First, the intent of d.net software is not to indentify and track an individual. Logging IP addresses, and consequently being able to convince an ISP to identify that address to a customer account, is a byproduct of system logs. Its a common convention to the net. I'm accepting of this since, generally, such logs are used for administrative purposes and discarded after a period of time. A smart business will have a policy to ensure these logs are dropped as soon as they become obsolete to avoid legal hassles ("Sure, we'd like to provide you that information and get caught up in your litigation... but we have a long-standing policy to delete logs after X days."). Less-intelligent [amazon.com] companies use them as gimmicks [slashdot.org]. In this case, everyone was able to act fast enough on a good enough reason to track down a theif. Its a byproduct, not the origional intent.

    Secondly, it is a software mechanism and not non-removable firmware. If, today, you decide you're just too uncomfortable with the whole idea of being able to be tracked via your d.net client... you can remove it. Delete it. It's gone. The PIII ID code could not be removed. And, furthermore, it could be activated without the user's knowlege.

    Finally, as stated by other people... d.net software is an "opt in" system. The PIII ID origionally shipped activated; you had to run specialized code to deactivate it. The implication is that it required prior knowlege as well as additional effort to NOT report your identity and invade your privacy. The d.net client requires prior knowledge and additional effort to activate - by default it will never report your existance.

    The whole idea of invasion of privacy is NOT the ability to be identified. The distinction is whether you consent to that identification.

  • One of the castoff hard disks I've dragged home (I'm a hardware packrat) announced this when hooked to a box and booted up:

    [some system brand name]
    For technical support call Xxxxxxx and Associates, [phone number]

    Then on to the DOS prompt. Apparently the idea was to get anyone who had trouble with a stolen system to call that number.. which happened to be its then-owner. Just a couple lines in the autoexec.bat. Dunno if any crook was ever fool enough to do it, but this dated back to the days when its 20mb of programs would have cost a few thousand to replace off the shelf, so maybe a thief wouldn't have wiped the drive.

  • Re:RC5 (Score:1)

    by AME ( 49105 )
    This is exactly why I picked GIMPS over Distributed.net and SETI@Home.

    RC5: We know that there's an answer, and a probability theorist could even tell you how long it will take to find.

    SETI: Even if you believe in E.T. (I don't), the particular data being examined by SETI seems of minimal real value in finding him.

    GIMPS: We have every reason to believe that huge Mersenne primes exist beyond those already known, but we don't know. The only way to find them is by a brute force.

    In this sense, I consider, the GIMPS project to be somewhat more serendipitous research -- more interesting. (Ok, "serendipitous" is the wrong word, since we are, in fact, looking for huge primes. But it's 3:45AM and I can't think of the right word.)

    [By the way, there are only 38 known Mersenne primes and the most recently discovered is over 2 million digits long. If you like huge numbers, GIMPS is the project for you.]

  • >but then what do we do when we really forget the password???

    Restore from backups?

    Ale

  • RC5 (Score:1)

    by ODiV ( 51631 )
    Sorry that this is a little off topic, but I haven't seen anything on /. about rc5 in awhile and I have a question to ask.

    Here goes...

    What's the point of rc5? I can see d.net wanting to participate (because of the money and to test distributed computing), but why is the money being given away at all??

    Everyone _knows_ that if you search long enough, you'll find the key. It's not a question of 'if' it's a question of 'when'... so what's the point?

    *shrug*... Maybe I just don't understand.

  • Re:RC5 (Score:1)

    by ODiV ( 51631 )
    First of all, thanks for your response.

    Now I have two problems with this:
    1. Couldn't you just calculate about how much time it would take to search through all those keys?
    2. With d.net finding the keys, how useful will the time be? "The rc5 project took 5 years to crack by millions of computers that worked on it when they felt like it." It's not a controlled environment, so won't the time be meaningless?
  • Comparing D.Net's IP tracking of the client to Microsoft's is a moot point. D.Net has proven by their actions that they (and their motivations) are worthy of our trust. Microsoft however, has proven by their actions that even when they do follow the letter of the law, their motivations are not worthy of our trust.

    Remember? Reputations. Reputations. Reputations.

    Identical actions can be interpreted as either good or evil depending on the overall context.
  • No, from non-encrypted backups that are stored off site in a vault. :) (what happens when you forget your combo to the vault?)
    BTW, y are we so worryed about securety anyway?
  • So the distributed.net logs were able to give them the IP address of the most recent connection from that machine. Utterly useless. In order to find out more detils of the connection, didn't someone have to call the ISP and fax them a warrant?
  • Please help me to understand why microsoft office is any less of an active effort to setup when compared to a distributed.net client. Additionally, the bloatware that is MSOffice will function without the GUID, can the same be said of the distributed.net client?
  • I don't know about Windoze machines or MacOS, but all Unix varieties I know about let you easily change the MAC address, so that's not a reliable identifier.

    This is a very useful feature; it allows me to have a Windoze machine at home to connect to my cable modem when I have a problem with MediaOne and they refuse to admit to the existence of other than Windoze and MacOS. At other times, my Linux machine, normally connected to the net, uses that Windoze box's MAC address, (the one that MediaOne associates with my connection), rather than the one programmed into its NIC. This means I don't have to swap NICs between the two machines to humor MediaOne.

  • You're confused. Why should MediaOne care how my machine sets its MAC address, so long as there's only one NIC connected to the cable modem? It's easier for them than to have them change their idea of my MAC address when, at their request,I switch from my normal machine to the Micro$oft machine and then change it back after the problem is debugged. It's easier for me than swapping the card between machines and totally equivalent from their viewpoint. The Micro$oft machine exists solely so I can plug it in in place of my real machine when I call MediaOne with a problem.

    My e-mail address is petersonp@genrad.com. I have no reason to hide behind anonymous postings.
  • I ran RC5 until SETI came out. I am hooked on the poweruser competitions. Do people run both apps? Should I switch back? I figure the data churned by these apps are more usefull to society than the crap I churn out.
  • Well laptops with rc5 are not a good look - the cpu will be working all the time which prevents most of the power saving tricks from coming active. (kinda like NT on laptops)

    As for your hardware blowing out... perhaps it was ratshit anyway. Edge gear is crap worldwide.
  • You realise what controversy this would have caused if the theifs had cracked it? :)
  • So does this mean that if I have the SETI@home client installed, I'd be able to find my computer if it got abducted by aliens?

    "P.C. phone home..."

Slashdot Top Deals

BLISS is ignorance.

Close