Talk:Backdoor (computing)

message: I removed a paragraph from the article, after reading through the cited paper and rewriting the paragraph for clarity. Here's my clarified version:
:The paper Countering Trusting Trust through Diverse Double-CompilingACSAC (www.acsac.org): Countering Trusting Trust through Diverse Double-Compiling points out that it is possible to verify that an untrusted compiler is free of Trusting Trust exploits, if the attacker has access to both the source code of the untrusted compiler, and the machine code of a trusted compiler or cross-compiler. (The trusted compiler need not have any relationship to the untrusted compiler; for example, it might produce less efficient code, or code for a different platform.)
At first glance, this attack seems worthless — if I have a trusted compiler, why am I bothering with the untrusted compiler?
But at second glance, things look up — perhaps the untrusted compiler is much better than the trusted one, and we'd prefer to use it, if only we could prove it was trustworthy. (So I added that last parenthetical sentence to the paragraph.) All we have to do, according to the cited paper, is compile the untrusted compiler's source with our trusted compiler, giving C = UT, and then compare the given binary UU to UC (since U and C should be functionally equivalent). If the binaries match, then UU is trustworthy; otherwise, we can't say anything one way or the other. (For example, real-world compilers usually add filesystem-dependent debugging information or timestamps to their output, so they wouldn't be considered trustworthy by this approach.)
Okay, but look again! At third glance, we realize that our "diverse double-compiling" approach involves the production of UC, which is a version of the untrusted compiler compiled from trusted source code using a trusted compiler. (In fact, it's supposed to be bit-for-bit identical to the original compiler!) So at this point, why are we bothering with UU at all? (And remember, we have no reason to think that our untrusted compiler really is UU at all — it might be UW, and again that's usually true for real-world compilers.)
So after all that doubletalk about "diverse double-compiling", what we've come away with is this:
:If you compile trusted source code with a trusted compiler, then you can trust the binary.
Well, of course you can (modulo Thompson's caveat about compromised loaders)! We don't need a thirteen-page PDF to tell us that! --Quuxplusone 08:48, 16 February 2007 (UTC)
thread_title: Dumbness

message: You're right about one thing: Why bother with UU at all, if you have the source for U and expect it to compile properly on T?
This approach would be useful for testing whether you have an existing binary compiler which may or may not be compromised, and want to find out if it has been. In other words, it's rootkit detection. It makes no sense, however, if you can simply compile UT out of the box, and then compile UUT (should read U sub U sub T, but UUT doesn't seem to get along with Wikimedia, or perhaps even HTML) -- after all, presumably U produces better binaries somehow, so why wouldn't you make the compiler itself "better"?
But therein lies the problem: Why bother with U at all, unless it somehow produces better binaries? If it does produce better binaries, those better binaries will be different, anyway, so the whole test is pointless anytime you'd want to use it. I suppose one compile might have better error reporting, or it might operate faster, but how often do we see changes like that happen to modern compilers, versus optimization?
After all, if you're using a compiler and a compiled language, chances are you don't care much how good your compiler or language are, other than how fast your program will run after it's compiled.
--(This section will be signed when I bother getting an account. Feel free to butcher at will, haven't touched "Dumbness" as I don't have a clue about the right way to do this...) —The preceding unsigned comment was added by 63.162.81.179 (talk) 12:08, 12 March 2007 (UTC)
thread_title: Confusion about Dumbness

message: What about writing a few words about Intel plans to "improve" Centrino Pro platform? Here are a few of the (some already implemented?) features (source):
*- NIC based TCP/IP filters configurable remotely
*- Handy magic bypass for TCP/IP filters
*- Remote BIOS updates over the network
*- Remote IDE redirection, as in boot off CDROM over the network
*- Persistent storage even if you change hard disks
*- Authentication can be done on Kerberos. 
*- Built in web interface on every machine (port 16994)
*- handy well documented SDK for building whatever you need to interact with this
Gaz v pol 15:13, 12 June 2007 (UTC)
thread_title:  Intel plans (remote KVM improvement) 

message: Instead of removing the hard disk physically, it's easier to write your own dissasembler. Compile it with the infected compiler, it won't recognize it as "the" dissasembler it was taught to infect. If nobody points out a flaw in my reasoning, I'll remove that last part about removing the hard disk. --euyyn (talk) 00:25, 8 February 2008 (UTC)
replies: text: to eliminate hardware backdoor possibility one have to control entire system life-cycle including own silicone foundry. Some remedies: use some old stuff, programmable ics, log everything in statu nascendi, program inhi^ AC.  — Preceding unsigned comment added by 99.90.197.87 (talk) 02:55, 16 May 2012 (UTC)
thread_title:  Excess 

message: easier lit:   — Preceding unsigned comment added by 99.90.197.87 (talk) 20:13, 25 May 2012 (UTC)
thread_title:  hard bd 

message: Induc was actually discovered by the Delphi programmer.
This blog post (in Russian) was written on August 12, and the article on the Sophos website for 6 days later  — Preceding unsigned comment added by 159.224.121.67 (talk) 13:57, 11 December 2012 (UTC)
thread_title:  W32/Induc-A 

message: I've already started one discussion about this and now I'm starting a second.  For some strange reason, people are adding content to the article which has nothing to do with the article's topic.  Case in point: "South African police team fly to Apple HQ to crack Oscar Pistorius iPhone code."  Nowhere in the cited reference does it say anything about backdoors.  Second case in point: Apple's goto fail bug.  The first two references don't even mention anything about backdoors and the third-reference does but calls it a "nefarious conspiracy", yet our article describes it as if it were a fact.  It's not.  We should not be going around spreading conspiracy nonsense as if it were fact.  A Quest For Knowledge (talk) 11:03, 31 March 2014 (UTC)
replies: text: Thanks for describing your position.  I've had some experience elsewhere on wiki about similar difficulties.  Your position can roughly be summarised as "if the source doesn't use the word 'X', we cannot post that reference under topic 'X'."  Mine is admittedly a broader view, because not every writer on the planet describes 'X' under those terms.  English is a more fluid language than French or other languages that have 'official' dictionaries and people who are trained to look after the lexicon.  So in my view, a writer who is unconcious of the finer points of wikipedian discussion of 'X' may describe his subject as 'A', especially if s/he uses the English as second language.  The Samsung backdoor is a useful case in point.  If that does not explain what wikipedia considers to be a 'backdoor', what is the use of wikipedia?  I challenge you to find a more appropriate term than 'backdoor' in the case of Samsung. 69.60.247.253 (talk) 16:53, 31 March 2014 (UTC)
thread_title:  Off-topic content be in the article 

message: I downloaded Beast on my computer in safe mode with networking and so it dosen't find it's way into the system of my files. I on purposely hacked my brother's computer and he got really mad. How do i fix this?
*Description-
*Removal-
*Reading help content-
♣♠♣♦♦♥ ♠₮৳  — Preceding unsigned comment added by 2601:1:8801:B20E:80E3:40FE:CB2F:BE53 (talk) 21:15, 15 February 2015 (UTC)
thread_title:  Beast 2.07 Remote Administration Tool 

message: that's a lol since Mr Ed Snowden.    quote : "in high-security settings, where such attacks are a realistic concern."  — Preceding unsigned comment added by 91.60.132.129 (talk) 01:08, 19 February 2015 (UTC)
thread_title:  "of no concern"