You 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.
Well - 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.
Fortunately 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.
Good 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.
