RevokeMsgPatcher rewrites WeChat and QQ binaries in place, and the next client update takes it back

The patch rewrites WeChatWin.dll and IM.dll on disk

The mechanism is direct binary editing rather than a network proxy or a loader. Selecting anti-recall causes the tool to modify WeChat's WeChatWin.dll and, for QQ and TIM, their IM.dll. The two file names are named outright in the usage notes, which is unusual candour for this kind of tool, and it tells you exactly what your antivirus is reacting to. Because the target is a vendor signed library, security software will usually raise a warning, and the project's instruction is to allow it. That is the cost of the approach rather than an accident: you are being asked to trust a modified signed library, and the trade is permanent until the client is replaced. There is no separate runtime component, no service, and no account to create.

A client update silently reverts everything, and nothing re-applies it

The single most important line in the usage notes is the reminder that after WeChat, QQ, or TIM updates, the patch has to be installed again. Because the edit is written into the installed files, an update overwrites the modified DLL with the vendor copy and the behaviour returns to stock without any error. Nothing in the project schedules or watches for that, and no background re-patching is described. For a user this is the difference between a tool you use once and a tool you maintain. You find out about it the slow way, when a message you expected to still be there has disappeared, and there is no indicator in the client that a recall succeeded or was blocked. Treat the patch as a state you re-verify after every update rather than a setting you set once.

There is no Mac or Linux build, and XP is explicitly out

The platform story is narrow and stated without hedging. The tool applies to the Windows versions of PC WeChat, QQ, and TIM, and the system requirement is Windows 7 or higher, with Windows XP explicitly not supported. Runtime requirements sit alongside it, .NET Framework 4.5.2 or later, and the notes warn that anything older may produce a program that does not respond when opened or fails outright. The consequence is that this solves exactly one problem on exactly one platform. If your messaging happens on a phone, on macOS, or on a Linux desktop, none of it applies, and there is no configuration that changes that because the tool operates on Windows PE binaries. Compatibility is also version specific rather than general, which is why a separate wiki page exists purely to track which client builds are supported.

The 2.0 QQNT dependency path was replaced, not extended

The release history shows the approach being swapped out rather than accumulated. Before version 2.0, anti-recall for QQNT depended on LiteLoaderQQNT, and the patching itself went through a DLLHijackMethod path, with two third party plugins integrated along the way, LL-plugin-list-viewer for viewing the plugin list and LiteLoaderQQNT-Anti-Recall. Version 2.1, released on 3 August 2025 and titled as the new QQNT anti-recall approach, takes its anti-recall signature from a different project entirely, NTQQAntiRecall. That means the LiteLoaderQQNT dependency is not part of how the current release works, and anything you read about the pre-2.0 method describes a tool you no longer have. The same pattern applies on the WeChat side, where post-4.0 anti-recall features come from BetterWX.

The author frames the project as carrying features over, not finding methods

There is a line in the credits worth reading as scope rather than modesty: the author states they do not participate in finding the method and only carry features over. The early content came from a separate project, wechat_anti_revoke, and the current signatures are attributed to NTQQAntiRecall and BetterWX. What this means in practice is that RevokeMsgPatcher is a packaging and delivery layer. It bundles the technique, the discovery of the install paths, the registry lookup, the admin elevation, and the download, rather than originating the offset hunting. That is a real strength if you want a working result with one click, and it is a real limit if a new client version shifts the signature, because the person most able to re-derive it is not necessarily the person who shipped the binary.

Registry lookup covers installer builds, portable builds need a manual path

Path resolution is the step that decides whether the first run is easy or fiddly. For standard installer versions of WeChat, QQ, or TIM, the tool reads the install location from the registry on its own, so step four of the usage notes is usually a confirmation rather than a task. Portable or green-field installs, referred to as the portable build, are not registered anywhere the tool can look, so you have to select the path by hand. The rest of the sequence is fixed: close WeChat, QQ, and TIM first, then launch the program as administrator and wait while it fetches the latest patch information into the bottom right corner. The interface is expected to stop responding for a while after you click anti-recall, which the notes attribute to the write operation rather than to a hang.

The multi-instance tool is a separate project inside the same solution

Running more than one WeChat account at once is bundled, but as its own unit of work rather than a checkbox in the main window. The multi-instance capability ships alongside, and only alongside, WeChat support, and it lives in its own directory, RevokeMsgPatcher.MultiInstance, alongside three other projects in the Visual Studio solution, RevokeMsgPatcher itself, RevokeMsgPatcher.Assistant, and RevokeMsgPatcher.Launcher. The wiki also has a dedicated page for the WeChat anti-recall and multi-instance walkthrough, separate from the QQ and TIM page, which tells you the two topics are documented on their own terms. The assistant and launcher projects are the packaging and update shell, and continuous integration runs on AppVeyor with the configuration held in appveyor.yml, which is a normal arrangement for a Windows only .NET tool.

Release 2.1 predates the last push by more than a year

The two dates to keep straight are the release date and the commit date. The most recent tagged build is version 2.1, dated 3 August 2025, and the download link in the project points at that specific archive, RevokeMsgPatcher.v2.1.zip, served from the GitHub releases download path. The last push to the master branch landed on 16 August 2026, so code in the repository has moved in the year since that zip was produced without a new tag. Backups exist as well, on a Chinese file host with the password coco and on Baidu netdisk with the extraction code 3rrj, which is worth noting if the primary link is slow from your network. The practical reading is that the artifact you download is older than the source you are reading, and a difference between them is not something the project currently explains.

Editorial conclusion

RevokeMsgPatcher makes sense for a single Windows user who keeps losing messages that other people retract and can live with reapplying the patch after every client update. It does not make sense as a managed or shared setup, since the change lands in a signed vendor binary with no rollback script, and it does not help anyone outside Windows or on an unsupported client build. Before running it, confirm the specific client version appears on the wiki page named for supported versions, close the client rather than patching a live install, and decide in advance how you feel about telling your antivirus to allow a modified system library, because that instruction is part of the documented procedure rather than an optional extra.

Frequently asked questions

Official sources

1. huiyadanli/RevokeMsgPatcher on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases