Re: Windows is 100% self-modifying assembly code? (Interesting security theory)

[Valdis.Kletnieks () vt edu]

On Thu, 09 Dec 2010 20:39:21 EST, John Jester Wilham Patrick III said:

(What the heck. It's Friday, and I've got this 50 pound bag of Purina Troll Chow
I'm trying to get rid of.. ;)

> Windows is written in pure, self-modifying assembly code. Notice how you
> can install 15 gigs of data from a single Windows install DVD, which can
> only hold 5 gigs?

Nope, that's just because files are compressed on the DVD.

> This is because the code is dynamically generated to minimize attack vectors.
> Any attempt to observe the static files on the disk will change how it looks
> in runtime. This is also why Windows needs to be updated so often, so the
> running code never looks like it did before.

Note that loading a program is *also* an attempt to observe the static file on
the disk - which would imply that how it looks in memory would depend on
how many times the program gets run.  Of course, hooking up a debugger
to the program, and noticing that the debugger disassembles it the same
way each time, would dispel the "dynamic self-modifying" theory.

Also, if it was dynamic self-modifying, you wouldn't need to do updates so the
running code looks different - each run would do that by itself.   However,
shipping patches to install on machines when you can't predict what the
current version of the self-modifying code looks like would be a bear.

> Maybe all applications with Windows compile on runtime for dynamic binaries,
> yet through .net's open, user-friendly API are still compatible?

This would come as a big shock to all those 3rd-party application programmers
who thought they were using a compiler that generated code that stayed put,
even when they looked at it in their debugger.  Unless you're suggesting that
all the 3rd party programmers are in on the conspiracy?  That would be right up
there with NASA managing to keep quiet all 400,000 people involved in faking
the moon landing.

> Balmer said he wanted to make Vista and 7 an OS that would not slow down
> after usage, but instead speed up. Windows is constantly reprogramming itself
> to suit the behavior of it's users and performing security and performance
> auditing.

This doesn't require self-modifying code.  It only requires some performance
tuning code that's able to do some introspection.  For instance, if you keep
track of what files are used, and how often, and which files are used together,
you can use that information to do a better job of defragmenting the disk - one
user may have Microsoft Word moved to the fastest part of the disk because
that's their most-used app, while somebody else gets a disk optimized for
Outlook and Firefox.
 
> All viruses are just malicious scripts.

Only true if you consider binary code a "script" (cue outcries about microcoded
CPUs in 5..4..3.. ;)

> No one ever has ever had an attack vector against Windows 7 or Vista.

There have been security advisories and patches against both Vista and 7.
You don't seriously suggest that *none* of those patches had a weaponized
exploit for them, do you?  (Remember the *vast* difference between "No one
has ever..." and "I have heard no reports of anybody ever...")

Attachment: _bin
Description:

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/