Popular this Month

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: ~ Bisecting Browser Bugs (Arne Georg Gisnås Gleditsch)

Posted by Arne George Gisnås Gleditsch on May 14, 2019
Posted in: Guide.
Tagged: , , , .
2 comments
Ammonite

When running WebRTC at scale, you end up hitting issues and frequent regressions. Being able to quickly identify what exactly broke is key to either preventing a regression from landing in Chrome Stable or adapting your own code to avoid the problem. Chrome’s bisect-builds.py tool makes this process much easier than you would suspect. Arne from appear.in gives you an example of how he used this to workaround an issue that came up recently.
{“editor”, “Philipp Hancke“}

In this post I am going to provide a blow-by-blow account of how a change to Chrome triggered a bug in appear.in and how we went about determining exactly what that change was. ...

Continue Reading

webrtcH4cKS: ~ Finding the Warts in WebAssembly+WebRTC

Posted by Philipp Hancke on April 11, 2019
Posted in: Reverse-Engineering, Technology.
Tagged: , , , .
4 comments

A while ago we looked at how Zoom was avoiding WebRTC by using WebAssembly to ship their own audio and video codecs instead of using the ones built into the browser’s WebRTC.  I found an interesting branch in Google’s main (and sadly mostly abandoned) WebRTC sample application apprtc this past January. The branch is named wartc… a name which is going to stick as warts!

The repo contains a number of experiments related to compiling the webrtc.org library as WebAssembly and evaluating the performance. From the rapid timeline, this looks to have been a hackathon project. ...

Continue Reading

webrtcH4cKS: ~ How Janus Battled libFuzzer and Won (Alessandro Toppi)

Posted by Alessandro Toppi on March 6, 2019
Posted in: Guide.
Tagged: , , , , .
Leave a Comment

Thanks to work initiated by Google Project Zero, fuzzing has become a popular topic within WebRTC since late last year.  It was clear WebRTC was lacking in this area. However, the community has shown its strength by giving this topic an immense amount of focus and resolving many issues.  In a previous post, we showed how to break the Janus Server RTCP parser. The Meetecho team behind Janus did not take that lightly. They got to the bottom of what turned out to be quite a big project. In this post Alessandro Toppi of Meetecho will walk us through how they fixed this problem and built an automated process to help make sure it doesn’t happen again. ...

Continue Reading

webrtcH4cKS: ~ First steps with QUIC DataChannels

Posted by Philipp Hancke on February 11, 2019
Posted in: Guide, Technology.
Tagged: , , .
7 comments

QUIC-based DataChannels are being considered as an alternative to the current SCTP-based transport. The WebRTC folks at Google are experimenting  with it:

Let’s test this out. We’ll do a simple single-page example similar to the WebRTC datachannel sample that transfers text. It offers a complete working example without involving signaling servers and also allows comparing the approach to WebRTC DataChannels more easily. ...

Continue Reading

webrtcH4cKS: ~ What I learned about H.264 for WebRTC video (Tim Panton)

Posted by Tim Panton on January 29, 2019
Posted in: Technology.
Tagged: , , .
5 comments

It has been a few years since the WebRTC codec wars ended in a detente. H.264 has been around for more than 15 years so it is easy to gloss over the the many intricacies that make it work.

Reknown hackathon star, live-coder, and |pipe| CTO Tim Panton was working on a drone project where he needed a light-weight H.264 stack for WebRTC, so he decided to build one. This is certainly not an exercise I would recommend for most, but Tim shows it can be an enlightening experience if not an easy one. In this post, Tim walks us through his step-by-step discovery as he just tries to get video to work. Check it out for an enjoyable alternative to reading through RFCs specs for an intro on H.264! ...

Continue Reading

webrtcH4cKS: ~ Let’s get better at fuzzing in 2019 – here’s how

Posted by Philipp Hancke on December 14, 2018
Posted in: Guide.
Tagged: , , , , .
1 comment

Fuzzing overload. Image: Star Trek One Trek Mind #55: No Trouble With Tribbles

Fuzzing is a Quality Assurance and security testing technique that provides unexpected, often random data to a program input to try to break it. Natalie Silvanovich from Google’s Project Zero team has had quite some fun fuzzing various different RTP implementations recently.

She found vulnerabilities in:

In a nutshell, she found a bunch of vulnerabilities just by throwing unexpected input at parsers. The range of applications which were vulnerable to this shows that the WebRTC/VoIP community does not yet have a process for doing this work ourselves. Meanwhile, the WebRTC folks at Google will have to improve their processes as well. ...

Continue Reading

webrtcH4cKS: ~ Troubleshooting Unwitting Browser Experiments (Al Brooks)

Posted by Al Brooks on December 11, 2018
Posted in: Guide.
Tagged: , , , , .
2 comments

Echo cancellation is a cornerstone of the audio experience in WebRTC. Google has invested quite a bit in this area, first with the delay-agnostic echo cancellation in 2015 and now with a new echo cancellation system called AEC3. Debugging issues related to AEC3 is one of the hardest areas. Al Brooks from NewVoiceMedia ran into a case of seriously degraded audio reported from his customers’ contact center agents. After a lengthy investigation it turned out to be caused by a Chrome experiment that enabled the new AEC3 for a percentage of users in Chrome stable.
Al takes us through a recap of how he analyzed the problem and narrowed it down enough to file a bug with the WebRTC team at Google. ...

Continue Reading

webrtcH4cKS: ~ Improving Scale and Media Quality with Cascading SFUs (Boris Grozev)

Posted by Boris Grozev on November 12, 2018
Posted in: Technology.
Tagged: , , .
Leave a Comment

Deploying media servers for WebRTC has two major challenges, scaling beyond a single server as well as optimizing the media latency for all users in the conference. While simple sharding approaches like “send all users in conference X to server Y” are easy to scale horizontally, they are far from optimal in terms of the media latency which is a key factor in the user experience. Distributing a conference to a network of servers located close to the users and interconnected with each other on a reliable backbone promises a solution to both problems at the same time. Boris Grozev from the Jitsi team describes the cascading SFU problem in-depth and shows their approach as well as some of the challenges they ran into. ...

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