4 ms·
I think it's pretty obvious that we cannot trust any messenger app that is closed source or relies on some company's service infrastructure. If it's closed sour
by jgaa 10y ago
I think it's pretty obvious that we cannot trust any messenger app that is closed source or relies on some company's service infrastructure. If it's closed source, you cannot possible know what it does. If it's relying on a company's infrastructure, it's likely to be banned by oppressive governments (and that includes most of the so called "free world"). In frustration over my own Government (Norway), I started last year a project to launch a new IM client based on the legacy TorChat protocol (https://github.com/jgaa/darkspeak https://github.com/jgaa/darkspeak). It turned out to be way more work than I expected - so it's been on hold for a few months while I spend time on some more urgent projects. However, I think p2p IM software, based on open source, over Tor (or similar technologies) is the only way to preserve privacy and confidentiality in the future.
- dr_zoidberg 10y ago> If it's closed source, you cannot possible know what it does. You can set up a wifi and try to MitM yourself and see what packets WhatsApp is sending/receiving. Then you can try to snoop on them and test. The fact that it is closed source doesn't mean you can't analyze it, it just means it's a black box that you have to carefully dissect.
- jgaa 10y agoYou can get some idea by looking at where the packages are going - but in todays ipv4 space, most p2p packages have to transit trough some public IP addresses. That means that, unless you are able to decrypt the traffic, it will be difficult to know if someone is listening in on the conversation. Also, just by looking at the packages, you will not have any means to detect back-doors, unless they are accessed while you are looking. Back-doors potentially requested by intelligence agencies for snooping on high value targets are likely to go undetected.
- MichaelGG 10y agoSo just look at the actual code executing. Should be fairly easy to tell if there's some huge secret function in the binary.
- jgaa 10y agoWell - you know, when you strip the symbols from the optimized binaries, the "huge_exploit_nsa_hook()" function kind of morphs into 0x66666666 or some other seemingly random number. Besides, I knew only one programmer who could read binary dumps of a program and instantly tell what id did. That was 30 years ago, when executables were measured in kilobytes.
- MichaelGG 10y agoFortunately there are useful tools that'll help navigate binaries, like IDA Pro. They'll produce control flow graphs in addition to letting you annotate things. I've done this in a professional capacity a few times, though I'm not remotely an expert and barely know what I'm doing. In Java, it's even easier due to JVM restrictions. I wrote an obfuscator for .Net, but Java offers less capabilities in it's bytecode. I even used a commercial product that had been obfuscated. The obfuscator broke something on Mono. It took about an hour to write a small script to go through the binary and fixup the broken bits so other tools would work on it.
- dr_zoidberg 10y agoGood call on reversing, I'd written about it in a first draft but then scratched everything and started over again. Indeed, there are some good reversing tools. Still, his call on packet analysis being incomplete (unless you happen to see an interesting event) is right. I was thinking of a more simple test to see if things are effectively encrypted, and how resistant to cryptoanalysis is the protocol.