
MS Windows Once Caused Second Life To Break An Inkjet Printer - Kroeler
http://nwn.blogs.com/nwn/2018/06/windows-second-life-yoz-linden-lab.html
======
corysama
There’s a fun story out there about software physically breaking a hard drive.
At the time, this was actually quite difficult for drivers to _avoid_ doing.
So, when a certain manufacturer came out with a drive it finally considered
safe against driver errors, it proclaimed a bounty for anyone who could prove
them wrong.

The winner put the drive on a table, connected with a cable, but not attached
to a case. Then he wrote a routine that slammed the read head to one side,
then slowly moved it back. Each time the routine looped, the drive would scoot
across the table until it finally fell off the edge.

~~~
prewett
That reminds me of the IBM "Black Team" QA group story where a guy writes a
perfect tape drive driver, formally verified and everything. The "Black Team"
was annoyed they couldn't find a problem with it, so they wrote a program to
spin the tape at the cabinet's resonant frequency, until the cabinet
eventually fell over.

[http://www.penzba.co.uk/GreybeardStories/TheBlackTeam.html](http://www.penzba.co.uk/GreybeardStories/TheBlackTeam.html)

~~~
m_samuel_l
That's a hardware issue.

------
bmurray7jhu
It is easy to "physically break" a thermal printer. Simply stop the servo
motor while continuing to provide the power to the printer element heater.
Your printer will soon catch fire. I've done it a few times myself while
writing printer drivers.

~~~
empath75
So you’re the guy:

[https://en.m.wikipedia.org/wiki/Lp0_on_fire](https://en.m.wikipedia.org/wiki/Lp0_on_fire)

~~~
vvanders
> In the event of a printing stall, and occasionally during normal operation,
> the fusing oven would heat paper to combustion. This fire risk was
> aggravated by the fact that if the printer continued to operate, it would
> essentially stoke the oven with fresh paper at high speed.

Ouch. Talk about failing open.

------
minikites
There's a fabulous article from Raymond Chen about EXE headers in general:
[https://blogs.msdn.microsoft.com/oldnewthing/20060130-00/?p=...](https://blogs.msdn.microsoft.com/oldnewthing/20060130-00/?p=32483)

>A Win32 executable file begins with a so-called "MZ" header, followed by a
so-called "PE" header. If the "PE" header cannot be found, then the loader
attempts to load the program as a Win16 executable file, which consists of an
"MZ" header followed by an "NE" header.

>If neither a "PE" nor an "NE" header can be found after the "MZ" header, then
the loader attempts to load the program as an MS-DOS relocatable executable.
If not even an "MZ" header can be found, then the loader attempt to load the
program as an MS-DOS non-relocatable executable (aka "COM format" since this
is the format of CP/M .COM files).

------
CurtHagenlocher
How exactly is this a bug in Win32? We can argue about whether or not this was
a good design choice, but it wasn’t Win32 that opened an HTTP connection,
wrote the response stream to disk and then executed the file without any kind
of validation.

~~~
Analemma_
Linden probably deserves the bulk of the blame, but it is a little weird that,
if Windows sees a file with an .exe extension that but no PE structure, it
will just happily take whatever bits it gets and run them directly. But I
guess if COM executables genuinely had no structure than there was nothing
else that could be done. Yet again, back-compatibility is Microsoft's savior
and curse at once.

~~~
danso
As much as I want to blame Windows for it, this seems like reasonable behavior
if the updater software is passing bytes straight from the HTTP stream.
Unfortunate that the 404 page happened to have a byte sequence that would be
interpreted as a COM, but the Updater should have been validating the
downloaded exe in the first place. Not just for 404 but for actual .exe files
that may be malicious

~~~
duskwuff
> Unfortunate that the 404 page happened to have a byte sequence that would be
> interpreted as a COM

That's the thing. _Any_ byte sequence which didn't have an EXE header was
interpreted as a COM executable. And in the (NT)VDM environment, there aren't
a lot of illegal operations, so executing random data (like an HTML error
page) can cause quite a bit of unpredictable behavior before it crashes or
gets caught in a loop.

------
tedunangst
If you run arbitrary code from the internet arbitrary things can happen.

~~~
ge0rg
This is also true for running arbitrary non-code.

~~~
giomasce
Most arbitrary data is actually valid x86 code.

~~~
Const-me
Random data is very likely to give you e.g. “invalid instruction” runtime
error when executing.

------
pkaye
Nothing quite as fun as piping a postscript to a printer in you college Unix
lab and watching garbage being spewed out. Meanwhile due to misconfigured
permissions, you cannot cancel the job. So you quietly shut of the printer and
walk out of the lab.

~~~
salgernon
I tried to teach myself postscript by writing directly to the new
laserprinters at school .. and was met the next day by a very angry grad
student sysadmin waving two reams of mostly postscript error pages. Something
about not being in his accounting budget since I was an undergrad annoyed him.
Fortunately, he decided that the only solution was to give me access to his
departments new Sun workstations running NeWS.

~~~
DonHopkins
You should have installed the PostScript error handler that prints up giant
posters of your error messages and stack dumps scaled and tiled across many
pages in a gargantuan font. Maybe they would have given you a really big
printer instead of a Sun running NeWS.

------
karmakaze
So disappointing. I was expecting a story about a bug in both 2nd life and
Windows that somehow caused an action in the virtual world to affect he host
one a la 13th floor. Maybe next time. [Please fix the title.]

------
joombaga
I'm curious what actually happened to physically break that printer.

~~~
tedunangst
Didn't you see the picture? It smashed itself to pieces!

~~~
_bxg1
That was a stock image...

~~~
ytwySXpMbS
That's the joke

------
cowboysauce
When I was 13 I wrote a C program that wrote random data to a file. I had the
idea to try executing these files. Most of them did nothing, but I remember
that one did end up causing the printer to print out pages of gibberish.

Years later I found myself wondering how that even worked in the first place.
Surely the chance of generating a valid executable was basically zero. Now I
know why.

I wish I had kept that executable, it would've been interesting to disassemble
it.

------
xvf22
We had 8086 IBM machines in our typing class. I remember writing a program to
send random bits to the big dot matrix printer. I'd keep a buffer and when the
printer did something strange I'd save the buffer and replay it till I
isolated the sequence. When a substitute would show up the printer would put
on a show ;)

------
jaclaz
Was it really necessary to add to the article the picture of a printer that
clearly had been smashed by a sledgehammer or fell from the third floor?

------
reaperducer
If true, we can add this to the infamous PET race condition as the second way
that software can physically break a computer setup.

~~~
rashkov
Can you provide a little more info? I'm find it difficult to come up with
sufficient search terms to look that up myself

~~~
pjc50
I think that's the "killer poke"
[http://www.6502.org/users/andre/petindex/poke/index.html](http://www.6502.org/users/andre/petindex/poke/index.html)

XF86Config used to come with similar dire warnings about not overdriving
monitors.

------
DonHopkins
At one point, HP2000's would crash if you tried to rewind the disk drive.

------
russdill
Where's the original tweet?

~~~
supermdguy
Looks like a slack screenshot

------
rasz
TLDR:

-lets eval() this random piece of bytes we got from non secure connection

-lets curl | sudo sh

