Comments
By martinralbrecht 2026-01-3117:049 reply WhatsApp's end-to-end encryption has been independently investigated: https://kclpure.kcl.ac.uk/ws/files/324396471/whatsapp.pdf
Full version here: https://eprint.iacr.org/2025/794.pdf
We didn't review the entire source code, only the cryptographic core. That said, the main issue we found was that the WhatsApp servers ultimately decide who is and isn't in a particular chat. Dan Goodin wrote about it here: https://arstechnica.com/security/2025/05/whatsapp-provides-n...
> We didn't review the entire source code And, you don't see the issue with that? Facebook was bypassing security measures for mobile by sending data to itself on localhost using websockets and webrtc.
https://cybersecuritynews.com/track-android-users-covertly/
An audit of 'they can't read it cryptographically' but the app can read it, and the app sends data in all directions. Push notifications can be used to read messages.
> Push notifications can be used to read messages.
Are you trying to imply that WhatsApp is bypassing e2e messaging through Push notifications?
Unless something has changed, this table highlights that both Signal and WhatsApp are using a "Push-to-Sync" technique to notify about new messages.
https://crysp.petsymposium.org/popets/2024/popets-2024-0151....
By itsthecourier 2026-01-3120:381 reply Push-to-Sync. We observed 8 apps employ a push-to-sync strat- egy to prevent privacy leakage to Google via FCM. In this mitigation strategy, apps send an empty (or almost empty) push notification to FCM. Some apps, such as Signal, send a push notification with no data (aside from the fields that Google sets; see Figure 4). Other apps may send an identifier (including, in some cases, a phone num- ber). This push notification tells the app to query the app server for data, the data is retrieved securely by the app, and then a push notification is populated on the client side with the unencrypted data. In these cases, the only metadata that FCM receives is that the user received some message or messages, and when that push noti- fication was issued. Achieving this requires sending an additional network request to the app server to fetch the data and keeping track of identifiers used to correlate the push notification received on the user device with the message on the app server.
By fasbiner 2026-02-010:20 Nothing changed, but many people struggle to understand their our own degree of relative ignorance and overvalue high-level details that are leaky abstractions which make the consequentially dissimilar look superficially similar.
By vpShane 2026-02-033:59 No, I'm saying Meta can't be trusted.
By cookiengineer 2026-01-3120:552 reply Why did you not mention that the WhatsApp apk, even on non-google play installed devices, loads google tag manager's scripts?
It is reproducibly loaded in each chat, and an MitM firewall can also confirm that. I don't know why the focus of audits like these are always on a specific part of the app or only about the cryptography parts, and not the overall behavior of what is leaked and transferred over the wire, and not about potential side channel or bypass attacks.
Transport encryption is useless if the client copies the plaintext of the messages afterwards to another server, or say an online service for translation, you know.
Things like this combined with the countless ways to hide "feature flags" in a giant codebase makes me feel that anything less than "the entire app was verified + there is literally no way to dynamically load code from remote (so even no in app browser) + we checked 5 years of old versions and plan to do this for the next 5 years of update" is particularly meaningful.
Still very important but my issue has never been with zucks inability to produce solid software, rather in its intentions and so them being good engineers just makes them better at hiding bad stuff.
By cookiengineer 2026-02-0114:31 Back in the days people called skype [1] spyware because it had lots of backdoors in it and lots of undocumented APIs that shouldn't have been in there.
The funny part was that skype was probably the most obfuscated binary that was ever available as "legitimate" software, so there were regular reversing events to see "how far" you could get from scratch to zeroday within 48h hackathons. Those were fun times :D
[1] Skype, pre Microsoft rebrand of Lync as Skype
There's a whole section, early, in the analysis Albrecht posted that surfaces these concerns.
By cookiengineer 2026-01-3122:171 reply Where in the document is that? Can you provide a page number or section title?
By jibe 2026-02-012:31 ^f
Of particular note here is that while compromised WhatsApp servers could add arbitrary members to a group, each member's client would show the new member's presence and would not share prior messages, only future messages.
Now, of course, this assumes the client hasn't been simultaneously compromised to hide that. But it's defense in depth at the very least.
It is worth noting that this may be eroding as we speak: https://www.livemint.com/technology/tech-news/whatsapp-could... (Jan 24 2026) reports that Whatsapp is developing a way for one member to share historical messages en masse with a new group member. While this is manually triggered by the sender at the moment, it presents an enticing attack surface on technical, social-engineering, and political fronts to erode retroactive security much more rapidly going forward.
(And it goes without saying that if you think you're exempt from needing to worry about this because you're not involved in certain types of activity, the speed at which policies are evolving around the world, and the ability to rapidly process historical communications data at scale, should give you pause. "Ex post facto" is not a meaningful principle in the modern AI-enabled state.)
"People you send messages to have access to those messages. (And could therefore potentially share them with others.)" doesn't seem like a particularly scary security threat to me.
By btown 2026-02-0217:39 The threat here is that the ability of an attacker to add themselves to a thread, stacked with a new ability to either socially-engineer or otherwise attack an existing member to click a single share-history button, could result in disclosure of history without explicit intent to share.
By 1vuio0pswjnm7 2026-02-023:52 "We didn't review the entire source code, ..."
Why not
"Our work is based primarily on the WhatsApp web client, archived on 3rd May 2023, and version 6 of the WhatsApp security whitepaper [46]."
Did not even look at the continously changing mobile app, only looked at part of the minified Javascript in the web client
Not sure what this accomplishes. Are the encryption protocols used sound, is the implementation correct. Maybe, but the app is closed source and constantly changing
But users who care want to know about what connections the software makes, what is sent over those connections, to whom it is sent and why. There is no implicit trust as to Meta, only questions. The source code is hidden from public scrutiny
For example, the app tries to connect to {c,e8,e10,g}.whatsapp.net over TCP on port 80
The app has also tried to connect over UDP using port 3478/STUN
These connections can be blocked and the user will still be able to send and receive texts and make and receive calls
Meta forces users to install new mobile app, i.e., untrusted, unaudited code, multiple times per year. This install grows in size by over 100%
For example, there were at least four different apps (subsequent versions) forced on users in 2023, five in 2024 and four in 2025
In 2023 the first was 54.06MB. In 2026, it is now 126MB
By some_furry 2026-01-3117:122 reply Thank you for actually evaluating the technology as implemented instead of speculating wildly about what Facebook can do based on vibes.
Unfortunately a lot of investigations start out as speculation/vibes before they turn into an actual evaluation. And getting past speculation/vibes can take a lot of effort and political/social/professional capital before even starting.
Well yeah. If they had solid evidence at the start, why would they need an investigation?
By chaps 2026-02-0117:40 It's not as obvious of an answer as it initially sounds. Coming at this from a stint in investigative journalism where even beginning an investigation requires getting grants and grants involve convincing other people that the money is going to good use. Also having been told that an investigation I ran was nothing by multiple editors that turned out to be something big... it really shifted how I perceive investigations and what it means to stick your neck out when everyone's telling you that something isn't happening even when it is.
By afiori 2026-02-0116:05 Vibes are a perfectly solid ground to refuse to engage with something.
By Jamesbeam 2026-01-3123:33 Hello Professor Albrecht,
thank you for your work.
I’ve been looking for this everywhere the past few days but I couldn’t find any official information relating the use of https://signal.org/docs/specifications/pqxdh/ in the signal protocol version that WhatsApp is currently using.
Do you have any information if the protocol version they currently use provides post-quantum forward secrecy and SPQR or are the current e2ee chats vulnerable to harvest now, decrypt later attacks?
Thanks for your time.
By morshu9001 2026-01-3121:001 reply They also decide what public key is associated with a phone number, right? Unless you verify in person.
By NoahZuniga 2026-01-3123:231 reply That's protected cryptographically with key transparency. Anyone can check what the current published keys for a user are, and be sure they get the same value as any other user. Specifically, your wa client checks that these keys are the right key.
By morshu9001 2026-02-011:181 reply Even if your client is asking other clients to verify, what if everyone has the same wrong key for a particular user Whatsapp has chosen to spoof?
By NoahZuniga 2026-02-0112:021 reply Well, surely your client knows what its own key is, and would notice that the listed key is wrong when it checks it.
By morshu9001 2026-02-0117:161 reply They can also tell your client it has the correct key. Yours and the other clients are all talking to their mitm in this scenario. There's fundamentally no way to solve this without users verifying keys out-of-band.
By NoahZuniga 2026-02-020:111 reply > They can also tell your client it has the correct key.
No they can't. Key transparency cryptographically makes sure everyone gets the same result.
By morshu9001 2026-02-0220:041 reply Key transparency is a public list of keys, like what CAs do. That still trusts an authority. Of course a third party could archive/republish the key list and you could trust them instead of Whatsapp, but that's what I call an out of band key verification.
These are all good measures though. It's much harder for Whatsapp to mass attack users this way.
By NoahZuniga 2026-02-0311:36 Well, more than just that. For the published key transparency information to be trusted it has to not just be signed by WhatsApp, but also by an independent witness. In this case Cloudflare.
So for wa to do a man in the middle attack they would also need to convince Cloudflare to sign two inconsistent tree heads.
Signal protocol prevents replay attacks as every message is encrypted with new key. Either it's next hash ratchet key, or next future secret key with new entropy mixed via next DH shared key.
Private keys, probably not. WhatsApp is E2EE meaning your device generates the private key with OS's CSPRNG. (Like I also said above), exfiltration of signing keys might allow MITM but that's still possible to detect e.g. if you RE the client and spot the code that does it.
By uoaei 2026-02-0315:55 Whatsapp didn't implement Signal's protocol verbatim. They appropriated the core cryptographic security and then re-implemented the rest on their own servers. This removes all guarantees of secrecy as long as they can run arbitrary code on the servers they own.
By TurdF3rguson 2026-02-011:061 reply Wouldn't ratchet keys prevent MITM too? In other words if MITM has your keys and decrypts your message, then your keys are out of sync from now on. Or do I misunderstand that?
By maqp 2026-02-0110:12 The ratchets would have different state yes. The MITM would mix in different entropy into the keys' states. It's only detectable if the MITM ever stops. But since the identity key exfiltration only needs to happen once per lifetime of installation (longer if key is backed up), the MITM could just continue forever since it's just a few cycles to run the protocol in the server. You can then choose whether to read the messages or just ignore them.
One interesting way to detect this would be to observe sender's outgoing and recipient's incoming ciphertexts inside the client-to-server TLS that can be MITM'd by users. Since the ratchet state differs, so do the keys, and thus under same plaintext, so do the ciphertexts. That would be really easy way to detect MITM.
> We didn't review the entire source code
Then it's not fully investigated. That should put any assessments to rest.
By that standard, it can never be verified because what is running and what is reviewed could be different. Reviewing relevant elements is as meaningful as reviewing all the source code.
By dangus 2026-02-017:37 Let’s be real: the standard is “Do we trust Meta?”
I don’t, and don’t see how it could possibly be construed to be logical to trust them.
I definitely trust a non-profit open source alternative a whole lot more. Perception can be different than reality but that’s what we’ve got to work with.
By giancarlostoro 2026-01-3121:052 reply Or they could even take out the backdoor code and then put it back in after review.
By KellyCriterion 2026-01-3121:23 ++1
"target market product alignment" :-D
I have to assume you have never worked on security cataloging of third party dependencies on a large code base.
Because if you had, you would realize how ridiculous it is to state that app security can't be assessed until you have read 100% of the code
That's like saying "well, we don't know how many other houses in the city might be on fire, so we should let this one burn until we know for sure"
What you are saying is empirically false. Change in a single line of executed code (sometimes even a single character!) can be the difference between a secure and non-secure system.
This must mean that you have been paid not to understand these things. Or perhaps you would be punished at work if you internalized reality and spoke up. In either case, I don't think your personal emotional landscape should take precedence over things that have been proven and are trivial to demonstrate.
By JasonADrury 2026-02-018:32 > Change in a single line of executed code (sometimes even a single character!) can be the difference between a secure and non-secure system.
This is kind of pointless, nobody is going to audit every single instruction in the Linux kernel or any complex software product.
By jokersarewild 2026-01-3123:061 reply It sounds like your salary has depended on believing things like a partial audit is worthwhile in the case that a client is the actual adversary.
By charcircuit 2026-01-3123:541 reply Except Meta is not an adversary. They are aligned with people who want private messaging.
By mikkupikku 2026-02-011:34 Brutal sarcasm.
as long as client side encryption has been audited, which to my understanding is the case, it doesn't matter. That is literally the point of encryption, communication across adversarial channels. Unless you think Facebook has broken the laws of mathematics it's impossible for them to decrypt the content of messages without the users private keys.
Well the thing is, the key exfiltration code would probably reside outside the TCB. Not particularly hard to have some function grab the signing keys, and send them to the server. Then you can impersonate as the user in MITM. That exfiltration is one-time and it's quite hard to recover from.
I'd much rather not have blind faith on WhatsApp doing the right thing, and instead just use Signal so I can verify myself it's key management is doing only what it should.
Speculating over the correctness of E2EE implementation isn't productive, considering the metadata leak we know Meta takes full advantage of, is enough reason to stick proper platforms like Signal.
> That exfiltration is one-time and it's quite hard to recover from.
Not quite true with Signal's double ratchet though, right? Because keys are routinely getting rolled, you have to continuously exfiltrate the new keys.
No I said signing keys. If you're doing MITM all the time because there's no alternative path to route ciphertexts, you get to generate all those double-ratchet keys. And then you have a separate ratchet for the other peer in the opposite direction.
Last time I checked, by default, WhatsApp features no fingerprint change warnings by default, so users will not even notice if you MITM them. The attack I described is for situations where the two users would enable non-blocking key change warnings and try to compare the fingerprints.
Not saying this attack happens by any means. Just that this is theoretically possible, and leaves the smallest trail. Which is why it helps that you can verify on Signal it's not exfiltrating your identity keys.
By jcgl 2026-02-0110:01 Ah right, I didn't think about just outright MitMing from the get-go. If WhatsApp doesn't show the user anything about fingerprints, then yeah, that's a real hole.
Not that I trust Facebook or anything but wouldn’t a motivated investigator be able to find this key exfiltration “function” or code by now? Unless there is some remote code execution flow going on.
By impure-aqua 2026-01-3121:492 reply WhatsApp performs dynamic code loading from memory, GrapheneOS detects it when you open the app, and blocking this causes the app to crash during startup. So we know that static analysis of the APK is not giving us the whole picture of what actually executes.
This DCL could be fetching some forward_to_NSA() function from a server and registering it to be called on every outgoing message. It would be trivial to hide in tcpdumps, best approach would be tracing with Frida and looking at syscalls to attempt to isolate what is actually being loaded, but it is also trivial for apps to detect they are being debugged and conditionally avoid loading the incriminating code in this instance. This code would only run in environments where the interested parties are sure there is no chance of detection, which is enough of the endpoints that even if you personally can set off the anti-tracing conditions without falling foul of whatever attestation Meta likely have going on, everyone you text will be participating unknowingly in the dragnet anyway.
"Many forms of dynamic code loading, especially those that use remote sources, violate Google Play policies and may lead to a suspension of your app from Google Play."
https://developer.android.com/privacy-and-security/risks/dyn...
I wonder if that would deter Meta.
By monocasa 2026-02-010:34 Some apps have always been more equal than others.
By oofbey 2026-01-3122:20 I don’t know these OS’s well enough. Can you MitM the dynamic code loads by adding a CA to the OS’s trusted list? I’ve done this in Python apps because there’s only 2 or 3 places that it might check to verify a TLS cert.
By maqp 2026-01-3122:05 >Not that I trust Facebook or anything but wouldn’t a motivated investigator be able to find this key exfiltration “function” or code by now?
Yeah I'd imagine it would have been found by know. Then again, who knows when they'd add it, and if some future update removes it. Google isn't scanning every line for every version. I prefer to eliminate this kind of 5D-guesswork categorically, and just use FOSS messaging apps.
By hn_throwaway_99 2026-01-3121:06 The issue is what the client app does with the information after it is decrypted. As Snowden remarked after he released his trove, encryption works, and it's not like the NSA or anyone else has some super secret decoder ring. The problem is endpoint security is borderline atrocious and an obvious achilles heel - the information has to be decoded in order to display it to the end user, so that's a much easier attack vector than trying to break the encryption itself.
So the point other commenters are making is that you can verify all you want that the encryption is robust and secure, but that doesn't mean the app can't just send a copy of the info to a server somewhere after it has been decoded.
By coppsilgold 2026-01-3121:192 reply No closed-source E2EE client can be truly secure because the ends of e2e are opaque.
Detecting backdoors is only truly feasible with open source software and even then it can difficult.
A backdoor can be a subtle remote code execution "vulnerability" that can only be exploited by the server. If used carefully and it exfiltrates data in expected client-server communications it can be all but impossible to detect. This approach also makes it more likely that almost no insider will even be aware of it, it could be a small patch applied during the build process or to the binary itself (for example, a bound check branch). This is also another reason why reproducible builds are a good idea for open source software.
With all due respect to Stallman, you can actually study binaries.
The claim Stallman would make (after punishing you for using Open Source instead of Free Software for an hour) is that Closed Software (Proprietary Software) is unjust. but in the context of security, the claim would be limited to Free Software being capable of being secure too.
You may be able to argue that Open Source reduces risk in threat models where the manufacturer is the attacker, but in any other threat model, security is an advantage of closed source. It's automatic obfuscation.
There's a lot of advantages to Free Software, you don't need to make up some.
By sigmoid10 2026-01-3121:39 This. Closed source doesn't stop people from finding exploits in the same way that open source doesn't magically make people find them. The Windows kernel is proprietary and closed source, but people constantly find exploits in it anyways. What matters is that there is a large audience that cares about auditing. OTOH if Microsoft really wanted to sneak in a super hard to detect spyware exploit, they probably could - but so could the Linux kernel devs. Some exploits have been openly sitting in the Linux kernel for more than a decade despite everyone being able to audit it in theory. Who's to say they weren't planted by some three letter agency who coerced a developer. Relying on either approach is pointless anyways. IT security is not a single means to all ends. It's a constant struggle between safety and usability at every single level from raw silicon all the way to user-land.
By tptacek 2026-01-3121:56 It's weird to me that it's 2026 and this is still a controversial argument. Deep, tricky memory corruption exploit development is done on closed-source targets, routinely, and the kind of backdoor/bugdoor people conjure in threads about E2EE are much simpler than those bugs.
It was a pretty much settled argument 10 years ago, even before the era of LLVM lifters, but post-LLM the standard of care practice is often full recompilation and execution.
By objclxt 2026-01-3121:53 > in any other threat model, security is an advantage of closed source
I think there's a lot of historical evidence that doesn't support this position. For instance, Internet Explorer was generally agreed by all to be a much weaker product from a security perspective than its open source competitors (Gecko, WebKit, etc).
Nobody was defending IE from a security perspective because it was closed source.
By refulgentis 2026-01-3121:311 reply This comment comes across as unnecessarily aggressive and out of nowhere (Stallman?), it's really hard to parse.
Does this rewording reflect it's meaning?
"You don't actually need code to evaluate security, you can analyze a binary just as well."
Because that doesn't sound correct?
But that's just my first pass, at a high level. Don't wanna overinterpret until I'm on surer ground about what the dispute is. (i.e. don't want to mind read :) )
Steelman for my current understanding is limited to "you can check if it writes files/accesses network, and if it doesn't, then by definition the chats are private and its secure", which sounds facile. (presumably something is being written to somewhere for the whole chat thing to work, can't do P2P because someone's app might not be open when you send)
https://www.gnu.org/philosophy/free-sw.html
Whether the original comment knows it or not, Stallman greatly influenced the very definition of Source Code, and the claim being made here is very close to Stallman's freedom to study.
>"You don't actually need code to evaluate security, you can analyze a binary"
Correct
>"just as well"
No, of course analyzing source code is easier and analyzing binaries is harder. But it's still possible (feasible is the word used by the original comment)
>Steelman for my current understanding is limited to "you can check if it writes files/accesses network, and if it doesn't, then by definition the chats are private and its secure",
I didn't say anything about that? I mean those are valid tactics as part of a wider toolset, but I specifically said binaries, because it maps one to one with the source code. If you can find something in the source code, you can find it in the binary and viceversa. Analyzing file accesses and networks, or runtime analysis of any kind, is going to mostly be orthogonal to source code/binary static analysis, the only difference being whether you have a debug map to source code or to the machine code.
This is a very central conflict of Free Software, what I want to make clear is that Free Software refuses to study closed source software, not because it is impossible, but because it is unjustly hard. Free Software never claims it is impossible to study closed source software, it claims that source code access is a right, and they prefer rejecting to use closed source software, and thus never need to perform binary analysis.
Binaries absolutely don't map one-to-one with source code. Compilers optimize out dead code, elide entire subroutines to single instructions, perform loop unrolling and auto-vectorization, and many many more optimizations and transformations that break exact mapping.
By TZubiri 2026-02-024:57 That is true, but I don't think I ever said that binaries map one-to-one with source code.
I was referring to source code to binary maps, these are files that map binary locations to source code locations. In C (gcc/gdb) these are debug objects, they are also used in gdb style debuggers like Python's pdb, Java's jdb. They also exist in js/ts when using minifiers or react, so that you are able to debug in production.
By singpolyma3 2026-01-3121:453 reply I was with you until you somehow claimed obfuscation can improve security, against all historical evidence even pre-computers.
By Arch-TK 2026-01-3121:54 Obscurity is a delay tactic which raises the time cost associated with an attack. It is true that obscurity is not a security feature, but it is also true that increasing the time cost associated with attacking you is a form of deterrant from attempts. If you are not at the same time also secure in the conventional sense then it is only buying you time until someone puts in the effort to figure out what you are doing and own you. And you better have a plan for when that time comes. But everyone needs time, because bugs happen, and you need that time to fix them before they are exploited.
The difference between obscurity and a secret (password, key, etc) is the difference between less then a year to figure it out and a year or more to figure it out.
There is a surprising amount of software out there with obscurity preventing some kind of "abuse" and in my experience these features are not that strong, but it takes someone like me hours to reverse engineer these things, and in many cases I am the first person to do that after years of nobody else bothering.
By mike_d 2026-01-3122:00 This is a tired trope. Depending exclusively on obfuscation (security by obscurity) is not safe. Maintaining confidentiality of things that could aid in attacks is absolutely a defensive layer and improves your overall security stance.
I love the Rob Joyce quote that explained why TAO was so successful: "In many cases we know networks better than the people who designed and run them."
By TZubiri 2026-02-010:13 I think you are conflating:
Is an unbreakable security mechanism
with
Improves security
anything that complicates an attacker improves security, at least grossly. That said, then there might be counter effects that make it a net loss or net neutral.
Expalin how you detect a branched/flaged sendKey (or whatever it would be called) call in the compiled WhatsApp iOS app?
It could be interleaved in any of the many analytics tools in there too.
You have to trust the client in E2E encryption. There's literally no way around that. You need to trust the client's OS (and in some cases, other processes) too.
By JasonADrury 2026-01-3121:351 reply >Expalin how you detect a branched/flaged sendKey (or whatever it would be called) call in the compiled WhatsApp iOS app?
Vastly easier than spotting a clever bugdoor in the source code of said app.
By refulgentis 2026-01-3121:394 reply Putting it all on the table: do you agree with the claim that binary analysis is just as good as source code analysis?
By JasonADrury 2026-01-3121:40 Binary analysis is vastly better than source code analysis, reliably detecting bugdoors via source code analysis tends to require an unrealistically deep knowledge of compiler behavior.
By anonymars 2026-01-3122:37 Empirically it doesn't look like there's a meaningful difference, does it?
Not having the source code hasn't stopped people from finding exploits in Windows (or even hardware attacks like Spectre or Meltdown). Having source code didn't protect against Heartbleed or log4j
I'd conclude it comes down to security culture (look how things changed after the Trustworthy Computing initiative, or OpenSSL vs LibreSSL) and "how many people are looking" -- in that sense, maybe "many eyes [do] make bugs shallow" but it doesn't seem like "source code availability" is the deciding factor. Rather, "what are the incentives" -- both on the internal development side and the external attacker side
By tptacek 2026-01-3121:57 I don't agree with "vastly better" but its arguable both in the direction and magnitude. I don't think you could plausibly argue that binary analysis is "vastly harder".
By TZubiri 2026-01-3121:44 Nono, analyzing binaries is harder.
But it's still possible. And analyzing source code is still hard.
By Ajedi32 2026-02-0215:39 I think "manufacturer is the attacker" is precisely the threat people are most worried about.
And yes you can analyze binary blobs for backdoors and other security vulnerabilities, but it's a lot easier with the source code.
What’s the state of the art of reverse engineering source code from binaries in the age of agentic coding? Seems like something agents should be pretty good at, but haven’t read anything about it.
Nothing yet, agents analyze code which is textual.
The way they analyze binaries now is by using textual interfaces of command tools, and the tools used are mostly the ones supported by Foundation Models at training time, mostly you can't teach it new tools at inference, they must be supported at training. So most providers are focused on the same tools and benchmarking against them, and binary analysis is not in the zeitgeist right now, it's about production more than understanding.
The entire MCP ecosystem disagrees with your assertion that “you can’t teach it new tools at inference.” Sorry you’re just wrong.
Nono, you of course CAN teach tool use at inference, but it's different than doing so at training time, and the models are trained to call specific tools right now.
Also MCP is not an Agent protocol, it's used in a different category. MCP is used when the user has a chatbot, sends a message, gets a response. Here we are talking about the category of products we would describe as Code Agents, including Claude Code, ChatGPT Codex, and the specific models that are trained for use in such contexts.
The idea is that of course you can tell it about certain tools in inference, but in code production tasks the LLM is trained to use string based tools such as grep, and not language specific tools like Go To Definition.
My source on this is Dax who is developing an Open Source clone of Claude Code called OpenCode
Claude code and cursor agent and all the coding agents can and do run MCP just fine. MCP is effectively just a prompt that says “if you want to convert a binary to hex call the ‘hexdump’ tool passing in the filename” and then a promise to treat specially formatted responses differently. Any modern LLM that can reason and solve math problems will understand and use the tools you give it. Heck I’ve even seen LLMs that were never trained to reason make tool calls.
You say they’re better with the tools they’re trained on. Maybe? But if so not much. And maybe not. Because custom tools are passed as part of the prompt and prompts go a long way to override training.
LLMs reason in text. (Except for the ones that reason in latent space.) But they can work with data in any file format as long as they’re given tools to do so.
Here's the specific source on this matter:
https://youtu.be/VsTbgYawoVc?si=6ZE83umppNCz9h-a&t=1021
"The models today, they are tuned to call specific tools. We've played with a lot of tools, you can hand it a bunch of tools it's never seen before and it just doesn't call them. There's something to the post-training process being catered to certain sets of tools. So anthropic, cloud 4, cloud3.7 before that, those models are the best at calling tools from a programming standpoint. They'll actually keep trying and going for it. Other models like Gemini2.5 can be really good, but it doesn't really call tools very eagerly. So we are in the state right now where we kind of have to provide the set of tools that the model expects.
I don't think that'll always be the case, but we've given it a bunch of LSP tools. I've played with giving, say, giving it 'go to definition' and 'find references', and it just doesn't use them. I mean you can get it to use them if you ask it to, but it doesn't default to kind of thinking that way, I think that'll change."
He then goes on to theorize it's the System Prompt, so open models like Llama where you can customize the system prompt might have an advantage. (I think API models still have a prebaked prompt, not sure). Additionally, even when you control the prompt, he argues there's a (soft) limit to the amount of tools it can handle.
Personally, I think a common error with LLMs is conflating what is technically possible and what works in practice. In this case the argument is that custom tools and MCPs are possible, but it's limited in the sense that "you often need to explicitly tell them to use such tool, you can only have a small amount of custom tools", when you compare it to system prompt specified tools, and tools in the training set which are fine tuned to, it's a whole different category, the native tools are just capable of way much more autonomy.
A similar error I've seen is conflating the context length to the capacity to remember. That a model has a 1M token window means that it could remember something, but it would be a categorical mistake to claim or depend on the model remembering stuff in a 1M token conversation.
There's a lot of nuance in these discussions.
Another common mistake today is to observe one LLM failing to do something in a single situation, and to generalize that observation to "LLM's are incapable of doing this thing." Or "they're not good at this kind of thing" which is what you're repeating here. This logic underlies a lot of AI skepticism. Sure you and they aren't skeptics and acknowledge this will get better. But I think you're over-indexing on a specific problem they observed. Plus to blame the LLM when they haven't optimized the system prompt is IMHO quite silly - it's kind of like "did you read the instructions you were giving it?". What I think they should say is "I tried this and it didn't work super well out of the box. I'm sure there's some way to fix it, but I haven't found it yet." Instead of blaming the model intrinsically.
In contrast, I've seen coding agents figure out extremely complex systems problems that are clearly outside of their training set - by using tools and interacting with complex environments, and reasoning and figuring it out.
Plus, "tools" can be multi-layered. You give an agent a "bash" tool, and voila, it has access to every piece of software ever written. So I don't think any of these arguments apply in the slightest to the question of de-compiling code.
By TZubiri 2026-02-022:27 >"What’s the state of the art of reverse engineering source code from binaries in the age of agentic coding?"
This is the original comment I was responding to, we were talking about state of the art Agentic models. So not generalizing to other scenarios.
>Sure you and they aren't skeptics and acknowledge this will get better
I think this is a common bipartisan trap where you lose a lot of nuance. And it's imprecise, you don't know whether I'm a skeptic or not. It's like reading a nuanced opinion and trying to see if they are Republican so you can agree or Democrats so you can disagree.
>Plus to blame the LLM when they haven't optimized the system prompt is IMHO quite silly - it's kind of like "did you read the instructions you were giving it?"
I think the context here is that when using agentic tools like Claude Code, you don't control the system prompt. You could write your own prompts and use naked API calls, but that's always more expensive, (because it's subsidized), and I'm not sure what the quality of that is.
The bottom line is that API calls, where you can fully control the system prompt, are more expensive. And using your OpenAI/Anthropic subscription has a fixed cost. So in that context they don't control the system prompt.
Even in cases where you could control the system prompt and use the API, there's the fact that some models (the state of the art) are fine tuned for specific tool use, so they have a bias towards fine tuned tool use. The claim is not that they are "incapable of doing X thing" it's that it's a bias towards the usage that was known at train-time or fine-tune time, instead of at inference which is much weaker. Nuance.
>Instead of blaming the model intrinsically.
Again, not blaming or being a skeptic here, just analyzing the state of the art and its current weakness, it's likely that these things are going to be improved in the next generation, this is going to move fast, if you conflate any criticism of the tools with "skepticism" you are going to miss the nuance.
>In contrast, I've seen coding agents figure out extremely complex systems problems that are clearly outside of their training set - by using tools and interacting with complex environments, and reasoning and figuring it out.
Yeah for sure, I'll give you a concrete example on this point where we agree. I made a model download a webdriver for a browser and taught it to use the webdriver to open the site, take screenshots, and evaluate how it looks visually, in addition to actually clicking buttons and navigating it. This is a great improvement when the traditional approach is just to generate frontend code and trust that it works (which to be fair, sometimes works great, but you know, it's better if it see that.)
And it works, until it doesn't and I have to remind it that it can do that. It's just a bias. If they would have trained the model with WebDriver tool access, the model would use it much more (and perhaps they are already doing that and we will see it in the next model.)
The main thesis is that instructions taught at train time 'work better' than at fine-tune time which in turn are stronger than 'inference'. To be very specific during inference tool use is much more likely immediately after mentioning it, it might be stronger more consistently at the system prompt, (but it competes with other system prompt instructions and it's still inference based). To say nothing of the costs associated with adding to inference tokens, compared to essentially free training/finetune biases. I don't think anyone disagrees that stuff you teach the model during training has better quality and less cost than stuff you teach at inference.
I think playing around with logit biases is an underrated tool to increase and control frequency of certain tools, but it doesn't seem that's being used much in this generation of vibecode tools, the interface is almost entirely textual (with some /commands starting to surface). Maybe the next generation will have the option to configure some specific parameters instead of entirely relying on textual prompting.
By refulgentis 2026-01-3121:371 reply Agents are sort of irrelevant to this discussion, no?
Like, it's assuredly harder for an agent than having access to the code, if only because there's a theoratical opportunity to misunderstand the decompile.
Alternatively, it's assuredly easier for an agent because given execution time approaches infinity, they can try all possible interpretations.
Agents meaning an AI iteratively trying different things to try to decompile the code. Presumably in some kind of guess and check loop. I don’t expect a typical LLM to be good at this on its first attempt. But I bet Cursor could make a good stab at it with the right prompt.
By TZubiri 2026-02-0119:20 Cursor is a bit old at this point, the state of the art is Claude Code and imitators (ChatGPT Codex, OpenCube).
Devin is also going very strong, but it's a bit quieter and growing in enterprises (and pretty sure it uses Claude Opus 4.5 and possibly Claude Code itself). In fact Clawdbot/Moltbot/OpenClaw was itself created with devin.
The big difference is the autonomy these models have (Devin more than Claude Codes), Cursor was meant to work in an IDE and that was a huge strength during the 12 months that the models still weren't strong enough to work autonomously, but they are getting to the point where that's becoming a weakness. Models like Devin are getting a slower acceleration but higher top speed advantage. My chips are on Devin
By roughly 2026-01-3121:48 I think there’s a good possibility that the technology that is LLMs could be usefully trained to decode binaries as a sort of squint-and-you-can-see-it translation problem, but I can’t imagine, eg, pre-trained GPT being particularly good at it.
By JasonADrury 2026-01-3121:39 I've been working on this, the results are pretty great when using the fancier models. I have successfully had gpt5.2 complete fairly complex matching decompilation projects, but also projects with more flexible requirements.
By JasonADrury 2026-01-3121:32 >Detecting backdoors is only truly feasible with open source software and even then it can difficult.
This is absurd. Detecting backdoors is only truly feasible on binaries, there's no way you can understand compiler behavior well enough to be able to spot hidden backdoors in source code.
By prakashn27 2026-01-3119:379 reply Ex-WhatsApp engineer here. WhatsApp team makes so much effort to make this end to end encrypted messages possible. From the time I worked I know for sure it is not possible to read the encrypted messages.
From business standpoint they don’t have to read these messages, since WhatsApp business API provide the necessary funding for the org as a whole.
Facebook has never been satisfied with direct funding. The value is in selling attention and influencing users’ behavior.
By neuralkoi 2026-01-3122:47 This is why most tech founders who go big never retire, even as billionaires. The power they gain, only the wisest would refuse.
By bossyTeacher 2026-02-014:042 reply > Ex-WhatsApp engineer here. WhatsApp team makes so much effort to make this end to end encrypted messages possible. From the time I worked I know for sure it is not possible to read the encrypted messages.
None of this makes the point you want to make. Being a former engineer. The team making "so much effort". You "knowing for sure". Like many in security, a single hole is all it takes for your privacy to pour out of your metaphorical bag of sand.
By dangus 2026-02-017:46 It’s not even “a single hole,” it’s that companies can change their mind at any time.
That person doesn’t work there anymore. For all we know Zuck could wake up one day and say “that’s it, we need the data and revenue from reading WhatsApp chats. Change our policy in the most low key way possible.”
Honestly, it’s too tempting isn’t it? They have the largest conversation network out there.
It doesn’t help that the company has just about zero trust built up among their customers. The whole dang company changed their name arguably to try to shed the “Facebook” baggage.
By Taurenking 2026-02-027:52 [dead]
Nice! Hey, question: I noticed Signal at one point had same address on Google Play Store as WA. Can you tell us if Signal devs shared office space with WA during integration of the Signal protocol? Related to that, did they hold WA devs' hand during the process, meaning at least at the time it was sort of greenlighted by Moxie or something. If this is stuff under NDA I fully understand but anything you can share I'd love to hear.
By xvector 2026-02-0119:02 It's public knowledge that Moxie and team helped out https://signal.org/blog/whatsapp-complete/
By blindriver 2026-01-3120:034 reply It only takes one engineer in all the teams at Whatsapp that has different directives to make all your privacy work completely useless.
By rustyhancock 2026-01-3120:32 The legal and liability protection these messaging services get from E2EE is far too big to break it.
Besides I get the feeling we're so cooked these days from marketing that when I get freaked out that an advert is what I was thinking about. It's probably because they made me think about it.
Or maybe I need to update my meds?
By philipallstar 2026-01-3120:10 Assuming there's no code review or audit, I suppose.
By dagmx 2026-01-3123:24 How would you hide that? Unless you’re assuming nobody ever has to try and fix bugs or audit code to find it, and there’s some kind of closed off area of code that nobody thinks is suspicious. Or you maintain a complete second set of the app core libs that a few clandestine folks can access, and then hope nobody notices that the binaries don’t line up and crash logs are happening in obscured places.
By cactusfrog 2026-01-3120:201 reply I would be surprised if the code was hidden from other people engineers.
By maqp 2026-01-3120:55 How are you hiding it from IDA pro though?
By zatertip 2026-01-3122:42 According to Kristeligt Dagblad in Denmark, he was using Snapchat: https://www.kristeligt-dagblad.dk/tidligere-superligaspiller...
I have no doubt that that rank and file engineers were not aware of the underlying functionality that allowed for plain text content to be read.
Nobody would ever create a SendPlainTextToZuck() function that had to be called on every message.
It would be as simple as using a built in PRNG for client side key generation and then surreptitiously leaking the initial state (dozens of bytes) once in a nonce signing or something when authenticating with the server.
By oofbey 2026-01-3122:27 I’ve often thought one of Zuck’s superpowers is in finding ways to get smart and moral people to do truly evil things. Sometimes it’s mind games. Sometimes it’s careful layers of obfuscation.
Here it might be: This analytics package is dynamically loaded at runtime because reasons. This abuse flagging and review system is bundled with analytics because reasons. This add on for reconfiguring how the analytics package behaves at runtime, and has a bunch of switches nobody remembers why they’re here but don’t touch them they’re fragile.
From what you know about WA, is it possible for the servers to MitM the connection between two clients? Is there a way for a client to independently verify the identity of the other client, such as by comparing keys (is it even possible to view them?), or comparing the contents of data packets sent from one client with the ones received on the other side?
Thanks.
By NoahZuniga 2026-01-3123:26 No.
Whatsapp uses key transparency. Anyone can check what the current published keys for a user are, and be sure they get the same value as any other user. Specifically, your wa client checks that these keys are the right key.
Whatsapp has a blog post with more details available.
By NoImmatureAdHom 2026-02-011:10 The backups are either unencrypted by default or have keys held by Meta / your backup provider. I think this means three-letter agencies can see your chats, just with a slight delay.
Another comment above mentions that you can recover conversation histories with just your phone number--if that's true then yup. The E2EE is all smoke and mirrors.
By ewuhic 2026-01-3122:45 [flagged]
