Most audio plugin UIs have always been a step behind other modern UIs. This isn’t completely surprising; the popular UI frameworks for audio plugins are either primitive in their styling options, or require lots of effort to make look good. Knowing this, I was very impressed by how pleasant BIAS FX’s UI was; the animations were smooth, theming was consistent, and things like drag-and-drop felt perfectly natural. I was curious how they pulled it off.

Too good to be true

As it would turn out, the answer wasn’t some magical, proprietary UI framework: it was HTML and CSS. This isn’t surprising in 2023—even decades-old apps like Photoshop now have portions of their UI that are just embedded web views. However, I’ve never seen this strategy used in an audio plugin before. I’m not certain BIAS FX is the first to do this, but it’s the first I’ve come across, which made it interesting to me.

Surprisingly, rather than effectively shipping a copy of Chromium, the platform-native browser engine is used to drive the web view (at least on macOS). This keeps installation size down, and as a bonus, yields a smoother experience given how well-optimized WebKit is for Apple hardware/platforms.

Nothing to see here

Knowing the UI is really just a website explains a lot about about its fidelity; as such, my focus shifted to peeking at the website sources and assets directly. Looking through the plugin’s resources directory reveals no shortage of HTML/CSS/JS files. Some of these look normal, but others (such as index.html) look more like this:

$ xxd index.html | head -n 10
00000000: 5047 3030 3030 3030 2d30 3030 302d 3030  PG000000-0000-00
00000010: 3030 2d30 3030 302d 3030 3030 3030 3030  00-0000-00000000
00000020: 3030 3031 0500 0000 3136 3830 37c5 0200  0001....16807...
00000030: 0017 763a f864 b48c c5be 2e3e 7932 4642  ..v:.d.....>y2FB
00000040: 5798 5198 32a2 d78f 2c0b 868b 60b2 d93e  W.Q.2...,...`..>
00000050: 9815 9a38 2588 5a32 7dca a32a ca8b e55b  ...8%.Z2}..*...[
00000060: 71a7 9ef8 6856 9a10 f63d 8145 b56c 1af4  q...hV...=.E.l..
00000070: 5e86 0d57 44c1 70ac 325c c1cd 97e8 3536  ^..WD.p.2\....56
00000080: 9933 1fd7 5a0e 81dc f4a5 0135 ac76 c9cc  .3..Z......5.v..
00000090: f2d5 edf0 cdf4 500f 6c67 167e 6614 63c9  ......P.lg.~f.c.

Clearly these files are in some encoded format. Comparing a handful of these encoded files visually shows they all share an apparent structure: a GUID followed by “garbage”. The high entropy of these files suggests the “garbage” is likely compressed or encrypted data:

$ rahash2 -a entropy index.html
index.html: 0x00000000-0x00000300 entropy: 7.66375743

WTF: What’s the format?

Spoiler alert: it’s not compression. Some reversing of the plugin tells that these files are a thin container over an encrypted payload. Represented as a C type, the format looks like this:

struct EncodedFile __attribute((packed)) {
  int8_t magic_guid[36];          /* PG000000-0000-0000-0000-000000000001 */
	
  int32_t salt_len;               /* 0x5 */
  int8_t salt[salt_len];          /* 16807 */
	
  int32_t payload_len;            /* 0x2c5 */
  uint8_t payload[payload_len];   /* ... */
};

Every file begins with the magic GUID shown above. Since the plugin loads all files through the same code path—and not all files are encrypted—this GUID is used as a flag to indicate if the file needs decryption before its contents are returned to the calling code.

Following the GUID is a 32-bit integer containing the length of the “salt”, a numerical ASCII string used in deriving the encryption key for the file. Finally, there is another 32-bit integer holding the length of the encrypted payload, followed by the payload itself.

Encryption begone

More reversing shows that the payload itself is encrypted using AES-256 in ECB mode. Each file has a unique key derived from a constant “prefix” string and the salt in the preamble. The steps for deriving the key are as follows:

  seed = Concatenate(salt_prefix, salt)
part_a = MD5(SHA1(seed))
part_b = SHA1(MD5(seed))
   key = Truncate(Concatenate(part_a, part_b), 32)

To summarize in English, the key is computed by:

• concatenating the salt prefix and the salt to form the “seed”;
• running the seed through MD5 then SHA-1 (part A) and SHA-1 then MD5 (part B);
• concatenating A and B; and finally,
• truncating the result to 32 bytes.

Not the most advanced protection, as you can see. That said, as to not lay out everything in this post, finding the salt prefix is left as an exercise to the reader; it’s not too difficult. :)

If you’re following along and want to check your work, the key for index.html is:

4b2e5b1df4854e717a0953d916dc653f047f33b72961235001a2233fbec5a611

and the SHA-1 sums of the encrypted and decrypted files are:

$ shasum index.html index.html.dec
3c49b8aa65bd24c376485bd6cf9da238367515c7  index.html
52c6ddf10ce91c84ed38e5be80e4377d58b2b90c  index.html.dec

All of this research was done on BIAS FX 2.6.1.6290 for macOS.

Debugging (without LLDB)

Since the UI is all web-based anyway, native debuggers (e.g. LLDB) are unlikely to be of much help here for debugging the UI. However, a very important detail was mentioned earlier: on macOS, the UI uses a native WebKit web view. This means that like other native web views running on the system, it can be debugged using Safari’s developer tools.

Simply opening the “Develop” menu in Safari and looking in the submenu matching your computer’s hostname will reveal all of the debuggable web views on the system. If a BIAS FX plugin window is open, it will show up in the list.

Wrapping up

This was a fun project, but wasn’t really started with any goal in particular and as such, has no logical conclusion. There’s probably a lot more to be explored with the web inspector, but I ran out of time to experiment further.

To conclude, I have a handful of final notes that didn’t really fit in anywhere else in this writeup, but might be relevant for any future research:

• JUCE is unsurprisingly used for the native parts of the plugin.
• The WebKit-based web view appears to be provided by or used in tandem with JUCE’s web browser component.
• Attributes in the UI HTML suggest Angular is used in the UI.
• The plugin’s UI assets are copied to (and served out of) a temporary folder on disk. I’m unsure what the benefit of this is.
• Assets remain encrypted on disk, which means they are decrypted in-transit when loaded by the web view. This can be confirmed through more reversing, but isn’t super interesting.
• The $store variable seems to hold a lot of plugin UI state; probably worth fiddling with.
• The Native variable looks enticing and seemingly exposes communication to the plugin’s backend, which is based on a system of “commands” whose handlers & registration can be seen in native code.

As always, feel free to reach out if you have any questions.

The slides were designed to supplement my speaking (rather than doing the talking for me), and per conference rules, there was no recording. That said, you may still find them useful on their own. Feel free to contact me if you have any questions.

The GIF above shows Calculator.app being opened by exploiting this vulnerability. The source code for the proof-of-concept shown above is available here.

Library feeds

Sketch users can create collections of reusable design assets and share them with other users; these collections are called “libraries”. To enable the distribution and maintenance of libraries over the internet, Sketch utilizes “library feeds”, which are just minimal RSS feeds that inform Sketch about a library. Shown below is the feed for Apple’s official iOS 14 UI library, with some unnecessary information trimmed for brevity.

<?xml version="1.0" encoding="utf-8"?>
<rss>
  <channel>
    <title>Apple iOS UI</title>
    <description>Apple iOS 14 Sketch library</description>
    <language>en</language>
    <item>
      <title>Apple iOS UI</title>
      <sparkle:minimumSystemVersion>70</sparkle:minimumSystemVersion>
      <sparkle:maximumSystemVersion>71</sparkle:maximumSystemVersion>
      <pubDate>Thu, 28 Jan 2021 9:00:00 +0000</pubDate>
      <enclosure url="https://...cdn.apple.com/.../library.dmg" ... />
    </item>
  </channel>
</rss>

When installing or updating a library via a library feed, Sketch will automatically download whatever is at the URL specified by the “enclosure” tag. In the example shown above, the library’s content is distributed as a DMG file.

Unrestricted file transfer

It turns out there are no restrictions on the type of URL that may be specified in the enclosure tag — it doesn’t have to use HTTPS, or use any web protocol at all. Given this lack of restrictions, it is possible to create a library feed with any URL imaginable, pointing towards any type of content; Sketch will happily download it.

Quarantine bypass

Users of macOS are familiar with pop-up dialogs asking them to confirm they would like to open a file downloaded from the internet. These prompts appear because web browsers (among many other applications) mark files downloaded from the internet with the “com.apple.quarantine” extended attribute; this signals to macOS that the file should be treated with caution.

The key detail here is that this behavior is not automatic; applications must explicitly mark downloaded files for quarantine. Prior to Sketch 75, files downloaded as part of library feeds were not marked for quarantine.

Remote code execution

To recap so far, Sketch will download any type of file (from any URL) specified in a library feed, and neglect to mark the downloaded file for quarantine. This behavior isn’t ideal, but also isn’t super interesting on its own.

However, I’ve left out one important detail — after Sketch downloads a file from a library feed, that file will be automatically opened, with no user interaction at all.

Now things are more interesting. All of these behaviors combined provide a great foundation for remote code execution — the only remaining task is finding a file type that can be used to execute code when it is opened.

Terminal profiles

Surely there is no shortage of third-party applications suitable for this task, but I wanted to find an application that ships with macOS that could be used. The default terminal emulator on macOS (Terminal.app) supports saving a “terminal profile” to a file, which looks something like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>CommandString</key>
    <string>open -a Calculator; killall Terminal</string>
    <key>ProfileCurrentVersion</key>
    <real>1.0</real>
    <key>RunCommandAsShell</key>
    <false/>
    <key>name</key>
    <string>CVE-2021-40531</string>
    <key>shellExitAction</key>
    <integer>0</integer>
    <key>type</key>
    <string>Window Settings</string>
    <key>warnOnShellCloseAction</key>
    <integer>0</integer>
  </dict>
</plist>

When a terminal profile is opened, it launches Terminal.app, creates a new window using that profile, and runs the startup command specified in the “CommandString” property. This makes terminal profiles a great choice for achieving remote code execution in the context of this vulnerability.

It is important to note that if Sketch were properly quarantining downloaded files, the terminal profile would not be able to open and execute code without confirmation. Even with proper quarantining, some users might just click “Run” anyway, but that’s a separate problem out of scope for this blog post. :)

URL handler

To make installing libraries (or delivering this exploit) even easier, Sketch registers a URL handler that accepts links in the following form:

sketch://add-library?url=<LIBRARY_FEED_URL>

This makes it possible to install a Sketch library feed by simply clicking a link. In fact, Apple uses this strategy to provide access to their official Sketch libraries. While using the URL handler is not necessary for exploiting this vulnerability, it makes it even easier; potentially securing remote code execution on the victim’s machine with just one click.

Proof of concept

A small proof-of-concept which opens Calculator.app by exploiting this vulnerability (shown at the top of the page) is available on my GitHub here.

Closing notes

Sketch 75 and beyond now appropriately quarantine files downloaded from library feeds. If you aren’t using Sketch 75 or newer, you should avoid using any untrusted library feeds and update as soon as possible.

Finally, I’d like to thank Sketch for their swift cooperation in fixing this vulnerability and for providing a €1,250 reward for reporting this vulnerability.

• using Emacs 28’s native Elisp compilation; and
• compiled for ARM64 (rather than running under Rosetta).

There are many different macOS Emacs “distributions” out there, and I wasn’t sure which to choose so I opted to compile Emacs from source myself.

The rest of this post is primarily a guide for my future self, but I’ve published it for anyone else interested in building Emacs from source on macOS. I’m not super familiar with building Emacs from source — these are just the steps that worked for me.

Prerequisites and dependencies

Emacs has a handful of dependencies which can all be installed via Homebrew with the following command:

brew install autoconf texinfo gnutls jansson gcc libgccjit

Next, get the Emacs source code by cloning it from the GitHub mirror:

git clone https://github.com/emacs-mirror/emacs.git --branch emacs-28 --depth 1

Depending on how far in the future you are reading this, the specific branch to use will likely have changed. However, never forget to specify --depth 1 as it reduces the download size and speeds up the clone operation tremendously.

Building (and waiting)

This is the important part. Start by running autogen.sh to generate the appropriate configuration utility, then invoke it as follows:

CFLAGS="-I$(brew --prefix libgccjit)/include -I$(brew --prefix gcc)/include"
LDFLAGS="$CFLAGS -L$(brew --prefix gcc)/lib/gcc/11"
CFLAGS="$CFLAGS -O2"

./configure --disable-silent-rules --with-xml2 --with-gnutls \
	--with-native-compilation --with-json --with-modules --with-ns \
	--without-mailutils --without-dbus --without-imagemagick --without-rsvg \
	--without-xpm --without-tiff --without-gif --without-lcms2 \
	--without-libsystemd --without-cairo --without-imagemagick \
	--without-toolkit-scroll-bars

Note: The GCC major version is hardcoded here and will need to be adjusted in the future.

You may want to adjust the feature set and compiler flags as you see fit. Once configure is done running, the rest of the build is rather easy:

make -j8
make install

Assuming all goes well, you should be greeted with a nice “fully-native” Emacs application bundle located in the “nextstep” directory of the Emacs source tree.

https://binary.ninja/2021/07/08/creating-great-themes.html

To prevent users from tampering with these files, a signature of the relevant data is often included so the software can verify the license file:

1. has not been tampered with; and
2. was truly created by the software vendor.

While this is certainly better than using pattern-based serial numbers, it is far from perfect.¹ By itself, this strategy is vulnerable to a trivial attack known as public key replacement.

Public key replacement

Public key replacement (PKR) occurs when an attacker replaces the public key embedded in the software with their own. Simply put, this means that the attacker can now pretend to be the vendor and sign their own license files.

An attacker will first reverse engineer the program to determine valid license parameters. Next, they will generate a key pair matching the type found in the software. They will then construct or generate an ideal license file, signed with their private key. Finally, they will replace the public key found in the binary with their own. Now, when the software runs, it will gladly accept the illegitimate license.

What makes this such an attractive attack for pirates is that replacing the key requires little effort. It is a simple find and replace operation. If there are no other protections in place, once the public key has been swapped, additional patching is usually not required.

In other words, disassembling and patching the program after each release isn’t necessary. A one-time reverse engineering effort paired with a find-and-replace Python script could turn into a reliable crack for years to come.

Key reuse and recycling

In many copy protection implementations, the key used to verify license signatures is used for that purpose only. This means replacing it has no side effects! Instead, try using the same signing key to also decrypt critical application data, server responses, etc. where possible.

By doing this, replacing the key will cripple the rest of the app.² If the attacker wants to bypass this, they will need to decrypt all the relevant data with the original key, then re-encrypt it to with their private key. If the data comes from the network rather than the disk, this additional hurdle will be even harder to bypass without a special proxy.

Key integrity checks

Another strategy to make PKR more difficult is to check the integrity of the key at runtime. An easy way to do this is to calculate the key’s checksum.

Hold on a moment, though. Don’t even think about including the checksum of the key in the binary. That is just as easy to replace as the key itself!³ Instead, compute the checksum at runtime and manually check individual bytes. This will require patching to bypass, or a key whose checksum collides with the real key at the points in question. Checking a sufficient amount of bytes can reduce the odds of the latter to almost zero.

Wrapping up

It’s important to remember that it is impossible to prevent your app from being cracked. However, I think increasing the effort needed (especially aiming to prevent automated patching) is always worthwhile. I like these strategies because they aren’t very difficult to implement as a software vendor, but make cracking your app a bit more annoying. :)

Appendix

Hijacking dynamically linked functions

First and foremost, library injection allows you to override the implementation of dynamically linked functions. Sometimes larger (typically cross-platform) applications extract most of their business logic into a separate library. This extraction opens up an attack surface in which we can reimplement functions at our convenience.

Assume we are targeting a commercial application with the intent of extending the trial period by one week. From our analysis we know the application calls a (dynamically-linked) function, days_left, to get the number of days left in the trial. The code below shows how we can reimplement this function while also preserving the implementation of the old one.

#include <dlfcn.h>
#include <unistd.h>

int (*old_days_left)(void) = NULL;

int days_left(void) {
  if (!old_days_left) {
    old_days_left = dlsym(RTLD_NEXT, "days_left");
  }

  return old_days_left() + 7;
}

Simply compile this code as a shared library and use the environment variables mentioned earlier to load it. The steps to do this on macOS look like this:

$ clang -shared extend.c -o libextend.dylib
$ DYLD_INSERT_LIBRARIES=./libextend.dylib ./example_application

When our library is injected into the application, our implementation will be called instead, and we can enjoy a longer trial period.

See the man page for dlsym to better understand how the code above works. On macOS you may need to use DYLD_FORCE_FLAT_NAMESPACE=1 to ensure your implementation is used, and I’ve heard you may need to disable System Integrity Protection as well.

Persistent injection on macOS

Should we want to make our changes from the previous examples permanent, we could replace the app’s main executable with a script which launches the application with our library injected.

To do this, rename the main executable (you can just put an underscore in front if it), and create an empty text file with the main executable’s old name. Open the file in a text editor and add the following:

#!/bin/sh

CONTENTS=$(dirname "${0}")
CONTENTS=$(cd "${CONTENTS}/.."; pwd)

# Here is where you would configure your injection. Copy your compiled library
# to somewhere inside the app bundle, such as the Frameworks directory.
export DYLD_INSERT_LIBRARIES="$CONTENTS/Frameworks/libextendedtrial.dylib"

# If your application was called "HelloWorld", make that this script's name.
"$CONTENTS/MacOS/_HelloWorld" "$@"

Finally, make the script executable with chmod +x HelloWorld. Now you should be able to open the application normally, via the Dock, Spotlight, etc. and your library will always be loaded. Note that some applications manually verify their code signature, etc. and this method will not work in some of those cases.

I was curious how this was done, so I started to investigate. The Chrome developer tools confirmed my suspicion that these realtime updates are achieved through the use of WebSockets.

When the page is first loaded, the client opens a WebSocket connection and sends a subscribe request, which looks like the following:

{
  "subscribe":[
    "^GSPC",
    "^DJI",
    "^IXIC",
    "^RUT",
    "AAPL"
  ]
}

As you can see, the client just specifies a list of stock symbols to receive updates for. The backend will then send new data to the client as it becomes available, roughly every second. Here is a response from the server:

CgRBQVBMFZqZ4UMYoI+hlvlcKgNOTVMwCDgBRXIUSr9IyOXZDmWAwmXA2AEE

Looking at the response, it is easy to recognize it is Base64 encoded. But when decoded, the data is not structured in any obvious format. Further inspection of the Yahoo Finance site’s code reveals that these are actually Protobuf messages.

PricingData.decode = function decode(r, l) {
  if (!(r instanceof $Reader)) r = $Reader.create(r);
  var c = l === undefined ? r.len : r.pos + l,
    m = new $root.quotefeeder.PricingData();

  while (r.pos < c) {
    var t = r.uint32();
    switch (t >>> 3) {
      case 1:
        m.id = r.string();
        break;
      case 2:
        m.price = r.float();
        break;
      case 3:
        m.time = r.sint64();
        break;
      case 4:
        m.currency = r.string();
        break;

      // Additional fields omitted for brevity...
    }
  }

  return m;
};

Reverse engineering the decoding function (shown above) allows us to construct a valid Protobuf message definition for the server’s responses:

message PricingData {
    string id = 1;
    float price = 2;
    sint64 time = 3;
    string currency = 4;
    string exchange = 5;
    int32 quote_type = 6;
    int32 market_hours = 7;
    float change_percent = 8;
    sint64 day_volume = 9;
    float day_high = 10;
    float day_low = 11;
    float change = 12;
    string short_name = 13;
    sint64 expire_date = 14;
    float open_price = 15;
    float previous_close = 16;
    float strike_price = 17;
    string underlying_symbol = 18;
    sint64 open_interest = 19;
    sint64 options_type = 20;
    sint64 mini_option = 21;
    sint64 last_size = 22;
    float bid = 23;
    sint64 bid_size = 24;
    float ask = 25;
    sint64 ask_size = 26;
    sint64 price_hint = 27;
    sint64 vol_24hr = 28;
    sint64 vol_all_currencies = 29;
    string from_currency = 30;
    string last_market = 31;
    double circulating_supply = 32;
    double market_cap = 33;
}

It is also worth noting that no authentication is required by the client to connect and receive realtime data. This means you can (theoretically) use the API in your own programs, as long as your language of choice is supported by Protobuf and has a WebSockets library.

I do not believe this API is intended for public use, so I would exercise caution when using it for your own purposes. Furthermore, despite the large number of different fields defined, only a subset of them are regularly streamed, specifically fields 1-3, 5-9, 12 and 27. You will need to fetch the remaining data from a different source.