Mastodawn

Power_to_the_People (he/him)17h ago

Caria Giovanni - Harpocrates

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

David Chisnall (*Now with 50% more sarcasm!*)1d ago

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.

I was under the impression that Signal sends random spurious notifications to devices to mitigate this, to make correlations harder for someone who observes these notification.

Caria Giovanni - Harpocrates 1d ago

@david_chisnall
You're correct that Signal implements noise injection
via spurious notifications to frustrate timing
correlation attacks — that's a documented mitigation.
The residual concern is at the infrastructure layer:
Google's FCM still receives the device token, IP,
and delivery timestamp for every real notification.
The spurious traffic makes statistical correlation
harder, not impossible — especially for a state-level
observer with visibility into both ends.
Molly's UnifiedPush implementation eliminates the
FCM dependency entirely, which is why it's the logical next audit target.

@Harpocrates Did you compare this with #Molly ?

Caria Giovanni - Harpocrates 1d ago

@jan
Not yet — Molly is on the list precisely because of the Firebase dependency I flagged. The UnifiedPush implementation is the interesting delta to audit. If the metadata leak vector is eliminated at the transport layer, the threat model changes significantly.

Watch this space.

Cat 🐈🥗 (D.Burch)

@Harpocrates @stroz There is an unofficial patch that removes Google Play Services from the APK, which you might be interested in analyzing. It takes care of the Firebase issue.

https://langis.cloudfrancois.fr/
Repo: patched-apps

As for the second issue, using Signal (or Langis) over a Tor service, like Tor VPN Beta, InviZible Pro, or Orbot, will decouple your real IP with Certificate revocation queries.

•  https://f-droid.org/packages/org.torproject.vpn
•  https://apt.izzysoft.de/packages/pan.alexander.tordnscrypt
•  https://github.com/guardianproject/orbot-android

Signal Without GCM/FCM

A version of Signal without Google/Firebase Cloud Messaging dependency

ms_nonbinary_flag

@catsalad afaik molly.im (android only) should be fine too, atleast the foss version, for issue 1
@Harpocrates @stroz

Caria Giovanni - Harpocrates 1d ago

@catsalad @stroz
im totally with you

@Harpocrates ...this is shit. In the age of tracking your entire online behaviour this is as significant as reading your messages in plain text - almost.

@Harpocrates “we made a secure messaging app to get you away from insecure big tech”

“it doesn’t depend on google right”

@Harpocrates signal would be so good were it not penetrated by this corporate attitude of “oh we absolutely must be a centralized service that collects phone numbers and relies on fashcloud providers for everything”

Caria Giovanni - Harpocrates 1d ago

@zaire I understand your point and i agree, for this im trry to understand how mitigate is the thing.
Anyway im try to specialize in greyware and is a new frotnier world .

Bruce Walzer 🇨🇦1d ago

@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?

https://www.ndss-symposium.org/ndss-paper/improving-signals-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.

Improving Signal's Sealed Sender - NDSS Symposium

NDSS Symposium

Caria Giovanni - Harpocrates 1d ago

@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.

DJGummikuh 22h ago

@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? 🤔

Caria Giovanni - Harpocrates 18h ago

@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.

DJGummikuh 14h ago

@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?

Caria Giovanni - Harpocrates 18h ago

@DJGummikuh ...A real structural solution would be moving towards a RINA-based network to eliminate these metadata-heavy architectural dependencies entirely.

James Just James 17h ago

@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!

Caria Giovanni - Harpocrates 17h ago

@purpleidea Thnx!
Agreed. Infra transparency is the missing link. I'm currently pivoting from standard code analysis to a Code Intelligence approach.
Most tools look for bugs; I’m mapping behavioral patterns that standard scanners miss by design. If the infra is a black box, the code behavior is the only source of truth we have left. Verifying the stack is the only way forward.

James Just James 17h ago

@Harpocrates I can't agree more. I work in the infra space, so I've always been keen to dig into that side of things.

Please spread the word. There's zero reason they should keep that secret and proprietary.

Thanks!

Pieter de Bruin 🌍🌈☮️ | 🟢🔴16h ago

@Harpocrates what did signal have to say?

Caria Giovanni - Harpocrates 16h ago

@pdebruin Signal would probably say everything is 'by design' for the sake of mass adoption. But honestly? The existence of forks like Molly to fix those 'design choices'—like Firebase dependencies or OCSP leaks—speaks louder than any official statement. 😉 Some of us just prefer a higher baseline.

@Harpocrates noobie q: is presence/lack thereof of google play services relevant to 1?

Caria Giovanni - Harpocrates 14h ago

@NocturnalNessa Exactly what I was getting at with the Signal analysis. Even without Play Services, the kernel-level network stack leaks too much metadata to the ISP. That’s why I’m looking at RINA in user-space—to decouple the app from the OS's networking baggage entirely

Scraft161 10h ago

@Harpocrates
I was already wary of signal since they are centralized and require a phone number to sign up (something that in many EU countries you have to link to your ID 😬) and due to that centralization they will receive message metadata (mostly who you talk to and when) as part of their service, and even if they say they don't store it, that is only something I can take their word on.

I would be fine with the latter if I could stay anonymous with account creation, but that is not really an option...