Hacker News Reader

Comment by georgemcbay | Hacker News Reader

Yeah, but you have to trust that someone (who is really independent and not in on the backdoor) is actually doing that. Also, the fact that all binaries distributed through mobile stores have to be signed with a private key makes this a more difficult proposition with mobile software than it is with desktop software. (Unlike desktop EXEs you can't just hash the resulting binaries).

I supposed you could pull apart the container format (apk or ipa) and compare the .class files (Assuming Java, I haven't looked at this software so I don't know if it is standard Android or a lot of NDK stuff) or ObjC object files one by one to look for discrepancies versus a local build using the same tools... hopefully someone volunteers to do that and keeps doing it again on each new release.

View on HN

The Whisper Systems people and the community are already discussing this issue, at least for the released Android app:

https://github.com/WhisperSystems/TextSecure/issues/127

For iOS I believe that decrypting the binary and doing an objdump, then comparing the resulting assembly is a reasonable approach to ensuring that two builds do the same thing. Comparing objdump results won't protect against particularly insidious backdoors like those injected through data resources or binary headers, but in tandem with a source audit should give a fairly respectable degree of assurance.

This process would be quite easy to automate.

> For iOS I believe that decrypting the binary and doing an objdump, then comparing the resulting assembly is a reasonable approach to ensuring that two builds do the same thing.

Not a chance.

And if someone is doing this, we are well past "particularly insidious".

You have to trust everyone who claims the binary is clean, yes. But the vendor must also trust all these conspirators! And they can't bribe everyone - it only takes one honest guy with a decompiler and it's game over.

Debian SSL bug lasted a while.

This is not a case of "many eyes make all bugs shallow, so all OSS software is safe". This is a case of "many eyes will look at my covert code, can't take the risk of discovery". Debian SSL is not comparable because it was an accidental (if stupid) bug. We are talking about deliberate malice, not bugs (which are inevitable in open and closed code alike).

At the state actor level do you really think you will be able to distinguish a stupid bug and an intentional flaw? Its not like they will make it call home with a bunch of code, they would just use a class of attack not well known and you wouldn't be able to tell the difference. That's all it takes, one little hole.

I imagine certain organisations knew about buffer overflow bugs long before they were used publicly, so imagine if this was the 70's and you saw some strcpy calls peppered into some useful code, would you really be able to know 1) the class of attack exists and 2) if it was intentional or not?

Yeah, but that is always a threat with any code ever written by anybody other than oneself. The only assurance against that is if one writes their own code compiled with their own compiler and run on their own fabricated hardware. Oh, and implementing their own security algorithms. Which means any data exchange would be impossible.

It all comes down to the idea that if you the user have concerns with the app, you the user can take the approrpriate measures to verify, given enough time.

Reply on news.ycombinator.com