Linux does not have the uniform, backward-compatible, robust binary compatibility that Windows has. This tends to complicate things both for virus/worm writers and ISVs trying to release binary builds of their software.
The target program may have been compiled with different gcc optimizations, or with -fomit-frame-pointer, which often rearranges things enough to foul up a stack-smashing exploit.
They may be using a different compiler, or a different version of gcc. That's enough to break library linkage on many programs.
They may be linking against different libraries, or the people building those libraries may have opted to have different code compiled in. The libraries probably aren't going to be laid out in the same places in memory at runtime. The kernel ABI may be different (the module loading mechanism, for example, has changed on the 2.6.x kernels). They may be on a different architecture.
They may or may not be running the target program as root. They may be running it in a chroot. Or perhaps a helper program the virus depends on may not be installed.
Individually, none of these are particularly difficult to get around. In fact, it likely won't stop a determined cracker from breaking into one particular system similar enough to one he can test his custom-crafted exploit against.
But collectively, they fragment Linux systems and their vulnerabilities into so many little special cases that the virus/worm writer may not find the platform as a whole to be a worthwhile target.
That demonstration is performed under some rather articial conditions. Note that:
The backdrop and the projection will line up only within a narrow viewing angle.
A camera and an external projector are needed in two different positions, something that may make it hard to fit onto stand-alone vehicles or moving people.
The projector adds light to a reflective surface: not useful when the backdrop is darker than ambient light reflecting off the subject.
Our colour vision is okay, but nowhere as sophisticated as good as our ability to perceive motion and changes in brightness and tone.
The projection system isn't likely to be able to superimpose such a consistent image that it can mask moving folds in clothing and angular bits on vehicle bodies.
Here's an enlightening snippet from Neal Stephenson's "In The Beginning, There Was The Command Line":
The file systems of Unix machines all have the same general structure.
On your flimsy operating systems, you can create directories (folders)
and give them names like Frodo or My Stuff and put them pretty much anywhere you like. But under Unix the highest level--the root--of the filesystem is always designated with the single character "/" and it always contains the same set of top-level directories:
and each of these directories typically has its own distinct structure of subdirectories. Note the obsessive use of abbreviations and avoidance of capital letters; this is a system invented by people to whom repetitive stress disorder is what black lung is to miners. Long names get worn down to three-letter nubbins, like stones smoothed by a river.
This is not the place to try to explain why each of the above directories exists, and what is contained in it. At first it all seems obscure; worse, it seems deliberately obscure. When I started using Linux I was accustomed to being able to create directories wherever I wanted and to give them whatever names struck my fancy. Under Unix you are free to do that, of course (you are free to do anything) but as you gain experience with the system you come to understand that the directories listed above were created for the best of reasons and that your life will be much easier if you follow along (within/home, by the way, you have pretty much unlimited freedom).
After this kind of thing has happened several hundred or thousand times, the hacker understands why Unix is the way it is, and agrees that it wouldn't be the same any other way.
Welcome to Unix! You are a lawful male human user. $ rm *.c~ You feel as though you're missing something. $ file * j1.au: An ornamental clip. rep12.doc: A pair of snow docs. hayw.pl: A fizzy file.
$ pkill -INT -f mozilla The magic missile hits the lizard! The lizard resists! The lizard hits! $ pkill -TERM -f mozilla The bolt of fire hits the lizard! The lizard resists! The lizard hits! User is about to die. $ pkill -KILL -f mozilla The death ray hits the lizard! The lizard is killed! Welcome to experience level 5. You gain some swap.
$ cat/dev/zero >/dev/mt0 & The cat catches a tape ration. $ sleep 60; jobs The cat is still eating. $ stty dec ^[0;1mOh wow! Everything looks so cosmic!^[0m^M$ sttu^Hty^H ^H^W sane^Mfg^M^C^C^C^K^[0;1mThe jumbo shrimp ululates! You hear the studio audience applaud!^0m^M^H^M$ stty sane^M Everything looks SO boring now. You see here a cat corpse.
$ mount/dos You mount your saddled dos. $ ls -d ~/wkfolder You see here a large boulder. $ cp ~/wkfolder/dos You try to pick up the boulder, but your dos cannot lift any more. $ umount/dos You can't. The saddle seems to be cursed. $ fuser -mk/dos You feel as though someone's helping you. $ umount/dos You dismount. You've been through the dungeon on a dos with no name.
$ halt Suddenly, the dungeon collapses! You die...
Slashdot Mirror
The target program may have been compiled with different gcc optimizations, or with -fomit-frame-pointer, which often rearranges things enough to foul up a stack-smashing exploit. They may be using a different compiler, or a different version of gcc. That's enough to break library linkage on many programs.
They may be linking against different libraries, or the people building those libraries may have opted to have different code compiled in. The libraries probably aren't going to be laid out in the same places in memory at runtime. The kernel ABI may be different (the module loading mechanism, for example, has changed on the 2.6.x kernels). They may be on a different architecture.
They may or may not be running the target program as root. They may be running it in a chroot. Or perhaps a helper program the virus depends on may not be installed.
Individually, none of these are particularly difficult to get around. In fact, it likely won't stop a determined cracker from breaking into one particular system similar enough to one he can test his custom-crafted exploit against.
But collectively, they fragment Linux systems and their vulnerabilities into so many little special cases that the virus/worm writer may not find the platform as a whole to be a worthwhile target.
"Honey, how'd you like your eggs?"
"Quake'd, please. And launch Emacs under the coffee pot, will you?"
It could be worse.
"Yes. Disney is infringing upon our trademark. And no, we can't show you the other ear."