SovietExtension: a Mac WeChat 4.0 plugin that patches the app binary

What SovietExtension actually patches, and who it is for

SovietExtension is a plugin for Mac WeChat 4.0 and later, written in Objective-C++ and released under the MIT licence. It targets one platform: macOS on Apple Silicon. The README is blunt about the second one: the author states they have no Intel machine, so the Intel build is not developed or tested and does not work. The repository topics list anti-revoke and hook, which describes the family of behaviour the plugin implements rather than a single feature.

The audience is narrow by design. The README says the project is for learning, research and personal tinkering, and that it accepts no issues other than bug reports and no donations of any kind. That is not a support commitment in the usual open source sense. If you need a plugin with a maintainer who will answer configuration questions, this is not it.

The repository itself is small: a README, a LICENSE, several PNG and GIF screenshots, and a SovietExtension directory that holds the Rely folder with install.sh, uninstall.sh, insert_dylib, a supported_versions.txt file and the built framework. There is no package manager manifest at the top level, no CI configuration and no test directory.

How the install script injects the framework into WeChat.app

The mechanism is binary patching, not a plugin API. WeChat on macOS does not expose a supported extension point, so SovietExtension takes the other route: it copies a compiled framework into the application bundle and adds a load command that makes the dynamic loader pull it in at startup.

The install script prints its own variables as it runs, and those names describe the data flow precisely. APP_PATH is /Applications/WeChat.app. PLUGIN_SRC_PATH points at Rely/Plugin/SovietExtension.framework inside the repository. FRAMEWORK_DST_PATH is /Applications/WeChat.app/Contents/MacOS/SovietExtension.framework, so the framework lands in the MacOS directory next to the main executable. INSERT_DYLIB_PATH is the bundled insert_dylib binary, and LOAD_DYLIB_PATH is @executable_path/SovietExtension.framework/SovietExtension, the relative path recorded in the load command.

Before any of that, the script reads CFBundleShortVersionString and CFBundleVersion from the installed WeChat and matches them against Rely/supported_versions.txt. The sample output shows a rule line in the form 4.1.9.58|4.1.9|268602|Tested on Mac WeChat 4.1.9.58, which means the match is on the full display version, the short version and the build number together. Only then does it copy and inject.

The last visible step is a code signature check. In the sample output the script reports that signature verification failed but notes the app may still run for debugging. That is the central trade-off of the whole approach: modifying the bundle invalidates the signature, and the project proceeds anyway.

Installing SovietExtension: open WeChat once, then run install.sh

The README gives one prerequisite before anything else: if WeChat was just installed, open it manually once first. Without that step the README warns the app may report that it is damaged and cannot be opened after the plugin is installed.

Installation is a shell script inside the Rely folder. From the repository root, the README's first form is:

cd SovietExtension/Rely
sh install.sh

The README also gives the absolute-path form, which is what its sample terminal session uses:

sh /Users/mustangym/SovietExtension/SovietExtension/Rely/install.sh

Expect a banner, then a detected-version block showing CFBundleShortVersionString and CFBundleVersion, then either a version check pass with the matched rule or a failure. On success the script prints the log and uninstall commands. The README's own example ends with:

rm -f /tmp/YMWeChatAntiRevokePatch.log
open -a WeChat
tail -f /tmp/YMWeChatAntiRevokePatch.log

That sequence clears the old log, launches WeChat and follows the plugin's log file at /tmp/YMWeChatAntiRevokePatch.log. If WeChat shows a permission prompt on first launch after install, the README says to follow it. If the script fails with cp: ... Operation not permitted, the fix is in System Settings, Privacy and Security: grant Full Disk Access and Files and Folders to whichever terminal you ran the script from. The README lists Terminal, iTerm2, VSCode, Cursor and Warp as common cases, and the rule is that the tool you actually used needs the permission.

To confirm which WeChat you have before installing, the troubleshooting section gives two commands:

defaults read /Applications/WeChat.app/Contents/Info.plist CFBundleShortVersionString
defaults read /Applications/WeChat.app/Contents/Info.plist CFBundleVersion

Compare both values against the supported table. A matching major version is not enough; the README states that the same large version number can hide a different build number, and a different build may not work.

The supported-version table is the real constraint

This is the part that decides whether the project is usable for you, and it is stricter than most plugin projects. The README lists exactly two WeChat builds: 4.1.11.23 with build 269079, marked as tested by release 1.1.2, and 4.1.10.53 with build 268853, described as the version downloaded from the official site as of 2026-06-19. Both rows are marked supported on Apple Silicon and unsupported on Intel.

Anything outside the table is explicitly not guaranteed. The README says other versions are adapted as chance allows, and asks users not to push. That is a maintenance posture, not a roadmap. WeChat 4.x moved to Qt, and the README says reverse engineering it is comparatively troublesome, which is the stated reason new builds are not tracked automatically.

There is a second failure mode that has nothing to do with versions. The install output shows a code signature warning. Once the framework is copied into the bundle and a load command is added, the app no longer matches its original signature. The README does not document what Gatekeeper or macOS updates do to a patched WeChat afterwards, and it does not describe a rollback path other than running the uninstall script. If your machine policy requires signed applications, this plugin is the wrong tool regardless of version.

Uninstalling, and what the README does not cover

Removal is a script, not a manual cleanup. From the Rely folder:

sh uninstall.sh

Or by absolute path, which is how the troubleshooting section presents it:

sh /Users/mustangym/SovietExtension/SovietExtension/Rely/uninstall.sh

The README recommends this first if WeChat will not open after installing. If it still will not open, the documented next step is to delete WeChat and reinstall the official version. Note what that implies: the recovery path of last resort discards the patched app entirely, so any local WeChat data you have not backed up is your responsibility, not the script's.

Beyond that, the documentation is thin in ways worth naming. The README does not document rollback of individual injected components, does not explain how to verify that the load command was removed, and does not describe what the plugin does at runtime beyond the anti-revoke topic and the effect screenshots. There is no changelog in the README, though the repository publishes releases. There is also no stated update procedure: nothing in the README tells you whether to uninstall before installing a newer plugin build over an older one.

Alternatives, and where the approach differs

The honest comparison is not another named plugin, because the README names none. It is the category the plugin belongs to: injecting a framework into a signed application bundle. The alternative approach in the same space is to leave WeChat.app untouched and run a separate process that observes or drives it from outside, or to use whatever extension points the vendor exposes.

The difference is concrete. SovietExtension's install.sh writes into /Applications/WeChat.app/Contents/MacOS and adds a load command pointing at @executable_path/SovietExtension.framework/SovietExtension. That is why the script needs Full Disk Access for your terminal, why the signature check fails, and why every WeChat update can invalidate the installation. An out-of-process tool would not touch the bundle and would not need those permissions, but it also could not hook code inside WeChat the way an injected framework can. You are trading installation friction and signature integrity for in-process access. Whether that trade is worth it depends entirely on whether your exact WeChat build is in the table.

A third option is simply not to patch WeChat at all. Given that the README restricts support to two builds and states that Intel is unsupported, that is a reasonable default for most people.

Licence and the cost of keeping up

The repository is MIT licensed. That permits use, modification and redistribution with the licence and copyright notice preserved. It says nothing about WeChat's own terms of service, and the README does not address that question. Distributing a patched WeChat.app, as opposed to the plugin source, is a different act from distributing the plugin, and the MIT licence does not speak to it. This is not legal advice; if you plan to redistribute anything beyond the repository contents, that is a question for someone qualified to answer it.

The upgrade cost is the version table. Each entry is a display version, a short version and a build number that the script matches together, so every WeChat update that is not already listed means waiting for a new rule in Rely/supported_versions.txt and a new release. The repository's recent releases, 1.4.1 and 1.4.0 and 1.3.1, all landed on 2026-09-17, and the last push to the repository was on 2026-09-17. The README states plainly that other versions are adapted as chance allows, so you should not read that activity as a commitment to track every WeChat build. If you depend on the plugin for daily use, budget for the periods when your WeChat version is ahead of the table and the plugin does not install.

Editorial conclusion

Adopt SovietExtension only if your Mac is Apple Silicon and your WeChat bundle version and build number appear in the repository's supported-versions table, and only if you accept that install.sh modifies WeChat.app in place and that uninstall.sh is the documented way back. Skip it on Intel Macs, on any WeChat build outside the table, and on machines where WeChat must stay code-signed and unmodified. Before installing, run defaults read /Applications/WeChat.app/Contents/Info.plist CFBundleVersion and compare the number against the table; if it does not match, stop there.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. MustangYM/SovietExtension on GitHub
4. README
5. Releases