discord: add Krisp patcher

[FlameFlag]

Krisp is Discord's proprietary noise cancellation feature. On nixpkgs it fails to load because patchelf/code signing changes cause the module's built-in signature verification to fail (see #195512)

This PR binary-patches discord_krisp.node to bypass the signature check, deploys the patched module to the user's Discord config dir at runtime, and handles macOS ad-hoc re-signing

There was a prior attempt (and this was inspired by it):

• discord: fix krisp module #290077 Binary-patched Krisp using hardcoded mangled C++ symbol names looked up via objdump. This approach technically works. Locating IsSignedByDiscord by its mangled symbol and patching it is functionally equivalent to what we do here.

The problem is maintenance: If the symbol gets stripped/renamed entirely (which Discord could do at any time), the approach breaks with no fallback. Also see #290077 (review)

Here is how my patch works (conceptually):

On ELF, the patcher finds a unique byte pattern in .text that corresponds to the MD5 comparison in the signature check (pmovmskb + cmp $0xffff), walks back to the function start, and overwrites it with mov eax, 1; ret

On Mach-O (macOS), it starts from the _SecStaticCodeCreateWithPath import stub and walks callers upward, each hop is the single unique caller of the previous target. When the chain fans out (multiple callers), we've found IsSignedByDiscord() and patch it to return true. Then re-sign with darwin.signingUtils

At runtime, deploy-krisp.py copies the patched module into the user's config dir before Discord starts. It uses a SHA-256 marker to skip redeployment on subsequent launches and to catch cases where vanilla Discord overwrites our files (macOS APFS case-insensitivity). On fresh installs it waits for Discord to bootstrap its core modules before writing to installed.json

I'm keeping it off by default tho, using Krisp with a modified Discord client probably violates Discord's ToS. But, using Vencord/Equicord/Moonlight already violates those same terms, so enabling Krisp alongside them doesn't introduce any new ToS risk

Closes #195512

Tested on NixOS and Nix-Darwin

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[vladdeSV]

does this go against Discord's TOS?

from the wiki regarding patching the binary:

Warning: The usage of such modifications goes against Discord's Terms of Service and Krisp's Terms of Use and can result in your Discord account being terminated and/or being banned from using Krisp's services!

if so, should this be in the official NixOS packages?

EDIT: totally missed it's off by default, my bad

[FlameFlag]

does this go against Discord's TOS?

if so, should this be in the official NixOS packages?

By this logic that would mean we would have to drop Vencord and Equicord and all other 3rd party Discord clients, as Discord doesn't allow any 3rd party clients or modifications

Practically nobody has ever been banned for using 3rd party clients or modifications (when used in "good faith"), Discord seemingly only cares that you don't hammer their API (which obv none of these stuff do)

EDIT: I re-read it again and as well I saw your edit, seems like we misunderstood each other, to clarify it's disabled by default ofc, and I said in PR itself, it's enabled implicitly by using 3rd party modification like Vencord or Equicord as you're knowingly breaking ToS anyways

[FlameFlag]

@ashuramaruzxc Thanks a lot for the review!

[ashuramaruzxc]

Some parts of the code regarding reading files and bytes could be improved but overall lgtm

[FlameFlag]

Now that #507728 is merged, this PR needed more than just conflict resolution

That PR changed how the non-stable Linux Discord packages are fetched/staged: PTB/Canary/Development now use Discord's distro/module packaging, and discord_krisp may come from source.modules.discord_krisp instead of a separate *-krisp entry in sources.json.

I updated this PR to support both worlds: legacy Krisp zips and distro module Krisp sources. For distro modules, Krisp can be a brotli-compressed tar module, so the patching path handles that too. When withKrisp is enabled we stage the other distro modules normally, but leave discord_krisp to the runtime deploy helper so the patched module is the one Discord sees

For the relevant changes please look at: 1c52ef9 (I squashed it out because I wanted it to purely serves as a clean diff)

[typedrat]

This heavily leaks memory on my system. Just leaving Discord open for a couple of hours with this enabled, the Python script ends up consuming around ~40 GB of RAM.

[alper-han]

This heavily leaks memory on my system. Just leaving Discord open for a couple of hours with this enabled, the Python script ends up consuming around ~40 GB of RAM.

This might not be related to this.

I’m experiencing a similar issue when screen sharing is active while using Vesktop. I don’t think this is related to this PR.

[typedrat]

This heavily leaks memory on my system. Just leaving Discord open for a couple of hours with this enabled, the Python script ends up consuming around ~40 GB of RAM.

This might not be related to this.

I’m experiencing a similar issue when screen sharing is active while using Vesktop. I don’t think this is related to this PR.

No, it's specifically the Python script added in this PR, which I've pulled in as a patch against my nixpkgs.

[ashuramaruzxc]

No, it's specifically the Python script added in this PR, which I've pulled in as a patch against my nixpkgs.

Please provide your system information,
kernel version,
discord version, etc
and steps to reproduce

I've tried keeping discord open with this patch already over 30 hours and it doesn't seem to leak memory with this patch on both x86_64-linux and aarch64-darwin

[FlameFlag]

This heavily leaks memory on my system. Just leaving Discord open for a couple of hours with this enabled, the Python script ends up consuming around ~40 GB of RAM.

I couldn't really replicate this on my side, but I added a fix for what looks like the likely cause. Even aside from the memory issue, this should be the more correct watcher behavior

[koffydrop]

It seems to be fixed on my end

[typedrat]

Can confirm this fixed my issues.

[koffydrop]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 506089
Commit: 3327261e53f551e4b4393ef3d6ac660976c19a1d

---

x86_64-linux

✅ 4 packages built:

• discord
• discord-canary
• discord-development
• discord-ptb

[koffydrop]

Approved automatically following the successful run of nixpkgs-review.

[FlameFlag]

nixpkgs-review result

Generated using nixpkgs-review-gha

Command: nixpkgs-review pr 506089
Commit: 3327261e53f551e4b4393ef3d6ac660976c19a1d (subsequent changes)
Merge: 8999d9638e92c733682680a177732c5d85c53333

Logs: https://github.com/FlameFlag/nixpkgs-review-gha/actions/runs/25623268452

---

x86_64-linux

✅ 4 packages built:

• discord
• discord-canary
• discord-development
• discord-ptb

---

aarch64-linux

✅ No rebuilds

---

x86_64-darwin (sandbox = relaxed)

✅ 4 packages built:

• discord
• discord-canary
• discord-development
• discord-ptb

---

aarch64-darwin (sandbox = relaxed)

✅ 4 packages built:

• discord
• discord-canary
• discord-development
• discord-ptb