Henri: again, a warm welcome thanks for the applause and thanks for your interest in
Apple's low latency Wi-Fi and in this talk especially about cracking open what makes
Apple's low latency Wi-Fi so fast before we begin let me introduce myself with a few words
so I am a researcher at OpenKritis we publish information about German cyber
security regulations and cyber security regulations in the EU and if terms like
EU NIS2 or EU CRA do mean anything to you then visiting our website might be a
worthwhile thing to do and besides that I am a student at the Hasso Platner
Institut and the contents of the following talk will be about oh yeah come
from my master's thesis and my research at the chair of Jiska Klassen mobile and
wireless security so as you might know Apple devices are highly interconnected
devices for example if you own a Mac and an iPad you can do things like extending
your Mac's desktop to your iPad in a wireless manner with Sidecar display for
example or you can use your mouse and your keyboard to remote control your iPad
from your Mac with universal control you can also use your iPhone as a webcam on
your Mac or even a desk cam with continuity camera and with iPhone mirroring it's
possible to remote control your iPhone from your Mac and there are a bunch of
different features that make up this ecosystem experience Apple built and all
these features are comprised and summarized under this umbrella term
continuity now the features I just presented all share three things in
common they mostly transmit video data they operate under real-time constraints and
they leverage this link layer protocol low latency Wi-Fi and in the past there
have been a few questions about low latency Wi-Fi and its interface LLW zero for
example researchers have questions about how this interface is open from a
system level perspective or whether third -party devices are low latency Wi-Fi
compatible and in the end as well what makes low latency Wi-Fi actually low
latency now these questions are quite difficult to answer because there are
so many traces and logs we can examine in different files and using different
utilities so for example we can investigate the system logs we can also
investigate kernel traces with Ktrace and Dtrace we can examine cross-process
communication with XPC examine backtraces and aside from the system level
perspective we can also take a look at the packet captures on any interface
possible and because of this vast amount of information and this wide variety of
utilities utilities we can use there has been a missing solution in the past that
correlates this log information from different log sources in a timely manner and
even from different devices because without this solution it's very very difficult to
to correlate events that occur the other occur among different files for example so
imagine you have several files on multiple devices then this solution a log aggregator would
need to merge these files in order to facilitate
research for network protocol details and this is why
the first part of this talk will be about building a
log aggregator before diving into the details of low
latency Wi-Fi so let's start by building a log
aggregator there are of course some strings attached some
challenges and the first one is the availability
of forensic sources especially on iOS there are
different utilities we can use primarily on macOS for
example the console application for viewing the system
logs on Apple platforms Wire shark for capturing network
captures packet logger for capturing bluetooth captures
CCtool this is a utility that collects information from a
separate logging framework in apple platforms that are related to
IEEE 802.11 information and dtrace and ktrace are utilities that can collect kernel traces
so as already mentioned these utilities are available on macOS but before my
research it was uncertain whether dtrace ktrace and cctool are available on
iOS and as it turns out there is an alternative for ktrace which we will look at in a second
and by reverse engineering the underlying framework of cc
tool which is called core capture control i was able to
reimplement cc tool for ios concerning dtrace we
don't know yet whether that is feasible on ios
so further research needs to be done here now if
you take a look at the 'Ha ck Different' Discord and
search for ktrace you might end up in the general
channel and find a post which talks about ktrace being
available in some repository called system commands and
you might find yourself looking this repository up on
github in the apple open source software distributions organization and
you might find yourself confused because there's no trace at all of ktrace
however as it turns out there is a release of this repository back in 2022
that actually lists a tool called trace
and it turns out that trace is able to generate ktrace possible output
and using the right build commands and the correct
dependencies especially header files from the
kernel it's possible to build the trace utility for
ios and therefore bring support for ktrace output
to ios and ipad os devices the second challenge
is about clock offsets because when we talk about
collecting logs from multiple devices we also talk
about devices where clocks are not perfectly aligned
and this is especially cumbersome when and unfortunate when trying to
aggregate different log files because without aligning the clocks
the aggregated log file will end up being misaligned
so the solution here is of course to collect the
clock offsets and compute them during log collection
so that we can account later on during the log aggregation for the clock offsets
and i did that by implementing an NTP client and an
NTP server that can communicate wirelessly or even
through a simple lightning cable or USB-C cable and
using iproxy. The collection on multiple devices
of forensic sources is a second or third problem because before we can aggregate logs
we need of course collect the logs and manually initiating these tools is quite cumbersome
because when you look at this table there are at
least 11 tools we would need to initiate manually
so the solution here is of course to automate this
and i did that by implementing a small toolkit
consisting of several shell scripts this toolkit is
invoked from MacOS and is essentially just a command line
interface where the MacOS device can instruct the
ipad via an ssh tunnel to initiate start and stop
certain commands and basically this toolkit is about process management
and also about transferring files between both
devices and in the end there are essentially two
scripts running on both devices simultaneously that initiate the
tools that collect log sources
so you can connect your ipad or ios device to your mac the script then starts the captures
network captures for example with tshark and tcpdump
then you can run your network protocol or continuity
feature or whatever you like afterwards the script will
collect more information especially log information
from the system logs transfer the files back to the
Mac and then the toolkit will run the log aggregation
which is of course a problem on its own because we have to deal with varying file formats
there's json data involved with console and ktrace for example
there are pcapng files in the output of cctool
and wireshark and even custom output with dtrace
so the solution here is to build file specific parsers
parsers that pass the information in these files into custom business logic
and once we have this information in business logic basically in
objects, python objects for example
we need of course filter some irrelevant data out
because there is a lot going on we are not interested in
and finally the log aggregator will write data
into either a pcapng file or a log archive file
it's already hinted at noise filtering is also a
challenge so as you might imagine in an operating system
there is a lot of boring stuff going on a lot of
regular stuff a lot of stuff we are not interested in
and the idea here is to record these traces and store them in a file so that it contains
data that acts as reference for noise data and then we can go ahead and record
traces from the protocol we are interested in for example sidecar display
which of course holds the fun traces the traces we are
interested in the traces that are low latency wi-fi related
and then using this noise reference data and comparing it to the
traces of sidecar display in this example we can filter out the boring stuff
the stuff we are not interested in and on a
technical level this happens based on hash values
the log aggregator also supports static filters so
that you can define whitelist and blacklist filters
and filter out log lines based on process names so
in this example the aggregated log file won't contain
any log lines from a process called electron for
example so building a log aggregator in the end
involved developing multi-device support the log aggregator supports multiple input formats
and is basically extensible to any tracing utility you can invoke on the command line
it supports log archive and pgfile output accounts
for clock offsets and also for noise filtering
so let's move on to investigating the network stack on macros and ios
the network stack on macros and ios and essentially
on any apple platform consists of multiple system
components so starting in the user space there
are a variety of um system demons in the case of
sidecar display for example the avconferenced demon
and the wi-fi peer-to-peer demon and these system
demons call into a data structure called the Dyld
shared cache this data structure holds frameworks and
libraries that system demons need to function properly
and these frameworks in the end call into kernel space
and the kernel space is comprised of well the kernel
binary but also kernel extensions which are other
macro binaries and these kernel extensions are specialized
for different tasks like networking related tasks
time management communicating with coprocessors etc and as it turns out in the past
in the last few years apple moved some of this networking related
kernel part and some networking related kernel extensions into user space
into a second Dyld shared cache which is called the driver kit shared cache
and because this second Dyld shared cache wasn't
documented thoroughly before yeah this talk actually
here's a slide that covers some of these frameworks in more detail so for example the
driver apple broadcom wlan is a user space process
which re-implements the apple broadcom wlan core
kernel extension and manages interfaces queue - queues -
and configures wireless chips then another important
framework will be the networking driver kit this
is actually a public framework and it is used for
providing foundational functions to communicate with
networking drivers and there's also the io80211 driver
the driver kit that handles iEEE 802.11 concepts and states
and it substitutes the former kernel extension io80211 family
there are also other
private frameworks in the driver kit shared cache which are apparently empty
it's not clear why that is maybe apple forgot about
developing these frameworks maybe they postponed development
that's unsure so far
but basically these are the system components we need to examine in order to
get an idea of what is going on in the network stack on apple platforms
we have user space processes
we have the Dyld shared cache that contains certain frameworks
system calls kernel extensions and a variety of driver kit components
so in order to investigate low latency wi-fi
we can from a system level perspective take a look at
how mac os for example manages its interface low latency wi-fi zero llw zero
and at first this interface needs to be activated of course
in user space this is done by the avconference
demon that calls into the networking framework
which then calls a system call called channel open
and the flow of execution goes through the kernel into the kernel extension ioskywalk family
which is a kernel extension responsible for networking related tasks
and as you can see this kernel extension calls a function called set interface enable
and the ioskywalk family calls into this driver kit
component com apple driver kit apple broadcom wlan
and in the end enabling this interface is basically attaching a berkeley packet filter
so providing a memory region
for the av conference demon to transmit data via
the llw zero interface and receive data from it
low latency wi-fi is also configured by a second user
space demon which is called the wi-fi peer-to-peer demon
and presumably this demon calls into the wi-fi peer-to-peer framework
presumably then calls into the kernel and into the ioskywalk family
which in turn presumably calls into the driver kit domain
i'm saying presumably because grant central dispatch is involved here and
grant central dispatch is responsible for asynchronous function calling so
tracing the system and function call is not very easy
however most interestingly here is that the io 802.11 driver kit
calls a function which is called configure hpp
low latency wi-fi parameters and this function
is used by basically any sidecar any low latency wi-fi related
continuity feature we investigated so this function is used by sidecar display
universal control iphone mirroring airplay to mac
which is used when you mirror your ipad screen for
example to your mac and apple watch mirroring which
is basically iphone mirroring but for the apple watch
on iOs and this function calls another function
default vo low latency wi-fi parameters that obviously
based on the name yeah provides static parameters for low latency wi-fi
and these static parameters are passed to this
function called set low latency wi-fi parameters
and before turning to these parameters let's first
investigate how the data transmission is done
using llw0 so the avconferenced daemon calls again into the network framework
which calls into the kernel space by using a system
call called channel sync and the flow of execution
goes again into the IOSkywalk family and as it turns
out the IOSkywalkfamily uses data structures that
hint at submission queues submission queues and
completion queues are used in nvme for communication
with coprocessors so we can assume that the ioskywalk
family is responsible for communicating the kernel
packets that are to be sent over the network with
a wireless chip and in the end the ioskywork family
informs probably the wireless chip that data is available to be sent
after transmission the driver kit shared cache and
the networking driver kit gets informed that some
packets have been transmitted and the networking
driver kit calls into kernel space to inform the
kernel about which packets can now be freed from
memory so in the end the system components involved in
data transmission with low latency wi-fi reside both in user space and in kernel space
in user space the system daemons av-conference
daemon and wi-fi peer-to-pe daemon are involved
we figured out that some parts of the kernel space
of the networking stack moved into user space into a
second dyld shared cache which is called the driver
kit shared cache and other concepts are at play here
for example nvme berkeley packet filters and system calls like channel open and channel sync
so let's continue with investigating the low latency
property of llw as a quick reminder when we talk about low
latency wi-fi we are talking about the network access
layer in the tcp ip stack or in the osi iso model
about the link layer and the physical layer on the link layer um therefore we can look into
um standards like the ieee 802 11 standard and as it turns out low latency wi-fi
leverages concepts that are defined in these standards and in particular in the amendments e
n and ac the e amendment defines concepts for quality of service and the n amendment
defines concepts on high throughput and we are
going to cover some of these concepts in order to
understand what low latency wi-fi is doing in order
to achieve low latency in the e amendment there is
something called the enhanced distributed channel
access the edca categorizes network traffic into four
different access categories and from background
to voice they all feature different priorities for
medium access and channel access and low latency
wi-fi uses and classifies its traffic in the
access category voice also for video traffic
so if you use sidecar display for example or iphone mirroring you are probably
transmitting or your device is probably transmitting data in the access category voice
now to understand how this arbitration and priority for medium access is achieved we need to
consider how devices access the medium so suppose the medium has been busy busy because
a network devices have been sending data then
devices with very high priority control frames get to
send first after waiting for a short interface spacing
however if no such network devices are available
then devices that have EDCA classified and network traffic available in the queues
well next to send and as you can see there's an
arbitration interface spacing for the access category
voice and video that is shorter than the arbitration interface spacing for network traffic
classified as best effort for example or background and to prohibit
network devices from transmitting simultaneously there is a second concept involved here
before transmitting data which is called the random
backoff period so before devices start sending data
they initiate a random backoff counter and to visualize
that i have this little figure here so suppose
the medium is idle multiple devices have data
available to be sent and suppose multiple devices
that decide simultaneously now to just send data
because they don't initiate any random backoff timer
then this causes some trouble on the medium because in a wireless scenario
sending data is always louder than receiving data so while sending you can't
see a random backoff counter here and detect collisions
on the yeah in a wireless scenario so this is why
there's the concept of random backoff counters where
devices choose a random integer between the interval
from zero to a variable called cwmin and this variable is different for each access category
so suppose there are two devices picking a random
backoff count and the smartphone down here picks
the integer one then this device gets to send first and therefore wins access to the medium
and transmission can happen without any collisions and
after the random backoff period during transmission
there are different transmission opportunity values
for each access category and video traffic for
example gets to send for the longest duration while
audio traffic and best effort and background traffic
have shorter transmission opportunities now recall this
function called 'default VO L ow latency wi-fi parameters'
this function um provides
different um yeah configuration values for low
latency wi-fi and as it turns out the ieee802.11
specification is coherent with the parameters defined
by the default vo low latency wi-fi parameters
and actually this function and the parameters defined in it precisely match the ones
defined in 802.11 until 2012. there's also a second
function called default low latency wi-fi parameters
and as it turns out this function completely
skips the initial contention window and a random backoff period
so that devices can send right after the arbitration interframe spacing ellipses
and this function also defines a transmission opportunity that exceeds the
value defined in 802.11 by far
so with default llw parameters devices can send up to eight milliseconds
as a disclaimer we did not observe this function
being used in a real world scenario but it's still
defined in the source code so this function might be used somewhere the n amendment
introduces another concept called aggregated mpdu
and this concept allows multiple mac layer protocol
data units to be aggregated in a single physical layer
data frame and there's another concept called AMSDU
where multiple payload data can be put into a single mac
layer frame so that yeah the on the mac layer there
are less mac headers less physical headers and less
that's interframe spacings and this in turn also saves acknowledgement frames for example
and in turn um the gains here are of course um for
lower latency when looking at the device tree in
mac os we can see that low latency wi-fi
um has some um special configuration parameters for
llw0 and as it turns out there's the channel bandwidth
property which translates into 80 megahertz channel
bandwidth so this bandwidth is defined in the ac amendment of
ieee 802 11 which defines specifications for radios with
very high throughput and in this particular example the
channel was configured to the channel 52 operating on a frequency of 50 to 60 megahertz
there are also hardware capabilities involved on the mac layer
so if you look up the io 802 11 driver kit and
look up for the term sdb or rsdb then you will find
references to some functions called real simultaneous dual band rsdb enables devices to
um establish two separate links on the mac layer on
the link layer so devices can establish a link to an
access point for example while establishing also
a second link for for a peer-to-peer communication
and as it turns out the kernel cache on a mac mini
with m4 running mac os acquire contains references to
broadcom firmware of broadcom chips that all feature
rsdb so it is very likely that mac os devices and ios
devices use rsdb for transmission on the link layer and rsdb is not only a thing
uh for mac devices and apple devices but also
um for android devices for example so in the end
low latency wi-fi achieves its low latency characteristic by labeling its traffic in the
access category voice with special parameters from
different amendments especially the edca parameter
set of the e-amendment for fast channel access it
introduces it leverages concepts like amsdu and
ampdu and operates on a channel bandwidth of 80 megahertz
and hardware capabilities are also involved with rsdb
so to wrap this up why actually bother why is reverse engineering low latency wi-fi relevant
well because this is a matter of interoperability as
we have seen interoperability should be technically
feasible because it is basically an open standard that
is being implemented here and hardware capabilities
present in low latency wi -fi are also available for
example in the android world so apple is basically
implementing an open standard here but seemingly
reserves it for proprietary features because
there doesn't seem to be any documentation on using
low latency wi-fi and interacting with it from a user
space perspective in the past there have been multiple re-implementations of several
features in the apple ecosystem so for example open
drop ones re-implemented and open-sourced airdrop
watch which brought apple watch support in android
open haystack open-sourced the find my network
and there are a bunch of features that rely on
low latency wi-fi but which have not been reverse
engineered yet and maybe we will see some of
these features being re-implemented in the future
thank you very much
Herald: thank you very much henry for this insightful talk we have a few minutes left for questions
please find your way to the microphones if you have questions uh number one please
QA: hi um thank you for the uh thank you for the great presentation yeah uh in one
of your slides you showed that the nvme is also
involved when when we send data via um via this this
network um i just want to understand uh also that you
showed that there is a priority that whether voice
data would be sent first or video data would be
sent first so there might be some in memory buffer
or the data might be saved in the nvme for a part yes
but but the issue is that if if you write for every
every um display that that i want to share with my
phone or or from an apple tv to my desktop if i keep
writing to the nvme it has a right cycle so it will wear out so do you think that for
every thing that they share there there is an
nvme write or read that happens or or they save
these packets in in some memory buffers before
they get short short questions please and could
could the audience please keep the noise level down for the answer thank you yes
Henri: that is uh probably
happening i haven't looked into nvme too much and
um haven't considered this specific scenario yet so
um yeah i guess further research needs to be done here yeah thank you
Herald: one question from the signal angel please
QA: is this on okay the internet would like to know whether it's possible to sneeze the
decryption from end to end
Henri: uh whether it's encrypted from end to end yes it is um sidecutter place for
example uses srtp on the application layer yeah
Herald: number three please
QA: hi uh does it have any control
mechanisms like awdl which had the synchronization
mechanism does it have something like that and
did you look at it um synchronization in what sense
like time synchronization or like awdl did the channel
uh yeah so there's yeah there's a channel sequence uh and i guess it's the same uh as awdl
thanks yeah uh sadly we're in a tight schedule
so we won't be able to take more questions now
is there a place when where people can find you
after this talk to ask you a few more questions well
probably at the platy ponies where platy ponies
uh in hall h so you can look at that on c3 nav
but i will also stay in in this room um just after after this talk so you can talk to me
Herald: uh sadly we have uh the yearly review right after so it's gonna get really busy