I have gone through ken thompson's compiler hack paper, can't we just go through the complier's source code and check for any backdoor, what was the article's point?


Can we be sure that there are no backdoor's if we check the latest language's source code like python or php?

  • 1
    Cross-posted: security.stackexchange.com/q/203048/71850
    – Glorfindel
    Feb 6, 2019 at 10:38
  • From the left side of page 763 of your link: "We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere."
    – 8bittree
    Feb 7, 2019 at 16:53

3 Answers 3


No. The source code is not usable since it cannot be executed, only machine code can be executed. And to transform it into a binary you need a compiler. But you have no assurance that the compiler you are using to make that binary does, in fact, make a faithful job of the transformation.

To guard against the Thompson hack you have to bootstrap your own compiler, starting with a small program that you wrote yourself and progressively making it more powerful while maintaining accountability. The point of Thompson's paper is that proving a compiler is trustworthy is as much effort as creating it in the first place.

  • So also no matter how many powerful languages would come up in future none of them is completely trustworthy? Feb 6, 2019 at 10:53
  • "To guard against the Thompson hack you have to bootstrap your own compiler, starting with a small program that you wrote yourself and progressively making it more powerful while maintaining accountability" – That won't help either. Thompson explains that the compiler is merely an example. The exact same trick can be applied to anything that stores, transmits, manipulates, transforms, or interprets executable code, such as the dynamic linker, the harddisk, the RAM, the memory bus, the CPU, … Feb 6, 2019 at 11:25
  • 5
    @user9355495: The point of the paper is to be a thought experiment, not a real "attack". It isn't really talking about programming languages, but rather the point is that no, you can't 100% trust anything on a computer. You have no way of proving that your 100% known perfectly good banking app, when run on your phone, doesn't trigger a hardware module designed to use the app to steal your money. It's not talking about real-world threat vectors, it's describing possible vectors which may or may not exist. Compilers are merely a good example of the deceptive complexity involved.
    – Phoshi
    Feb 6, 2019 at 12:23

The point is that there is no back door in your source code because the compiler that you use to compile that code has been tweaked to add it into the binary it produces any time it detects that it is compiling a compiler or compiling login. To catch this you need to be looking at the object code not the source (And assuming that your tools for looking at object code have not themselves been compiled with a compiler that adds code to hide things from you!).

Once a compiler has been compromised, nothing it compiles can be trusted, including compilers that it compiles (even if their own source is clean) because the compromised compiler compiling the clean compiler can be making the clean compiler compromised while it is compiling the compiler....


If you had access to the source code for the full tool chain, viewing that source would indeed be sufficient. The thing is, that is a nigh impossible task decades after the fact. Note that decades after the fact refers not to today, but when the article was written. Assemblers were already a thing, and an assembler is nothing more than a simple compiler.

If you want to be sure that your compiler hasn’t been hacked, you need to write it in binary. And you need to do that for your entire tool chain — perhaps it wasn’t the compiler that was hacked, but the disk driver or editor. Perhaps it was the file copier. At some point you either have to trust your tools, or start from scratch with bare metal. Today’s CPU’s are sophisticated enough that you could hide such a hack in them without difficulty.

Think of the recent Intel chip vulnerability (meltdown, spectre) or the alleged Bloomberg China chip attack.

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