Do proprietary compilers inject botnets into our binarys at compile time? I mean you can analyze small ones but not bigger ones. Imagine every .exe is a botnet and big companys like antivir actually ship botnets instead of antiviruses.
Just think about it
Java could be botnet free due to its easy decompilation
But compilers like msvc could produce botnet binarys every minute worldwide
>>51505571
of course. the intel and msvc compilers insert weaknesses to all crypto graphic functions so while they appear secure in design and implementation actual binaries produced can be backdoored easily. this is why truecrypt had a successful audit but the NSA can still break into truecrypt containers if needed as it was compiled with MSVC
>>51505571
GCC could be a botnet
JUST
>>51505660
https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html
>The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect.
>>51505664
>probably the most used FOSS compiler, audited frequently
>botnet
>>51505691
/thread
>>51505571
No need, since every relevant computer runs X86.
You lost the day Intel ME/AMD PSP was introduced.
>>51506282
lol wut
it's never been audited and it's mostly abandonware at this point
>>51505691
The interesting implication of this is that even FOSS software is theoretically not safe.
You could take it even further and say if you did not create your system from the hardware up you can't be 100% sure the software you run is not secretly malicious.
>>51506357
Wat?
>>51505691
wasnt that basically what i said tho? you cant trust anything as it is possible to exploit it all the way up the chain
>>51506282
even if you compile it from source yourself you could still be using a backdoor'd compiler to compile your compiler so any programs you compile with that backdoor'd compiler will also be backdoor'd without you even knowing.
>>51508749
And any disassembler could be botnet, too not showing the botnet code
>>51506357
THIS
exaxly this intel ME and all that closed ring -1 -2 -3 undocumented bullshit is scary.
We need openhardware and i hope arm will provide this
>>51511360
Providing source that intel me can disable itself use network without knowing of kernel and execute
http://www.slideshare.net/mobile/codeblue_jp/igor-skochinsky-enpub
>>51508749
Then use a language that has a self hosted compiler. Write up a compiler and use it to compile itself and you will know the code is good.
>>51511757
even self hosted would still be compromised by this kind of attack. unless you go back to writing directly in machine code but even then you cannot be sure the CPU isn't doing something dodgy. basically with modern CPUs with all their secret blobs for "management" it makes it impossible to develop anything you can truly trust
Kek, you really think antivirus software is built in Visual Studio?
>>51512631
The latest versions of NOD32 and Kaspersky are compiled with VS2013. So year?
