Following the trail of Calif’s “WeWorm” research
Could AI find a vulnerability automatically by analyzing a software patch? If so, how accurate would it be — and would it still need human intervention?
Recently, Calif published a write-up on a zero-click vulnerability in WeChat that could lead to remote code execution.
Their post gave us only a few clues: the bug was a memory corruption issue in WeChat’s VoIP stack, but the technical details were intentionally left out.I searched around to see whether anyone else had analyzed the vulnerability, but I could find almost nothing publicly available. No root cause, no patch analysis, no proof of concept — not even much speculation.
That was enough to get me curious.If the vulnerable and patched versions were both available, could an LLM work backward from the patch and figure out what the vulnerability was? So I decided to give it a try.
Get the Before-and-After Versions
From Calif’s post, we knew that WeChat 8.0.76 was vulnerable and that the issue was fixed in 8.0.77. Those gave us the two versions we needed for the patch diff.
Historical WeChat APKs are available from this GitHub repository: https://github.com/DJB-Developer/wechat-android-history-versions
Diff the patch
I extracted the two versions into separate folders and started using Diaphora to compare the native libraries. That immediately led to the first challenge: some of the .so files were several megabytes in size, and a full Diaphora diff could take hours.
Instead of waiting for every comparison to finish, I exported the Diaphora .sqlite databases for each version and left the actual comparison to the LLM.
Let the LLM Analyze the Changes
I kept the setup simple. I actually started with Claude Code（CC) using Opus 5, but that experiment ended almost immediately — the request was rejected under its cyber safety classification.
So I fell back to Opus 4.6 and continued from there, using CC together with Binary Ninja 6.0, which has built-in MCP support, for the reverse-engineering work.
I gave the LLM the two exported Diaphora .sqlite databases and asked it to analyze the changes between the vulnerable and patched versions.
Realize It Went Down the Wrong Path
After a few hours of analysis, Claude Code came back with its first “vulnerability.” I was excited, but I wasn’t fully convinced that it was the actual issue fixed by the patch. So I asked it to dig deeper.
After about another hour of analysis, Claude Code eventually concluded that its first theory was wrong.
It then changed its strategy and spent a few more hours exploring a different path. This time, it came back with another interesting theory and was much more confident that it had found the vulnerability.
I checked the reasoning myself. The theory depended on one important assumption — and my instinct was that the assumption might be wrong.
Back on Track
After two consecutive failures, I was starting to feel a little disappointed. More importantly, I was seeing what may be one of the most dangerous failure modes of an LLM in reverse engineering: it can produce an explanation that sounds completely plausible, then keep building on top of it and drift further and further away from the real problem.
At that point, I decided to step in and give it one simple direction: start from what the attacker can actually control.
That completely changed the investigation!
After another couple of hours, Claude Code came back with a surprise: this time, it had found the real vulnerability — in a file I had not expected at all.
Calif has said that they are intentionally withholding the technical details for now and plan to present the full analysis at an upcoming conference. Out of respect for that disclosure timeline, I’m not going to reveal the root cause or exploit details here. But I’ll leave one small hint: it involves a word you would probably expect to see in a machine-learning paper more often than in a VoIP vulnerability report.
Lessons Learned
Looking back, this experiment left me with three takeaways.
1. LLMs can significantly accelerate vulnerability analysis.
They are extremely useful for processing large amounts of code, comparing changes, generating hypotheses, and exploring multiple paths quickly. Used well, they can compress hours of manual work into a much faster investigation loop.
2. Humans still need to set the direction.
LLMs are very good at exploring once the search space is defined, but they are much less reliable at deciding which direction is worth exploring in the first place.
A simple analogy is travel: if you want to get from one city to another, the LLM can help optimize the route, compare connections, and work through all the details — but someone still needs to decide whether the journey should start by taking a plane, a train, or driving in the opposite direction.
In this investigation, that meant stepping back from the model’s theories and asking a more fundamental question: what can the attacker actually control? Once that direction was set, the analysis moved forward again.
3. The most dangerous answer is not a wrong answer — it is a plausibly correct one.
A clearly wrong answer is easy to reject. A plausible one is much more dangerous. An LLM can take a weak assumption, build a coherent explanation around it, find evidence that seems to support it, and become increasingly confident in the story it has created.
That is exactly what happened during this investigation. The model was not producing nonsense. It was producing theories that were reasonable enough to keep following — and that is what made them dangerous.
In Chinese, there is a phrase I like for this: “自我感动” — becoming increasingly convinced by a story simply because it feels right.
And with LLMs, sometimes 自我感动常在.
Reference
Calif Research. “WeWorm.” September 8, 2026.
Original research post
Leave a Reply