Hacker News Reader

Comment by skullum | Hacker News Reader

How can they be orthogonal when eventually you need open software of some kind to make a verification?

If the software I use to verify the closed source software is closed, then I will need another piece of software to verify that the verify-ing software is what it says it is and so on until we reach a piece of software that I can verify with my own eyes (or a friend has verified with their eyes).

We all eventually have to place our trust somewhere but we shouldn't have to agree with where you decided to trust.

View on HN

If you didn't trust the closed source disassembler you use, for whatever reason, you would verify the assembly output, not the actual software. In practice this is often done unintentionally anyway: it's common to run a debugger (ex: gdb, windbg) alongside an annotating disassembler (like IDA). objdump (from GNU binutils) also supports many non-Unix executable formats, including PE (Windows) and Mach-O (OSX/iOS).

For fun I just compared objdump's entry point function assembly of a downloaded Pokemon Go IPA to the Hopper representation, and, no surprise, they are identical.

This is not a position widely held in the software security industry.

Quite the opposite it’s axiomatic in the industry that you need capabilities to verify closed source.

You don't need open software of any kind to verify it.

It sure helps though. And being able to compare source code to binary is good for checking blobs.

No one knows what nasties are hidden in these blobs that run on EVERY phone out there. I’d actually go as far as saying cell phone processing modules are completely insecure. Unlikely to receive updates. Poorly documented. Security standards are likely to be weakly implemented with gaping holes.

As for proof, I’d point at the lack of source code as a starting point. Open source doesn’t guarantee security but it at least lets interested parties try to the degree they want or need to.

As for proof, I’d point at the lack of source code as a starting point.

Much better proof would be frequent exploits through the vectors you consider examples glaring insecurity.

Sure. Go and have a look at GSM and friends. I’d say the cellular network in general is routinely being manipulated. The protocols and standards for over-the-air are demonstrably insecure and assuming the actual hardware is also insecure is reasonable as well.

Part of the point of this thread is that 'modern flagship phones' are designed with problems like that in mind. You're the one claiming to have 'proof' they are trivially insecure.

I pointed at the lack of source code as a starting point for proof of complete insecurity. I pointed at the ease of the existing protocols in active use as an example of that insecurity. That insecurity is the basis for Stingray fake towers. If you can fake the tower then the cellular modules can’t be much better.

I’m sure various agencies are quite frustrated by their inability to use the cellular modem as an entry point into Apple’s phones. That by itself is another pointer.

I didn’t claim to have proof other than that.

That's proof for the values of proof that include 'innuendo'.

You haven’t addressed any of my points to any particular depth. So I’m not sure why you have such faith in this tech.

Reply on news.ycombinator.com