3 ms·
It's not that scary if you actually bother doing binary analysis. Especially now with things like Godbolt. What made it as horrifying as it was at the time was
by salawat 4y ago
It's not that scary if you actually bother doing binary analysis. Especially now with things like Godbolt.
What made it as horrifying as it was at the time was the closed nature of compilers, and the increasing unfamiliarity with what actual machine code looked like, and the non-existence of tooling to help recerse actual runtime behavior.
Popping in a hidden 'hunter2' login handler is still going to require hiding/deriving/comparing against that state/hash/input on that machine. That extra cruft is going to stick out.
Whether anyone can be bothered to dig into it is another question. Theoretically speaking though, all computation is human reading or writing, just implemented with circuits.
- kragen 4y agoWell, something like seL4 with its proof of binary correctness could maybe solve the problem, unless the attacker manages to backdoor Coq too. But I think the situation now, relative to then, is precisely the opposite of what you state. The C compiler Thompson backdoored was distributed as source code under a fairly liberal (but non-transferable) license; its compiled form was only a few tens of thousands of instructions, including all the libraries it was linked with; the people it was distributed to were very familiar with the machine code; and single-stepping through machine code was a common way to debug problems. An old boss of mine had his first system administrator job about that time; his first task as a sysadmin, as I recall it, was to port a program written in assembly language to the operating system they were using. By comparison, today, many people use compilers they don't even have source code for; GCC and clang are tens of millions of instructions; many programmers even in C, C++, and other such low-level languages don't know assembly; most programmers work in high-level languages like Python, Java, or JS, and those have even less familiarity with assembly; and there are some eight orders of magnitude more useless computation being carried out in which such a backdoor could hide.
- salawat 4y agoIndeed. I'm one of the few who actually does dive into binary/asm on occasion, or at least try to decompile/reverse binaries for the lulz. These days you probably could sneak something in with a good chance of getting away with it for a while with the complexity explosion and volume of code to go through. That doesn't mean it isn't unrecoverable from though, even if every compiler is infected. It's just painful is all.
- kragen 4y agoMaybe. We're talking about a hypothetical power struggle, one aspect of which is that one group subverts the computing resource of another group. Even if at some point the second group realizes this has happened (potentially difficult when not only their decompilation tools but also their intragroup communications are subject to interception and alteration by the first group) there's no guarantee that they will ever regain control of those resources. The first group may be able to leverage their control enough to severely impact the second group's prospects in every aspect of the struggle. More generally, when groups of people are engaged in a power struggle, there's no guarantee that things will return to the status quo ante.
- intelVISA 4y agoML tooling is hopefully easing some of the tedium of manual binary analysis. Basic asm/REing is still CS101 in most civilized places
- salawat 4y agoDefinitely did not touch on the linking toolchain in the CS101 I did. I ended up having to figure that out the hard way through Linux From Scratch builds and cobbling together weird symbol resolution environments based on wanting to do things in my own idiosyncratic way. Ghidra helps a lot these days. ldd and the other linker/binutils do the rest.