Blackbox Exploration

All posts tagged Blackbox Exploration

webrtcH4cKS: ~ The WhatsApp RTCP exploit – what might have happened?

Posted by Philipp Hancke on May 17, 2019
Posted in: Reverse-Engineering, Technology.
Tagged: , , , , .
2 comments

As you may have heard, Whatsapp discovered a security issue in their client which was actively exploited in the wild. The exploit did not require the target to pick up the call which is really scary.
Since there are not many facts to go on, lets do some tea reading…

The security advisory issued by Facebook says

A buffer overflow vulnerability in WhatsApp VOIP stack allowed remote code execution via specially crafted series of SRTCP packets sent to a target phone number.

This is not much detail, investigations are probably still ongoing. I would very much like to hear a post-mortem how WhatsApp detected the abuse. ...

Continue Reading

webrtcH4cKS: ~ How Zoom’s web client avoids using WebRTC

Posted by Philipp Hancke on October 23, 2018
Posted in: Reverse-Engineering.
Tagged: , , , , .
2 comments

Rube Goldberg’s Professor Butts and the Self-Operating Napkin (1931)

Zoom has a web client that allows a participant to join meetings without downloading their app. Chris Koehncke was excited to see how this worked (watch him at the upcoming KrankyGeek event!) so we gave it a try. It worked, removing the download barrier. The quality was acceptable and we had a good chat for half an hour.

Opening chrome://webrtc-internals showed only getUserMedia being used for accessing camera and microphone but no  RTCPeerConnection like a WebRTC call should have. This got me very interested – how are they making calls without WebRTC? ...

Continue Reading

webrtcH4cKS: ~ Messenger was not forced to wiretap but…

Posted by Philipp Hancke on October 1, 2018
Posted in: Reverse-Engineering.
Tagged: , , .
Leave a Comment
This Phone Is Tapped.jpg


By david drexler – Flickr, CC BY 2.0, Link

Back in August, Reuters reported on a “secret legal fight” between the FBI and Facebook about wiretapping Messenger calls. The Verge as they found our old post about reverse-engineering Messenger from 2015 and had a number of follow-up questions on it for a Messenger wiretapping article they ran. Technical details on the case are quite hard to find so I was not able to dig deeper into the specifics around wiretapping.

Reuters now reports that Facebook will not be forced to wiretap Messenger calls with the FBI noting: ...

Continue Reading

webrtcH4cKS: ~ Suspending Simulcast Streams for Savvy Streamlining (Brian Baldino)

Posted by Brian Baldino on August 6, 2018
Posted in: Technology.
Tagged: , , , , , , .
1 comment

If you’re new to WebRTC, Jitsi was the first open source Selective Forwarding Unit (SFU) and continues to be one of the most popular WebRTC platforms. They were in the news last week because their parent group inside Atlassian was sold off to Slack but the team clarified this does not have any impact on the Jitsi team. Helping to show they are still chugging along, they released a new feature they wanted to talk about – off-stage layer suspension. This is a technique for minimizing bandwidth and CPU consumption when using simulcast. Simulcast is a common technique used in multi-party video scenarios. See Oscar Divorra’s post on this topic and that Fippo post just last week for more on that. Even if you are not implementing a  simulcast, this is a good post for understanding how to control bandwidth and to see some follow-along reverse-engineering on how Google does things in its Hangouts upgrade called Meet. ...

Continue Reading

webrtcH4cKS: ~ YouTube Does WebRTC – Here’s How

Posted by Philipp Hancke on March 24, 2018
Posted in: Reverse-Engineering.
Tagged: , , .
6 comments

I logged into YouTube on Tuesday and noticed this new camera icon in the upper right corner, with a “Go Live (New)” option, so I clicked on it to try. It turns out you can now live stream directly from the browser. This smelled a lot like WebRTC, so I loaded up chrome://webrtc-internals to see and sure enough, it was WebRTC. We are always curious here to see how large scale deployments are implemented, so I immediately asked WebRTC reverse engineering master Philipp “Fippo” Hancke to investigate deeper. The rest here is his analysis. ...

Continue Reading

webrtcH4cKS: ~ All I want for Christmas is Hangouts to use WebRTC on Firefox

Posted by Philipp Hancke on December 21, 2017
Posted in: Reverse-Engineering.
Tagged: , , , .
3 comments

Tsahi discovered Hangouts on Firefox started working again and quickly called Fippo to investigate

As the year 2017 comes to an end, there was a small present. Hangouts started to support Firefox with WebRTC instead of rejecting access – plugin access had been unavailable since Firefox 53 removed NPAPI in April 2017. While it had been public for a while that the Firefox WebRTC team had been testing this, it was a nice Christmas present to see this shipped. Tsahi Levent-Levi was one of the first people to notice.
This comes at a time where other Google teams are being criticized for promoting Chrome-only experiences. Kudos to the Hangouts team for showing that you still care about the web as an open platform! ...

Continue Reading

webrtcH4cKS: ~ Slack Does WebRTC Video – Here’s How (Gustavo Garcia)

Posted by Gustavo Garcia on December 15, 2016
Posted in: Technology.
Tagged: , , , , .
6 comments

Slack is an über popular and fast growing communications tool that has a ton of integrations with various WebRTC services. Slack acquired a WebRTC company a year ago and launched its own audio conferencing service earlier this year which we analyzed here and here. Earlier this week they launched video. Does this work the same? Are there any tricks we can learn from their implementation? Long time WebRTC expert and webrtcHacks guest author Gustavo Garica takes a deeper dive into Slack’s new video conferencing feature below to see what’s going on under the hood. ...

Continue Reading

webrtcH4cKS: ~ Is Slack’s WebRTC Really Slacking? (Yoshimasa Iwase)

Posted by Yoshimasa Iwase on March 24, 2016
Posted in: Reverse-Engineering, Technology.
Tagged: , , , , , .
10 comments

Earlier this month Fippo published a post analyzing Slack’s new WebRTC implementation. He did not have direct access or a team account to do a thorough deep dive – not to mention he is supposed to be taking some off this month. That left many with some open questions? Is there more to the TURN network? How does multi-party calling work? How exactly is Slack using the Janus gateway? Fortunately WebRTC has an awesomely active and capable community that quickly picked up the slack (pun intended). ...

Continue Reading

webrtcH4cKS: ~ Dear Slack: why is your WebRTC so weak?

Posted by Philipp Hancke on March 3, 2016
Posted in: Technology.
Tagged: , , , , .
9 comments
slack webrtc2

Dear Slack,

There has been quite some buzz this week about you and WebRTC.

WebRTC… kind of. Because actually you only do stuff in Chrome and your native apps:

I’ve been there. Launching stuff only for Chrome. That was is late 2012. In 2016, you need to have a very good excuse to launch something with WebRTC and not support Firefox like this:
 

Maybe you had your reasons. As usual, I tried to get a dump from chrome://webrtc-internals to see what is going on. Thanks to Dag-Inge Aas for providing one. The most interesting bit is the call to setRemoteDescription:

I would like to note that you reply to Chrome’s offer of UDP/TLS/RTP/SAVPF with a profile of RTP/SAVPF. While that is still tolerated by browsers, it is improper.
Your a=msid-semantic line looks very interesting. “WMS janus”. Sounds familiar, this is meetecho’s janus gateway (see Lorenzo’s post on gateways here). Which by the way works fine with Firefox from what I hear. ...

Continue Reading

webrtcH4cKS: ~ Traffic Encryption

Posted by Philipp Hancke on September 23, 2015
Posted in: Technology.
Tagged: , , .
1 comment

So I talked about Skype and Viber at KrankyGeek two weeks ago. Watch the video on youtube or take a look at the slides. No “reports” or packet dumps to publish this time, mostly because it is very hard to draw conclusions from the results.

The VoIP services we have looked at so far which use the RTP protocol for transferring media. RTP uses a packet header which is not encrypted and contains a number of attributes such as the payload type (identifying the codec used), a synchronization source (which identifies the source of the stream), a sequence number and a timestamp. This allows routers to identify RTP packets and prioritize them. This also allows someone monitoring all network traffic (“Pervasive Monitoring“) to easily identify VoIP traffic. Or someone wiretapping your internet connection. ...

Continue Reading