March 4th, 2006
Maxxuss: "I've hacked the Skype-AMD 5-person call limit"
Note: This post contains code that the code-author re-posted as an update on Sunday, March 5.
You’re looking at a screen grab of a 10-participant Skype conference call- on an AMD X2-powered CPU.
"Now wait a minute," you might be saying. "I thought Skype conference calls on non-Intel boxes had a five-participant limit."
Well, yes, they do- and as I posted here the other day, AMD’s attorneys are not too pleased about this. They sense that this restriction might be deliberate - possibly a living artifact of a partner alliance between Skype and Intel that limits Skype 2.0’s conference call capacity on non-Intel boxes.
I suppose that is to be decided, but a blogger-hacker named Maxxuss has written code that he says will defeat this restriction.
Maxxuss has posted a hack for this five-participant ceiling. And he has made it publicly available, code and all.
I, of course, cannot personally vouch for the code, nor warn against it. But this is big news, and that’s a lot of why we are here. And you, too.
So let us see what Maxxuss has come up with.
"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," Maxxuss writes. "The patch design isolates the minimal set of instructions that need to be modified to cancel this limitation."
As to the Code Analysis (i.e. Reverse Engineering) at work here, Maxxuss writes that an initial analysis of the executable revealed that the code references the string "You can now add up to 9 people to this call - <a href="skype:?go#intel-10way">learn more</a>"".
Maxxuss then provides the relevant call block code:
He then takes several more steps to explain how he gets to the core logic.
Next, he walks readers through some steps that lead to how to "suppress" the code that he believes limits Skype conference calls on AMD-powered PCs to a limit of five participants:
The routine with the patching code is located at 0×7251C0, which is unused otherwise. It is a bit more complex as expected, due to the fact that we cannot simply write into the code segment - this would result in a memory protection exception, since Windows and Skype itself sets the access rights to "executable and readable" (i.e. not writable). However, temporarily circumventing the memory protection is easy. We just use Windows’ VirtualProtect kernel function. So, in summary, the patch code does:
- Make the code at 0×7FF7D0 - 0×7FF7E0 writeable and save original access rights,
- Patch three bytes,
- Restore original access rights,
- Do what the original code at 0xB7CC40 did, which we have replaced.
For clarity, I will now post a rendering of Maxxuss’ assembler code in two screen grabs. Update: Maxxuss re-posted this code on Sunday, March 5:
And now the second part (which includes the last section of the updated first grab, for continuity purposes);
Has this code changed your mind or reaffirmed your suspicions about the Skype-Intel-AMD controversy?
Russell Shaw is an enterprise computing journalist, analyst and author based in Portland, Oregon. See his full profile and disclosure of his industry affiliations.
