Skype55 deobfuscated version released | Hacker News Reader

Skype55 deobfuscated version released

skype-open-source.blogspot.com

133 pointsmariuz66 comments

I don't understand this project. According to the creator, the purpose is "to make Skype open source" [1], but the project relies on binary files distributed by Skype. As a result, they have repeatedly faced DMCA notices [2] which regularly causes the source code is become unavailable.

An earlier blog post made it to Hacker News. I found the comment at http://news.ycombinator.com/item?id=2611728 insightful.

[1]: http://skype-open-source.blogspot.com/2011/06/skype-protocol...

[2]: https://github.com/skypeopensource/skypeopensource/issues/1

For a clean room reverse engineering they could analyse the Skype binaries to document the protocol.

Clean room requires that those creating the implementation don't have access to the original implementation. Having the same person(s) inspect the binaries and create an implementation fails this requirement.

See: http://en.wikipedia.org/wiki/Clean_room_design

But how can you test if you protocol/document correct? Yes, Epycs code may have question about legit and some other stuff. But after it going to a beta or stable stage. We can use Epycs protocol documentation to write, for example, epycs.java and make it fully "clean room".

You get someone who is not involved with the reverse engineering to test it.

Look up the term "Chinese Wall".

What's required (for purposes of courtroom defense) is a clearly documented procedure in which those who have access to the source being reimplemented (the spec writers and testers) NOT be the coders, and vice versa.

Another example is the SMB/CIFS reimplementation in the case of Samba. Here, because the protocol was an over-the-wire system, analyzing network packets (not covered by source analysis proscriptions) was sufficient to create a Free Software implementation.

Yeah, we will do it. But now project still at first stage.

Can't be the protocol itself patented?

that would involve describing it

Describing just one part of it could be sufficient to sue, but not sufficient to develop a client.

Software patents are intentionally vague, so I doubt anybody could write a working client based on a patent alone (even if whole protocol was claimed to be described).

You are probably correct, but this is an abuse of the patent system, since the quid pro quo for patent protection is the disclosure of the invention to advance the state of the art.

Yeah... I don't really understand what their issue is to be honest. It really is up to Skype if they want to release their protocol. You can't really force anyone into being open source. I actually disagree with their methods, its the same as a closed source company violating the GPL when they steal source code like this.

It really is up to Skype if they want to release their protocol.

This isn't true. Nothing stops you from analyzing and implementing their protocol. This project, however, is only the first part.

Reverse engineering has given us so many good things - Samba, OpenOffice, Wine, MAME (and other emulators) the bitkeeper debacle, which gave us git. Then there are all the Linux and UNIX drivers that were written by reverse engineering windows drivers because vendors weren't supporting those operating systems.

The guys who reverse engineered Exchange Server were acquired by Cisco.

I don't understand why the Skype case is 'evil'. distributing the binaries may violate terms of service, but it isn't illegal in large parts of the world.

It did also give us the PC running Windows - so there is a dark side ;-)

Unless your home PC is an IBM PC-AT it's the result of reverse engineering.

Remember, open source doesn't mean free. It just means you can view the source.

That's not the usual use of the term in tech. Even Microsoft, after some initial confusion, has settled on using "shared source" rather than "open source" to describe situations where they share the source but not under an open-source-definition-compatible license.

The Open Source Definition provides a very clear explanation of when the term open source should be used: http://www.opensource.org/osd.html

In one sense, I feel "The Open Source Movement" have co-opted a plain english two word phrase.

Their introduction there can be rewritten as "Open source doesn't just mean the source is open. We claim there are also implications about the means of distribution."

It's as though someone was telling people "free beer" doesn't just mean beer that's free, it also needs to be in glass not cans - free beer in cans needs to be called something else…

I think there's a lot of "open source" software out there that is not "open source(tm)". I'm not sure "the open source movement" are doing themselves any favors by aggressively defending their particular definition of a descriptive phrase that is widely known and easy to assume you understand.

(But I also understand the need for specific technical meanings in the software field, and that phrases like "open source" end up being part of the field's jargon, and have far more specific technical meanings than the "plain english" deconstruction of the words indicate. I just think the "open source" case has backed itself into a corner where people assume a plain english interpretation of the phrase, then have the "open source movement" people need to jump on them and say "no, you're wrong". As displayed upthread.)

I don't believe that the term "open source" was in common use at all prior to the phrase being deliberately coined in a strategy discussion in 1998 http://www.opensource.org/history

For describing software this is likely so, but the phrase has also been a part of the technical jargon of the intelligence community for a lot longer.

I think it's rather natural to think that something called "open" can be used, not merely looked at. I think it's also natural to emulate what is observed. If I can't use what I learn by observing something, what's the point?

I understand the opposing view, which claims it's natural to mean "look but don't touch" by "open". I'll grant that it can be a plain english interpretation. But it's an interpretation that violates the instinct of the observer.

For spamming this is a gold mine.

Mind elaborating?

I cannot speak for dr_rezzy, but I wouldn't be surprised if the Skype network experienced more spam following a reimplementation of the Skype protocol. Having control over the behaviour of every client allows Skype the company to more tightly control the behaviour of the network, including automated/bulk messaging. A client that can be freely modified/scripted makes it harder to restrict/filter automated behaviour e.g. spam.

I don't believe that this is (despite stated intent) making Skype "open source". It would be more accurate to say that this work makes it possible to create an open-source wrapper around a proprietary kernel. This wrapper could then be updated as times change to support different platforms, as long as the linkage to the kernel was compatible. This neatly steps around some legal problems because:

1) The wrapper itself is not encumbered (unless some patent issues applied)

2) Users with a legal copy of Skype on one platform can apply the wrapper themselves (though they cannot redistribute the result)

You can even imagine distributing (via, say, github) a kit consisting of the wrapper and a tool that applies that wrapper to a user-supplied Skype binary. All legal as far as I know (IANAL etc.)

This already happens and is dismissed on the linked blog comments.

But i have no idea what it IS then

Why? With that much work and grey legal areas, it's much easier to embrace WebRTC and just try to evangelize it or applications that use it. I think Skype will be a thing of the past soon enough. WebRTC is already quite impressive for a few lines of JavaScript (and optionally C++ if you want to do server side muxing and reduce the number of connections needed in a multiparty "call").

In a couple days I wrote a pretty simple, but functional multiparty video chat web-app. I'm just waiting for Chrome to support multiple PeerConnection objects.

I guess I don't understand the obsession with trying to interop with Skype.

> I guess I don't understand the obsession with trying to interop with Skype.

Massive existing user base?

>> I guess I don't understand the obsession with trying to >> interop with Skype.

> Massive existing user base?

Web browsers have even more massive user base though, and (insha'Allah) will include WebRTC as standard before too long.

People don't use Web browsers for video chat. They use Skype. Getting people to change will be hard, especially since the browser offers no real benefits over Skype.

I'm not saying we shouldn't try to get people to change, only that it will be hard and Skype interoperability is a very legitimate thing to want to achieve.

I can't really see how Skype can stay in the game after browsers support VOIP. At the moment if one party doesn't have Skype, it generally means either they end up installing it or (more likely) you abandon VOIP. At the point when you can say "no problem, just go to this URL...", Skype starts to seem pretty redundant. Of course that won't happen immediately, and always the possibility the plan might get derailed somehow, so I'd agree that Skype interop would be good.

They have nat-free servers and their own automatic nat-traversal methods. Even if every single browser supports VOIP, you won't be able to use it between 2 random people using standard home connection. Until we get out of the lack of IPv4 addresses situation there can be no true peer to peer network.

Sure, I wasn't particularly thinking it would be peer to peer. It can easily be through somebody other than Skype though.

The PeerConnection API has methods of doing NAT traversal. STUN, etc. It's already covered.

Its not enough. Need something like skype supernode functionality.

I don't understand why. I'm not a networking expert but I have some experience with networking... I mean, I've already tried a proof-of-concept out with a computer behind a NAT router and it worked fine.

Think about 2 devices (A,B) behind routers in different networks. Connections from A end up on B's router since there's no existing connection to match and connections from B end up on A's router. Unless you explicitly configure port forwarding B will never know that A is calling him.

Is that not precisely what STUN/TURN is for?

Yeah - that will do, but the TURN operator is a third party. I commented about the situation assuming Joeboy meant P2P connection without Skype or anyone else Skype-like (the URL is the only thing needed). If you're ok with someone else providing TURN and making money on it in some way to pay for the bandwidth, then yeah - that's enough.

I'll be honest, I'm currently abusing the STUN servers that Google uses in their own WebRTC examples and will need to evaluate my own options. I was under the impression that STUN could be used to establish a connection that from then forward was able to be only peer to peer after the connection through the NAT had been established.

Yeah, skype supernode concept very sexy.

Why would it be peer to peer?

That's actually an issue with skype on mobile (which I think is fixed now since they use centralized servers for mobile connections).

I assumed P2P, since Joeboy mentioned "no problem, just go to this URL...". If you're not doing this in a P2P way, then you need an account with third party and the third party sometimes needs to transfer both your signalling and your audio. That means they need to get money for that from somewhere...

In that case you're pretty much in the same position as with Skype - just without a download. Account, configuration, potential payments, etc. remain.

Edit: Actually now I see a solution - if only one person had an account, this would still be possible and he could start a call by sending some URL. So for the other person this is "just go to this URL". Unfortunately we still need a third party to handle the traffic unless you require the account holder to ensure their network is capable of acting as a server.

WebRTC includes the various standard methods for NAT hole punching (STUN and the like)

> People don't use Web browsers for video chat.

That was before Google Voice+Video+Hangouts. A significant number of people I contact with has already switched to Google because it is much easier to use.

The browser offers no benefit? No installation, I can tweet, facebook, text, email a single link that opens an instant video chat with me, that's not a benefit? No user account registration, etc?

There's literally no effort needed to start using it. In fact, with oAuth you can even tie into existing user bases. Chat with all of your Facebook/Twitter friends by authing those accounts and the backend telling you which friends already have it. You get built in userbases for free almost.

That 'almost' is a lot bigger than you're making it out to be.

With a hypothetical "WebRTC video chat" service, in order to chat with "any of my facebook friends", I need to:

- Give all my data on my Facebook friends to the service in question. (Let's assume for the moment that it's a benevolent hypothetical chat service and I don't have to give up a lot) - Invite one of my friends. - Hope that my friend accepts the service accessing their information in the same way (A very big hurdle if it's a service they've never heard of)

Or I could just use Skype, that they're already on.

... It's still a wash in my opinion. There's no account required at all for a WebRTC application. I can send you a link on any service and you're a click away from video chatting with me. The Social Auth integration was just an example of how easy it would be to build off of existing user bases.

Grandparents probably don't note this difference. Skype is decidedly most popular by faraway folks keeping touch, particularly those that aren't terribly computer-savvy.

Grandparents have to be the most likely to understand or benefit from this difference.

Grandma, open the email I sent you and click the link [or] Grandma, Go to "tinyurl.com/5yp7q".

versus,

Grandma, download Skype, find it, run it, walk through the Installer, make an account, login, add my username, then call me. (and even then, this is glossing over a gross number of details that are hard for the unsavvy).

Even if it's already set up, there's no barrier to use of a simple WebRTC-based service assuming it's done correctly.

No; Grandma already has Skype installed & linked to your usernames, because you (or some other relative) did that for her. Probably at the same time you bought her a laptop.

So it's just ring ring "hello?"

Vs. sending an email to tell her to click this link so that you can call her....

If she knows to wake the computer up (or start it up) during your evening hours, that's enough -- Skype starts when the computer starts, unlike a browser.

Skype is easier than email, generally (and Grandma may not bother with email...). You don't even need typing skills. Just click the "answer" button when it rings, or if you want to call me, click my name then click "call".

And even further...I bet many in this situation do some sort of Skype lesson during holiday visits.

Granted, I agree with the grandparent here: ultimately, browser-based software would be easier, but you have an entrenched user base who aren't likely to quickly change to new tech.

That's how I set it up for my wife's parents, since 2006 - a not very cheap laptop back then, still works fine (had to be Windows XP). Works good 6 years later.

Then my father, became computer geek late in his years, and I can't even stop his mouth when comes to applications :) - He's bigger kid than me in that respect...

Everyone already has Skype. That hurdle was overcome a long, long time ago. Skype is an application that is just as ubiquitous as the web browser these days.

There are lots of things that I could do in a web browser, but still don't, yet.

Old habits die hard; that's part of the problem. But also, we're still not there yet, AFAIK, turning browser apps into applications. Sure, I can tweet a link to everyone to video chat with me. But how well will that work if my browser isn't running when they call?

Skype is an always-on native application that doesn't steal a slot in the dock/taskbar when it's not in active use, and also just claims its reasonable slice of memory and doesn't generally go up from there. I keep it running, and people call me or IM occasionally.

My browsers... I generally have Chrome & Firefox and sometimes Opera up at varying times during the day (different browsers because I don't like mixing business with personal cookies, and because Facebook gets its own browser entirely), and they're all closed down sometimes. They suck up lots of memory (my tabs tend to accumulate rapidly until it gets out of hand and I do a cull), and it's pretty frequent that some site's JavaScript gets a bit wild and steals too much processor/bandwidth as well, so I shut them down whenever I can.

So how do I use some browser tab to be always available for calls and IM? If the right browser & tab are open, how will it even notify me when someone's IM'ing me? How annoying will it be to find the right tab, to respond?

The GMail interface is superior to Thunderbird for email, but I still pull two GMail accounts into Thunderbird (along with others hosted elsewhere) because it shows the little envelope in the tray when I have new mail, and I can mouse-over that to see what it is.

Well, and I can still search my entire message history (for 6 diversely-hosted accounts), write emails, etc., while offline, and don't have to provide Google access to my mail server. Etc..

Maybe there are good solutions to all of these problems? But I can't go changing all of my habits every time someone tells me "there's a new way!" -- I have work to do. Generally when I try, I get burned and have to change back.

Addendum -- I'm a technical user. I'm not completely ignorant of the possibilities. So take my reluctance to change, and multiply that by some large factor for everyone who finally got the hang of using Skype to keep in touch with their family overseas....

[immediate edit: I do know that some of these problems are solved; but I need all of them, or something so much better to my general workflow that it's worth the effort to switch and lose whatever I'm losing.]

I hadn't considered the limitations of "you have to have the browser open" as my browser is never closed.

You're right in that some of the problems are solved (I get native notifications of new email in Gmail via Web Notifications and a Chrome plugin that turns them in inotify (or whatever) notifications, and the indicator on my app'd tab in Chrome changes from zero -> one).

I do appreciate the feedback, these were conditions I hadn't even considered and need to account for.

No way. Skype is hands down the highest quality online voice chat system. I play online games with friends and we always use Skype for voice chat.

I don't know what sort of audio processing magic Skype is performing but whatever it is it's incredibly good. My group tried lots of alternatives (Ventrilo, Mumble, TeamSpeak, Steam, etc) and Skype is easily the best. All the others have issues with poor quality, speaker feedback, and/or keyboard sounds. Skype has none of that. Crystal clear voice chat even when the mic is directly beside a clickety clackety keyboard.

It'll take a hell of a lot more then a simple web client to dethrone Skype.

It's not as if Mozilla and Google chose rinkydink codecs for WebRTC...

I'm sure they didn't, but Skype is just that good. Every single VOIP system my group used had issues. The microphone picking up audio from speakers and keyboard typing being two of the most problematic. Skype was the only one where that wasn't an issue. Their system just automagically filters out the cruft.

Meanwhile the voice chat built into gmail was one of the absolute worst and was completely unusable. It's a much more complicated problem than people realize.

It's not simply about compression, Skype has a decade-long head start on tweaked echo/feedback suppression, gain control, dejitter, adaptive quality adjustment and so on. The call quality is marvelous, even with Macbook mic and lossy hotel wifi (I spend at least an hour every day using it right now).

I'm sure the browser vendors will catch up, but haven't even seen mention of some of these features yet with regard to WebRTC.

No offense, and this isn't likely to be popular given the downvote above... but look harder. These are things that at they very least ARE being considered already for WebRTC.

I promise I'm not trying to be abrasive. I'll update with some links when I get a chance to get to a proper computer.

My experience is that Mumble blows Skype out of the water for background noise suppression. I can't have a call in a windy area without riding the mute button on Skype, but Mumble lets me adjust the signal/noise threshold to the point where it only picks up my voice.

The fact that it doesn't crash every other day is a nice bonus too.

Skype's codec (SILK) is superior to the ones listed for WebRTC.

Mumble's current codec (old version of CELT) is competitive and possibly better.

SILK was open sourced a while ago, and was combined with CELT to make the Opus voice codec, which is best-of-class and is even competitive with codecs like AAC for music compression. I suppose any client who wants to could adopt it, but none have yet.

Thanks for this info. In a another side project I'm working on video transcoding and (at this point) WebM. I'm still learning and it appears I need to familiarize myself with the lower level details of both video codecs and codecs for this sort of live calling, I'll have to check out Mumble/SILK. thanks.

Silly how it must vary between places, for me skype has always been terrible for conferences, with delay of a couple seconds, constant disconnections, using ridiculous amounts of bandwidth, attempting to modify volume of other programs (!?) etc., while Ventrilo/TeamSpeak never had any issues.

Reply on news.ycombinator.com