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

📰 .NET and .NET Framework January 2026 servicing releases updates

A recap of the latest servicing updates for .NET and .NET Framework for January 2026.

https://devblogs.microsoft.com/dotnet/dotnet-and-dotnet-framework-january-2026-servicing-updates/ #dotnet

I've done small (but fun) .NET Framework research, and I found a new exploitation primitive (vulnerable behavior). In many cases, it may directly lead to RCE.

I'll discuss it during Black Hat EU and I'll drop a paper afterwards 🫡

https://www.blackhat.com/eu-25/briefings/schedule/index.html#soapwn-pwning-net-framework-applications-through-http-client-proxies-and-wsdl-49018

When giving #security guidance to developers, be sure to impart an understanding of the underlying problem, not just which API's to use or not. If you don't do this, enterprising developers will often reintroduce the problem by adding the problematic capabilities to an otherwise safe API.

To give a specific example, and to try to atone for some of my past sins:

The underlying problem in unsafe deserialization that leads to remote code execution is user-provided data telling your application what type it wants to be. When data can choose what type it is, it can choose types that have exploitable side effects in their constructors, setters, or destructors. Polymorphic deserializers are inherently unsafe.

In the past I've told people "use this API, it's safe". But when that API is safe because it doesn't allow polymorphism, developers inevitably modify the API to add polymorphism when it makes the overall design of the application simpler.

The portion of the #OWASP #serialization cheat-sheet on .NET is based on a talk I gave in 2017 before I understood this problem. (https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html#net-csharp )

It's much more difficult, but training developers to write secure code requires teaching them what the real problems are.

#appsec #training