svnscha - security

When Citrix App Protection Becomes App Obstruction

2025-07-01T00:00:00+00:00

When Your Own Product Keeps You Honest

You're trying to connect to your virtual desktop through Citrix Workspace, ready to access your work environment and get stuff done, when suddenly you're greeted with this delightfully cryptic message:

App protection component is restricting this launch. Contact your system administrator for further assistance.

Ah yes, classic. Especially when you ARE the system administrator and this error message tells you absolutely nothing useful. It's like getting a "something went wrong" alert - technically accurate, but not exactly actionable.

In my case, Nextcloud running on the host caused the problem. Closing Nextcloud allowed Citrix to connect; starting it again blocked the connection. I work at Citrix on a different team, which made this an interesting problem to debug in my spare time.

So, why?

Here's what's happening: When you have Nextcloud running on your host machine, it uses LD_PRELOAD as part of its Flatpak sandboxing mechanism. This is a perfectly legitimate system mechanism that allows applications to override or extend library functions at runtime.

App Protection sees a process using LD_PRELOAD on the host and treats it as suspicious, even though the process is unrelated to the virtual desktop connection.

The solution? A gentle conversation with the allow list to explain that these specific LD_PRELOAD patterns from Nextcloud are actually friends, not foes.

The Essential References

Before we fix this, credit where credit is due. The Citrix documentation that actually helped:

The Fix: Configuring the LD_PRELOAD Allow List

First, open the App Protection allow list configuration file:

sudo nano /opt/Citrix/ICAClient/config/AppProtection_Preload_Allowlist.json

Add the following entries to diplomatically inform App Protection that these specific LD_PRELOAD patterns from Nextcloud are legitimate and shouldn't trigger its protective instincts:

{
  "LD_PRELOAD=/app/bin/../lib/libzypak-preload-host.so:/app/bin/../lib/libzypak-preload-host-spawn-strategy.so:/app/bin/../lib/libzypak-preload-host-spawn-strategy-close.so" : "Nextcloud",
  "LD_PRELOAD=/app/bin/../lib/libzypak-preload-child.so:/app/bin/../lib/libzypak-preload-child-spawn-strategy.so" : "/app/lib/com.nextcloud.talk/Nextcloud",
  "LD_PRELOAD=/app/bin/../lib/libzypak-preload-child.so:/app/bin/../lib/libzypak-preload-child-spawn-strategy.so" : "/app/lib/com.nextcloud.talk/Nextcloud"
}

What do these entries mean?

Each line maps a specific LD_PRELOAD pattern to the application that uses it. The first entry handles Nextcloud's main process, while the second handles child processes. By adding these to the allow list, App Protection will graciously step aside and allow your virtual desktop connections to proceed without further interrogation.

Bonus: Finding Your Own LD_PRELOAD Patterns

If you're dealing with other applications that get blocked, here's a handy script to identify which processes are using LD_PRELOAD on your system (copied from the linked documentation):

#!/bin/bash
for pid in /proc/*/; do
    pid=${pid%*/}
    pid=${pid##*/}
    environ_file="/proc/$pid/environ"

    if [[ ! -f "$environ_file" ]]; then
        continue
    fi

    ld_preload_entry=$(tr '\0' '\n' < "$environ_file" | grep -w "LD_PRELOAD")
    if [[ -n "$ld_preload_entry" ]]; then
        cmdline_file="/proc/$pid/cmdline"
        cmdline=$(tr '\0' ' ' < "$cmdline_file" | awk '{print $1}')
        echo "\"$ld_preload_entry\" : \"$cmdline\""
    fi
done

This script scans all running processes and outputs the exact format you need for the allow list configuration.

Apply the Changes

Once you've updated the configuration file, restart the App Protection service:

sudo systemctl restart AppProtectionService-install.service

Et voilà! Harmony restored. Error banished, virtual desktop connection established, and you can finally keep Nextcloud running on your host machine while accessing your work environment without any diplomatic incidents.

Pro tip: Document this fix somewhere you'll actually remember to look. Future you will thank present you when setting up a new machine or after a product update kindly resets your allow list. This post is basically my way of creating searchable breadcrumbs for anyone (including future me) who encounters that cryptic error message and wonders why Nextcloud seems to be the culprit.

🚀 New Release: antispy SDK 2025.1.0

2025-04-22T00:00:00+00:00

I work on system insights and observability with the uberAgent team at Citrix. Outside work, Rene Windegger and I maintain the antispy SDK. We have worked on it for six years, and version 2025.1.0 is now available.

What began as a weekend experiment to confuse disassemblers has grown into an SDK for developers who want to make binary analysis more difficult.

What's New?

📚 Comprehensive Documentation

We've documented everything-every macro, every intricate detail of the virtual machine, and even the obscure compile-time tricks. Explore it all at antispy.xyz/docs. Plus, you can test examples live.

✨ Compiler Explorer Integration

Meet play.antispy.xyz, your in-browser playground for experimenting with the SDK. Adjust macros, tweak compile options, and analyze disassembly to your heart's content. Think of it as godbolt, but tailored for the paranoid.

Example

Explore the demo showcasing libantispy::encrypted_ptr, a feature that compiles into 22 basic blocks of obfuscated code-serious protection in action.

#include <antispy/libantispy.h>

int main() {
    libantispy::encrypted_pointer<int> ptr;
}

Try it yourself: play.antispy.xyz - libantispy::encrypted_pointer

Unlike libantispy::encrypted_pointer, the standard std::shared_ptr behaves quite differently, as demonstrated below:

After all, std::shared_ptr isn't designed to be obfuscated, is it?

🧠 Constexpr Code Generation

The antispy virtual machine now supports full compile-time constexpr functionality. Transform data, encrypt logic, and generate obfuscation layers-all before runtime. Who needs CPU cycles anyway?

⚙️ Updated Toolchains

We've modernized everything so you don't have to:

Android + iOS SDKs: ✅
Outdated compilers: 🪦
Legacy baggage: 🔥

If you're still using GCC 4.x, well, good luck.

Why antispy SDK?

The antispy SDK is useful for high-assurance binaries, anti-reversing work, or experiments with disassemblers. It includes documentation and a live explorer so you can try the available techniques before adding them to a project.

Platforms & Architectures

The antispy SDK supports the following major compilers and CPU architectures when C++20 is available:

Windows: x86, x64, ARM64
Linux: x86, x64, ARM64
macOS: ARM and Intel
iOS: Including tvOS, watchOS, visionOS
Android: x86, x86_64, armeabi-v7a, armv8a
Bare Metal SOCs: Fully supported

This gives you the same API across the supported platforms.

TL;DR: If C++ metaprogramming excites you and you believe binaries should fight back, this SDK is your perfect match.

Got feedback, feature requests? Let us know-we're probably not sleeping anyway.

Simplify SSH

2024-10-03T00:00:00+00:00

Why, You Ask?

I was tired of entering my SSH key passphrase every time I connected to a server. The setup below lets ssh-agent remember it for the current terminal session and also keeps host settings in one place.

It's time-consuming and frustrating. I'm tired of it.

Getting Started

So, you've got your shiny new SSH key and every time you want to connect to a server, you're greeted with that ever-familiar password prompt. Sure, typing your SSH key passphrase every time is good for security, but, come on - who wants to do that? I mean, I don't know about you, but I've got enough passwords to remember without constantly dealing with this nonsense.

Let's save ourselves some time and effort by getting the SSH agent to remember our keys for us. That way, you can just run your commands like the seasoned developer you are without worrying about the whole "password entering" thing every single time.

Step 1: Start the SSH Agent

First things first - let's get the SSH agent up and running. It's like your personal SSH butler, here to remember your key so you don't have to.

Open up your terminal and type:

eval $(ssh-agent -s)

Boom! Now the agent is running in the background, ready to hold your keys like the responsible little daemon it is.

Step 2: Add your key to the SSH Agent

Now that the agent is up, let's give it your key. You only need to do this once per session, and the agent will keep it ready for you.

ssh-add ~/.ssh/your_key

Replace your_key with the name of your private key file. Enter the passphrase once and ssh-agent will remember it for the rest of the terminal session.

Step 3: Configure your SSH setup to be even lazier (I mean efficient)

Okay, we've got the agent running and the key added, but we can take it one step further. Why not tell SSH exactly what key to use for which server, so you never have to worry about it picking the wrong one?

To do this, we're going to set up a ~/.ssh/config file. If you don't have this file yet, don't worry - it's as easy as creating it:

touch ~/.ssh/config

Now, crack open that file with your favorite text editor and set things up like this:

Host your-server-alias
    HostName your.server.com
    User your-username
    IdentityFile ~/.ssh/your_key
    IdentitiesOnly yes

Breaking it down

Host: You can use any alias here that makes sense to you. This is what you'll type when you want to connect to this server.
HostName: The actual domain or IP address of the server.
User: Your username on that server, so you do not have to specify it each time.
IdentityFile: The path to your SSH private key.
IdentitiesOnly yes: Tells SSH to use only this key, rather than trying every key it can find in the agent (which is how you avoid that annoying "user mismatch" issue).

Step 4: Create a wrapper script for SSH Agent control

Alright, you want control over when your SSH agent starts up - totally understandable! Instead of running the agent automatically on login (which might feel a bit too autonomous), we'll create a neat little wrapper script. You can trigger it whenever you feel like starting the agent and adding your SSH key for the session.

Here's how to set that up.

Create the wrapper script

Let's create a script that starts the SSH agent, adds your key, and gives you control over when it runs. We'll call this script init-ssh, and we'll stick it somewhere like /usr/local/bin so it's available from anywhere in your terminal.

Create the script: Open your terminal and create the init-ssh script:
```
sudo nano /usr/local/bin/init-ssh
```

Add the script content: Paste the following content into the file:

#!/bin/bash

# Start the SSH agent
eval $(ssh-agent -s)

# Add the key to the agent
ssh-add ~/.ssh/your_key

# Optional: Display agent status for peace of mind
ssh-add -l

Make the script executable: Give the script executable permissions:
```
sudo chmod +x /usr/local/bin/init-ssh
```

How to use the script

Whenever you want to start your SSH agent for a session, just run:

. init-ssh

This will start the agent, add your key, and show you a list of the keys currently loaded in the agent. You've got full control - start the agent when you want, stop it when you're done, and enjoy a password-free SSH experience for the duration of that session.

Optional: Stopping the SSH Agent

If you want to stop the SSH agent after you're done with it, you can either let it die when you close your terminal or manually kill it with:

eval $(ssh-agent -k)

That way, you get all the convenience of an SSH agent when you need it, without it running indefinitely in the background. You're now in complete control of your SSH setup, and you can keep things secure and efficient, exactly the way you like it.

Happy SSH'ing!