Static + dynamic analysis of Signal's APK.
-
Static + dynamic analysis of Signal's APK. The good news first: Signal is genuinely exceptional.
Rust core (libsignal_jni.so), post-quantum hybrid Double Ratchet (Kyber-1024 + X25519), Direct ByteBuffers with immediate zeroing after PIN/username hashing, Intel SGX attestation for SVR — MREnclave verification means even a compromised Signal server can't extract your PIN hash.
But two things stood out:
1. Firebase is always there. Google receives IP + notification timestamps regardless of message content. If you need metadata privacy, Signal still leaks presence data to Google's infrastructure.
2. Certificate revocation endpoints hit http://g.symcd.com in plaintext. An ISP or state-level observer can fingerprint Signal usage from DNS queries and HTTP traffic to those CAs — without touching message content.
Conclusion: strongest crypto engineering in consumer messaging. The attack surface isn't the cryptography. It's the operational dependencies.
Soon the full analysis
#infosec #AndroidSecurity #Signal #privacy #ReverseEngineering #postquantum #mobileforensics
@Harpocrates Sorry for the thread semi-hijack, but this seems to be a good place to ask this: has there been anything interesting done against this statistical attack against Signal's sealed sender?
>...strongest crypto engineering in consumer messaging.
I think that sort of statement is more about interesting features than security strength. There are lots of secure messaging protocols out there and you can't get more secure than secure. Considering the high complexity of the Signal Protocol I doubt that it would just happen to be the *most* secure. Your point about cryptographic security vs dependencies is still well taken.
-
Static + dynamic analysis of Signal's APK. The good news first: Signal is genuinely exceptional.
Rust core (libsignal_jni.so), post-quantum hybrid Double Ratchet (Kyber-1024 + X25519), Direct ByteBuffers with immediate zeroing after PIN/username hashing, Intel SGX attestation for SVR — MREnclave verification means even a compromised Signal server can't extract your PIN hash.
But two things stood out:
1. Firebase is always there. Google receives IP + notification timestamps regardless of message content. If you need metadata privacy, Signal still leaks presence data to Google's infrastructure.
2. Certificate revocation endpoints hit http://g.symcd.com in plaintext. An ISP or state-level observer can fingerprint Signal usage from DNS queries and HTTP traffic to those CAs — without touching message content.
Conclusion: strongest crypto engineering in consumer messaging. The attack surface isn't the cryptography. It's the operational dependencies.
Soon the full analysis
#infosec #AndroidSecurity #Signal #privacy #ReverseEngineering #postquantum #mobileforensics
@Harpocrates look at the network stacks (well, I guess it would be their HTTP client). It's my understanding that each platform has a different implementation (iOS, Android, Desktop) so the "Rust core" isn't really *everything*, just the cryptography. -
@Harpocrates look at the network stacks (well, I guess it would be their HTTP client). It's my understanding that each platform has a different implementation (iOS, Android, Desktop) so the "Rust core" isn't really *everything*, just the cryptography.
@feld Spot on @feld. The 'Rust-everything' transition is still a work in progress, and my analysis confirms that while the Rust core (libsignal-client) is a fortress for the crypto logic, it still hands off to platform-specific wrappers for I/O. On Android, it's hitting OkHttp, and that’s exactly where the metadata starts bleeding.
I've just published a deep dive on this. I spent some time reversing the native binaries and monitoring the JNI heap—the memory hygiene is impressive (Direct ByteBuffers, immediate zeroing, NativeHandleGuard), and the hybrid Kyber-1024 implementation is already live. But as you suspected, the network stack (Firebase + plaintext OCSP) remains the Achilles' heel.
Check out the full technical breakdown here:
https://blackcodeitalia.wordpress.com/2026/03/06/signal_centuria_002-under-signals-hood-technical-analysis-of-rust-kyber-and-jni-buffer-management/" -
@Harpocrates Sorry for the thread semi-hijack, but this seems to be a good place to ask this: has there been anything interesting done against this statistical attack against Signal's sealed sender?
>...strongest crypto engineering in consumer messaging.
I think that sort of statement is more about interesting features than security strength. There are lots of secure messaging protocols out there and you can't get more secure than secure. Considering the high complexity of the Signal Protocol I doubt that it would just happen to be the *most* secure. Your point about cryptographic security vs dependencies is still well taken.
@upofadown No worries about the hijack @feld, the NDSS paper is a great catch.
Statistical attacks on Sealed Sender are the ultimate 'metadata vs. crypto' headache. Unless we move to full-on Mixnets or constant-noise traffic (which kills battery/UX), it’s hard to solve for a consumer app. Signal seems to be banking on 'good enough' obfuscation for the masses while over-engineering the implementation.
On the 'most secure' bit: I totally get that complexity is the enemy. But when I say 'strongest engineering,' I’m talking about the implementation depth. Most apps just slap a library on a standard stack; Signal is rewriting the stack in Rust and pushing hybrid Post-Quantum (Kyber) and SGX attestation before they're even industry standards.
It’s that focus on the binary level—like the Direct ByteBuffer hygiene—that sets them apart in my audit. It’s about making the implementation as hard to exploit as the protocol itself.
-
@feld Spot on @feld. The 'Rust-everything' transition is still a work in progress, and my analysis confirms that while the Rust core (libsignal-client) is a fortress for the crypto logic, it still hands off to platform-specific wrappers for I/O. On Android, it's hitting OkHttp, and that’s exactly where the metadata starts bleeding.
I've just published a deep dive on this. I spent some time reversing the native binaries and monitoring the JNI heap—the memory hygiene is impressive (Direct ByteBuffers, immediate zeroing, NativeHandleGuard), and the hybrid Kyber-1024 implementation is already live. But as you suspected, the network stack (Firebase + plaintext OCSP) remains the Achilles' heel.
Check out the full technical breakdown here:
https://blackcodeitalia.wordpress.com/2026/03/06/signal_centuria_002-under-signals-hood-technical-analysis-of-rust-kyber-and-jni-buffer-management/"@Harpocrates the biggest metadata leak they have really is media attachments in groups. You can just go to the CDN (cloudflare) and ask for logs of a specific URL and now you have the IPs of all the group members and can use that to identify them by going after their ISPs -
@Harpocrates the biggest metadata leak they have really is media attachments in groups. You can just go to the CDN (cloudflare) and ask for logs of a specific URL and now you have the IPs of all the group members and can use that to identify them by going after their ISPs
@feld accurately pointed out. Centralized CDN distribution is the ultimate metadata killer.
The fetch request for group media effectively acts as a signed attendance sheet. Even with a hardened Rust core, the infrastructure logs (Cloudflare) provide a full map of group members' IPs to anyone with access.
It’s the classic trade-off: high-speed delivery vs. anonymity. I’ll include a CDN-de-anonymization section in the Langis follow-up. This makes the Tor/VPN routing conversation much more than just a 'hardening' preference." -
Static + dynamic analysis of Signal's APK. The good news first: Signal is genuinely exceptional.
Rust core (libsignal_jni.so), post-quantum hybrid Double Ratchet (Kyber-1024 + X25519), Direct ByteBuffers with immediate zeroing after PIN/username hashing, Intel SGX attestation for SVR — MREnclave verification means even a compromised Signal server can't extract your PIN hash.
But two things stood out:
1. Firebase is always there. Google receives IP + notification timestamps regardless of message content. If you need metadata privacy, Signal still leaks presence data to Google's infrastructure.
2. Certificate revocation endpoints hit http://g.symcd.com in plaintext. An ISP or state-level observer can fingerprint Signal usage from DNS queries and HTTP traffic to those CAs — without touching message content.
Conclusion: strongest crypto engineering in consumer messaging. The attack surface isn't the cryptography. It's the operational dependencies.
Soon the full analysis
#infosec #AndroidSecurity #Signal #privacy #ReverseEngineering #postquantum #mobileforensics
@Harpocrates please correct me if I'm wrong, but aren't CRLs categorically HTTP? To my knowledge, only OCSP started supporting TLS. That nonwithstanding, couldn't state actors also scan for IP access?
-
@Harpocrates please correct me if I'm wrong, but aren't CRLs categorically HTTP? To my knowledge, only OCSP started supporting TLS. That nonwithstanding, couldn't state actors also scan for IP access?
@DJGummikuh spot on. CRLs/OCSP stay HTTP to avoid TLS recursion, but that’s the trap. By fetching them directly, the client leaks the Cert Serial Number in plaintext to the ISP/AS.
It’s a perfect fingerprint: Query to g.symcd.com + encrypted Signal CDN traffic = 99% user identification. Signal should force OCSP Stapling to kill this 'last mile' metadata leak, but the APK shows the client is still chatting with CAs independently. The lock is post-quantum, the doorbell is plaintext. -
@Harpocrates please correct me if I'm wrong, but aren't CRLs categorically HTTP? To my knowledge, only OCSP started supporting TLS. That nonwithstanding, couldn't state actors also scan for IP access?
@DJGummikuh ...A real structural solution would be moving towards a RINA-based network to eliminate these metadata-heavy architectural dependencies entirely.
-
Static + dynamic analysis of Signal's APK. The good news first: Signal is genuinely exceptional.
Rust core (libsignal_jni.so), post-quantum hybrid Double Ratchet (Kyber-1024 + X25519), Direct ByteBuffers with immediate zeroing after PIN/username hashing, Intel SGX attestation for SVR — MREnclave verification means even a compromised Signal server can't extract your PIN hash.
But two things stood out:
1. Firebase is always there. Google receives IP + notification timestamps regardless of message content. If you need metadata privacy, Signal still leaks presence data to Google's infrastructure.
2. Certificate revocation endpoints hit http://g.symcd.com in plaintext. An ISP or state-level observer can fingerprint Signal usage from DNS queries and HTTP traffic to those CAs — without touching message content.
Conclusion: strongest crypto engineering in consumer messaging. The attack surface isn't the cryptography. It's the operational dependencies.
Soon the full analysis
#infosec #AndroidSecurity #Signal #privacy #ReverseEngineering #postquantum #mobileforensics
@Harpocrates Great work! If you have the reach (signal org has ignored my questions) please get them to release all of their infra automation code!
They've build a substantial amount of infrastructure and that should be open source so that someone could replicate the network easily if for some reason we were forced to!
