Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Skype 5-way Calling Limit Cracked 427

BobPaul writes "It turns out when Skype limited 10 way calling to Intel Processors only it really was arbitrary! Maxxus has a patched version of Skype that allows 10-way calling regardless of the processor installed. There's also info about the patch: "The patch is the result of two phases: code analysis and design of the patch. The code analysis, or reverse engineering, reveals the relevant code block, which overrides Skype's limitation for Intel's dual-core CPUs. The patch design isolates the minimal set of instructions that need to be modified to cancel this limitation." Windows only so far."
This discussion has been archived. No new comments can be posted.

Skype 5-way Calling Limit Cracked

Comments Filter:
  • Lawsuit (Score:4, Insightful)

    by mtenhagen ( 450608 ) on Saturday March 04, 2006 @12:15PM (#14850043) Homepage
    I think this shows this was done on purpose to lock out amd users. A lawsuit by amd should be succesfull.
    • Re:Lawsuit (Score:5, Interesting)

      by cmoney ( 216557 ) on Saturday March 04, 2006 @01:56PM (#14850453)
      Yeah, except they're not locking out just AMD users. They're also locking out anybody who has an Intel chip that doesn't meet their arbitrary requirements. So to me it sounds more like a forced obsolescence plan to get people to upgrade to higher end PCs.
      • Re:Lawsuit (Score:3, Insightful)

        I really don't understand how they're going to get users to upgrade. If anything, this harms Skype. If I can't ru skype on a amd....i'll use...another VOIP program.
    • Of course, I'm ignorant. But how come a law suit? Companies make marketing arrangements all the time. What law says Skype has to work with AMD at all? Why should Skype have to write software to work on AMD? No reason at all other than the desire not to alienate a set of users. Skype doesn't have a monopoly on VoIP, if they want to limit their software to Z80s or PowerPC chips, why shouldn't they be allowed to? Market pressures will determine if self-imposed limitations prove workable for Skype, not the poli
      • Personally, I think it shows how incredibly stupid this move was on Intel's part. They're in the middle of an ongoing antitrust suit with AMD and this just gives AMD more ammo to use against them without giving any kind of real gain.

        If they were bit players in the market, it'd be one thing. Considering they're already going through antitrust litigation and thus under greater scrutiny than normal, this move just had "dumb, dumb, dumb" written all over it.
      • by Stephen Samuel ( 106962 ) <samuel@bc g r e> on Saturday March 04, 2006 @03:42PM (#14850705) Homepage Journal
        Of course, I'm ignorant. But how come a law suit? Companies make marketing arrangements all the time.

        The rules change slightly when you've got a near-monopoly. This is part of what tripped up Microsoft in their anti-trust trials.

        The problem is that it's far easier to convince someone to exclude "the competition" from the market when the competition has a disproportionately small portion of the market.

        For the ease of math, let's say that the Skype market is 90% Intel, 10%AMD. If Intel had to pay Skype 10million to compensate Skype for the lost market in excluding AMD then AMD would have to pay 90million to get Skype to do the same thing. Add to that the fact that Intel has 10x as much income from their larger market share (presuming the same gross profit margin -- which is rarely accurate in a near-monopoly situation) and you have a 90-1 difference in impact on their profit margins.

        Or - - to put it another way, between gross profits and market share, Intel could afford to buy off 100 market slots for every one that AMD could afford to.
        If it came to open warfare like this, AMD would be reduced to a tiny portion of the market and customers would be effectively unable to even find business that deal with AMD. (Dell anyone?). Once you further reduced AMD's market share like this, Intel's ability to further marginalize them would increase until AMD was reduced to an insignificant market access independent of the relative quality of their products.

        It's basically a market-ratio squared relationship which can easily spiral into a near-absolute market ownership, denying customers any real choice in the market no matter how good the competition is. (MS/Linux, anybody?)

        It's actually a worse than ratio squared relationship because we haven't taken into account the probability that, if Intel has a 100-1 ratio of market-exclusionary agreements, they can now charge a higher profit margin without significantly affecting customers' willingness to buy AMD. That, however is harder to quantitize, so I'll only mention it, rather than including it in my math.

        About the only real way to avoid this problem is to create artificial rules designed to stop such market-killing agreements when the market gets too lopsided, to prevent market choice from getting totally destroyed.

      • by rpdillon ( 715137 ) * on Saturday March 04, 2006 @06:05PM (#14851149) Homepage
        A marketing arrangement, as you call it, is one thing. But in this case, it goes beyond a mere marketing is a very specific type of marketing arrangement in which one company (Skype), in exchange for cash, artificially cripples their product to only work with a certain other (unrelated) product (in this case, dual-core Intel CPUs). The key element here is that the product (Skype) would, if left to it's own devices, work with either Intel or AMD CPUs, but has been crippled in it's use with a certain subset of those artificially.

        This is really a form of product tying [], which was made illegal by the Sherman Antitrust Act (1890), but only if a non-trivial amount of business is affected by the tying. This last requirement will likely be the reason the suit isn't successful, but that certainly dosn't mean that the behavior isn't borderline, at best.

        Again, this isn't a compatibility issue, as you said, "Why should Skype have to write software to work on AMD?" The real question is "Why should Skype be allowed to artificially exclude AMD users in exchange for money from AMD's competitor?"

  • by Anonymous Coward on Saturday March 04, 2006 @12:17PM (#14850050)
    Ah, Maxxuss. Is there anything you can't do? First you crack OS X, now Skype. You and DVD Jon should team up and become some sort of cracking superheros.
  • "Arbitrary"? (Score:5, Interesting)

    by v1 ( 525388 ) on Saturday March 04, 2006 @12:21PM (#14850065) Homepage Journal
    Since this limit was "arbitrary", that means the only deciding factor was not technology, but money. I wonder how much the block cost Intel?

    And now that it's in the open, (like that was going to take very long?) I wonder if they'll remove the block?
    • I wonder if they'll sue the cracker?
      • Re:"Arbitrary"? (Score:5, Interesting)

        by BVis ( 267028 ) on Saturday March 04, 2006 @12:57PM (#14850207)
        It'd be an interesting test case for the DMCA, wouldn't it? In this case it's not specifically copy or content protection software that's being circumvented, but a feature designed to maintain (potentially) a marketing agreement, if in fact that's what this turns out to be.
        • "In this case it's not specifically copy or content protection software that's being circumvented, but a feature designed to maintain (potentially) a marketing agreement, if in fact that's what this turns out to be."

          Exactly which is why the DMCA does not apply. The DMCA is very explicit in saying that it is only illegal to reverse engineer or crack encryption for the purpose of circumventing a copy protection scheme.
    • by djtack ( 545324 ) on Saturday March 04, 2006 @01:28PM (#14850333)
      In the first article []on this deal that slashdot linked, Intel admitted the limit was arbitrary, and the result of a marketing deal:
      But there are no specific instructions in Intel's current Pentium D or Core Duo chips that enhance the performance of VoIP applications, an Intel representative said. Skype is using an operation called "Get CPU ID" to identify the type of processor running on the PC. The Skype software has been preset to only accept Intel's chips as having the performance necessary to host conference calls of more than five people, the representative said.
      • The Skype software has been preset to only accept Intel's chips as having the performance necessary to host conference calls of more than five people, the representative said.

        If that was said by a representative from Intel then that statement quite qualifies as misrepresenting a competing product. Comparison is perfectly fine, misrepresentation is definitely not and Intel should be forced to compensate for it.
        • Not quite true. It said "...preset to only accept Intel's chip...", which is more or less meaningless market-speak. It says nothing of the actual performance of any of the chips. It doesn't say AMD chips don't have the performance, just that Skype won't utilize the performance on other chips.

          Intel does this crap all the time. They partner with companies and have them put "if (cpu == intel)" restrictions around some features so users will have an arbitrarily "better" experience on an Intel chip than on o
  • by Anonymous Coward someone demonstrating that the X2 can in fact handle 9+1 persons at once, which I have no doubt it can. Then it's time for Intel to open up the wallet and give AMD some nice $$$ and some even nicer PR. Stand by to bend over!

  • I know what you all are thinking. Great! He hacked it with three bytes, and showed his work. Now all AMD needs to do is get a 10-way conference call going on an X2 and they'll have another strike in their lawsuit against intel.

    But wait -- there is a way out. See the code is written to identify CPUs, and to run on dual core CPUs, but it doesn't make that distinction for AMD. So all the defense needs to do is set up an XP box running an AMD 1.4 GhZ "Firebird", next to some oily rags, get a 10-way conference
  • by augustz ( 18082 ) on Saturday March 04, 2006 @12:24PM (#14850077) Homepage
    Skype made a lot of noise in their press release saying that the 10-way feature was "optimized" for Intel chips. This was picked up by the media of course as well as evidence of AMD's poor performance.

    I'm having trouble understanding what this optimization that used the special features of Intel chips (presumably their high power) was. It looks from the patch that they just check who the manufacturer is, and if it is not AMD, they pretend your computer doesn't have the power to host 10 participants.

    What's also interesting is that folks likely signed up for SkypeOut and other paid products not realizing that they would be treated differently depending on what chipsets they happen to use, especially as that choice matters almost no where else. They should give more warning about this to paid users.

    This focus on locking software into specific vendor chips seems a dangerous one. No longer will it be the best chip that will win, but the focus goes to competing on locking up software applications. The proprietary unix'es went down that path, and it would be sad if Intel managed to get that to happen here.
    • by dubl-u ( 51156 ) * <> on Saturday March 04, 2006 @12:30PM (#14850108)
      I'm having trouble understanding what this optimization that used the special features of Intel chips (presumably their high power) was. It looks from the patch that they just check who the manufacturer is, and if it is not AMD, they pretend your computer doesn't have the power to host 10 participants.

      My guess, like yours, is that this is blatant marketing crap. But it would be nice to see some tests of how many people can be usefully conferenced on different hardware. Skype is a CPU pig, and it's possible that they really have optimized it for some Intel-specific feature.
      • by Anonymous Coward on Saturday March 04, 2006 @12:43PM (#14850156)

        To anyone doing such testing, make sure the code running is the same that would run on a dual-core Pentium. I didn't follow the patch in detail, but you'd have to make sure that any flags changed after CPU detection (like for instance the one at 0xB8E6DC) is the same for both cases. Else you might find yourself in the situation that, yes, the limit is removed, but you're still running a different ("unoptimized") path. In the (very interesting case) that the code crashes on AMD (due to use of Intel-only prefetch instructions or whatever, I don't even know if such still exists?), such crash can be used to land smack boom right in the relevant code to analyze.

        A good reverse-engineer could then fix the code if needed (substituting or even noping the faulting ops) -- the theory being that the major optimizations are in fact portable.

        In fact, demonstrating that there truly really is only one code-path would be pretty damning too; that's evidence this is just pure PR with no grounding in tech at all. So either case makes for an interesting evening in front of IDA.

        • by LLuthor ( 909583 ) <> on Saturday March 04, 2006 @12:55PM (#14850199)
          due to use of Intel-only prefetch instructions or whatever

          The AMD instruction set is a strict superset of the Intel instruction set. There are no Intel-only instructions anymore. There are however many AMD-only instructions (3dnow, 3dnow+, etc.), so if the situation were reversed, there might have been a legitimate claim, but since the AMD CPUs were locked out, it is clearly a bribe^Wmarketing descision.

          • "There are no Intel-only instructions anymore." Ah, but you see, the "CPUID" instruction works differently on intel than than it does on AMD. On AMD it actually reports that the user is using an AMD processor! Intel's chips therefore have a huge advantage--marketing.
          • AMD chips aren't as quick at Intel extensions, or at least so it seems. Audio processing plugins always seem to bench faster on Intel chips than on AMD chips. Usually, they are only optimised for SSE, not 3dnow. So while the AMD chips run them just fine, and aren't dragging along, they don't compare to the Intel chips. I'm poking around on Waves' site but I can't find the document I was looking for. It may only come with their plugins. At any rate it's got them benched on a number of chips, and the Intel ch
            • The SSE implementation on the AthlonXP wasn't particularly fast. IIRC, then just added some logic that decoded SSE ops into FPU ops and let the AthlonXPs nice FPU crunch it. This is part of why there wasn't really any speedup in SSE-optimized apps for the Athlon. Now the K8 may be a different beast in this regard. I haven't seen any recent benchmarks, however.
      • Yeah, the hacker should've done more code comparisons to see if CUPID checks are done in other parts of the programs. Having said that, a clever programmer working for Skype would've done the CPU check just once and store the result somewhere, so he could read it when he wants to do CPU-specific optimization. Considering this check was done only during the "Add Users to this Conference" segment of the program, it seems to confirm the suspicion that the only thing the CPUID is used for is to determine how ma

    • What I'd like to see is benchmarks, on Intel and Amd, with 10 clients attached. That way, we can see if the code is indeed optimized for Intel, or if it's just crap. I suspect it's crap.

      If anything, I'd suspect we'd see Intel being, what, 10% or 15% less load. Which would be something, but not something which justifies a 50% crippling of AMD hardware. And it'd be funny if AMD actually performed better.

      Yeah, someone should benchmark:
      Origional Executable, 5 clients, Intel
      Origional Executable, 5 clients, A
  • by Anonymous Coward on Saturday March 04, 2006 @12:27PM (#14850090)
    Yeah right.. I'm gonna' d/l this patch and app from (in Russia!!!), they even say on their aite that that "There is no virus or backdoor added!". You've got to be kidding me!
  • by tlk nnr ( 449342 ) on Saturday March 04, 2006 @12:29PM (#14850098) Homepage
    Will we see transcripts from depositions done by AMD?
    I'd bet that they will be as funny as some of the SCO transcripts.

    I'd bet that they will depose the programmer who wrote the code encryption and the GenuineIntel check, and then continue with his supervisors.

    Who authorized to add code encryption?
    Who approved it?
    How were the limits to 5 or 10 concurrent connections determined?
  • by dubl-u ( 51156 ) * <> on Saturday March 04, 2006 @12:32PM (#14850116)
    Anybody know anything about their encrypted binary? I can't figure out what they were trying to achieve with that. Some sort of misguided anti-hax0r protection? Or perhaps they're trying to conceal something...
    • No black helicopters here -- just greed. This is the same company that created Kazaa and bundled a bunch of spyware with it. So enterprising hackers modified it to remove the spyware, as well as the built-in advertising banners, and released Kazaa Lite.

      The Skype binary is encrypted to try to prevent a similar thing from happening (removal of ads, addition of features that are technically possible but they might want to limit for marketing reasons). Up until now Skype hasn't done any sufficiently annoying
    • I think it's more of an effort to thwart reverse-engineering and the creation of compatible third-party clients than anything else. Encrypting the binary is just one thing; they also try to pull some other tricks, such as refusing to run when SoftICE is installed on your system, and so on.
  • Limit (Score:5, Interesting)

    by Eightyford ( 893696 ) on Saturday March 04, 2006 @12:33PM (#14850119) Homepage
    So what is now limiting the conference calls to 10 people now? Is that a phone company limit, or another arbitrary limit?
    • by Svartalf ( 2997 ) on Saturday March 04, 2006 @01:05PM (#14850239) Homepage
      Unless Skype's playing reflector for the whole conference, each peer's connectivity limits what you can/can't do.

      At 128kbps (the average upstream speed on broadband these days in the US...), you can typically host a four to six way voice conference or a 2-3 way video conference. This is because you have to provide the outbound traffic for each of the peers and control traffic. With a reflector system, you can host larger conferences, limited only by the inbound bandwidth because the reflector is flipping the traffic from your mic (and possibly camera...) to all the participants. However, that's REALLY bandwidth intensive, so to keep it economical, you'd probably limit it to 10 participants or so to limit hogging of that limited resource.

      Now, this is all due to everything being unicast UDP. If we had IPv6 and Multicast support for the same available, one could handle at least up to the 10 without needing a reflector as the router infrastructure would handle it right along with the video on demand, etc. streams. However, since this is not likely to happen in our or several generations' lifetimes at the rates things are going, waiting or wishing for that is a waste of time. :-)
  • Maxxuss (Score:2, Redundant)

    by LiNKz ( 257629 ) *
    Maxxuss is definitely making a name for himself (if it really is only one person). He is already heavily involved with removing Apple's restrictions on Mac OS X for Intel too.
  • BitTorrent Mirror (Score:3, Informative)

    by Anonymous Coward on Saturday March 04, 2006 @12:54PM (#14850193)
    BitTorrent Mirror here []
  • by Mignon ( 34109 ) <> on Saturday March 04, 2006 @01:01PM (#14850219)
    The code seems to be calling the cpuid instruction, so as far as the "Windows-only" patch, could anyone comment on patching the Linux kernel to essentially lie to the Skype client?

    Or, so as not to break other programs that use cpuid (to determine which instructions they can run, for example) perhaps this could be done in a user-space way.

    I'm thinking of artsdp as a model, so you would just launch your Skype client with something like "cpufake --cpuid='Genuine Intel Dual Core We Like Skype' skype.bin" (or whatever it's called.)

    I've got no idea how such a program would work, but the article did say the code was encrypted so I wonder if that would be an issue.

    • Indeed... (Score:5, Insightful)

      by Svartalf ( 2997 ) on Saturday March 04, 2006 @01:21PM (#14850297) Homepage
      Considering that SIPPhone already HAS voice conference calls of at least 10 or more, works with ANY SIP enabled device that's not crippled to a single provider (Vonage devices come immediately to mind...), and costs nothing for VoIP calls- I'd say, skip Skype all together, especially after this little stunt.
      • Re:Indeed... (Score:5, Interesting)

        by bobcat7677 ( 561727 ) on Saturday March 04, 2006 @01:47PM (#14850415) Homepage
        Svartalf, you are indeed insightful today. Personally I use Asterisk meetme conferences for all my conferencing needs. Only limited to my server horsepower and available bandwidth. Can have almost an unlimited number of people call into it through SIP, IAX2 or an IAX2 trunked PTSN #.

        I tried skype a couple times (mostly because some girl talked me into it), but she wasn't worth it. The lack on interoperability totally killed it. The last thing I need is yet another app running on my main console all the time. Asterisk runs happilly on my server in the corner and rings my normal home phones all over the house if someone is trying to reach me. I might even pay for a skype IAX2 or SIP access account. But being a closed system they are too much trouble to deal with.
    • I don't see any reason why you couldn't apply the same sort of patch to the linux client. However, I don't think the linux client supports 10-way yet, even if you have an Intel Core-Duo. Once they come out with a 10-way capable client, one should be able to apply the exact same method as what Maxxus described. The only reason I made the Windows only comment was because the actual patch has only been applied to the windows only binary thus far. It will be repeated with any linux client that supports 10-way w
    • Not really. CPUID is an untrappable ring 3 instruction, so all callers get basically an honest answer. You'd have to single-step the entire program, or do a speculative emulation to identify the call points then breakpoint them, or something similar, to subvert it.
  • by fastdecade ( 179638 ) on Saturday March 04, 2006 @01:04PM (#14850231)
    Just goes to show why we need open protocols and open code for the future of VOIP. It's too important to leave to a single company, which is why I prefer SIP and clients like Google Talk and Gizmo [] where possible.
  • No shit (Score:5, Insightful)

    by grasshoppa ( 657393 ) <skennedy@AAAtpno ... inus threevowels> on Saturday March 04, 2006 @01:24PM (#14850316) Homepage
    It was a made-up limit? No kidding.

    Remember folks; Asterisk. Skype isn't open source, and the company behind it has it's own motives. Asterisk is open source, has a good community behind it, and can do *anything* you want it to. Regardless of the hardware behind it.
  • Optimizing for AMD (Score:3, Interesting)

    by JFMulder ( 59706 ) on Saturday March 04, 2006 @01:29PM (#14850335)
    Being in a company who worked exclusively on Intel and nVidia chips until recently, it is possible to have horrible performance when switching to AMD and ATI. In our case, we didn't use any nVidia specific GL calls. As for SS2, it is supported on both platform so in theory it shouldn't be an issue. The reality is, unless you are making a game and using what I'd call "game-oriented opengl calls", the performance is going to vary a LOT between ATI and nVidia. Don't believe the hype of these companies when they say that they support full OpenGL. Some either have very bad hardware for 2d ops with OpenGL or literally do software "decelleration". Benchmarks have shown speed dropping as much as 200% in some areas. As for AMD and Intel, after patching the executable, the performance was different, sometimes in favor of Intel, sometimes on AMD.

    With that being said, no platform specific instructions or features were used. I suspect the Skype guys may have simply used Intel machines for so long and never bothered using AMD machines for development and then were too lazy to simply rewrite some of the code so that it runs normally on AMD. This happens especially when you write tight assembly loops by taking into account instruction latencies for one processor and then realize the performance sucks on another platform. You then have the choice, rewrite it so that the performance is similar, or slap a OPTIMIZED FOR INTEL on the box.

    Thankfully we rewrote.
    • Not "optimized"... (Score:4, Insightful)

      by Svartalf ( 2997 ) on Saturday March 04, 2006 @02:51PM (#14850593) Homepage
      Sound software typically is optimized quite well for both company's offerings, esp. if you don't use special features of the other brand. To be sure, there's edge cases where you need that- but Skype's NOT one of them nor is there evidence that there's the degredation you claim happened with your app experience. (Not to mention that there's tons of other P2P VoIP applications that use SIP and Jabber technology that work as good or better than Skype, and there's other commercial proprietary systems (such as Eyeball Networks' stuff...) that DOES handle up to 10 people (or more as bandwidth will allow...) without needing a dual core anything, let alone an Intel one.)

      This is plain and simple being bought to support one over the other. Please don't try to defend this- it's not something that has much of any good explanation for this, especially considering that they actually DO appear to be just CPUIDing and crippling the app if it's not a dual core Intel CPU...
  • 10, or more? (Score:3, Interesting)

    by sam0737 ( 648914 ) <sam AT chowchi DOT com> on Saturday March 04, 2006 @01:40PM (#14850379)

    Of interest here is also the code marked with (*). It reveals that the string is somehow used if a certain memory location has the value 4. Theory is, this 4 means "4 additional conference members";

    Is that possible that by modifying some variables...we can have unlimited number of user in the conference?

    • Re:10, or more? (Score:2, Insightful)

      by kryptx ( 894550 )
      More precisely, I think it means that by modifying the source code, your limits can be imposed by your hardware instead of your software.
  • Intel compiler? (Score:3, Interesting)

    by kryptx ( 894550 ) on Saturday March 04, 2006 @01:43PM (#14850390)
    This sounds an awful lot like the type of code built by Intel's compilers, for which they're being sued by AMD. Is it possible Skype is using that very compiler, and just couldn't figure out how to make it work on AMD machines (presumably pre-lawsuit)?
  • This is a case of DMCA IP Protection being abused for trade protection rights Intel bought and paid for and AMD did not.

    Sherman Anti-trust aside (which this may be a real material breach) it looks like DMCA could either get abridged or affirmed for trade control purposes. For instance, does this mean someone with an Oracle license has the right to use some delta patches to open it wider open on their AMD Opteron for better threading than Intel?

    Hmmm... you see how the lines get to be less than black and whi
  • Two phases, huh? (Score:3, Insightful)

    by Just Some Guy ( 3352 ) <> on Saturday March 04, 2006 @01:47PM (#14850414) Homepage Journal
    The patch is the result of two phases: code analysis and design of the patch.

    In other words, he found the problem then fixed it. Forgive my ignorance, but how else would you possibly go about it? Apply random patches until one kind of works?

  • by flynt ( 248848 ) on Saturday March 04, 2006 @01:49PM (#14850425)
    Spoiled kids. When I was young, an occasional 3-way was enough.
  • Some text to phyche out the spam filter.
  • by XMilkProject ( 935232 ) on Saturday March 04, 2006 @03:12PM (#14850686) Homepage
    Skype didn't break any laws, and no one (except /.ers) said they did. It's their software and if they want to intentionally limit their customer based they are more than welcome to do so.

    The reason this issue is important is that it seems likely Intel went to Skype, and in some way coerced/bribed them to do this. This could be extremely strong evidence in helping AMD with their current lawsuit against Intel. Hence AMD issuing a subpoena to Skype, to retrieve information that will show whether or not Intel is to blame for this limitation.

    It's silly to hear people saying AMD should sue Skype. AMD doesn't care about skype, nor are they trying to run a huge campaign of lawsuits. They are only interested in forcing Intel to stop their current tactics which have arguably kept AMD from massive success in the OEM market.

Thus spake the master programmer: "When a program is being tested, it is too late to make design changes." -- Geoffrey James, "The Tao of Programming"