This is why you always publish code separately from blog posts and the like, when you're talking about reversing. As long as all you're doing is talking about it (and showing things like protocol structures, dumps, etc), there's nothing they can do. Back in ~2005, I took to writing blog posts that gave you everything you'd need to know to, say, implement Apple's Fairplay DRM. Because there was no code, they couldn't take it down, and it was able to propagate trivially -- in effect, a specification in narrative form.
That didn't stop Apple from going after bluwiki a couple of years ago for something as simple as reverse engineering the iPhone file transfer protocol. "There's nothing they can do" is never really true when you're talking about huge corporations with lawyers.
I'm not sure of the details of the bluwiki fiasco, but I can certainly say that this worked for me through my battles with Apple -- we had our share of issues, but never once did one of my blog posts (detailing everything that you'd need to know to reimplement any of the code) get a DMCA takedown notice or the like.
While I have no problem with anonymous publishing, I much prefer to operate in clear sight under my own name. Not only for the obvious benefits to me (e.g. my work with iTunes jumpstarted my career), but because I strongly feel that what I do is completely in the right, and publishing it anonymously simply gives the wrong impression.
Yes. Copyright covers exactly what's in their binaries, not anything you learn from their binaries.
I would argue that the opcodes in the binary are covered by copyright, but if you reverse-engineer those into C, that's your own creative work. Apparently Skype's lawyers did not see it this way, but why would they? If you're going to lie, you have to first convince yourself.
Copyright doesn't just cover "exactly what's in their binaries", because of the derivative works statutes. If you translate a book from English to French, the resulting book is still under the copyright of the original author; the same goes for taking disassembly -> decompiled C.
Something becomes a derivative work when excessive amounts of the source material structure comes from a copyrighted work. If you reverse engenear a program create a spec and have someone else code to that spec then copyright does not cover you.
You could create an original novel that was not a derivative work by taking once sentience from every book in a library and trying to create a meaningful work of art from it. Doing the same thing using a single book would probably not fly.
Yep, that's why the concept of clean-room reversing exists, to get around the derivative work concepts. It's not the only option, but it's probably the safest.
That's an interesting question. I'd be inclined to say no, but without precedent in court on this, it's tough to say. The reason I'd say no is that while pseudocode serves the same function as a "narrative spec" in this case, it's inherently not a new creative work -- it'd be easy to allege that it's a derivative work. I don't think you'll have an easy time convincing any judge that just because your 'code' doesn't compile or run, it's not still code and treated the same as, say, some C or Python.
Skype is claiming copyright on the source files that this guy created while reverse engineering the protocol? It's times like this when I really wish that everyone involved in that decision could be held personally responsible for the blatant lie that that is.
Even if it was against the law for him to reverse engineer the protocol, they don't own copyright to the source files he created.
I thought the researched decompiled the Skype client, posted the resulting source, reversed engineered the protocol, and wrote open source implementation. The decompiled source is definitely a derivative work and possibly copyrighted by Skype. It is hard to tell if the DMCA takedown is for that decompiled source.
The other problem is that by looking at the decompiled source, his source is tainted. He will have a hard time showing that it isn't a derivative work. Especially if he wasn't really careful writing the source from scratch and not cleaning up the decompiled source.
If you want to do this right, you do it the way Compaq did with the IBM PC BIOS. One group of engineers analyzes the code, and writes a english text specification. A 2nd group (100% disjoint) took that spec and then wrote a compatible BIOS.
This survived a legal challenge, but that was in the IP environment of the early '80s, so who knows what would fly now.
You don’t understand why companies care or you understand, but simply don’t agree?
A long time ago, I recall having a conversation with the CTO of a company that made BBS software. We wanted to integrate with his servers, so we wanted the proprietary protocol. We advised him to build an API so that his software would become an ecosystem and thrive.
He smiled and metaphorically patted us on the head like a parent explaining the world to children.
“If we publish the API for people to write new clients, people can also write new servers that talk to the clients we write, and we’d be out of business.”
Skype’s motivation is obvious: If the protocol is public, while some people will write software that enhances the Skype ecosystem, others will compete with Skype, and that isn’t what they want.
Their system operates under an assumption that all its parts are genuine, and so it places implicit trust into every client and expects it to operate fairly for the system's overall benefit. You open this thing up and there will be 3rd party nodes that do not comply with system's semantics -- supernodes become few and far between (why the hell would anyone be willingly relaying the traffic while on any sort of metered connection?), someone would add an encryption overlay disabling any "lawful interception" provisions they have in place (which they most certainly have or they would've been simply blocked all over the world), someone else would find a weakness in their p2p encryption and start eavesdropping on relayed calls, etc. Does Skype needs this sort of headache? No. Hence the highly obfuscated and encrypted binary with numerous anti-debugging and anti-reversing traps, and their very active suppression of reverse engineering attempts. Skype would basically stop working if it is ever open.
I suspect that skype's motivation is more that it charges for calls out to a landline and for calls in.
It uses these profits to pay for the free skype-skype service.
If I could access the skype protocol I could route all my phone calls over skype->landline and not pay them.
Unless of course they actually implemented the security system properly and have a secure method for identifying each end of the call - but they wouldn't have needed to do that because it's all secret.
I originally thought this would be illegal because of the Skype EULA. In Blizzard vs Bnetd the eight circuit ruled that, while reverse engineering for interoperability is permitted in some cases, you waive these rights when you agree to an EULA that says you can't.
4.2 Restrictions. You may not and you agree not to.
(a) sub-license, sell, assign, rent, lease, export, import, distribute or transfer or otherwise grant rights to any third party in the Software;
(b) undertake, cause, permit or authorize the modification, creation of derivative works or improvements, translation, reverse engineering, decompiling, disassembling, decryption, emulation, hacking, discovery or attempted discovery of the source code or protocols of the Software or any part or features thereof (EXCEPT TO THE EXTENT PERMITTED BY LAW); (emphasis mine)
Why do people still use Skype? Just use XMPP. Try to improve that instead of wasting effort on reverse engineering the horrible piece of poo that Skype is.
