Take as an example the Italian app "Immuni" (https://github.com/immuni-app), used by the government to trace contacts exposure against COVID-19.

Since many people were afraid about how the app would have used the phone location, contacts, etc.. the entire source code has been published on Github.

Now my question is: is there any guarantee that the published app has been built starting from that source code? In other words, potentially the app could be different from the source code, adding some exploits or privacy breaks.

  • 8
  • 1
    From a practical standpoint: The fake source code would have to match the malicious binary at least superficially and at least we can be sure that only a limited amount of time could be inverted into developing both. Also any future bugfix, feature extension etc. would have to correspond to similar changes in both source and binary behaviour. In particular, fixes only in the malicious part would need to correspond to no-op changes in the source. At any rate, keeping the facade up over a prolonged time might be somewhat non-trivial Jan 16, 2021 at 22:18
  • Regardless of the possibility, I know that for Android apps, some devs on XDA Forums published their source code and ad-free apps on the forum while publishing the same apps on the Play Store with ads. A further solution is to reverse engineer the downloaded app instead.
    – Andrew T.
    Jan 17, 2021 at 12:31
  • 2
    Which government is "the" government? Jan 18, 2021 at 13:18
  • @TobySpeight probably the Italian one since that is what they said about the app
    – SMMH
    Aug 31, 2023 at 0:36

7 Answers 7


As a general problem, I'm not aware of a robust way to validate that a given binary matches a given source repository (see, e.g., this discussion on Security.SE).

Ultimately, it boils down to a question of trust.
The most reliable solution is to build the given sourcecode yourself and not rely on the published binary (although you still have the question of whether you can trust third party APIs the program uses, the compiler and toolchain, etc). A more realistic option for most users (especially the non-tech-savvy ones) is to check downloadable binary's checksum again a published checksum. Then again, if you don't trust the party publishing the checksum, this is of course meaningless.

  • 1
    If one trusted the party that published the source of their binaries, one would likely have trusted the original binaries before the sources were released. I don't think source code does anything to increase the trust, unless one is able to reproduce the binary, as mentioned in the MadHatter's answer.
    – Ruslan
    Jan 15, 2021 at 20:38
  • 4
    There is a reproduceable build movement, but it has a long way to go for properitary app platforms (especially when the app should pass an App Store)
    – eckes
    Jan 16, 2021 at 21:33
  • @eckes: It irks me that the concept of fully-deterministic reproduceable builds seems to have been largely abandoned, since if builds aren't fully reproduceable one can never be sure that what one is testing is the same as what will be released.
    – supercat
    Jan 18, 2021 at 4:57

In addition to Mureinik's excellent point, there is a general move towards reproducible builds in FLOSS, which provides a useful halfway house between build it yourself and distributor publishes a single checksum.

Once the build toolchains are reproducible (that is, a given toolchain repeatably compiles a given set of reproducibly-buildable sources into bitwise-identical binaries) then a distributed solution becomes possible: a small number of enthusiastic and capable individuals can each systematically rebuild an app from a given set of sources, and each can publish checksums of their resulting binaries. If many such independent sources agree, users can easily verify correctness of their own copies by checksumming those.

  • 4
    ...except that mobile toolchains tend to do the opposite of reproducible builds - often and increasingly as a default employing random obfuscation of internal names, etc. Jan 16, 2021 at 6:38
  • 3
    @ChrisStratton couldn't agree more, but that's where desktop Linux was when the move started, and many distros - credit must go to Debian - have come a long way. Doubtless with a similar decision to move that way, mobile can join them.
    – MadHatter
    Jan 16, 2021 at 7:22
  • 4
    For example Signal uses reproducible builds <signal.org/blog/reproducible-android>
    – Luca Citi
    Jan 16, 2021 at 14:24
  • 3
    Interesting to note that Immuni seem to know and care about reproducible builds, but give a lot of reasons why they couldn't implement them on both iOS and android: web.archive.org/web/20200527063225if_/https://github.com/…
    – stevec
    Jan 17, 2021 at 13:59

Short answer: You can't.

There's a famous paper Reflections on Trusting Trust by Ken Thompson about how the compiler itself could be inserting the malicious code, including when compiling itself.

The best way would be to build the app yourself, or have it built by some entity you fully trust for this. Maybe you don't have the knowledge or tools yourself, but have a friend who is able to do that. Or you have the monetary means to hire someone which does this for you.

(Note all of this is easier for the Android version, doing the same for iOS apps would be harder, since it is only possible to install from the official App Store. In order to install an unofficial version you would need an Apple developer certificate or a jailbroken device)

One could also install it from a third party, such as from https://f-droid.org repository (it doesn't seem to be there currently, but since the app is AGPL, it could be added¹). That moves the trust from "the developer build the published app from the given code" to the third party running the repository.

As mentioned by MadHatter, there is a trend for reproducible builds, which really helps trust issues (but is harder to achieve). Usually, different compilations of the same code will not result in the same binary, even when using the same version of libraries, compiler, target, etc. Often, there are changes such as timestamp or the order of files which result in slightly different resulting binaries. We talk about a reproducible build when different people reach to the same program. If you installed an app from source X and hash 9dfd069921782a66fe0b52eae6c20fa75e669cff, but the same program, built from the same code by other unrelated people also result in the same program with hash 9dfd069921782a66fe0b52eae6c20fa75e669cff, that strongly hints that the result of compiling that code is the given program (or a conspiracy between them!). That would even allow you to compile it post-facto and verify that the program you installed with hash 9dfd069921782a66fe0b52eae6c20fa75e669cff is the same you obtained when compiling it yourself a week later (although, if it didn't match, it might have already done its evil wrongdoings).

Even if you don't directly use an unofficial built, that they publish the code has two other benefits to take into account:

First of all, they are more incentivized to play fair. If their app sent home a copy of your contact list, by itself that would be bad. But if they claimed that the code is [1] and then modified the application to additionally send them a copy of your contact list that would be much worse. Not only would they be doing that (for which they might come up with a reasonable explanation) but also purposefully concealing their wrongdoing lying about the code!

Could they do that? Yes, technically they could. But also, the blowback (if found) could be devastating.

Second, the risk not only lies in the potential modifications added on the compilation step, but also in the original code itself. By opening their code, that for review by other people, they are more clear about what they it is doing (including potential bugs or unintended security issues). It still doesn't help if nobody reviews the code and finds them, but the theory is that, eventually, someone would hopefully find them. This should also make the developers a bit more aware when coding the app.

¹ At least in theory, it might have problematic dependencies.

  • 2
    For COVID contact tracing apps like the one linked in the question using unofficial builds/building yourself isn't possible since only government sanctioned apps are allowed to use the Exposure Notifications API. (Or at least the custom version will have that functionality disabled, which makes the app significantly less useful) Jan 16, 2021 at 18:40

Your guarantee is political, not technical. If a government publishes an app that collects some personal information in the background, nothing much will happen if that’s later revealed. But if a government publishes source code and claims it’s the code for their app, but it’s later revealed that the published app wasn’t based on that source code, it will be a scandal; heads will roll and people will be sacked.

  • 6
    Voting machines in the US often "innocently" use a different source code rev than the officially validated one. So far no heads have rolled.
    – arp
    Jan 17, 2021 at 14:56
  • 1
    @arp i'm assuming Mike Scott meant countries with governments that are held accountable Jan 18, 2021 at 17:54

In theory, the binary could be reverse-engineered and shown to implement the source code. Some "paranoid" people might actually try to do this.

Now my question is: is there any guarantee that the published app has been built starting from that source code?

Technically speaking, if you reorder two lines of code the compiler might still generate the same machine code, although I don't think that is really relevant to you.

Is this practical?

Reverse-engineering something is hard. But reverse engineering if you have the source code is much easier than reverse-engineering something without source. It becomes less practical the larger an application is, but...

Near-enough is good enough

Although it's hard to prove that a binary is built from some source, there are lots of easy ways to prove that a binary isn't generated from that source. For instance, if it calls into an operating system API that the source code doesn't, you immediately know something fishy is going on. If you run the app in a debugger and it does something "suspicious" you can restrict your analysis to the relevant part of the source code and determine whether the binary checks out. Maybe in a debugger you can see it uses certain APIs in the background at random times that it shouldn't, sends more data than expected (e.g. voice data), or connects to unusual domains.

And let's face it, if the app were passive listening, using your camera when it shouldn't, or recording how you use other apps, this would be pretty obvious to a security analyst monitoring the app. And for big-deal apps like this, I'm sure some people do.

  • For Android apps at least, reverse engineering without the source code is not that hard. JADX does a pretty good job of it. I reverse engineered my country's contact tracing app (which didn't have source code), as a fun Friday afternoon project, since my employer wanted to blog about it.
    – James_pic
    Jan 18, 2021 at 12:47

For the specific case of Immuni, note that a feature request for reproducible builds is open since last May (more or less when the app came out). Add your thumb-up to that page if you think that this is important, but for now it seems that the devs just don't care and there is not sufficient push from the public to ask for it.

Unfortunately, Italy is light years behind other countries such as Germany when it comes to public awareness of issues like this one.


If there is malware on it then it will one day become detected. If it becomes detected then you can only imagine what also happens to the company's reputation.

  • 2
    Some companies like Cisco, Juniper or RSAInc might had a big blow but they are still in Business...
    – eckes
    Jan 18, 2021 at 5:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.