Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×

Pentium Computers Vulnerable to Attack? 227

An anonymous reader writes "One of the latest security scares is coming from security experts at CanSecWest/core '06 in the form of a possible hardware-specific attack. The attack is based on the built-in procedure that Pentium based chips use when they overheat. From the article: 'When the processor begins to overheat or encounters other conditions that could threaten the motherboard, the computer interrupts its normal operation, momentarily freezes and stores its activity, said Loïc Duflot, a computer security specialist for the French government's Secretary General for National Defense information technology laboratory. Cyberattackers can take over a computer by appropriating that safeguard to make the machine interrupt operations and enter System Management Mode, Duflot said. Attackers then enter the System Management RAM and replace the default emergency-response software with custom software that, when run, will give them full administrative privileges.'"
This discussion has been archived. No new comments can be posted.

Pentium Computers Vulnerable to Attack?

Comments Filter:
  • by Anonymous Coward on Tuesday April 11, 2006 @12:22PM (#15106891)
    physical access means the h4x0rs can take over your computer now, news at 11.
    • The Cansecwest presentation is here [cansecwest.com].
    • by Beryllium Sphere(tm) ( 193358 ) on Tuesday April 11, 2006 @04:44PM (#15109164) Journal
      But it looks like there may be something real here.

      The presentation lists events that will trigger a System Management Interrupt (SMI) and enter System Management Mode (SMM). Overheating is only one of them. Another is "century rollover". Taken literally, that would mean that anyone who could set the clock to 11:59 December 31 1999 [I'd say 2000 but I doubt the chip is mathematically correct] can enter SMM without needing physical access to the machine or to the circuit breaker for the air conditioning. Or to use the presentation's example, outl(0xB2, 0x0000000F);.

      If I read this problem report [monkey.org] correctly, then a process outside of SMM can write to the memory for SMM. (Controlled by the D_OPEN bit in the SMM control register).

      So it looks like you can do it without physical access, where "it" is a privilege escalation that *starts* from root. That's getting less absurd all the time as virtualization and technologies like SELinux become more common. Also allows planting a deeper-than-root rootkit. You could escalate to God of Hardware or in the CanSecWest example to "root at securelevel -1".

      Maybe I should email Duflot for details and write up something for my nerdish security blog [berylliumsphere.com]
  • by saleenS281 ( 859657 ) on Tuesday April 11, 2006 @12:22PM (#15106894) Homepage
    What am I missing here? If they already have that much access to the system, aren't you already screwed?
    • I suppose this could be used to elevate one's privileges. Restricted user runs the exploit code, and it spawns a process that runs under admin or system credentials.
    • Yeah that's what I'm thinking - if they have already got authority to overwrite your System Management RAM and reprogram your CPU interrupts... one of two things have occurred:

      1. They don't NEED to do any of it because they already own your box

      2. The system designers really fucked the pooch good on the security design of these components

      Come on even Windows knows that not just any Joe User should be able to reprogam the CPU interrupts...
    • FTFA: Cyberattackers can take over a computer by appropriating that safeguard to make the machine interrupt operations and enter System Management Mode, Duflot said.
      If they already have that much access to the system, aren't you already screwed?
      Decide already... Is this a cyberattack (online) or a physical attack (you sit in front of the computer and take out a blowtorch)??
      • Very true; If an attacker already has enough privileges to run a hardware level attack (fake an overheat), they already have root access. On the other hand, physical access is always a failure already. The only thing I would use an attack like this against would be a system storing an encrypted volume. Even then you can usually get around the encryption in some more traditional way.
        • why would you have to fake the overheat ?

          if you've got p4's installed in the machine, there's no need to fake anything, it's already in the package.

          aside from joking, badly written software that puts way too much pressure on the cpu, can overheat a badly ventilated machine. in some countries you just have to syncrhonize your attack with the weather conditions (over here it pops over 40C in the summer, a bit load on the machine and it will overheat by itself, no torch needed).

          and eventually there's no ultima
      • I could think of a few other ways to cause an overheat which aren't necessarily physical console access. They're not really remote exploits either, but let's say the target was in a datacenter. Even if you couldn't get into the datacenter, maybe you could interfere with the air conditioning equipment. (Which is usually outside / on the roof and less secure than the data equipment itself.) Or more simply perhaps, bribe/convince a janitor or someone in physical plant operations to divert or shut down cooling
    • What a crock. At least the editors could have linked to the actual presentation [cansecwest.com] (beware, it's a ppt). I was at CanSec West and this is not as scary as you would think. The exploit requires escalated privileges to begin with. The only thing it can currently be used for is bypassing secure levels inside of OpenBSD, where you already have root. Next time the editors could do a little research before posting, oh wait, this is slashdot. --m
      • by jmorris42 ( 1458 ) * <jmorris AT beau DOT org> on Tuesday April 11, 2006 @02:17PM (#15107894)
        > The exploit requires escalated privileges to begin with. The only thing it can currently
        > be used for is bypassing secure levels inside of OpenBSD, where you already have root.

        People, think this through a bit and some more dangers appear. If root can replace System Management Mode there are some interesting possibilities for evil. SMM runs at permission levels beyond ring0, think of it as ring-1. From there you can escape any virtualization, any chroot jail, probably even escape from inside an emulator like VMWare if you can manage to execute the exploit without the emulation catching it and simulating it. Until this is completely understood and fixed, Xen, usermode linux, chroot and possibly VMWare/VirtualPC should be suspect.

        Now imagine just how many people have root access to their virtual server at a hosting company and how many other users are running on the same physical hardware secure in the belief that their customer information is safe. But is it?
        • That is a good use of the vulnerability once you rig the hardware. You still have the rig the NVRAM and then cause the server to overheat sufficiently to trigger the failure. In theory, it sounds great, but as a practical matter, with that much physical access you could just threaten to stab the admins with your screwdriver until he gives you root on the other virtual servers.
        • any chroot jail

          If you've got root in a chroot "jail", you already own the machine. To break out of jail, just use a program such as the following (... and pass it a subdirectory within the "jail" as argument):


          #include <stdio.h>
          #include <unistd.h>

          void main(int argc, char **argv)
          {
          int i;
          if ( argc < 3 ){
          fprintf(stderr,"Bad argument count\n");
          exit(1);
          }

          if(chroot(argv[1])){

        • SMM runs at permission levels beyond ring0, think of it as ring-1.

          So does anything that can load before your kernel. (Like a boot sector virus.)

          Now imagine just how many people have root access to their virtual server at a hosting company and how many other users are running on the same physical hardware secure in the belief that their customer information is safe. But is it?

          This isn't really different than a boot sector. If you have root on a VIRTUAL server, you shouldn't have access to this or to the
  • What about MMUs (Score:2, Informative)

    by Anonymous Coward
    someone could do the same with ANY interrupt handler... oh wait... an MMU would protect against that.
  • Physical access (Score:4, Insightful)

    by Toba82 ( 871257 ) on Tuesday April 11, 2006 @12:24PM (#15106913) Homepage
    Physical access trumps all security. Everyone knows this. This really isn't news, just an interesting new exploit that happens to affect a lot of... systems that are already vulnerable from the same people in the same situation.

    Move along, folks.
    • Wish I had mod points for you.

      "Physical access" is one of the reasons why wireless will never - well, not anytime soon, anyway - be fully secure.

      • "Physical access" is one of the reasons why wireless will never - well, not anytime soon, anyway - be fully secure.

        Would you elaborate on that? I'm trying to understand the link between "Physical access" and "wireless".

        I'm hoping that setting up an OpenBSD machine (sparc64) to be an AP where only authorized people who log into it through ssh are allowed access through it with authpf and then only IPSEC traffic, might be able to provide decent security.
    • by jd ( 1658 )
      I believe that there may be situations in which there is an exploit into a contained part of the system, where that containment may be broken out of by exploiting this bug. I cannot think of any practical way this could be done that would actually add anything that wasn't required to perform the exploit in the first place, though.

      Having said that, I believe B3 security mandates that memory and other system resources have mandatory access controls for precisely this sort of reason - a user who already has sy

  • by dfn_deux ( 535506 ) * <datsun510&gmail,com> on Tuesday April 11, 2006 @12:25PM (#15106921) Homepage
    This hack assumes that the intruder already has write access to the nvram of the system. Also, the headline is just a cut/paste of a small portion of a poor article with few technical details. There is no PoC code, nor any specific chip mentioned. The headline refers to Pentium chips specifically and the articles says "any x86 based architecture, needless to say these are not interchangable terms... Shame on you Slashdot editors for posting this garbage...
    • By this point you may be asking yourself, "WTF is FCW.com anyway?" Their about page [fcw.com] explains:
      Established in 1987, FCW Media Group uniquely integrates government, business and technology news and information to produce resources that help government IT decision-makers achieve results and meet agency missions. Our market-leading print, online, event and custom media products form an integrated information system that serves the information needs of all members of the government IT buying team-agency executives, program managers, IT managers and systems integrators-across all segments of federal, state and local government.

      FCW stands for Federal Computer Week, a trade rag that US gov't stooges use to figure out how to best waste our tax dollars of shiny boxes with blinky lights. Their topic headings include the buzzwords:
      • Defense
      • Enterprise Architecture
      • Executive
      • Integrators
      • Intelligent Infrastructure
      • Product Solutions
      • Program Management
      • Security/Homeland Security
      • Wireless

      The anonymous submitter might do well to remain so. Scuttlemonkey, OTOH, may have to enter the witness protection program. He's getting as bad as Zonk.
  • RAM access? (Score:3, Insightful)

    by Bogtha ( 906264 ) on Tuesday April 11, 2006 @12:25PM (#15106923)

    Attackers then enter the System Management RAM and replace the default emergency-response software with custom software that, when run, will give them full administrative privileges.

    How is it that an unprivileged user can write to such a sensitive location in the first place?

  • I am so glad that we have legions of Security Experts to protect us against every possible Rube Goldberg attack out there. Thanks to their tireless commitment to security, I can sleep safer at night by knowing that no one will take a blowtorch to my processor, install custom software, and then override the security safeguards that they could have gotten through by booting into safe mode. These people are truly a God-send. </sarcasm>
  • Good Times (Score:5, Funny)

    by allanc ( 25681 ) on Tuesday April 11, 2006 @12:27PM (#15106936) Homepage
    Remember that old Good Times virus hoax? People who were In The Know knew that it was a hoax because it claimed that, just by opening it, it could physically destroy your computer.

    Then a few years later, Microsoft brought us Outlook with automatic attachment opening, making the first part possible, and now Intel has given us the potential for the second part.

    Good Times apparently wasn't a hoax, it was just ahead of its times. :)
    • just by opening it, it could physically destroy your computer.

      I think Commodore beat everyone up in terms of being ahead of time...try 1977! [6502.org]


    • Then a few years later, Microsoft brought us Outlook with automatic attachment opening, making the first part possible, and now Intel has given us the potential for the second part.

      Well, "hardware attacks" existed before too. There were some that would send your screen a refresh rate it couldn't handle, and it'd be destroyed (this is back in the text-mode days). Of newer things, some viruses would overwrite the BIOS, which I believe required reflashing in laptops which didn't have a ROM copy to reset to. Th
    • Re:Good Times (Score:5, Insightful)

      Then a few years later, Microsoft brought us Outlook with automatic attachment opening, making the first part possible,

      The watershed for me, will always be the IE images exploits, where a malicious website could run code, simply by your browser attemtping to download a carefully crafted image file.

      There I was, for years, telling people; "There's no way you can get a virus by just looking at an picture on the internet". Boy was I wrong.

      Bottom line, not matter what you pronounce impossible through software, invariably, somewhere out there, there exists a bug to accomplish just that.
    • Headbanger Virus (Score:3, Informative)

      by jd ( 1658 )
      The "Good Times" scare was a hoax, but it had an ancestor - the Headbanger virus - which actually could destroy the hard drive. It worked because neither DOS nor the drives had any kind of input validation. It was easy to derange the read heads - or break them entirely - by trying to go past the drive limits - first on one side of the drive, then on the other, repeatedly, as fast as the drive could operate.

      It was also based a little in reality - CPUburn could theoretically destroy an improperly heat-sinked

      • At this time, virus were usually very limited in how mane compters they culd effect.

        There was on that overwrote the park command so it didn't actually park the heads.

        There was an Apple Virus for the APPLE IIc(I think, maybe an earlier model) that changed where the heads read the disk. This trick was also a great way to hide data.

        There have been a coupl PC virus that wrote to 13. Another that overwrote the MBR.

        Now they are just inconvienant.
        • My favourite way of hiding data on the PC was to copy the FAT entries inthe the final sector (which nothing ever used, as it was "reserved" for diagnostic tools), then mark the sectors as bad. To unhide, just reverse the process.

          I looked into the possibility of using "dead space" (space left at the end of programs and other fixed-length files that canNOT be used by anything else), because when you load a program, you actually load complete sectors. It would have been easy to attach something to the disk int

  • by MobyDisk ( 75490 ) on Tuesday April 11, 2006 @12:29PM (#15106956) Homepage
    This attack would already require the malicious software to already be running on the machine and already have super-user access. Once you get there, it doesn't matter. The attack is worthless. Unfortunately, the article is short on details - so you can't tell if there is nothing to see, or if the report is just bad. I suspect there is nothing to see.

    Along a similar vein, I have developed a martial art where I can kill anyone in one blow. It requires that my opponent is already tied-up, asleep, and I have a gun.
  • by endrue ( 927487 ) on Tuesday April 11, 2006 @12:30PM (#15106964)
    Pentium computers are vulnerable to baseball bats!

    Seriously, if they have access then you are screwed anyways...

    - Andrew
  • New Security Rule: Keep you wife's hair dryer out of the computer room!
  • by SlappyBastard ( 961143 ) on Tuesday April 11, 2006 @12:32PM (#15106989) Homepage
    So, if I have a real firewall setup and I don't open every attachment I'm sent, I'm still safe, right? At the end of the day, you still have to run the exploit for it to work. So, how is that any worse than the rootkits running around at the moment? The vast majority of viruses still specifically depend on users who haven't hardened their systems.
  • What??? Overheat? So what does attacker have to do, block off all air holes? And what??? System Management RAM? You mean, like Remote Management module like HP's iLO access?

    I heard, act of God includes "stupidity".
  • by zenhkim ( 962487 ) on Tuesday April 11, 2006 @12:38PM (#15107046) Journal
    Just went and RTFA, and I'm frustrated by a lack of hard details about the new threat:

    - The article states that all x86 processors "could" be vulnerable. Does that mean the *entire* series of Pentium chips, even the older PIII and PII's? If so, are they equally as easy to compromise as the modern versions?

    - There is no mention of AMD architecture. Doesn't AMD have an equivalent "overheat failsafe" halt-and-cooldown function? Wouldn't that make AMDs vulnerable to this type of exploit as well, or do they require a slightly different attack?

    - Isn't the motherboard BIOS FlashROM responsible for the monitoring of and responding to dangerous CPU temperatures? Haven't they already been safeguarded against unauthorized writes, due to the Chernobyl virus?

    I think I'll hold off on ordering the prototype Borg implants when they come on the market.... :-(
  • What kind of longevity can you expect from a virus that tries to cook the CPU it runs on?

  • If the physical location of your servers is compromised, no amount of security software can save you.
  • Whoo, I'm safe!
    # machine
    i486
    Well, crap. :P
  • A few more details (Score:5, Informative)

    by Mr 44 ( 180750 ) on Tuesday April 11, 2006 @12:42PM (#15107100)
    I can't find the actual paper anywhere, but this blog posting [ncircle.com] has way more details than the article originally linked ... Very interestingly, Windows XP is not vulnerable, but OpenBSD is.
    • by Cleveland Steamer ( 625191 ) on Tuesday April 11, 2006 @01:12PM (#15107353)
      Yes, this blog posting is interesting, but it still leaves some important details out.

      Linux and *BSD have a /dev/mem device interface for accessing physical memory from user space. Usually, this device only allows access from a priviledged user:

      crw-r----- 1 root root 1, 1 Dec 6 12:34 /dev/mem

      Using /dev/mem, it should be possible to access the address range assigned to system management RAM. However, the CPU has a Model-Specific Register (MSR) for enabling and disabling accesses to SM RAM. The instructions that are used to read and write MSRs (RDMSR and WRMSR) must be executed from ring-0 (kernel level) or else a GPF occurs. However, the Linux kernel can be configured to provide a user level interface to MSRs via:

      crw-rw---- 1 root root 202, 0 Feb 24 09:18 /dev/cpu/0/msr

      Again, you'll probably need root priviledges to access the device.


      • Who says the system management ram is accessible by MSRs?

        Seems like there isn't enough on-die space to save the entire state of the O/S, and MSR writing is painfully slow, so it wouldn't have time to dump everything INSIDE the core before triggering thermal protection.

        More details? Anyone? Anyone?
  • Relax, I just got an email (that Thunderbird thought was a scam - you truly do get what you pay for...) with a link in it that automatically downloaded me a new processor (Pentium6 baby)...

    I ran it, and now my computer is "resting" for a few days.

    Take that Loic Duflot

    (if you want the link, just let me know, and when I boot up my new 6, I'll send it to you)

    --
    I just put some lightnin' in my Dell

  • by Oriumpor ( 446718 ) on Tuesday April 11, 2006 @12:47PM (#15107129) Homepage Journal
    Let me get this right, by DoSing the proc someone can overwrite the embedded code on the chip? If someone already owned the box and were to use this, it sounds like it would be the ultimate rootkit. Place in the proc, then when the system is hardened/reloaded initiate another DoS (lots are available for winblows) and viola instant re-infected Zombie PC.

    Or am I confused?
  • On a scale of 1 to 10, I think this threat is somewhere between 0.5 and 1.5. There are so many better ways to invade a computer than to somehow sneak this on there and wait for the machine to overheat. Especially now since the vunerability has been exposed, I'm sure the bit time virus vendors will now write code to look for it.

    Sure it is probably possible, but then I suppose it would be possible to retrofit my truck into a boat. Heck, it would probably be easier and faster to do that than it would be to
  • by dbc ( 135354 ) on Tuesday April 11, 2006 @12:51PM (#15107162)
    This reminds me of the vulnerability in the operating system that shipped with the Univac 1100/10. The checkpoint/restart facility allowed you to write a checkpoint image to tape. Part of the checkpoint image was the system status register.

    The crack:
    1. Checkpoint your job to tape.
    2. remount tape.
    3. fiddle the executive-mode bit in the dumped status register.
    4. remount tape.
    5. restart job -- mainframe p0wn3d.

    Of course, in those days, a student that could do that was quickly hired into the system programming staff so that they could keep a closer eye on him and also get some productive work from him.

    Ohh... BTW... if you can find an 1100/10 these days, it won't work any more. They fixed that about the same time they quit making CPU's out of vacuum tubes.

    I wish Intel would create new bugs, instead of just repeating old ones. Copycats.

    Just think, the script kiddies that pulled this off are now drawing Social Security.
  • I'm Safe (Score:2, Funny)

    by Waffle Iron ( 339739 )
    It's a good thing I run an old Athlon. This chip has a simple overheat handling procedure: just emit good old-fashioned smoke.

    Not only do you receive a convenient olfactory signal to alert you to the situation, but you also avoid security breaches brought on by overly complex thermal management.

  • Recently, researchers discovered a new hardware specific attack that could render virtually all computers vulnerable to attackers. They said that if an attacker gains access to the keyboard, they could inject any arbitrary code into the system and gain administrative privilages.
  • Do not leave your servers out in the open, lock them in a controlled access room (perhaps climate control as well). Throughly vet who gets into your server room. Additionally, do not let people who have low access levels access 'low levels' of the machine. This is revolutionary... in 20 years I can see it being commonplace for companies to have a "server room" outstanding research guys.
  • by throx ( 42621 ) on Tuesday April 11, 2006 @01:00PM (#15107255) Homepage
    ALERT!

    Pentium based machines are also vulnerable to a denial of service attack from a hacker with physical access to the machine and in the possession of a large axe. Should the attacker be wielding a pair of axes (one in each hand) then the attack would constitute a distributed denial of service.
  • Q: Oh hello Bondm be careful now, that table has a lot of expensive equipment on it. Bond: Can I surf for some p0rn on this computer? Q: Now Bond! Pay attention! That's your next target trainer. You just take this roll of duct-tape... Bond: I know, and use it to tie the hands of Mr Moto's gal-pal tot he bedposts? Q: No! Bond: What other possible use could there be for this stuff?? Q: Oh Bond, you take a piece of it and, while sipping a Martini, (shaken, not stirred) with one hand, you surrep
  • with a magnifying glass, focusing a beam of sunlight on pentagon computers...

    film at 11
  • by droopycom ( 470921 ) on Tuesday April 11, 2006 @02:32PM (#15108037)
    From : http://blog.ncircle.com/ [ncircle.com] (scroll down)

    cansecwest/core06: "security issues related to Pentium SMM"

    Loic Duflot
    Title: Security Issues Related to Pentium System Mgmt Mode

    It is day 2 at Cansecwest and this talk wins for 'so frightening that you want to hide under your desk in the fetal position'.

    I'll go through the high level technical and then end with pointing out a principal that is one of those universal truths I carry around with me everywhere.

    This entire exploit is based on documented x86 functions.

    Your CPU runs in a few modes, one of those modes is known as Protected mode, other known as System Mgmt Mode. When your OS is running, your in Protected mode and this is how much of the security is performed and you'll hear of ring0 and ring3. Just know that your in-world universe is in protected mode.

    System Management Mode (SMM) is used so that when there is something external to your OS world like say a thermal condition that needs to communicate some message, the CPU saves all its protected mode state out, does all this SMM stuff and then return to its regular scheduled program in protected mode.

    There are details that evolve registry addresses and very low level operations but for the most part, a system in a very secure state can be circumvented via this SMM facility. I'm talking free access to all memory and IO.

    The song goes a little like this:
    Enable SMI
    Open SMRAM space
    Replace default SMI Handler by custom one (do your duty)
    Close SMRAM space
    Trigger SMI
    Gain access to restricted operations.

    In the wider picture: works on most systems. Turns out that Linux and the *BSD's will fall victim to this attack strategy, however, Windows XP is not known to be exploitable because of a few system calls that are not present and more importantly a certain memory range in protected mode is not shared addresses to SMM.

    So, for the demo, they did not pick some shabby OS to exploit. How about OpenBSD at level2 (high security) with allowaperture=1
    Ummm...it worked. Theo, microphone please?

    Theo spoke to this OPENBSD issue and said he and the team have known about it for a year. They are between a rock and a hard-place because Xserver is really the core of the problem. It has too much damn access to regesters and is in the most unfortunate address space in protected mode because when in SMM, what is in that address range can be used to exploit.
    Solution is for Xserver people to abstract sufficiently so that the kernel can have more governance on the Xservers logic.

    Closing TK comments:
    A system or a world that has a policy governed by in-world mechanisms cannot be effective when a process in-world can reach to the out-world to cause in-world change. You could also say that since a problem cannot be resolved at the same logical realm it has been created, then it is also the case that the most effective governance of a world can only come from outside that world. Think about all the crazy things we do in the physical world. As soon as we could get to the strong and weak forces at the atomic level, we created a incredibly destructive device. I just hope that if string theory is right and there really are energy strings at the lowest level of the universe, that no one in our world get control of them. The negative outcome caused by the power hungry is too high a risk to even consider the positive benefits.

    Its late and I have been blogging way too much today I am certain that my mental packet loss is abnormally high. I'll return to this in-game out-game concepts later in another blog entry, when I am less sleep deprived.

    --tk
    • by Myria ( 562655 )
      How are you able to any of those sequence of operations if you are not *already* executing as root or as ring 0? If you already have control of ring 0 and/or root, you can do what you want to the computer already. SMM doesn't get you anything special, except perhaps the ability to mess with internal processor states you can't normally (make writable code segments in protected mode, for example).

      By the way, whenever the CPU does a memory read or write while in SMM, it asserts the SMM# pin. This means that
  • Why figure out something tricky and clever like an overheat-interrupt-security-rescue-procedure-overw rite-thingamajig when all you gotta do is send mails with an "for infection please click here" buttons?

    Works just as fine.
  • ...technical articles.

    Where to begin.

    First off, none of the low-power states C0->C4 stash to a system management RAM (yet). Second, the lower Cx states flush the cache, but they don't flush in response to heat, in that case they perform a Geyserville transaction which lowers frequency and voltage. Only if you exceed the thermal diode does it go tits-up. Now there's word it may save state in future Cx states, but I sincerely doubt anyone would be able to get inside the on-die ram, since it will sit beh
  • This vuln doesn't really mean much to general users. However, users who have Intel procs on secure cards (tamper resistant) should worry a bit. Generally, we try to control things on secure cards like thermal leakage (especially key bits).

    However, if you attack the driver of a secure card at the same time as you are thermally stressing it, you may be able to take it over, extracting the key data without triggering the tamper evident seals.

    Fortunately, security cards that I am familiar with do NOT use Intel

"Help Mr. Wizard!" -- Tennessee Tuxedo

Working...