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? 🤔
@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 I frankly still don't see the identification risk (other than the fact that the user uses signal in general), especially with CRL, where you get a list that usually is an aggregate of the issuer and therefore the same for multiple certificates. What am I missing?